YinDeskAgent 与工作流
我在用的 AI 工作流：四段式主线、自主循环、以及贯穿其中的上下文工程
当模型能力够用之后，真正的杠杆在工作流：怎么拆任务、怎么验证结果、怎么让人只做该做的决策。这篇笔记是我正在用的完整体系，由三部分组成：一条四段式主线、一个可选的自主循环模式、以及贯穿两者的上下文工程。
主线：四段式工作流
业界 2025–2026 年逐渐收敛出的共识是 Specify → Plan → Implement → Review 四段式（AWS Kiro、GitHub Spec Kit 都是对它的工具化）。核心思想：不要拿一句话需求直接让 AI 写代码，先让每一段产出"下一阶段的输入"，人只在段与段的交界处做决策。
目标：把模糊的想法变成无歧义的规格，同时不写一行业务代码。
- 用 grill-with-docs（拷问式访谈）逼出需求的边角：它会不断追问直到方案里没有"看情况"
- 过程中用 domain-modeling 把敲定的术语写进
CONTEXT.md词汇表、把难逆转的决策落成 ADR——这些文件是后续所有阶段的共享上下文 - 产出：规格 + 词汇表 + ADR
人机分工一句话
人的时间花在"决定做什么"（Specify、Plan、验收），Agent 的时间花在"怎么做"（查代码、写实现、跑测试）。
可选模式：自主循环（Loop Engineering）
四段式是"人在线时"的主线。对于边界清晰、可自动验证的任务（批量重构、按清单跑任务），还有更激进的玩法：Ralph Wiggum 式自主循环——while(true) 地重启 agent，每轮带着同样的 PROMPT.md 和磁盘上的进度文件，直到任务清单清空。
它的成立依赖一个反直觉的事实：上下文窗口是消耗品，磁盘才是记忆。每轮 fresh context 反而避开了长对话的上下文腐化。
适用边界
自主循环只适合"验证标准可以被机器执行"的任务（测试、类型检查、lint 全绿）。凡是验收依赖人的判断的任务，循环只会高速生产错误答案。
上下文工程：贯穿两者的底层技术
无论哪条路线，都围绕三个动作展开：
- 状态落盘：规格、计划、进度、词汇表全部写成文件（
CONTEXT.md、PRD、issues、progress 文件），对话只是过程，文件才是资产——这也是任何一轮对话结束后都能无损续上的原因。 - 子代理隔离：大范围搜索、独立实验、跑测试这类"会产生大量中间垃圾"的任务，委托给子代理，主上下文只保留结论。
- 及时重启：长对话一定会腐化（错误的尝试、过时的信息不断累积）。完成任务或跑偏之后，开新会话靠文件恢复状态，比在旧会话里"挣扎着找回状态"便宜得多。
守护栏
AI 生成代码的比例越高，传统工程实践的价值越大——它们是人类可控的护栏：
- 测试：行为级测试是 agent 唯一不会自欺的验收标准
- 类型系统：TypeScript/类型注解让"改了 A 坏了 B"变成机器可发现的问题
- Lint / 格式化：把风格争议从人的 attention 里清除出去
- Git 小步提交：每个 issue 一个 PR，错了单独回滚，不牵连别人
通用原则
- 能验证的事情就别靠感觉：测试和类型是 Agent 最好的护栏
- 上下文是稀缺资源：一次对话只解决一类问题
- 先让 AI 复述任务并指出疑点，再让它动手——一分钟成本，省一轮返工
- 工具链（Kiro、Spec Kit、各种 skill）只是四段式的不同实现，理解了分段思想，换任何工具都一样用