Anthropic 在 2026 年 8 月发布了一篇 43 分钟长读的 The AI-Native SDLC playbook。这类"官方最佳实践汇总"文章通常容易写成产品功能清单，但这一篇不一样——它真正回答了一个更前置的问题：
当 agent 能在几小时内写完过去几周的代码，软件开发生命周期里最慢的那一环，还是写代码吗？
文章的答案很干脆：不是了。瓶颈从中间（Build）转移到了两端（Plan 与 Test/Deploy），而绝大多数组织的流程仍然是为"人类手写代码"这个前提设计的。于是流程本身成了新的约束。
一、三个已经发生的变化
文章没有从"AI 能做什么"讲起，而是先摆了三个组织层面的事实。这三条决定了后面所有 play 的必要性。
第一，瓶颈转移了。 编码速度被抬升一个量级之后，左右两侧仍然跑在人类速度上——左侧的需求澄清与意图对齐，右侧的评审、测试、部署与合规。你压缩了 pipeline 中间最窄的一段，两端的排队立刻暴露。
第二，控制方式不再匹配现实。 人工逐行 review 的前提是"diff 是人类写的、量级是人类可读的"。当大部分 diff 由 agent 产出时，这个前提直接失效——评审者既读不过来，也无从判断那些看起来很合理、实际上与架构约定冲突的代码。
第三，治理成本上升。 异常仍然通过周会、月会、CAB（变更顾问委员会）来路由。AI 把生产节奏提到了小时级，审批节奏还停在周级，这个剪刀差只会越拉越大。
这三条合起来指向同一个结论：修补单点没有意义，需要重构的是整条生命周期的形态。
二、贯穿线索：每个阶段提交一个工件
这是整篇 playbook 最核心的结构性设计，也是我认为最值得先记住的一点。
传统 SDLC 是线性的阶段流转，阶段之间靠会议、文档和口头交接。AI 原生 SDLC 改成了一条由工件驱动的自动循环：每个阶段都以向版本控制提交一个工件结束，下一个阶段读取这个工件并被自动触发。
早期阶段主要是 Markdown 文件——intent.md、spec.md、plan.md；从 Build 开始变成代码及其记录——diff + tests、PR + review findings、incident record。
这个设计带来一个副作用，而且是很值钱的副作用：提交链本身就是审计轨迹。谁要求了什么、agent 产出了什么、谁在哪个环节批准，全部沉淀在 git history 里，不需要额外的流程系统去记录。对受监管行业来说，这几乎是把合规从"额外工作"变成了"开发的自然产物"。
文章用一句话收尾这个循环：
The loop keeps running. Human judgement stays above it.
循环持续运转，人类判断居于其上——注意是"居于其上"，不是"参与其中"。这是全文对人机分工的定性。
三、Stage 1–2：把意图从人脑搬到仓库
Plan：intent.md
非工程师也可以直接用 Claude（claude.ai / Cowork）做头脑风暴并生成 intent.md。模板包含五要素：问题、期望结果、受影响的用户或系统、约束、开放问题。
文章给的例子很能说明问题——“客户打电话问理赔状态"是问题陈述，“期望在门户自助查看"是结果，约束是"不新增 PII、仅用现有认证”。注意约束这一栏：把约束写进 intent，比事后在 review 里发现要便宜一个数量级。
产品负责人 review、纠正后 commit。衡量指标是从首次对话到 commit 的时间（应降到小时级），以及 intent.md 的存活率。
Design：spec.md
产品负责人把 intent.md 交给 Claude，同时载入品牌、安全、合规、UX 相关的 skills，产出 spec.md。
这里最大的变化是需求与设计被压缩进同一次 session。传统流程里分析师写需求、设计师做解析，中间有交接损耗；现在这一步被折叠了，但代价是"标准"必须提前编码成 skills，否则每次 session 的输出质量都会漂移。
衡量指标是 intent.md → spec.md 的间隔，以及 build 开始后 spec.md 的返工次数。
四、Stage 3：Build 的护栏三件套
Build 是六个阶段里 play 最多的一段，也是文章篇幅最重的部分。核心是三件事——CLAUDE.md、Skills、Hooks——它们解决的是同一个问题的三个层次。
Claude Code plan mode 作为默认起点
先用 plan mode 只读取代码库不改文件，产出 plan.md——改哪些文件、按什么顺序、测试策略、风险、以及如何证明做对了。人类批准后才进入实现。
文章给的 plan.md 示例里，风险一栏写的是"claims-core API 限流 50rps，需要加缓存”。这说明 plan mode 的价值不只是"先看后改"，而是把 agent 在探索代码库时发现的信息显式化，让人类可以在写代码之前就纠正方向。
auto mode（自动接受、并行执行）则是在护栏成熟之后才用于常规工作——顺序很重要，先有护栏，再谈自治。
CLAUDE.md：项目上下文，始终加载
用 /init 生成，内容保留"新成员第一天需要知道的"——命令、约定、架构、以及 Claude 常犯的错误。控制在 1 页以内。规则是：同一个错误犯两次，就写进这个文件。
文中给的 Payments service 示例：Java 21 / Spring Boot 3，金额必须用 BigDecimal，端点需要集成测试，不要改生成类。都是那种"团队里人人都知道但没人写下来"的默契。
Skills：制度知识，按需加载
必须一致应用的规则写成 .claude/skills/<name>/SKILL.md。示例是 secure-api-review：JWT 认证、OpenAPI 校验、审计事件、PII 不进日志，并附带可执行脚本。
与 CLAUDE.md 的区别在于加载时机——前者始终占用上下文，后者按需加载。判断标准很简单：如果这条规则每次都要用，进 CLAUDE.md；如果只在特定任务上要用，做成 skill。
Hooks：确定性护栏，强制执行
这是三件套里最强的一环，因为它不依赖模型"记得"或"自觉"。典型用法：阻止编辑受保护路径、自动跑 formatter/linter、拦截凭证进入 diff。不满足条件就 exit 2 直接阻断。
文章给的生产门禁示例 production-gate.sh 逻辑很直接：命令里含 deploy + production 且没有 RELEASE_APPROVAL 环境变量，就阻止。
三件套的关系可以理解为加载成本递增，执行确定性也递增：上下文 → 知识 → 强制。
并行
用 git worktree 开多个 session 并行推进；subagents（如 verifier、code simplifier、researcher）定义在 .claude/agents/ 下。其中 verifier 的设计值得注意——启动 app、跑改动及邻近流程、只报告不改代码。把"验证"和"修改"拆成两个角色，是为了避免 agent 为了让测试通过而改测试。
五、Stage 4：Test 的核心是给 agent 一个可验证目标
测试阶段最关键的一条：给 agent 一个可量化的验证目标——make test 通过、截图比对一致、接口返回 200。没有明确目标的 agent 只能自我感觉良好。
几个具体做法：
- 修 bug 先写失败测试，并且用 hook 禁止 agent 修改测试文件。这条和上一段 verifier subagent 的思路一致——切断"改测试让它变绿"这条捷径。
- UI 工作给浏览器和截图工具，让 agent 走"实现 → 截图 → 比较 → 调整"的闭环。
- 持续 evals：收集 20–50 个真实任务，在
CLAUDE.md/ skills / hooks 发生变更时于 CI 中非交互运行。这是把"配置漂移"变成可检测事件的手段——你改了护栏，就得证明护栏还有效。
六、Stage 5：Deploy 的治理从开会变成实时执行
多层 agentic review
REVIEW.md 定义什么叫 pass：bugs、security、compliance（对照 spec.md / plan.md）。区分 Important 与 Nit，并给 nit 数量封顶——避免 review 沉没在风格讨论里。
@claude 处理 review 评论。review 中第二次发现的错误要写回 CLAUDE.md——这条规则和前面"犯两次就写进文件"是同一套反馈机制的延伸，只是反馈来源从"人发现"变成了"评审发现"。
人类只审受监管的和关键的代码，其余交给 agent 多层互审。
Hooks 作为审批门禁
治理不再发生在 review 周期里，而是在 AI 行动的瞬间通过 hooks 强制执行。文章给了一个受监管企业的完整 settings 示例：deny 读取 .env*、限制网络出口、sandbox 隔离、拒绝 credentials、allowManagedHooksOnly。
CI/CD 与分层自治
判断类步骤（比如 triage 失败的构建，用 claude -p 输出三行摘要）先行且只读；写操作必须通过 PR。按环境分层自治——dev 环境自由，prod 环境人工授权。
还有一条容易被忽略但很重要的建议：rollback 应该是最常演练的路径。 当部署频率提高一个量级时，回滚的熟练度直接决定你敢不敢放开频率。
七、Stage 6：Maintain 让循环真正闭合
维护阶段是"循环"这个词兑现的地方。
检测脚本（Prometheus 等）持续监控控制带——CI 测试失败率、部署后 5xx 等。bands.yaml 定义偏离程度与对应的自治等级：
- 1σ：仅记录日志；
- 2σ：Claude 只读诊断，输出根因分析；
- 3σ：可以开 PR 或触发预批准 runbook（如回滚）。
这个设计的精妙之处在于：自治等级与偏离程度正相关。越反常的情况，agent 被允许的行动越多——因为此时"快速止损"的价值高于"谨慎"。而正常情况下 agent 保持安静。
发现的问题写回成新的 intent.md，进入下一轮循环。此外还有两个产品化能力：Claude Security 定时扫描仓库（带置信度，小修复走 PR，大问题写 intent.md），以及 Claude Tag 作为 incident channel 成员做第一响应并写事后总结到版本化的 lessons 文件。
八、几点判断
读完这份 playbook，有几个判断值得单独拎出来。
第一，“工件"这个抽象是整个设计的支点。 它同时解决了三件事：阶段间的自动触发、审计轨迹的自然沉淀、以及人机之间的接口契约。如果只学一条，就学这条。
第二，治理的执行时机被前移了。 从"事后开会审批"变成"AI 行动时 hooks 实时阻断”。这不只提高效率，也改变了治理的性质——从抽样检查变成全量强制。
第三，护栏的顺序不能颠倒。 plan mode → CLAUDE.md / skills → hooks → auto mode → 并行 session。每一步的自治都建立在前一步的约束之上。直接跳到 auto mode 的组织，大概率会在生产环境付出学费。
第四，人的注意力在上移，而不是在消失。 从逐行审查上移到意图、风险、政策合规。文章反复强调人类判断"居于其上"——这个定位比"人机协作"这种空泛说法要明确得多。
最后说一句实际的：这六个阶段里，最容易起步的是 Build 段的 CLAUDE.md + hooks，因为改动局部、见效快、不牵扯组织流程；最难的是 Plan 段，因为它要求非工程角色改变工作方式。但如果 Plan 段不动，你只是在更快地构建错误的东西。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
