这是全书最核心的一章。无论你做什么项目，都可以用这套流程来组织工作。

3.1 为什么需要一套流程

假设你刚安装好 AI 编码工具，想试试它的能力。你输入：

"帮我做一个记事本应用。"

AI 开始生成代码。文件一个个创建，代码一行行输出。看起来很不错——界面美观，功能齐全。

但当你仔细看的时候，发现了问题：数据存在浏览器的 localStorage 里，但你原本想存在服务器上。使用的技术栈不是你团队在用的。有些代码看起来很复杂，但你只需要简单的功能。

这就是"没有流程"的后果。AI 很强大，但如果不对齐目标，它做出的东西可能完全不是你要的。

为什么？因为 AI 没有读心术，也没有"项目上下文"的概念。它不知道你的团队用什么技术栈，不知道你的数据要存在哪里，不知道你的项目要扩展到什么规模。它只能基于你给的那一句话，从训练数据中"猜"一个最可能的实现。而猜的结果，几乎一定不是你要的。

一套好的流程，能确保 AI 始终在正确的方向上工作。 它不限制 AI 的能力，而是把 AI 的能力引导到正确的方向。

3.2 六步工作法总览

六步工作法将一次 AI 编码任务分解为六个步骤，形成一个闭环：

① 拆解 → ② 下发指令 → ③ 编码 → ④ 验收 → ⑤ 分支判断 → ⑥ 更新图纸
                                                                 ↓
                                                           回到①（下一个里程碑）

每个步骤都有明确的目标和产出：

3.3 详细说明

第一步：拆解

做什么： 把你要实现的功能拆解成若干个小任务，每个任务称为一个"里程碑"。

为什么这一步如此重要？ 因为 AI 的上下文窗口是有限的。一个复杂的任务如果一次性交给 AI，它会在多个功能之间跳来跳去，导致代码耦合度高、错误难以定位。拆解的核心目的不是"把大事化小"，而是把风险隔离——每个里程碑独立完成、独立验收，即使某个里程碑出了问题，也不会影响其他部分。

好的拆解是什么样的？

以一个"记事本应用"为例，可以拆解为：

• 里程碑 1：创建项目脚手架（项目结构、配置文件）
• 里程碑 2：实现笔记列表页面（显示所有笔记）
• 里程碑 3：实现笔记编辑页面（创建和编辑笔记）
• 里程碑 4：实现笔记删除功能
• 里程碑 5：添加搜索功能

拆解的原则：

• 每个里程碑应在 2 到 30 分钟 内能完成。如果感觉需要半天，说明拆得不够细。
• 每个里程碑应可独立验收。做完后能立刻测试。
• 里程碑之间应有依赖顺序。先做基础功能，再做上层功能。

如何与 AI 协作：

帮我把"记事本应用"拆解成若干个可以独立实现的里程碑。
每个里程碑应该可以在 30 分钟内完成，做完后能立刻测试。
列出依赖顺序。

第二步：下发指令

做什么： 针对当前要做的里程碑，向 AI 下达明确的指令。

为什么指令质量如此重要？ 因为 AI 的编码质量直接取决于指令的清晰度。模糊的指令（"实现用户登录"）让 AI 去猜，猜的结果几乎一定不是你要的。精确的指令（"实现用户登录，验收标准：密码用 bcrypt 比对、JWT 有效期 2 小时、错误返回统一格式"）让 AI 写出的代码能精确覆盖你的预期。验收驱动开发的核心就是"先定验收标准，再让 AI 出码"——验收标准本身就是最好的指令。

好的指令包含什么？

我们要实现里程碑 2：笔记列表页面。

需求：
- 显示所有笔记的标题和更新时间
- 按更新时间倒序排列
- 点击笔记进入编辑页面
- 支持分页，每页 10 条

技术约束：
- 使用 Next.js App Router
- 数据通过 API 接口获取（接口已在里程碑 1 中实现）
- 使用 Tailwind CSS 做样式

验收标准：
- 页面能正常加载并显示笔记列表
- 分页功能正常
- 点击笔记能跳转到编辑页面

指令的四个要素：

1. 要做什么——当前里程碑的目标。
2. 需求细节——功能的具体要求。
3. 技术约束——必须遵守的技术约定。
4. 验收标准——如何判断任务已完成。

第三步：编码

做什么： AI 根据你的指令生成代码。你在这个步骤中观察 AI 的工作，但不干预。

这个阶段你要做什么：

• 观察 AI 生成的文件是否符合预期。
• 如果 AI 理解了偏差，在它完成当前文件后指出。
• 不要打断 AI 的编码过程去修改细节——等验收阶段集中处理。

常见问题

AI 写的代码用了我没听说过的库怎么办？

先记下来，在验收阶段评估。如果这个库满足需求且不带来额外负担，可以接受。

AI 写了超出当前里程碑的代码怎么办？

温和地提醒它："这个功能在后面的里程碑中实现，先完成当前的任务。"

第四步：验收

做什么： 检查 AI 生成的代码是否符合要求。这是六步中最容易被跳过、但也最重要的一步。

为什么验收不可跳过？ 因为 AI 生成的代码从语法上看几乎总是正确的——它是一个概率模型，生成的每一个 Token 都是"在当前上下文中概率最高的那个"。这意味着它的代码看起来"对"，但逻辑错误、边界情况、安全隐患不是一眼能看出来的。验收不是不信任，而是工程的基本规范——就像你不会不检查就签收快递。

验收检查清单

1. 功能检查——功能是否按验收标准实现了？
2. 代码检查——代码风格是否一致？有没有明显的质量问题？
3. 边界检查——有没有处理异常情况（空数据、错误输入等）？
4. 安全检查——有没有明显安全问题（如 SQL 注入、XSS 等）？
5. 蓝图检查——代码是否符合项目架构的约定？

如何验收

你可以自己看代码，也可以让 AI 帮你检查。一个有效的方法是让 AI 做自检：

验收当前里程碑的代码。检查：
1. 功能是否全部实现
2. 代码质量是否合格
3. 边界情况是否处理
4. 是否存在安全隐患
5. 是否符合项目架构

第五步：分支判断

做什么： 根据验收结论决定下一步。

为什么 REBUILD 比 NEEDS_FIX 更重要？ 很多新手看到 REBUILD 会犹豫——"好不容易写了这么多，回滚了不就白做了？"但事实上，AI 写代码的成本接近于零，而人类审查代码的成本非常高。如果 AI 在错误的思路上走了 30 分钟，产生了 200 行代码，修复这些代码可能需要 3 轮对话（每轮 5 分钟，共 15 分钟），而且修复后的代码质量通常低于重写。如果选择重建——回滚到上一个干净的 commit，重新下发更精确的指令——AI 只需要 1 轮对话（5 分钟），而且生成的代码质量更高，因为上下文是干净的。

验收后有三种结论：

PASS：代码符合要求

• 行动：提交代码到 git，进入下一个里程碑。
• 提交信息示例：feat: 实现笔记列表页面

NEEDS_FIX：有小问题需要修复

• 行动：向 AI 描述问题，让它修复，然后重新验收。
• 示例："列表页的分页按钮样式不对，应该用圆形按钮而不是方形。修复后重新验收。"

REBUILD：偏离蓝图太多

• 行动：回滚代码（git reset --hard），重新下发指令。
• 示例："这个实现用了我不熟悉的状态管理库，回滚后我用更简单的方案重做。"

判断标准

第六步：更新图纸

做什么： 如果在实现过程中有新的发现（比如发现了更好的技术方案、原来的设计有漏洞），把这些发现写进蓝图。

为什么要更新蓝图？ 蓝图是 AI 的"工作记忆"——每次对话重置后，AI 通过蓝图重建对项目的理解。如果蓝图过期了，AI 就会基于错误的信息做决策。所以蓝图不是一次性的文档，而是持续更新的活文档。

什么时候更新蓝图：

• 发现了更好的技术方案。
• 原来的设计有遗漏或错误。
• 新增了之前没考虑到的需求。
• 某个里程碑的拆分方式需要调整。

3.4 一个完整的例子

让我们用一个完整的例子来演示六步工作法。

场景： 给笔记列表页添加分页功能。

第一步：拆解

这是一个小功能，不需要进一步拆解。整个功能就是一个里程碑。

第二步：下发指令

在当前笔记列表页添加分页功能。

需求：
- 每页显示 10 条笔记
- 页面底部显示分页控件（上一页、下一页、页码）
- 切换页面时不需要刷新整个页面

技术约束：
- 后端 API 已支持 page 和 size 参数
- 使用现有的 UI 组件库
- 分页组件放在页面底部

验收标准：
- 分页控件正常显示
- 点击页码能正确切换
- 第一页时"上一页"按钮禁用
- 最后一页时"下一页"按钮禁用
- 总页数正确显示

第三步：编码

AI 生成了分页组件和相关逻辑。你观察到它使用了项目中的现有组件。

第四步：验收

你检查发现分页功能正常，但"第一页时上一页按钮禁用"这个边界情况没有处理。

第五步：分支判断

结论是 NEEDS_FIX。你告诉 AI 修复这个边界情况。AI 修复后重新验收，通过。结论变为 PASS。

第六步：更新图纸

你发现了一个之前没考虑到的情况：当笔记数量很少（比如只有 3 条）时，分页控件不应显示。把这个发现更新到蓝图中。

然后进入下一个里程碑。

3.5 三条纪律

在六步工作法之上，还有三条贯穿始终的纪律。违反任何一条，都可能导致项目失控。

纪律一：没有蓝图不开工

不要在没有架构设计的情况下直接让 AI 写代码。为什么？因为 AI 没有长期记忆——每次对话，它看到的是一张白纸。如果你不给它蓝图，它就只能"猜"——猜技术栈、猜命名风格、猜数据结构。而"猜"在工程中是最昂贵的，因为不同对话中的猜测结果不同。你今天让 AI 做用户管理，它猜了一个命名风格；明天让 AI 做订单管理，它猜了另一个命名风格——两个模块的数据模型冲突了。

这五分钟的设计，能帮你省下后面五小时的返工。

纪律二：没有验收不固化

不要在没有验收的情况下提交 AI 生成的代码。为什么？因为 AI 存在"自洽陷阱"——它生成的代码看起来"对"，但可能逻辑错误、边界缺失、安全漏洞。功能测试只会检查"注册成功"，不会检查"密码是否加密"。如果提交了未验收的代码，这些隐藏的问题就被固化成了代码库的一部分。

一个简单的验收方法：让 AI 自己检查一遍自己的代码，然后你再确认。

纪律三：逢混乱必重建

如果你发现 AI 的代码偏离蓝图太远，或者在修修补补中变得越来越乱，果断回滚重来。为什么？因为修复成本可能高于重建成本。AI 写代码的成本接近于零，但人类审查代码的成本非常高。在混乱代码上修复一个 bug 可能要花两小时，而回滚重建只需要十分钟，而且生成的代码质量更高。

回滚不可耻，在错误的基础上修修补补才可耻。

本章小结

六步工作法是 AI 编码的核心流程，但它不是一个"必须严格遵守的模板"，而是一种思维方式。每一步背后的推演——拆解是为了风险隔离、下发指令是为了验收驱动、验收是为了对抗自洽陷阱、分支判断是为了平衡修复与重建的成本、更新图纸是为了保持 AI 的工作记忆准确——这些比记住六个步骤更重要。三条纪律（没有蓝图不开工、没有验收不固化、逢混乱必重建）是底线，不是建议。下一章，我们用一个完整的项目来实践六步工作法。