正在加载，请稍候
拆解 Anthropic 六阶段 SDLC 手册：intent.md 把签字对象从 diff 换成意图，持续评测与 hooks 接住确定性，附三跳薄弱环节与中国团队落地路径。
2026 年 8 月 21 日，Anthropic 发布《The AI-native SDLC playbook》（作者 Louis Claxton），把研发流程重组成一条六阶段产物链。这篇拆解讲清楚它为什么成立、哪里薄弱、国内团队怎么落地。
手册开篇断言"代码不再是瓶颈"，这不是产能自夸，而是排队论：流水线的约束点不会因为前置环节提速而消失，只会后移。实现环节快十倍，吞吐量不会跟着涨十倍——在制品会堆在下一道工序前面，而下一道工序永远是评审、测试与发布。社区对这份手册的双语拆解把这条推理梳理得很完整。
2025 年 DORA 报告量到的正是这个形状：90% 的受访者已在工作中使用 AI（同比上升 14 个百分点，中位每天 2 小时），AI 采用度如今与交付吞吐量呈正相关——这是对前一年结论的反转；但它依然与更高的不稳定性相伴：变更失败更多、返工更多、恢复更慢。同一份数据里吞吐上升、稳定性下降，是"构建环节提速了、验证环节没跟上"的流水线特征。信任度也沿着同一条裂缝分布：24% 的受访者对 AI 输出高度信任，30% 只一点信任或不信任——后者不是不喜欢工具，而是控制系统跟不上产出量，对来不及核验的输出打折扣。
手册把生命周期重组成六个阶段，每个阶段提交一份纳入版本控制的产物，供下一阶段读取：
| 阶段 | 提交产物 | 人做什么 | 具名做法 |
|---|---|---|---|
| 1. Plan | intent.md | 产品负责人评审并提交 | 以意图文件形式沉淀 |
| 2. Design | spec.md | 处理被标记出来的政策问题 | 需求与设计合并为一次会话 |
| 3. Build | plan.md，随后是 diff | 在任何改动之前批准计划 | plan mode、CLAUDE.md、skills、hooks、并行会话 |
| 4. Test | eval 结果 | 设定通过率闸门 | 持续 eval |
| 5. Deploy | 评审结论 | 在关键路径上判断意图与风险 | AI 进入 PR 评审回路、hooks 作为审批闸门 |
| 6. Maintain | 事故记录 → 新意图文件 | 接受或驳回自动生成的意图 | 控制带检测、事故频道里的 Claude Tag |
由此产生三大断裂：其一，瓶颈从写代码转移到规划、审查与部署，人的注意力要搬去新的约束点；其二，逐行审查失效——agent 产出翻倍后，逐行读 diff 的节奏必然被击穿；其三，治理成本上升——hooks 只能收紧、eval 要持续维护、并行会话的 token 支出按步数近似平方增长。
intent.md 是整条链的源头。几段问题陈述、受影响用户和待定问题，被压缩成一份可版本化的 markdown——提交历史即审计轨迹，后续的 spec、plan、diff 都从它派生。手册真正的动作不是提速，而是替换：产品负责人签字的对象从 diff 变成意图。这要求 Plan 阶段由人评审并提交，Design 阶段把需求与设计合并进一次会话。
Design 阶段还埋了另一个关键做法——技能编码标准：组织把品牌、安全、合规、UX 标准写进 agent 技能（skills），在规格撰写过程中注入，政策在写作时就被套用，而不是三周后在评审里才被发现。这对"规格是否符合组织政策"是实打实的改进；但它不检查"规格是否忠实于意图"——一条意图从未暗示过的需求，对下游一切环节都是隐形的，最终事故会记在一份人人都批准过的规格头上。
Test 阶段不再依赖阶段门禁加人工回归，而是持续 eval：一个低于通过率阈值的 eval 套件直接让流水线失败。Deploy 阶段 AI 进入 PR 评审回路，hooks 作为审批闸门。其中 hooks 是整份手册里唯一真正确定性的控制——它是 harness 在工具调用前执行的 shell 脚本，拒绝不是建议：
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Credential pattern in staged diff"}}
这个契约有三个不对称点：hook 可以拒绝一次调用，但保持沉默并不等于批准；退出码 2 是后续 JSON 覆盖不了的唯一结果；hooks 只能收紧政策、永远不能放松。对治理层来说这种不对称恰到好处——同时意味着你无法靠自动批准把 hook 当成消化评审积压的出口。关于 harness 层在 2026 年 AI 编程里到底承担什么，站内这篇模型还是 Harness？2026 年 AI 编程之争的工程真相有更完整的工程视角。
也要认清 eval 的承诺边界：回归套件告诉你的是行为没有朝着 eval 集已知的方向变化，它不回答"行为是否匹配上周二写的那份规格"。eval 闸门能承诺什么、不能承诺什么，Anthropic 工程博客上专门讨论过 evals 与 harness 设计。
把产物链读成编译流水线——intent → spec → plan → diff → 评审结论，每一跳都是高到低层的翻译。真实编译器靠结构挣来信任：中间表示带类型、各遍是确定性的、降级被下一遍拒绝会大声报错。这三条在这里都不成立：中间表示是英文散文，各遍是语言模型，且不存在"这份计划没有实现这份规格"这种类型错误——一份悄悄丢掉某条需求的计划照样编译通过，一路通到 CI 全绿。
于是有三跳薄弱环节值得点名：
人的角色因此从"逐行读 diff"转向"看标记、判意图、裁决关键项"。指标要成对用：领先指标（提交意图的时长、并行会话占比、首次 PR 评审耗时、eval 通过率）看节奏，滞后指标（意图存活率、构建后需求返工、agent 所写变更的 CI 一次通过率、逃逸缺陷、同类事故重复）看质量。尤其是入口队列的领先指标——从首次对话到提交意图文件的时长——会随着开环机器越高产越好看，必须和"进入第二阶段的存活率"配对，否则会被误读成进展。
反例也在这里。手册原话说："当 agent 把代码产出翻倍时，要么评审队列越积越长，要么代码在评审不足的情况下上线。"流程未改造的团队，典型路径是：Agent 写代码提速 → 安全与合规审查仍按人类产出节奏配置 → 产出堆在审查门前 → 团队被迫二选一，要么加班审导致审查质量下滑，要么放开闸门导致缺陷逃逸——AI 提效被审批关卡吃光。DORA 报告里吞吐与稳定性反向变化的统计形态，就是这条路径在宏观数据上的投影。企业要先把 agent 的权限边界和安全沙箱收住，再谈流程改造，Claude Code 沙箱架构深度解读讲的就是这层前置条件。
对国内 CTO 与技术负责人，这条链不必一步到位。按改造成本排序：
先改造（文档与流程层，成本最低）：
保留人工（短期不建议自动化）：
适用边界也要说清楚：hooks 只能收紧不能放松，完全自动化的审批流不在这套体系内；并行会话与分层评审的 token 成本随步数近似平方增长，长会话要设步数上限——这类开销在真实项目里怎么核算，参考站内这篇AIcoding 移动端落地成本账；对合规要求极高、必须逐行人工确认的团队，先只做意图文件层，不要一次上全链。生态侧的佐证是，AI 原生 SDLC 的开源工具正在成型——例如 potpie（Apache-2.0，把代码库与研发流程索引成 context graph 供 agent 使用），说明这条路线不只是文档层面的设想。
蓝曜炬辉在帮企业做 Claude Code 落地时，通常建议从"意图文件 + 一个 hook + 一个 eval"的最小闭环起步——它恰好覆盖上面三跳薄弱环节中的源头锚定与政策注入两处。
传统 PRD 是给人读的文档；intent.md 是链条的单一事实源，后续产物都从它派生，每个阶段边界都是一次机器可读产物的 git 提交。
不能。eval 管"行为没有朝已知方向变坏"，管不了"行为是否符合规格"；人工审查的定位从逐行读 diff 变成对意图与关键路径风险的裁决，二者是配合关系。
契约设计上 hooks 只能拒绝、不能批准：沉默不等于批准，退出码 2 不可被后续 JSON 覆盖。这是有意的治理不对称，也意味着 hooks 不能用来消化评审积压。
社区给出了与手册同一语汇的补法：下游产物 front matter 带上游产物的提交 SHA，让 git 记录派生关系而非先后顺序；spec → plan 这一跳可以用脚本校验；Maintain 入口设人值守，并把领先/滞后指标配对读。
从"意图文件 + plan mode + 一个 PreToolUse hook + 一个 eval"的最小闭环起步，覆盖意图源头与政策注入两处薄弱点，再按业务节奏扩展。