【AI Native开发-07】AI 动手前的人类闸门：Spec 与 Plan 评审

摘要

SDD 的四道闸门里，Gate 1（Spec 评审）和 Gate 2（Plan 评审）是AI 动手改代码之前仅有的两次人类拦截机会。这一篇专门讲人的动作：什么时候介入、重点审什么、怎么在十分钟内看出一份 Spec / Plan 靠不靠谱。

核心论点：

1. 评审不是”再读一遍”，而是带着对抗性的检查。AI 产出的文档天然倾向于”看起来完整、自洽、可行”——因为它被训练成给出让人满意的答案。评审的任务是戳破这种表面完整。
2. 两次评审审的东西完全不同。Spec 评审问”我们是不是在做对的事”，Plan 评审问”这件事会不会以危险的方式做出来”。
3. 评审的 ROI 在阶段上是递减的。计划阶段的一句质疑，值实现后的一次回滚，值测试后的一轮排查，值上线后的一次事故。

本篇给出两份可直接使用的评审检查表、评审者的注意力分配建议、四种评审反模式，以及”哪些必须人审、哪些可以让 AI 先过一遍”的边界。

一个典型场景

“删除草稿文章”的 Plan 交上来了，写得很漂亮：现状事实、三张文件清单、实现步骤、测试计划、风险回滚一应俱全。你赶时间，扫了一眼”结构挺完整”，点了通过。

实现完、测试也绿了，上线。第二天有人反馈：删文章时，文章头图和附件文件没被删，成了孤儿文件，越积越多。

回头看 Plan，它在”Files to change”里写了删除 .md 文件，但从头到尾没有提过文章引用的图片资源怎么处理。Spec 里也没写——因为写 Spec 的人默认”删文章当然会连带删掉它的图”。这个”当然”，AI 不知道，Plan 没覆盖，评审也没问。

这不是 AI 的错，是评审的失职。评审本应在 Gate 1 或 Gate 2 问出那个问题：“删掉一篇文章，它引用的那些 /public/images/... 文件怎么办？” 这一句话，就能避免线上一堆孤儿文件。

评审的价值，就是在最便宜的阶段，逼出那些”大家都以为别人会想到”的空白。

核心问题：评审到底在审什么

很多人把评审理解成”检查有没有错别字、格式对不对”。这是对评审最大的误解。

在 AI Native 开发里，评审的本质是：用人类的业务判断和架构直觉，去补 AI 不可能自己发现的那类空白。

AI 能自己保证的：结构完整、格式规范、步骤有序、语言通顺。 AI 不能自己保证的：

• 业务规则有没有遗漏（它不知道你脑子里”删文章连带删图”的默认假设）；
• 方案和真实业务约束是否冲突（它不知道这个系统的管理员其实就一个人，不需要做角色体系）；
• 改动会不会破坏用户没说出来但一直在用的行为；
• 复杂度是不是没必要（它倾向于展示高级模式）；
• 风险是不是被轻描淡写了（它倾向于报告好消息）。

一句话：AI 负责把它知道的写全，人负责发现它不知道的那些东西根本没出现。

两次评审的分工

两次评审都不能省。Spec 评审没过就做 Plan，等于在错误的需求上规划；Plan 评审没过就写代码，等于用正确的需求走一条危险的路。

Gate 1：Spec 评审检查表

评审一份 Spec 时，按顺序过这张表。任何一条答”否”，都不该放行。

【可测性】
□ 每条业务规则都能想到一个对应的测试吗？
□ 有没有"尽量""适当""友好""体验好"这类无法验收的词？
□ 验收标准具体到"两个独立的人会得出相同结论"了吗？

【完备性】
□ 正常流程写全了吗？
□ 异常流程（失败、超时、并发、重复操作）写全了吗？
□ 权限边界（谁能做、谁不能做、服务端是否二次校验）写了吗？
□ 数据约束（字段、状态、级联关系——比如"文章的图怎么办"）写了吗？
□ 用 F1–F6 逐项扫过了吗？（状态假设/权限放行/一致性缺口/
  幂等缺失/验收坍缩/非目标越界）

【明确性】
□ 每个状态、角色、动作都有唯一定义吗？
□ 有没有一句话能被读出两种意思？
□ "草稿""已发布"这类词，和代码里的真实表达核对过吗？

【可追溯】
□ 每条规则有 REQ 编号吗？
□ 编号能被后面的 Plan / 测试引用吗？

【边界】
□ 非目标（明确不做什么）写了吗？
□ 有没有需求里没提、但 AI 很可能"贴心"加上的功能，被提前排除了？

评审 Spec 最有效的一个动作：对着每条规则问”如果不写这句，AI 会怎么做？” 如果答案是”它大概率会猜错”，这句就必须留着、并且要写得更明确。

Gate 2：Plan 评审检查表

【现状理解】
□ "现状事实清单"每条都有代码证据（文件:行号）吗？
□ 有没有"推测未验证"的条目还挂着？（有就该转 Spike）
□ AI 对架构的理解，和你的直觉一致吗？

【影响面】
□ 新增 / 修改 / 不碰 三张清单齐全吗？
□ "不碰清单"里，是否覆盖了所有"牵一发动全身"的地方？
□ 修改清单里有没有你没预期到的文件？（有就要追问为什么）
□ 有没有"顺手重构""顺便优化"的无主改动？

【方案选择】
□ 有没有引入不必要的框架 / 抽象 / 依赖？
□ 用最简单的做法行不行？问一句"不这么做会怎样"
□ 方案和现有代码风格、架构模式一致吗？

【需求映射】
□ 每个 REQ 都能在实现步骤里找到落点吗？
□ 有没有步骤不对应任何 REQ？（可能是越界加功能）

【测试】
□ 每条 REQ 都标了在哪一层测吗？
□ 权限、异常、副作用（不只是状态码）有断言吗？

【风险与回滚】
□ 不可逆操作（删除、支付、外发）有缓解措施吗？
□ 回滚方案具体、可操作吗？还是空话？
□ 环境差异（本地/生产、dev/构建）提到了吗？

Plan 评审最高效的一个动作：直接翻到”Files NOT to touch”和”Risks”两节。 这两节最能反映 AI 是真理解了系统，还是在套模板。如果”不碰清单”写得敷衍、风险写得轻描淡写，这份 Plan 基本不可信——因为它没认真想过”哪里会出事”。

评审者的注意力分配

评审时间有限，不要平均用力。按风险高低分配注意力：

高注意力（必须逐字看、必须追问）：
  - 权限、安全相关规则
  - 不可逆操作（删除 / 支付 / 外发消息 / 数据覆盖）
  - 状态机、并发、幂等
  - 影响面里的"修改"和"不碰"清单
  - 非目标（防止越界）

中注意力（看逻辑、抽查）：
  - 正常流程、实现步骤顺序
  - 测试计划的覆盖
  - 数据约束

低注意力（扫一眼即可）：
  - 格式、措辞、编号规范
  - 模板各节是否填满（AI 通常填得很满）

一个反直觉的提醒：评审时最该花时间的，恰恰是文档里”没写”的部分。 写出来的东西 AI 一般不会错得离谱；真正的风险全在空白处——那些没人想到要提的默认假设（孤儿文件、级联删除、缓存失效、日志残留）。评审高手和新手的区别，就在于高手会盯着空白问”那 XX 怎么办”。

四种评审反模式

反模式一：橡皮图章。 扫一眼”挺完整”就通过。这是最常见也最危险的。它通常发生在赶时间、或评审人觉得”AI 写的应该没问题”时。对策：把检查表变成强制项，一条一条打勾，打不出来就不放行。

反模式二：格式警察。 把全部精力放在错别字、缩进、标题层级上，却没问过一句”删文章那图片怎么办”。格式问题 AI 几乎不会犯，业务空白才是重灾区。对策：评审先过业务和风险，格式最后扫。

反模式三：无限深挖。 评审变成对每个技术细节的辩论会，一个 Plan 审三天。这会让团队干脆跳过评审。对策：评审只回答”能不能动手”，不回答”最优解是什么”——方案优化可以在实现中进行，但安全和边界必须现在定。

反模式四：评审者背锅制。 把”评审通过”理解成”评审人为所有后果负责”，导致没人敢签、或签了就甩锅。对策：评审是团队对 AI 产出的共同把关，责任在流程设计（检查表是否覆盖风险），不在某个人有没有”看走眼”。目标是让空白越来越难溜过去，而不是追责。

人审 vs AI 先审的边界

评审本身也可以让 AI 先跑一轮，但要分清楚哪些能委托、哪些不能：

可以让 AI 先过一遍（生成”疑似问题清单”）：

• 结构完整性检查（模板各节是否填了）；
• REQ 编号映射的机械核对（哪个 REQ 没有落点）；
• 措辞里的不可验收词（“尽量""友好”）扫描；
• F1–F6 逐项的初步比对。

必须人来判断（AI 的结果只能当线索，不能当结论）：

• 业务规则是否有遗漏（AI 不知道你没说出口的默认假设）；
• 方案是否过度设计、是否符合真实业务约束；
• 不可逆操作的处理是否可接受；
• “不碰清单”是否覆盖了真正的系统软肋；
• 最终的放行决策。

经验做法：让 AI 先出一份”评审意见”，人再带着这份意见去评审。 AI 擅长机械地挑结构问题，人专注判断业务和风险。但注意——AI 的评审意见会倾向于”整体不错，有几点小建议”，它不会替你发现”孤儿文件”这种它根本不知道存在的东西。AI 的评审是补充，不是替代。

失败回退

• Spec 评审发现规则矛盾 / 关键场景缺失 → 打回 Spec 阶段补齐，不带着问题进 Plan；
• Plan 评审发现现状理解错误 → 打回重新研究代码库；
• Plan 评审发现技术可行性存疑 → 转 Spike，暂停 Implement；
• 评审中反复出现同一类漏审（比如总是漏级联数据）→ 把这类问题沉淀进评审检查表和 pitfalls.md，让它下次成为必问项。

最后一条是评审能力进化的关键：每一次”评审没拦住、后来爆了”的问题，都应该变成检查表里的一个新勾选项。 检查表不是一次写死的，它是团队踩坑史的结晶。

结语

AI 会把文档写得越来越漂亮、越来越完整。评审的任务不是欣赏这份完整，而是专门去找那些”因为太理所当然，所以谁都没写”的空白。

评审通过，AI 终于可以碰代码了。但”可以动手”不等于”可以放开手脚”。下一篇进入 Implement 阶段：怎么让 AI 严格按 Plan 改代码——一次只走一小步、明确允许和禁止修改的文件、每一步都停下来检查 Diff，以及为什么遇到”Spec 和代码对不上”时正确动作是暂停而不是自作主张。