AI 修复了一个 Bug。你没仔细看就提交了。一个月后，安全审计发现它"顺手"把加密库从 bcrypt 换成了 SHA256。

你让 AI 实现一个"用户注册功能"。你描述了需求，AI 写了代码，你测试了一下——注册成功，登录成功。你提交了代码，开始做下一个功能。

一周后，你发现注册功能有一个 Bug：当邮箱格式不对时，系统直接抛出了 500 错误，而不是返回友好的错误提示。你让 AI 修，它修好了——你看到了代码变更，看起来没问题。你又提交了。

一个月后，安全审计发现了一个漏洞：你的用户密码使用了不安全的哈希算法。你追查了所有代码变更，发现就是那个"邮箱格式 Bug 修复"的提交中，AI 不小心把密码加密从 bcrypt 换成了 SHA256。它不是故意的，它只是"顺便"改了那一行代码——因为它在修复 Bug 时，觉得"顺便优化一下密码加密"没什么问题。

你花了三天时间回溯所有变更，才找到这个"看似无害的修复"。这不是 AI 不靠谱，是你的流程不靠谱。你把"验收"简化成了"跑通一次就通过"，你把"修复"当成了"让 AI 直接改"。

4.1 从手动引导到自动执行

第一册的六步工作法是需要你手动参与的——你要每个步骤都确认，每个里程碑都验收。这在只有一个功能时没问题，但当你手上有 3 个、5 个功能要开发时，手动模式的效率瓶颈就出现了。

想一想六步流程中你需要做什么：拆解时要你确认方案是否合理、下发指令时要你写 Prompt、验收时要你亲自审查代码、分支判断时要你决定是提交还是重建、固化后还要你更新蓝图。每一步都在消耗你的注意力。而注意力和时间一样，是有限的。

自动工作流（Workflow） 的思路很简单：把"需要你判断"的步骤，变成"用规则判断"。验收标准是明确的（如"测试全部通过""没有架构偏移信号""代码行数没有异常增长"），所以分支判断可以用规则代替人工。下发指令是模板化的（从蓝图读取技术约束），所以不需要你每次手写。

• 自动拆解：把功能需求拆解为里程碑
• 自动编码：逐个里程碑执行
• 自动验收：每个里程碑完成后自动检查
• 自动分支判断：PASS 就继续，NEEDS_FIX 就修复，REBUILD 就重建
• 自动固化：验收通过后自动提交

4.2 结构里程碑——拆解的艺术

Workflow 的核心不是"自动编码"，而是"自动拆解"。编码是最简单的部分——AI 在这方面极其擅长。真正难的是把一个功能拆解成正确的粒度，让 AI 在每个粒度上都能独立工作、独立验证。

这就是结构里程碑要解决的问题。

在传统开发中，里程碑是"需求维度"的——完成了用户注册功能，就是一个里程碑。但在 AI 编码中，需求维度的里程碑太粗了。一个"用户注册功能"可能包含：数据库迁移、API 接口、参数校验、邮件发送、前端表单、错误处理。如果让 AI 一口气写完这 6 个部分再验收，你可能会发现 API 的返回格式和前端期望的不一致，数据库中的字段命名和后端代码的命名风格不同，邮件发送的配置写死了没有用环境变量。这时候要改，代价巨大——因为 6 个部分已经耦合在一起，改一个可能牵动五个。

结构里程碑的思路是：把一个"需求"拆成多个"可独立验证的工程节点"。每个节点是一个逻辑闭环——它可能不是一个"可用的功能"，但它是一个"可验证的模块"。

什么是"可验证"？就是你可以用一个脚本、一个测试用例或者一次手动调用，确认这个节点是对的。比如"用户数据模型的 Prisma schema 写完了"，你可以跑 npx prisma db push 来验证。比如"注册 API 的路由定义写完了"，你可以用 curl 发送一个请求，看它是否返回了正确的 201 状态码。

每个结构里程碑被验证通过后，通过 git commit 固化。固化的意思是：这个节点在未来的开发中，被视为不可修改的"地基"。下一个里程碑只能在这块地基上继续建，不能拆了地基重新建。

下面是一个正确的里程碑拆解和错误的里程碑拆解的对比：

错误的拆解（需求维度）：

里程碑 1：实现用户注册功能（包含数据库+API+前端+邮件）
→ AI 一口气写了 800 行代码
→ 验收发现架构偏移（前端直接调用了数据库）
→ git reset --hard，损失了所有 800 行代码

正确的拆解（工程维度）：

里程碑 1：用户数据模型的 Prisma schema（10 行代码，可独立验证）
里程碑 2：注册 API 路由和参数校验（30 行代码，可独立验证）
里程碑 3：密码加密和 JWT 签发逻辑（50 行代码，可独立验证）
里程碑 4：注册前端表单组件（80 行代码，可用 mock 数据验证）
里程碑 5：前端-后端集成（20 行代码，连接前后端）

如果某个里程碑的验收发现架构偏移，你只需要重建那个里程碑——最多损失 30 行代码，而不是 800 行。

结构里程碑还有一个重要的心理作用：它让"彻底重建"变得容易决策。如果 AI 写了 800 行代码后发现架构偏移，你的本能反应是"试着修复一下"——因为丢弃 800 行代码的沉没成本太高了。但如果 AI 只写了 30 行代码，你说"重建"几乎没有任何心理负担。而"轻松重建"恰恰是保持项目健康的纪律之一。

4.3 三步迭代循环

Workflow 的核心机制是三步迭代循环：

┌─────────────────────────────────────────────────┐
│              三步迭代循环                        │
│                                                  │
│  ① 下发指令 → ② 里程碑验收 → ③ 分支判断        │
│       │              │              │            │
│       └──────────────┴──────────────┘            │
│                        │                         │
│                  PASS → 进入下一个里程碑          │
│                  NEEDS_FIX → 修复后重新验收       │
│                  REBUILD → 回滚重建              │
└─────────────────────────────────────────────────┘

第一步：下发指令

Workflow 根据蓝图和需求描述，自动生成针对当前里程碑的指令。包含：

• 要做什么
• 技术约束（从蓝图读取）
• 验收标准

第二步：里程碑验收

AI 完成编码后，Workflow 自动调用验收机制检查：

• 功能是否实现？
• 是否偏离蓝图？
• 代码质量是否达标？
• 边界情况是否处理？

第三步：分支判断

根据验收结果，自动决定下一步：

• ✅ PASS → 提交代码，进入下一个里程碑
• ⚠️ NEEDS_FIX → 自动下发修复指令，修复后重新验收
• 🛑 REBUILD → 自动回滚，生成更精确的指令重新开始

4.4 验收驱动开发

在 Workflow 的流程中，有一个看似反直觉但极其重要的原则：先定验收标准，再让 AI 出码。

传统的开发流程是"先编码，后测试"——你写完代码，再写测试来验证。验收驱动开发把这个顺序反转了。在让 AI 写任何代码之前，你先告诉它"什么算完成"。

为什么顺序这么重要？因为验收标准对 AI 来说是一种"约束"。当 AI 知道"我的代码必须通过这 5 个测试才算完成"时，它的生成策略会从"写出看起来对的代码"变成"写出能通过这 5 个测试的代码"。后者远比前者可靠。

来看一个对比。

模糊指令：

"实现用户登录接口。"

AI 可能忽略密码加密、Token 过期、错误处理——它写了一个"能用"的登录接口，但你不确定它是否"安全可用"。

带验收标准的指令：

"实现用户登录接口。验收标准：

1. 密码必须用 bcrypt 哈希比对
2. 成功时返回 JWT，包含 user_id，有效期 2 小时
3. 失败时返回统一的 401 AppError
4. 连续 5 次失败锁定账号 30 分钟"

AI 生成的代码会精确覆盖这 4 条标准。因为验收标准是"硬约束"——AI 知道这些条目会被逐一检查。

验收驱动开发还有一个隐藏的好处：它让你在编码前就想清楚了"什么算完成"。很多时候，你在写验收标准的过程中就会发现需求中的模糊之处。比如写"用户登录接口"时，你可能会想：密码错误应该返回什么状态码？账号锁定后怎么解锁？这些问题的答案必须在编码前确定——如果你不确定，AI 就会替你确定，而它的选择不一定是你想要的。

4.5 三种模式

auto 模式的默认决策

如何选择模式

需求明确程度如何？
├─ 非常明确，没有歧义 → auto 或 silent
├─ 基本明确，但需要确认 → normal
└─ 比较模糊，需要探索 → 先用 Coach 手动走一遍

4.6 验收机制详解

Workflow 的验收机制是整个流程中最关键的部分。它不仅仅是"检查代码能否跑通"，而是三个维度的检查：

维度一：功能验收

检查代码是否实现了需求中描述的功能。

方法： 对比需求描述和实际代码。需求中说"支持分页"，代码中是否实现了分页参数和分页控件？

维度二：架构验收

检查代码是否偏离了蓝图约定的架构。

方法： 对比蓝图和实际代码。蓝图说"使用 Prisma ORM"，代码中是否用了 Prisma？蓝图说"API 放在 app/api/ 下"，代码中是否遵循了这个约定？

架构偏移的三种信号：

1. 篡改地基：修改了不该改的核心代码（如修改了数据库连接配置、认证中间件）
2. 过度设计：引入了不必要的复杂性（如添加了不需要的抽象层、设计模式）
3. 体积失控：单个文件无节制膨胀（超过 300 行）

维度三：安全验收

检查代码是否存在常见的安全漏洞。

检查清单：

• SQL 注入：参数是否经过正确转义或使用参数化查询？
• XSS：用户输入是否经过转义后输出？
• CSRF：是否有跨站请求伪造保护？
• 认证：敏感接口是否有权限检查？
• 数据暴露：API 是否返回了不应暴露的字段？

4.7 分支判断：PASS、NEEDS_FIX 与 REBUILD

三步迭代循环中的第三步——分支判断——是整个流程中最关键也最反直觉的环节。它有三个出口：PASS、NEEDS_FIX 和 REBUILD。

PASS 很好理解——验收通过，提交代码，进入下一个里程碑。

NEEDS_FIX 也很好理解——验收发现问题，AI 自动修复，重新验收。但这里有一个重要的限制：NEEDS_FIX 最多执行两次。如果修复了两次还是有问题，就自动升级为 REBUILD。

为什么要有这个限制？因为 AI 在"修复模式"下容易陷入"确认偏误"——它在错误的地基上不断打补丁，越修越乱。如果让它在同一个问题上反复尝试，你可能会得到一段"虽然通过了验收但引入了更多问题"的代码。

REBUILD 是最反直觉但最重要的分支。传统开发中，代码写错了，你修。但在 AI 编码中，"修"的成本可能高于"重写"。

原因很简单：AI 写代码的成本接近于零，但人类审查代码的成本非常高。如果 AI 在错误的思路上走了 30 分钟，产生了 200 行代码，你让 AI 修复这些代码——AI 可能需要 3 轮对话（每轮 5 分钟，共 15 分钟），而且修复后的代码质量通常低于重写。如果你选择 REBUILD——回滚到上一个干净的 commit，重新下发更精确的指令——AI 只需要 1 轮对话（5 分钟），而且生成的代码质量更高，因为上下文是干净的。

所以 REBUILD 的决策逻辑是： 当 AI 已经表现出"混乱"的迹象时（修复两次仍不过、修复引入了新问题、代码体积异常增长），立刻放弃当前工作，回滚重建。不要尝试"再修一次"。

4.8 上下文重置管理

Workflow 需要处理一个现实问题：AI 的对话上下文是有限的。

一个包含多个里程碑的功能，在实现过程中对话会不断增长。当对话变长后，AI 的表现会下降——它开始忘记之前的约定，忽略之前的代码。

Workflow 通过上下文重置来解决这个问题：

1. 每个里程碑完成后，记录当前状态
2. 重置上下文，清空对话历史
3. 在新的上下文中，重新加载蓝图和当前里程碑的指令
4. 继续执行

这就像工地上的交接班： 每个班次开始前，先看图纸和进度记录，然后开始工作。而不是靠上一个班次的人口头交代。

4.9 异常处理

Workflow 在执行过程中会遇到各种异常情况。以下是一些常见场景和处理方式：

场景一：验收反复不通过

一个里程碑验收了 3 次都 NEEDS_FIX，或者修复引入了新的问题。

处理方式： 自动升级为 REBUILD。回滚后重新生成指令，这次追加之前失败的经验。

场景二：AI 偏离了当前里程碑

AI 开始实现规划之外的代码（比如在做列表页时，突然开始写编辑功能）。

处理方式： 温和地提醒它回到当前里程碑。如果频繁发生，考虑需求描述是否不够清晰。

场景三：项目结构变更

AI 在实现过程中发现蓝图的设计有问题，需要修改。

处理方式： 暂停当前里程碑，先更新蓝图，然后重新开始。不要在错误的蓝图上继续编码。

本章小结

Workflow 的核心价值不是"自动编码"，而是"自动化的流程管控"。它把六步工作法中需要人工判断的环节替换为规则判断，实现了从需求描述到代码交付的全自动闭环。三个关键设计支撑了这个目标：结构里程碑（把功能拆成可独立验证的工程节点）、验收驱动开发（先定标准再编码）、分支判断的三种出口（PASS / NEEDS_FIX / REBUILD）。其中 REBUILD 是最反直觉但也最重要的纪律——当 AI 表现出混乱的迹象时，重建比修复更高效。下一章，我们将深入验收体系的设计——如何建立三层质量门禁。