祝融说。

7.1 为什么需要一套流程

假设你刚安装好 AI 编码工具，想试试它的能力。你输入："帮我做一个记事本应用。"

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

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

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

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

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

从第二部分的"心智跃迁"到这里，方法论开始落地。六步工作法，就是这条引导 AI 的核心轨道。

7.2 六步总览：拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸

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

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

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

7.3 每一步的详细拆解与产出物

第一步：拆解。

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

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

好的拆解是什么样的？以一个"记事本应用"为例，可以拆解为：

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

拆解的原则：

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

如何与 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 生成的代码是否符合要求。这是六步中最容易被跳过、但也最重要的一步。

为什么验收不可跳过？因为流畅、像样的生成并不能证明逻辑正确。模型依据上下文预测 token 分布；只有贪心解码每步取最高概率 token，采样则从分布中选择（见 Transformers 生成策略）。所以它的代码可能看起来"对"，但逻辑错误、边界情况、安全隐患不是一眼能看出来的。验收不是不信任，而是工程的基本规范——就像你不会不检查就签收快递。本章的验收对象是代码；当里程碑的变更影响模型行为（提示词、模型、采样参数、上下文）时，代码检查接不住模型输出的质量——模型输出质量的评估见第 23 章。

验收检查清单：

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

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

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

第五步：分支判断。

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

验收后有三种结论：

• PASS：代码符合要求。行动：提交代码到 git，进入下一个里程碑。提交信息示例：feat: 实现笔记列表页面。
• NEEDS_FIX：有小问题需要修复。行动：向 AI 描述问题，让它修复，然后重新验收。示例："列表页的分页按钮样式不对，应该用圆形按钮而不是方形。修复后重新验收。"
• REBUILD：偏离蓝图太多。行动：按第 10.4 节先区分个人未共享分支与共享提交、保存需要保留的工作并核验目标，再选择安全恢复路径，随后重新下发指令。示例："这个实现用了我不熟悉的状态管理库；我会按已核验的恢复路径回到干净里程碑，再用更简单的方案重做。"

判断标准：

为什么 REBUILD 比 NEEDS_FIX 更重要？很多新手看到 REBUILD 会犹豫——“好不容易写了这么多，回滚了不就白做了？”但 AI 的生成成本与人的审查成本并不对称；第 7 章这里保留信号表供流程中速查，完整总成本计算与适用边界见第 7.5 节。

第六步：更新图纸。

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

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

什么时候更新蓝图：

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

7.4 一个完整示例：笔记应用的分页功能

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

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

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

第二步：下发指令。

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

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

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

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

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

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

第五步：分支判断。结论是 NEEDS_FIX。你告诉 AI 修复这个边界情况。AI 修复后重新验收，通过。结论变为 PASS。

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

然后进入下一个里程碑。

7.5 修补还是重建：把总成本算完整

下面是一组教学假设，不是客户实测或行业基准：当前失败仅限尚未发布的独立里程碑，已验收基础可恢复，需求与接口已明确；统一以人民币计价，人力暂按每小时 200 元折算。已经花掉的时间是沉没成本，两条路径都从此刻计算增量成本。

在这些假设下，重建少花 180 元，原因是减少了理解混乱逻辑的工作，绝非生成免费。应先列出必须保护的文件与状态，按第 10.4 节核验恢复路径，再决定；任何路径都必须支付审查与验证成本。

这个结论随条件改变：如果旧模块承载隐含业务规则、数据迁移或复杂外部状态，重建需要额外恢复、补齐用例和协调上线，其总成本可能反超修补。相反，一个已定位、边界清楚的缺陷往往适合 NEEDS_FIX。把不确定项及其上限写出来，不能为证明重建划算而省略保护已有工作、停机或验收开销。第 8 章把这笔账作为纪律依据，第 10 章负责落实恢复动作，均不另造第二套算例。

【实操】用六步工作法完成一个小功能

题目：为一个已有的用户列表页添加"按姓名搜索"功能，完整走一遍六步工作法。

引导（每步应该做什么）：

1. 拆解：评估这个功能能否作为一个独立里程碑（能——它不依赖其他未完成功能）。如果觉得它太大，拆成"搜索 API 参数"+"搜索框 UI"+"结果实时刷新"三个子任务。
2. 下发指令：写出包含四要素的指令——目标（添加搜索功能）、需求（输入关键词按姓名模糊搜索、实时刷新）、技术约束（后端 API 已支持 search 参数、使用现有组件库、防抖 300ms）、验收标准（输入关键词能正确筛选、无结果时显示空状态、清除搜索恢复完整列表）。
3. 编码：让 AI 执行，只观察不打断。
4. 验收：用五维清单检查（功能/代码/边界/安全/蓝图）。特别注意边界——搜索关键词为空、只匹配到一条、包含特殊字符时是否正常。
5. 分支判断：验收 PASS 则提交（feat: 用户列表支持按姓名搜索）；NEEDS_FIX 则修复后重新验收；REBUILD 则回滚重建。
6. 更新图纸：把搜索功能的 API 契约、防抖约定写进蓝图。

验收要点（供讲师/自评使用）：

• 学员的指令是否包含全部四个要素？
• 学员是否在编码阶段保持了"只观察"？
• 学员的验收是否覆盖了边界情况？
• 学员的分支判断是否果断、符合经济账？
• 学员是否在完成后更新了蓝图？