AI 原生 SDLC 把评审前移——但有三个环节无人把关

先看全貌

这份手册（Louis Claxton，Anthropic，2026-08-21）把软件开发生命周期重组为六个阶段，每个阶段都提交一份纳入版本控制的产物，供下一阶段读取。提交历史即审计轨迹；所谓"做法"，就是生产每份产物的具体实践。

真正值得琢磨的是这条链，而不是阶段的数量。六阶段生命周期图比我们大多数人的工龄都长；而每一道阶段边界都是一次机器可读产物的 git 提交，这才是新东西——正是它让手册其余部分从愿景变成可执行的约束。

"代码不再是瓶颈"讲的是排队

手册以这句话开篇，很容易被读成一句产能自夸。它不是。它讲的是流水线的约束点在哪里，而约束点并不会因为你加快了它前面的环节就消失——它只会挪位置。把实现环节提速十倍，吞吐量不会跟着涨十倍；在制品会堆在下一道工序前面，而在任何一家软件组织里，下一道工序都是评审、测试与发布。

2025 年的 DORA 报告量到的正是这个形状。90% 的受访者已在工作中使用 AI——同比上升 14 个百分点——每天与之打交道的时间中位数为两小时。AI 采用度如今与交付吞吐量呈正相关，这是对前一年结论的反转。而它依然与更高的不稳定性相伴：变更失败更多、返工更多、恢复耗时更长。同一份数据里吞吐上升、稳定性下降，正是"构建环节提速了、验证环节没跟上"这种流水线的特征。

信任度也沿着同一条裂缝分布。DORA 受访者中 24% 对 AI 输出高度信任，30% 只有一点信任甚至完全不信任。后者并非不喜欢这个工具——他们是控制系统跟不上产出量的那群人，对自己来不及核验的输出打折扣，这个判断本身是对的。

所以对这份手册的诚实概括不是"教你跑得更快"，而是：约束点已经挪走了，你早就活在它的下游，而这里给出的是一次重组，把人的注意力挪到约束点如今所在的位置。手册自己的说法是："当 agent 把代码产出翻倍时，要么评审队列越积越长，要么代码在评审不足的情况下上线。"

这条链是一台编译器，而它的各遍都没有校验

把这条链看成一条编译流水线。意图被降级为规格，规格降级为计划，计划降级为 diff，diff 降级为评审结论。每一跳都是从较高层表示到较低层表示的一次翻译——而且完全和真正的编译器一样，只有当你能信任每一遍时，整体才值得信任。

真正的编译器是靠结构挣来这份信任的。它的中间表示带类型，它的各遍是确定性的，某一遍降级出来的东西若被下一遍拒绝，构建时就会大声报错。这三条性质在这里一条也不成立。中间表示是英文散文。各遍是语言模型，同样的输入在两天里可以降级成两个样子。而且没有任何一种类型错误叫做"这份计划没有实现这份规格"——一份悄悄丢掉某条需求的计划照样编译通过，一路通到 CI 全绿。

这也就意味着，那些做法并不是一袋子提效小技巧。每一个都是钉在某一跳上的检查，替代了编译器本来白送的那份校验。用这种方式读手册——对每个做法追问"它校验的是哪一次翻译"——缺口才会显形，因为缺口就是那些没人给它配做法的跳。

git 不会替你补上。提交历史给你的是产物之间的先后顺序，而不是派生关系：它记录了 spec.md 在 intent.md 之后提交，从未记录它是照着后者写出来的。规格落地之后再去修改意图，日志看起来一模一样。

哪个做法守哪一跳

换一个轴来比较这些跳——翻译错了会发生什么？——它们会归为三类而不是八种。在 spec.md → plan.md 这一跳上，plan mode 在人批准计划之前扣住每一次文件改动，所以翻译错了就会卡住；在 plan.md → diff 上，一个 PreToolUse hook 可以直接拒掉这次工具调用，所以被禁止的动作根本不会发生；在配置 → 行为上，eval 套件低于通过率阈值就会让流水线失败。这三跳是"失败即关闭"。在 diff → 政策上，分层 agent 评审产出按严重程度排序的结论、由人裁决关键项——翻译错了通常会被抓到，但那是概率意义上的。而在剩下三跳上，一次错误的翻译会产出一份形式完全正确的产物，一声不响地流向下游。

值得点名的不对称在于：hooks 是整份手册里唯一真正确定性的控制。其他每一处，这条链要么是模型在检查模型，要么是人在读散文。而 hook 是 harness 在工具调用之前执行的一个 shell 脚本，它的拒绝不是建议：

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Credential pattern in staged diff"
  }
}

注意这份 hook 契约不允许你做什么。hook 可以拒掉一次调用；保持沉默并不等于批准，而退出码 2 是后续 JSON 也覆盖不了的唯一结果。hooks 只能收紧政策，永远不能放松。对一层治理机制而言，这种不对称恰到好处——同时也意味着你无法靠自动批准把 hook 当成消化评审积压的出口。这一层确定性只能用来说"不"，也只用来说"不"。整体形态见面向 agent 的策略即代码，为什么强制拒绝优于口头叮嘱见护栏入门。

三跳薄弱环节

intent.md → spec.md：创造最多，检查最少

这一跳创造的信息比链上任何一跳都多。几段问题陈述、受影响用户和待定问题，要变成一份带接口、边界情况和验收标准的完整规格。手册在这里的贡献是实打实的，但方向不同：组织 skills 会在规格撰写过程中注入品牌、安全、合规与 UX 标准，于是政策在撰写时就被套用，而不是三周后在评审里才被发现。这是真正的改进，而它检查的是规格对政策的符合度——不是规格对意图的忠实度。

除了产品负责人把两份 Markdown 并排读一遍，没有任何东西在检查规格是否忠实于意图。一条意图从未暗示过的需求，或者一个被规格朝着省事方向悄悄敲定的待定问题，对下游的一切都是隐形的：计划会忠实实现它，测试会覆盖它，评审会放它过，而最终那起事故，将记在一份人人都批准过的规格头上。

diff → spec.md：评审代码不等于评审需求

按手册的描述，agent 化 PR 评审拿进来的 diff 对照组织政策来读，并按严重程度给结论排序。这能抓出缺陷、漏洞和约定违例——也就是在"需求默认正确"的前提下评审者会找的东西。这与追问"这份 diff 是不是规格要的东西"是两份不同的工作，而后一份工作才抓得住那个昂贵的失效模式：agent 把错的东西做对了。

eval 也覆盖不到。回归套件告诉你的是，行为没有朝着你的 eval 集已知的那些方向变化；它对"行为是否匹配上周二写的那份规格"只字未提。eval 闸门能承诺什么、不能承诺什么，见eval 驱动开发与 CI。

生产 → intent.md：唯一没有人类作者的产物

Maintain 阶段是手册里最新颖的部分，也是把守最少的部分。一个检测脚本盯着生产环境的控制带——测试失败率、错误率、周期时间——某一条被突破时就调用 Claude 去诊断；诊断结论被写成 intent.md，从第一阶段重新进入流水线。这是唯一一跳，产物进入链条的全过程都没有人类作者。

它的检查完全在下游：第一阶段的产品负责人评审。也就是说，这个回路闭合得有多紧，取决于那个入口队列有多少人在看。无人值守的入口，会把一个闭合的反馈回路变成一台不断生成工作的开环机器——而手册自己给第一阶段设的领先指标，从首次对话到提交 intent.md 的时长，会随着这台机器越高产而越好看。务必把它和滞后指标（进入第二阶段的存活率）配对使用，否则它会被读成进展。

这套指标没有测的东西

手册提出了一组考虑周到的领先与滞后指标——提交意图的时长、意图与规格两次提交之间的间隔、在评审质量不下滑的前提下每位工程师的并行会话占比、首次 PR 评审的耗时、eval 通过率；以及意图的存活率、构建开始后的需求返工、agent 所写变更的 CI 一次通过率、逃逸到生产的缺陷、同类事故的重复发生。其中缺了两样东西。

第一样是针对某一跳的度量。存活率量的是产品负责人是否接受了这份意图，而不是规格是否忠实于它。构建开始后的需求返工是最接近的代理指标，而它只有在误译已经害你白做一轮构建之后才会触发。

第二样是成本。并行会话与分层 agent 评审在设计上都会成倍放大 token 支出，而"在评审质量不下滑的前提下每位工程师的并行会话占比"只量了分子。agent 每一步都会把整段对话重新发一遍，所以一次长会话的输入 token 会随步数的平方增长——见agent 成本控制。六个阶段的 agent 产物，意味着相当多段对话。

让这条链真正承重

上面这些缺口都不构成反对这份手册的理由。它们是手册留给你的部分，而每一个都有便宜的补法，且都契合手册自己的语汇——要么是一份纳入版本控制的产物，要么是一个 hook。

盖上出处，让 git 记录派生而不只是顺序

把上游产物的提交 SHA 写进下游产物的 front matter：spec.md 带上它所依据的那份 intent.md 的 SHA，plan.md 带上规格的，PR 正文带上计划的。这样这条链就成了一张真正的图，而不是一堆恰好放在同一个仓库里的文件；"规格批准之后意图又改了"也从"得有人记得"变成了一项 CI 检查。一个 PreToolUse hook 可以拒绝那种 front matter 指向的 SHA 已不再是该产物 HEAD 的提交。这就是把决策回执模式套用到 SDLC 上。

先把最容易的那一跳检查机械化

在没有检查的几跳里，spec.md → plan.md 是唯一可以用脚本而非模型来校验的：一份计划若动了规格任何章节都没提到的文件，或者漏掉了规格点名的某个子系统，就值得在批准环节标出来。这是个粗糙的启发式，遇到重构会误报。它同时也几乎不花钱，而且抓得住那种悄悄长了范围的计划。

给意图 → 规格这一跳配一个裁判，而不是一个读者

最需要检查的那一跳，恰恰最不适合用脚本，因为两份散文之间的忠实度是一项判断。这正是带固定评分量表的 LLM 裁判该干的活：规格是否回应了意图提出的每一个待定问题，又是否引入了意图并未暗示的需求？把它当作 Design 阶段的闸门跑起来，一项阅读任务就变成了可度量的任务。信任它之前先校准它——见裁判校准与元评测，因为一个未经校准的裁判守在治理闸门上，比不设这道闸门更糟。

给自动入口加一道人工闸

生产环境检测出来的意图，落地时应当是一份带负责人和有效期的草稿，而不是与人类撰写的意图平起平坐。要统计的是接受数，不是生成数。这正是人在回路这个"该放在哪里"的问题最锋利的形态：整个回路除了这一点之外都是自动的，那这一点就必须真有人在。

hooks 留给那些绝不能靠概率的事

diff 里的凭据、对受保护路径的写入、生产部署，以及一切不可逆的动作。在这些地方，"模型通常做得对"不是一种可接受的控制，而 hook 只能拒绝的那种不对称在这里恰是优点。其余的，做成评审结论就够了。

可移植，还是只属于 Claude Code？

手册明确是模块化的——组织按优先级挑阶段和做法，每个做法都列出自己的前置条件。在规划落地之前值得先分清：哪些做法是你今天下午就能采纳的文件约定，哪些是靠提示词复现不出来的 harness 特性。

规格驱动开发不是 Claude 的发明，生态也很健康：GitHub 的 Spec Kit 采用 MIT 许可，star 数已过 13 万，并于 2026-08-21——它的一周岁生日——发布 v1.0.1，驱动着三十多个 agent（含 Claude Code）走完 specification、plan、tasks、implement 四步。AWS 的 Kiro 则围绕三份规格文件 requirements.md、design.md、tasks.md 建了一个 IDE。Anthropic 的命名不同，形态并无二致。

所以手册的"格式"那一半是一套约定，而这套约定正在全行业收敛。"强制"那一半是 harness 特性——而真正干活的正是"强制"这一半。一个采纳了 intent.md 却没有采纳任何"能拒绝"的东西的团队，采纳的是一套归档制度。

有一行值得比原文更加谨慎。把部署与回滚通过 MCP 暴露出去，等于把发布按钮交到 agent 手里、只隔着一层按环境划分的权限梯度，而权限梯度的可靠程度取决于其背后的身份。接线之前先读agent 身份与权限和环境权限；一个继承了某个人类凭据的部署工具不是权限梯度，是一套戏服。

从哪里开始

只有按约束点而不是按阶段序号来挑，模块化才有用。真正该问的是：眼下哪条队列最长。

最后一行不是凑数的答案。一次以"约束点已经挪走了"为全部前提的重组，不该闭着眼睛采纳——如果你看不见自己的在制品堆在哪里，你就分不清改善与挪位。度量手段见agent 可观测性；同一个约束论证放在单个功能而非整个组织的尺度上，见 AFK 编码。

手册的收尾是："回路继续转。人的判断留在它上面。"这个愿景是对的，而它是一句关于"位置"的主张：只有在产物真的被评审的地方，判断才留在回路之上。把检查装到各跳上，这句话描述的就是你的流水线；让各跳裸着，它描述的就只是一张图。

延伸阅读

本站相关：

• AFK 编码——同一个约束论证放在功能尺度上：并行度受限于评审能力，而不是 agent 的能力。
• 面向 agent 的策略即代码——为什么强制手段该放在 harness 里而不是提示词里。
• 决策回执与审计——上文那条 SHA 建议背后的出处标记模式。
• eval 驱动开发与 CI——eval 闸门能承诺什么、不能承诺什么。
• 裁判校准与元评测——让 LLM 裁判把守阶段边界之前的必读内容。
• Agent skills 与 agent harness——多数做法赖以搭建的两个原语。
• 人在回路 · 护栏入门 · agent 成本控制 · agent 可观测性
• Claude Code、Codex CLI、Cursor Agent 与 Aider——哪些 harness 提供了"强制"那一半。

原始出处：

• The AI-native SDLC playbook——Louis Claxton，Anthropic，2026-08-21
• Claude Code hooks 参考——事件名与 PreToolUse 的 deny 契约
• 2025 DORA 报告发布公告——吞吐量、不稳定性与采用度数据
• github/spec-kit——MIT 许可，star 数 13 万以上，v1.0.1（2026-08-21）
• Kiro specs 文档——requirements.md / design.md / tasks.md 的结构