AI 编码工作流：双层循环逐字稿

我设计并实际使用了一套双层循环的 AI 编码流程。外层用 PDCA 管任务：这次做什么、按什么顺序做、如何验收；内层负责把当前任务做出来：先读依据，再写代码，并通过工程检查校准和修正。

这套流程首先要解决的是“需求表达模糊不清”。如果只告诉 AI 做一个功能，它很容易用自己熟悉的方案补齐空白。所以，我预先通过建模和 API 设计，把 API 契约写成具体的测试断言。用具体的验收场景，约束 AI 最终的结果。

有了这些依据，外层再拆任务、安排成 DAG 任务顺序，并给每个任务写清修改范围和检查方法。

这样可以解决模型模型“上下文注意力不集中”的问题

进入内层以后，我先让 Agent 读取当前任务对应的规则、接口契约、相关代码和测试。这里同时处理“隐式约定”和“上下文倾倒”：模块边界、业务逻辑应该放在哪一层，不能只存在人的脑子里；但也不能把所有文档一次塞给 AI。我把基本约束放在项目入口，具体做法放在工程指南，当前任务的设计放在任务记录，执行时按需要读取。

这些规则也不会不断复制进 AGENTS.md。入口只保留基本约束和阅读路径，专业规则在对应指南或 Skill 里维护，变更时同步相关引用。这是在处理“指令文件腐化”，避免同一个要求出现好几个版本，越补说明反而越矛盾。

真正写代码时，我会让 Agent 一次处理一个行为，先根据业务规则编写并运行测试，再补实现、跑回归，最后在测试保护下整理代码。如果已有实现让测试直接通过，就核对它是否真正覆盖了要求。测试预期来自规则或已确认案例，而不是从刚写的代码反推。这针对的是“前馈痴迷”：出错以后，不能只追加一句“下次注意”，还要有测试或静态检查，能够在它再次写错时给出反馈。

检查阶段重点防的是“虚假胜利”。代码写完、测试文件生成，或者构建变绿，都不能直接当成任务完成。我会核对验收条件有没有逐条检查，记录实际执行的命令、退出码和观察结果。领域测试证明业务规则，接口测试证明请求和响应，持久化测试证明数据读写，各自不能替代。之后再分别审查代码是否符合工程规范，以及是否完整实现本次需求。缓存命中和上次的通过记录，也不会写成本轮刚运行的结果。

反馈多了以后，还会出现“反馈过载”：一堆日志里混着警告、环境错误和业务断言失败，AI 可能修了最显眼的警告，却漏掉真正的问题。所以我先看哪些信号影响当前验收。代码不符合明确预期，就修复重测；检查没有覆盖需求，就补检查；任务依赖变化，就回到外层调整计划；业务规则不明确，就暂停相关实现、先行澄清；环境缺依赖，就处理环境。成功保留简短结果，失败保留能定位到断言和条件的日志。

最后还要处理“信息散落”和“跨会话状态丢失”。业务规则和接口约定分别在对应文件中维护，任务状态、局部设计、检查结果和未决问题保存在任务记录里，不让聊天摘要和生成页面各自维护一套说法。新会话开始时，先看工作树，再核对当前来源和前置任务的结果是否仍然有效，然后继续。

所以，我做的不只是给 AI 一套提示词，而是把这些容易出错的地方变成具体步骤：开工前有依据，执行中有检查，失败后知道该修代码、改计划还是问业务，结束后能把结果交给下一次任务。外层保证任务有序推进，内层保证当前这一步得到验证。