Anthropic · The AI-Native SDLC Playbook

你学的那套 SDLC 没有被删掉，
只是每个阶段的产物换了形态

这份 playbook 讲的是：当写代码这一步快到几乎不要钱，整条流水线上真正卡住的是哪里，以及该怎么重新排。

“Code is no longer the bottleneck — the human-speed steps around it are.” 代码不再是瓶颈了，卡住的是它周围那些按人的速度走的环节。

一 · 六个阶段，和它们各自的产物

阶段名跟教科书一样：Plan、Design、Build、Test、Deploy、Maintain。变的是每个阶段结束时手里剩下什么——不是一份会议纪要，是一个进了版本库的文件。

阶段课本里的样子playbook 的做法留下的产物
Plan需求评审会、干系人访谈、签字直接跟 Claude 把痛点谈成机器可读的意图，写明要什么、为什么、有哪些约束intent.md
Design需求分析和概要设计分两拨人、分两个阶段合并成一次会话；组织的策略以 skills 的形式作为约束参与进来，有疑虑的地方标出来spec.md
Build看着设计文档开写，实现计划在脑子里先在 plan mode 里产出书面计划，人审过再动手改文件plan.md
CLAUDE.md
Test信号来得晚：CI、QA、线上把校验收成一条命令，让会话自己跑到过为止，再给人看测试 + 通过的构建
Deploy人逐行看完，治理靠自觉分层的机器评审按严重度排序，人的评审留给风险高的部分；治理在动作发生时被强制执行REVIEW.md
已合并的 PR
Maintain出事了等人响应控制带被击穿时自动触发诊断，结论写成新的 intent.md 回到第一步bands.yaml
新的 intent.md

这条产物链本身就是审计链：intent.md → spec.md → plan.md → PR → 事件记录，每一环都有 commit 作者和时间戳。原文的说法是「谁提的、agent 产出了什么、谁批准的」，全在 git 里。

二 · 走一遍：一个改动的完整生命

假设线上反馈：订单导出 CSV，数据量大的时候超时。下面是它在这套流程里怎么走完的。

  1. 意图落成文件 intent.md

    不是「优化一下导出」，而是把谁在什么场景下卡住、为什么要现在做、不能碰什么，写成一份进库的文件。

    # intent.md（示意，非原文内容）
问题: 商家导出 30 天以上订单时网关 60s 超时
来源: 客服工单 #4412 / 近 30 天 217 次
约束: 不改现有导出接口的 URL 契约
不做: 不引入新的队列中间件

  2. 需求与设计合并 spec.md

    课本里分开的两步在这里是一次会话。公司既有的策略以 skill 的形式在场——比如「大文件一律走对象存储签名 URL」——设计不需要你从头背一遍规范。拿不准的地方由 Claude 标出来给人看。

  3. 先写计划再改代码 plan.md

    plan mode 是只读的：它产出「要改哪些文件、按什么顺序、测什么」，你审过之后才开始动手。这一步是把设计评审强行插在写代码之前。

  4. 让它自己先跑到过 make test

    关键不在于让 Claude 写测试，而在于把校验收成一条能跑的命令，让它拿到反馈自己迭代，直到检查全绿再交到人手里。做 UI 的话，把浏览器和截图能力给它——原文说通常两三轮收敛。

  5. PR 上的分层评审 REVIEW.md

    REVIEW.md 定义要过几遍、每遍看什么：bug、安全、合规，findings 按严重度排。人的评审不是取消，是被留给真正需要判断的那部分代码。原文还建议给 nit 设上限——一次评审最多五条。

  6. 生产门口的那道 hook

    发布到生产由 hook 挡住，直到有人给出发布授权。原文的界线写得很清楚：agent 可以一路走到生产这道门前，但过不去这道门。

  7. 回到第一步 bands.yaml

    上线后由控制带盯着。指标偏离到不同程度触发不同动作，诊断结论被写成一份新的 intent.md 进入待办队列——这条流水线是个环，不是一条线。

三 · 两种控制层，别搞混

这是这份 playbook 里最值得你现在就记住的一个区分。它决定了当你想「让 AI 别再犯某个错」时，该往哪儿写。

Advisory · 建议性 skills（.claude/skills/）

把机构知识和策略写成规则，在代码被写出来的过程中起作用。它影响产出，但不构成拦截——写得再好，也是「让它更可能做对」。

Deterministic · 确定性 hooks（.claude/settings.json）

在动作发生之前放行、阻断，或者要求人来批准。它不看模型怎么想，它就是一道闸门。「不许直连生产库」这种事写在这里，不写在 skill 里。

Context · 上下文 CLAUDE.md

约定、命令、架构、常犯的错误——团队里那些「老员工知道、文档里没有」的东西。原文的建议是控制在一页以内。

四 · 这套流程怎么被衡量

原文把指标分成两类，并且要求成对看。只看前者，你得到的是一支跑得飞快、返工也飞快的团队。

类别原文列举的例子
先行指标
速度		从想法到 intent.md 提交的时间（预期从数周降到数小时）；intent.md 与 spec.md 两次提交的间隔；首次实现就被合并的 PR 占比；首次评审到达的时间（预期降到分钟级）
滞后指标
质量		每个改动的返工轮次；CI 测试失败率的 30 天滚动基线；上线后 5xx 比例；同类事件的重复发生；每人每周合并的改动数——要和返工率一起看

一个采纳顺序上的坑。原文特意说明：plays 是按阶段列的，但箭头给的是采纳顺序，两者不是一回事。比如 CI/CD 集成要求先有 PR 评审回路和 hook 闸门；持续 eval 要求先有 CLAUDE.md 和反馈回路。照阶段顺序从 Plan 一路铺到 Maintain，会在中途踩空。

那么，你的价值在哪

如果「能把代码写出来」不再稀缺，一个刚毕业的人最容易慌的就是这个问题。这份 playbook 其实已经回答了：它把大量篇幅花在意图、规格、评审策略、控制带、审计链上——这些全是判断，不是打字。

把模糊的话变成可执行的约束「导出有点慢」和上面那份 intent.md，中间隔着的东西没有被自动化掉。
看得出产出哪里不对评审能力现在是产能，不是资历的附属品。你读一个 PR 的速度和准度，直接决定这条流水线跑多快。
把没写下来的知识写下来团队里口口相传的约定，落进 CLAUDE.md 和 skills，才会作用在每一次生成上。

原文最后一句是 “Humans remain accountable for every decision that requires judgment.”——需要判断的决定，责任仍然在人身上。这句话不是安慰，是岗位说明。

2 / 3应届工程师