“Plan–Act、Test–Code、Doc–Code–Doc 是新工程时代的工程循环。”
延伸阅读：本章是对AI 的无状态性与 Context Window和Test–Code 循环：为什么测试代码比功能代码更重要在流程层面的综合应用。
本章把分散在对话中的工作流实践整理在一起，聚焦在三个循环：
Plan–Act、Test–Code、Doc–Code–Doc，以及它们在一个两人小团队里的真实落地方式。
1. Plan–Act：不要先看代码，而是先讲清楚问题
现实中的一个经验总结是这样的：
“我拿到东西之后，千万不要先去看代码，而是把需求跟 AI 描述清楚。”
一个典型的 Plan–Act 流程是：
- 先描述问题/需求，而不是直接打开 3000 行的大文件
- 让 AI 先尝试解决，观察它的执行过程
- 每一轮结束后，立刻验证结果，看是否真的解决了问题
- 同时关注 context 使用百分比，感知这个 AI 的思考逻辑跑到了哪里
如果两轮之后还没有解决：
- 让 AI 把自己的思考过程总结成一个文档
- 用这个总结文档作为“接力棒”，交给一个更强模型或一个新的 session
- 再在这个基础上继续搜索和尝试
当进入所谓“深水区”之后：
- AI 多轮尝试仍然没有解决
- 这时候就要开始人工读代码、手动修改
- 同时用 AI 之前生成的 debug logs 和文档作为辅助信息（详见Debugging：在深水区和 AI 一起查 bug）
2. Test–Code：用测试驱动 AI 的混沌产能
在 AI-native 的场景下，Test–Code 循环的本质是：
“用海量的 test case 去 cover 人脑 cover 不了的部分。”
这一点在Test–Code 循环：为什么测试代码比功能代码更重要章节已经详细展开，这里只强调和工作流相关的部分：
- 新需求开发时，尽可能让 AI 同时生成功能代码和测试代码
- 人类在 code review 中要把大部分精力放在测试代码上：
- 框架是否规范
- case 是否覆盖关键分支
- AI 有没有随意修改旧的测试
- 功能代码可以“大胆交给 AI 写”，但只能在测试网里大胆，在测试体系外要非常保守
在这种模式下，你可以接受：
- AI 的功能代码是“在混沌中写出来的”
- 但不能接受测试代码同样“在混沌中被随意改来改去”
3. Doc–Code–Doc：文档只记录“结果”，不记录“过程”
传统软件工程里，很多团队会如下操作：
- 写 PRD
- 再写 Tech Doc
- 再写执行记录
- 最后写代码，并且不断回填这些文档
在 AI 帮助下，这个模式有两个致命问题：
- 文档太多，人脑根本读不过来，很快就会失去对代码库的掌控力
- 文档和代码极难保持始终一致，一旦不同步，就会给 AI 输入大量矛盾信息
实践经验是：
- 把这一整套东西精简到：只有一类文档，文档和代码必须始终一致
- 不再区分 PRD 和 TDD，而是用一份“最简单的文档”承载高层设计和关键 Flow
- 文档的 scope 要刻意保持在高层：
- 全局架构
- 核心模块的职责
- 关键 flow（可以配图）
- 如果你想写一个比这个 scope 还低的文档，那它大概率就不应该存在
对于过程性的 plan、执行记录：
- 可以写，用来帮助当下这一轮 AI 工作
- 但在任务完成之后，要么删掉，要么只抽取其中的“结论性信息”合并到主文档
- 永远不要在代码库里保留“我们把 A 改成 B”这样的历史描述
这一点与AI 的无状态性与 Context Window中"删除所有 A，只保留 B"的原则是一致的。
4. 中高复杂度需求的标准工作流
把上面的经验综合起来，一个中等复杂度以上需求的标准工作流大致是：
Session 1：理解与计划
- 让 AI 多读全局性文档和相关代码