Anthropic 官方 AI 原生 SDLC 实战手册：六阶段改造路径

Anthropic 官方 AI 原生 SDLC 实战手册（六阶段改造路径）

基本判断：写代码不再是软件研发的瓶颈！

随着 Codex、Claude Code、Cursor 等 Coding Agents 能力的不断提升，编写代码的能力和速度都有极大提升，传统 SDLC 中围绕代码建立的流程——审批闸口、评审、交接、制度——却仍按"人速"运转，反而抵消了 AI 带来的生产力收益。

这导致了三个后果： 1. 瓶颈向构建阶段的两侧移动：规划、评审/测试、部署仍以人速运行； 2. 旧控制手段与现实脱节：逐行人工评审在智能体产出大部分 diff 时已不可行； 3， 治理成本上升：例外事项仍要排队等每周/每月的会议和委员会。

AI 原生 SDLC 的本质：从线性流程到"工件链闭环"

全文最关键的设计思想，可提炼为三点： 1. 流程从直线变成环：AI 嵌入每个阶段，阶段间自动交接、自动触发下一阶段。 2. 每个阶段以"提交一个版本化工件"结束，下一阶段以"读取该工件"开始：intent.md → spec.md → plan.md → diff 与测试 → 带评审结论的 PR → 事故记录。前期以 Markdown 为主（产品负责人和智能体都能读懂并执行），构建之后以代码及其记录为主。 3. 这条提交链同时就是审计链：谁提的需求、智能体产出了什么、谁批准的，全部留痕。人类的注意力从"逐行干活"上移到"把守闸口"——评审智能体标记的内容，而非从零开始每个阶段。

六个阶段的具体打法

1. Plan —— 用 intent.md 捕获意图 想法不再排队等产品经理代笔。发起人用自己的语言与 Claude 头脑风暴，产出包含问题、预期结果、受影响方、约束和待决问题的原型规格，提交到版本库。无需任何前置条件，是最适合起步的 Play。度量：从首次对话到提交 intent.md 的时间（目标：数周 → 数小时）及产品负责人的采纳率。

2. Design —— 需求与设计压缩进一次会话 Claude 基于已批准的 intent.md，在组织级技能（品牌、安全、合规、UX）约束下产出 spec.md，并主动标记风险点。产品负责人只评审不执笔；策略在撰写规格时即被应用，而非数周后在评审中被发现。是否进入构建，始终由人决定。

3. Build —— 无批准计划不动工 · 计划模式为默认起点：工程师先让 Claude 在只读的计划模式下产出 plan.md（改动哪些文件、顺序、风险、验证方式），迭代到"一个没看过对话的工程师也能照此实施"才批准提交； · CLAUDE.md：把新人第一天需要的知识（命令、约定、架构、常犯错误）固化为智能体每次会话必读的文件。经验法则是"同一个错误犯两次，就把纠正写进去"，并保持在一页以内； · Skills：把必须一致执行的制度性知识（如 API 安全标准）做成版本化、可中央更新的技能。但技能只是劝导性控制——必须无例外成立的策略，需要确定性的 hook 兜底。"技能让违规变少，hook 让违规近乎不可能"； · Hooks 作为构建期护栏：拦截受保护路径的编辑、编辑后自动跑格式化、防止凭证进入 diff。构建期的 hook 不该要求人工审批，否则人又被拉回并行会话的关键路径； · 并行会话与子 agent：一名工程师用 git worktree 同时驱动多个独立会话，重复性工作封装为子 agent。工程师的角色从"写代码"转向"编排与评审"，实际上限是一个人能认真评审多少条工作流。

4. Test —— 先自验，再给人看 · 反馈回路：始终给 Claude 验证自己工作的手段（测试、构建、截图对比），让它迭代到通过为止。修 bug 时先写复现失败测试并提交，且用 hook 禁止智能体修改测试文件——"修复前就存在、且智能体无法改写的测试，才是 bug 已修复的证据"。同时要保护回路本身不被削弱； · CI 中的持续 evals：这是 AI 原生版的阶段门 QA。收集 20–50 个真实任务及其可接受结果组成评估套件，每当 CLAUDE.md、技能、hook 或模型变更时运行——因为驾驭智能体的配置本身，值得享受和代码同等的回归测试。每次生产事故都要沉淀为一个永久性 eval。

5. Deploy —— 双向评审 + 行动时即治理 · PR 评审闭环：Claude 既评审别人的 PR（按 REVIEW.md 定义的 bug、安全、合规三个 pass，按严重度分级），也处理自己 PR 上的评审意见并推送修复。人类评审聚焦意图与风险。职责分离被保留：写代码的智能体无权批准代码，分支保护仍要求代码所有者批准。评审中重复出现的问题回流到 CLAUDE.md； · Hooks 作为审批闸口：allow / ask / block 三态，不可协商的闸口放在平台团队管控的 managed settings 中，工程师无法关闭。文中给出了一份受监管企业的完整托管配置示例（权限白黑名单、沙箱、凭证隔离、仅允许托管 hook/MCP/插件市场、最低版本强制），并提醒应按仓库数据分级裁剪而非照抄； · CI/CD 集成：以 claude -p 非交互方式在流水线中承担需要判断力的环节（分流失败构建、起草 changelog），沙箱执行、短期限定凭证、部署能力通过 MCP 按环境开放。核心原则是：智能体可以做生产闸口之前的一切，且不能越过闸口；回滚路径必须是流水线中演练最充分的一条。

6. Maintain —— 闭环 · 自动闭环：确定性脚本（均值/标准差 + Western Electric 规则，不含模型）监控生产指标，越带即触发 Claude：1σ 仅记录，2σ 只读诊断，3σ 才允许行动——且行动路径仅限开 PR 进评审闸或触发预批准的 runbook。诊断结果写成 intent.md 重新流入第一阶段。人的角色从"启动工作"变为"分诊与批准"； · Claude Tag：事故从 Slack 等协作渠道直接进入，Claude 以独立身份成为频道成员担任第一响应者，频道本身就是审计轨迹，事后把复盘写入版本化的经验文件供未来调查读取。

贯穿全文的治理思维

· 人始终对需要判断力的决策负责，但人的位置从流水线上移到了闸口； · 治理在智能体行动时强制执行（hook、沙箱、托管配置），而不是事后评审周期； · 与遗留系统共存：每类工件指定唯一事实源——要么仓库为权威、遗留系统引用提交，要么 Jira/需求工具为权威、Markdown 为工作副本（通过 MCP 回写），底线是双向链接（记录 ID <-> commit SHA）； · 采纳顺序 ≠ 阶段顺序：Play 是模块化的，按依赖图采纳，无前置依赖的 Play（如 intent.md、CLAUDE.md）可任意起步。

原文地址

https://claude.com/blog/the-ai-native-sdlc-playbook