这是对 Anthropic 官方课程 《The AI-Native SDLC Playbook》（共 14 课）的完整思路整理。 不需要任何 AI 或工程背景——我们从"什么是 SDLC"讲起，一步步讲清楚这本手册到底在解决什么问题、给出了什么答案。
SDLC（软件开发生命周期）就是一个想法从"有人提出"到"真正上线运行"要走的完整流程。 几乎所有公司走的都是同一套六站流水线：
传统做法里，每一站由不同的人负责：产品经理写需求、架构师做设计、工程师写代码、QA 测试、发布团队上线、运维盯着线上。 工作靠文档、工单和签字在各站之间传递。流程重，是为了在"写代码又慢又贵"的年代保证每一步都有人负责、可控。
像 Claude Code 这样的 AI 编码工具，已经能把"构建"这一站的速度提升好几倍。 但手册开篇就指出一个残酷的事实：只提速中间一站，整条流水线快不了多少——瓶颈只是转移到了两边仍然"以人的速度"运行的站点（规划、评审、部署）。
拖动下面的滑块，亲自感受一下：
这就是整本手册要解决的问题：代码不再是瓶颈之后，会发生三件事—— ① 瓶颈转移到构建两侧仍以人速运行的阶段； ② 老的控制手段失配（AI 一天产出的代码，人根本逐行审不完）； ③ 治理成本上升（例外情况还要等每周才开一次的委员会）。 所以流程本身必须像"写代码"一样被彻底改造。
手册给出的答案叫 AI 原生 SDLC：保留旧流程的控制目标（每一步有人负责、可审计）， 换上新的执行方式（AI 干活，人在关卡处评审）。流程不再是一条直线，而是一个环： 每一站结束时提交一份"产物"（一个文件），下一站从读取这个文件开始；线上出了问题，又会自动写出新的需求文件，回到第一站。
点击下图中的任意一站，看看这一站里人做什么、AI 做什么、产出什么文件：
把六站的产物连起来，就是整个环的"接力棒"传递链——每根接力棒都是一个存进代码仓库的文件，谁写的、谁批的、什么时候改的，全部自动留痕，这条提交记录本身就是审计轨迹：
| 阶段 | 传统 SDLC | AI 原生 SDLC |
|---|---|---|
| ① 规划 | 需求经委员会收集、工作坊提炼、层层签字后手工撰写 | 提出者直接和 Claude 头脑风暴，写成人类可读、机器可执行的 intent.md |
| ② 设计 | 分析师写规格，设计师再解读，两个独立阶段、两拨人 | 需求与设计压缩进一次 AI 会话，由编码成 skill 的组织标准（品牌/安全/合规）自动约束 |
| ③ 构建 | 测试和代码手写，文档等主体开发完了再补 | AI 先出书面方案（plan mode）再写代码；团队知识存在 CLAUDE.md 和 skills 里 |
| ④ 测试 | 在阶段边界设 QA 关卡，出问题几天后才知道 | AI 自己跑测试、自己修，直到全绿才交给人；持续 evals 贯穿实现过程 |
| ⑤ 部署 | 人逐行评审每一行代码，治理靠评审周期、时松时紧 | 多层 AI 评审打底，人只审"意图与风险"；hooks 在 AI 行动的同时强制执行审批闸门 |
| ⑥ 维护 | 人盯着生产环境找 bug，凌晨告警可能没人看 | AI 监控线上指标，异常自动诊断、写成新 intent.md 送回环的起点 |
手册把每个做法叫一个 "play"（打法）。每个 play 都用同一套模板讲清五件事：改变了什么、如何开始、具体步骤、治理考量（怎么保证可控）和如何度量（用什么数据证明有效）。 下面按六个阶段分组，点击任意一课展开要点：
核心提出全书论点：AI 把构建提速后，瓶颈转移、控制失配、治理成本上升，所以要把线性流程改造成"产物驱动的环"。plays 是模块化的，组织可以按自身需要分批采用。
治理每个需要判断力的决定，最终仍由人负责；人的注意力跟着"待评审的产物"走。
核心任何人（包括不懂技术的同事）用大白话和 Claude 头脑风暴，AI 按组织模板写成 intent.md：问题是什么、想要什么结果、影响谁、有什么约束、还有哪些没想清楚。提交进代码仓库，产品负责人审阅批准。
治理文件本身就是审批记录：作者、时间戳、修订历史全在 Git 里。
度量从第一次对话到 intent 提交的耗时（应从数周缩到几小时）；intent 的"存活率"（被接受进入设计的比例）。
核心intent 批准后，Claude 在一次会话里直接产出需求+设计规格 spec.md，过程中受组织的品牌、安全、合规、UX 标准（写成 skills）约束，拿不准的疑点会被显式标出来。产品负责人只需评审：它解决了原来的问题吗？疑点处理了吗？
治理政策冲突在写 spec 时就暴露，不用等几周后的评审会；spec、生成它的提示词、当时生效的 skill 版本全部留档。
度量intent → spec 的耗时；开工后需求返工的次数。
核心工程师把 spec 喂给 Claude 的"计划模式"（此模式下 AI 只能读代码、不能改）。AI 产出实现方案：改哪些文件、什么顺序、用什么测试证明。工程师审问方案——"这会破坏什么？哪步风险最高？你放弃了哪些选项？"——迭代到"一个没看过对话的人只凭方案就能实现"为止，批准后存为 plan.md。
治理设计评审发生在任何代码生成之前——此时改方向只是改一份文档的事。
度量一次实现就合并的改动占比；合并后的代码与 plan.md 的相符率。
核心一份放在仓库根目录的文件，写"新人第一天需要知道的事"：构建/测试命令、代码约定、架构说明、AI 常踩的坑。AI 每次开工前都会读它。黄金法则：同一个错误犯两次，就把纠正写进去。控制在一页以内。
治理它受版本控制，改动像代码一样走评审——AI 依据的指令因此可审计。
度量AI 重复犯"本应被拦下的错误"的频率；新成员到第一个合入 PR 的时间。
核心把"必须被一致执行的规则"（安全标准、API 规范、品牌指南）写成 skill：一个带触发条件的说明文件，AI 干相关活时自动加载。政策变了只需集中改一处，全员下次会话自动生效。
治理关键洞察：skill 是建议性的，hook 是强制性的——"skill 让违规变得罕见，hook 让违规几乎不可能发生"。必须无条件成立的政策，要在 skill 背后再垫一层 hook。
度量PR 评审中引用该政策的意见数——skill 生效后应趋近于零。
核心一名工程师同时跑多个 Claude 会话，每个在独立的代码副本（worktree）里干不同的任务，互不干扰。会话内部还能派出 subagent（限定权限的小助手）处理重复子任务，如"验证器"（跑起来看看改动是否生效）、"简化器"、"调研员"。
治理并发上限不是技术问题，是"一个人能认真审查多少条流"；仓库里的 hooks 和权限设置对所有会话统一生效。
度量评审质量不降的前提下，人均并发会话数、人均每周合并的变更数。
核心永远给 AI 一条"验证自己工作"的途径：一条命令跑测试、跑构建，UI 工作给它截图工具对照设计稿。AI 自测自修直到通过，交到人手里的已经是检查过的东西。修 bug 时先让 AI 写一个能复现 bug 的失败测试，再修代码。
治理回路本身要被保护：修代码的 AI 绝不能有能力削弱对代码的检查——用 hook 禁止它在修复期间改测试文件。
度量AI 产出的变更在 CI 上的一次通过率；每个 PR 的人工评审时长（应下降）。
核心evals 是"给 AI 配置做的回归测试"：收集 20–50 个真实任务和预期结果，做成自动化测试套件。每当 CLAUDE.md、skills、hooks 变化时自动运行——这些文件在指挥 AI 的行为，理应享受代码级的回归测试待遇。每起生产事故都要沉淀成一条 eval。
治理导致通过率下降的配置改动，合入前必须先过评审。
度量eval 通过率随时间的变化；CI 拦下的回归 vs 漏到生产的回归。
核心所有 PR 先过同一套 AI 评审：按 REVIEW.md 里定义的策略跑三遍扫描（bug / 安全 / 是否符合 spec 和 plan），结论按"重要 / 小毛病"分级，小毛病设数量上限。人只审最高层的两个问题：这个改动是否实现了意图？风险是否可接受？评审第二次发现同类错误时，纠正自动写回 CLAUDE.md——下个 PR 起就不会再犯。
治理职责分离：写代码的 AI 没有任何途径批准自己的代码，合并仍需人类 code owner。
度量首次评审响应时间（应到分钟级）；合并前拦截的缺陷 vs 漏出去的缺陷。
核心hook 是在 AI 每个动作前自动运行的检查脚本，能给出三种裁决：放行、暂停等具体某人批准、拦截。典型用法：生产部署必须有具名的发布授权，否则直接拦下。拦截必须"自我解释"——原因和获批途径出现在 AI 的输出里。
治理对受监管企业，控制放进"受管设置"由 IT 统一下发：工程师无法覆盖，配合沙箱、凭据剥离、插件市场白名单，形成 AI 碰不掉的硬边界。每次裁决连同时间戳记入日志。
度量每个闸门上的等待时间；闸门上线前后漏到生产的违规次数。
核心让 AI 以无人值守方式跑在流水线里：先从只读的判断任务开始（分析构建失败原因、写 changelog），再渐进到写入任务（修 lint、响应评审意见）。部署/回滚能力做成按环境限定的白名单工具：开发环境 AI 可自由部署，生产环境只能"准备发布、等人批准"。回滚是全流水线里演练最多的路径。
治理核心原则一句话：AI 可以一直行动到生产闸门之前，但不能越过它。AI 写的任何东西都以 PR 形式出现，没有直达主分支的路。
度量不需要叫人就完成分类的流水线故障占比；DORA 四指标。
核心一个纯确定性的脚本（不含任何 AI）监控线上指标的"控制带"，按偏离程度分层响应：轻微偏离只记日志；中度偏离唤起 AI 做只读诊断；严重偏离时 AI 可以行动——但也只能开一个进入评审闸门的 PR，或触发预先批准的回滚。诊断结果写成新的 intent.md，像普通需求一样重新进入环——环从此自己喂养自己。事故也可以从 Slack 等渠道进来（Claude Tag 让 AI 成为事故频道的第一响应者）。
治理分层边界由版本控制的配置强制；每次调用、发现、分流决策都带时间戳记录；人负责分流和批准，不再需要亲手启动。
度量从指标异常到 intent 出现在分流队列的时间；同类事故的重复率（应随 eval 补充而下降）。
核心给平台团队一份按落地顺序排列的文档清单：受管设置 → 权限 → 沙箱 → hooks → skills → 插件市场 → 受管 MCP → 企业部署 → 监控与合规 API。这个顺序本身就是控制成熟度的递进路线。全书始终强调：转变把人的判断放在流程中心，同时满足大型组织的治理与监管要求。
整本手册的治理思想可以浓缩成一个三层模型——就像高速公路的安全体系：路边的提示牌、物理护栏、收费站的抬杆。 越便宜、越确定的控制越先执行，人的判断力只花在真正需要它的地方：
把政策写成 AI 干活时自动加载的指南。它让违规变得罕见，但没有强制力——某次会话仍可能没照办。
在 AI 每个动作前自动运行的检查，可放行、可暂停等批准、可直接拦截。它让违规几乎不可能发生，且每次裁决留痕。
只保留给真正需要判断力的决定：意图对不对、风险可不可接受、生产发布放不放行。人从"逐行检查"升级为"关卡裁判"。
另一条贯穿全书的纪律：每个做法都自带度量。每一课都定义了"先行指标"（马上能看到的信号，如 intent 到 spec 的耗时）和"滞后指标"（长期效果，如返工率、事故重复率），而且刻意只用系统里本来就有的数据——Git 时间戳、PR 记录、CI 日志——不给团队增加新的统计负担。