Anthropic 发布：AI 原生 SDLC（软件开发生命周期）实施指南

先看全局：代码不再是瓶颈，等待才是

传统 SDLC 默认最昂贵的是 Build。需求经过会议和签字，设计变成规格，工程师花数周写代码，测试、评审和发布围绕这个长周期展开。Build 足够慢时，其他阶段偶尔等待并不显眼。

Agent 改变了这个比例。代码可能在数小时内出现，但需求澄清、安全评审、测试设计、变更审批和生产授权仍按原来的人工节奏运行。Build 缩短了，流程两侧没有一起缩短。

于是瓶颈从“谁来写代码”迁移到“谁来说明意图、验证结果、承担风险和授权生产”。如果人类仍逐行审查每个 diff、批准每条命令，团队只是从亲自写代码变成排队看 Agent 写代码。

Anthropic 没有删除六个阶段，而是把人工传话改造成可读取、可提交、可触发的工件。以 Git 为权威源时，最小闭环可以记成：

结构化 Markdown 工件 → 提交 Git 并版本化 → 触发下一阶段 Agent → 系统先验证 → 人类在关键 Gate 判断 → 生产反馈写回新的 intent.md。

原图把线性流程改成闭环；下方中文轨道补出闭环实际依赖的工件和闸门。

Plan intent.md 产品负责人接受

→

Design spec.md 规格与风险获批

→

Build plan.md 工程师接受计划

→

Test 代码 + 测试证据 验证通过

→

Deploy PR + 审查记录 代码所有者批准

→

Maintain 发布/事故记录 控制带被突破

↩ 新的 intent.md 生产发现回到计划，循环才闭合

Markdown 和 Git 只是实现手段。关键是每个阶段都有唯一、可追踪的批准状态。早期适合用 intent.md、spec.md、plan.md；进入 Build 以后，代码、测试、PR、流水线日志和事故记录也都是正式工件。Jira、ServiceNow 或 Figma 仍可作为权威源，最低要求是用记录 ID 和 commit SHA 与仓库互相指向。

下面这张表先给出六阶段全貌，后文再严格按指南顺序逐段展开。

每一阶段都必须回答四个问题：交给下一段什么、机器拿什么验证、什么判断仍由人做、怎样知道改造确实有效。少一项，自动化就只是更快地产生待处理输出。

一、Plan：把模糊想法变成 intent.md

传统规划依赖产品经理反复访谈、开会、整理用户故事，再把业务人员的原话翻译成正式需求。信息在多轮转述中丢失，问题提出者也很难看见自己的意图最终变成了什么。

AI 原生做法是让想法提出者直接用自然语言描述问题、影响对象、预期结果、限制和未决问题。Agent 负责追问和整理，生成既能让人阅读、又能让后续 Agent 执行的 intent.md。产品负责人纠正并接受后，才进入 Design。

• 提交工件：intent.md，保留提出者、时间、问题、对象、约束和开放问题。
• 机器证据：文件版本、修订历史以及从原始对话到提交内容的轨迹。
• 人类 Gate：产品负责人决定这是不是值得进入下一阶段的真实意图。
• 建议指标：从首次对话到 intent 提交的时间，以及提交后真正进入 Design 的比例。

这一步的价值远不止“AI 帮产品经理写 PRD”：第一次交接就留下了机器可读的原始意图。后续阶段不必再依赖会议参与者的记忆来补上下文。

二、Design：让政策在 spec.md 生成时生效

传统设计往往把品牌、安全、合规、UX 和架构规则留到后期审查。规格已经写完甚至代码已经完成，政策负责人这时才发现冲突，返工自然昂贵。

指南建议让 Agent 读取已接受的 intent.md，同时加载企业政策和设计规范，在同一次工作会话里生成 spec.md。遇到政策冲突时，Agent 标出问题，但不替负责人做最终取舍。

• 提交工件：spec.md，包含需求、设计选择、边界、风险和未解决冲突。
• 机器证据：使用了哪些政策或 Skill、哪些要求被满足、哪些冲突仍然存在。
• 人类 Gate：产品负责人判断规格是否实现意图；政策负责人处理安全、合规或品牌冲突。
• 建议指标：intent 到 spec 的周期，以及规格提交后出现的需求返工。

这一步把政策介入提前了。规则从事后核对清单变成规格生成时的输入。

三、Build：先批准 plan.md，再允许 Agent 写代码

Build 是原文篇幅最大的一段。“让 Agent 写代码”只是起点，难点在于它依据什么行动、能改什么、怎样并行以及哪个系统说了算。

第一步是 Plan Mode。Agent 先阅读代码库，写出准备修改的文件、实施顺序、风险和验证方法，形成 plan.md。工程师先审计划，再允许执行。这样，人类在代码大量生成之前就能纠正方向。

第二步是把不同类型的知识放进不同控制层：

• CLAUDE.md 保存构建命令、架构约定和反复出现的项目错误，最好保持一页左右，并随项目变化更新。
• Skill 保存安全标准、设计规范和重复流程，提高 Agent 遵循组织政策的概率。
• Hook、测试和 CI 承担必须稳定执行的规则，例如冻结目录不可修改、修 Bug 时测试不可改写。
• Settings、sandbox、网络白名单和短期凭证限制 Agent 能看到和触达的环境。

这些层不能互相冒充。CLAUDE.md 和 Skill 属于提示与知识层；必须永远成立的边界要由 Hook、CI、分支保护或权限系统强制。硬规则也不会自动正确，只会稳定执行被写进去的规则。

第三步是处理事实源和并行。仓库或旧业务系统都可以权威，但不能同时维护两份没有链接的“真相”。平行会话适合在独立 worktree 中承担互不干扰的完整任务；Subagent 是主会话里的窄职责助手，拥有独立上下文和受限工具。共享文件较多的工作仍应串行，并行上限最终取决于人类能审多少结果。

• 提交工件：获批的 plan.md、代码 diff 和测试。
• 机器证据：构建、测试、计划一致性以及 Hook 的允许或阻断记录。
• 人类 Gate：工程师批准计划，并判断实现是否符合意图、风险是否可接受。
• 建议指标：首次实现即合并比例、返工轮次以及 diff 与 plan 的一致性。

四、Test：让证据独立于写代码的 Agent

Agent 在交给人之前，应能自己运行构建、测试、类型检查和视觉验证，并根据失败结果继续修正。这是反馈回路：失败立即回到执行者，而不是先进入人工审查队列。

但“Agent 自测通过”还不够。验证证据不能由产生代码的同一执行过程随意改写。对 Bug 修复，先写出并提交一个确定会失败的测试，再通过 Hook 或审查规则阻止 Agent 在修复过程中修改它。否则 Agent 可能通过放宽断言、删除边界条件或重写测试制造绿色结果。

连续反馈回路和独立 verifier 也不同。前者在同一会话里快速纠错；后者使用新的上下文和独立工具权限重新验证结果，避免继承写代码时的假设。运行日志、截图、会话记录、OpenTelemetry 和 PR check run 共同构成证据链，而不是一句“测试已经通过”。

测试范围还要覆盖 Agent 配置。原文建议从近期真实工作中收集 20–50 个任务；模型、提示词、CLAUDE.md、Skill 或 Hook 变化时都运行同一批 eval。每次生产事故也应变成永久 eval。

• 提交工件：测试日志、截图差异、独立验证结论和 eval 结果。
• 机器证据：一键验证命令、受保护的失败测试和持续回归集。
• 人类 Gate：代码所有者判断证据是否真的覆盖预期行为和风险。
• 建议指标：Agent 自检后的首次 CI 通过率、eval 通过率以及生产回归数量。

五、Deploy：Agent 自动走到生产 Gate 为止

Deploy 章节包含三层能力：AI 参与 PR review、Hook 充当审批闸门、Agent 在 CI/CD 中非交互运行。共同原则是：Agent 可以自动完成生产闸门之前的一切，但没有路径自行越过生产授权。

AI review 可以按 Bug、安全、合规等 pass 检查 PR，也可以响应 @claude 评论修改代码、修复检查并推送更新。REVIEW.md 负责定义什么算 Important、什么只是 Nit、哪些生成文件或 CI 已覆盖内容应该跳过。

职责分离不能消失。AI review 的发现可以影响判断，却不能自行批准或阻断 PR；分支保护仍要求 code owner 批准，写代码的 Agent 没有批准自己改动的路径。

发布能力按环境分级：开发环境可以更自由，staging 居中，生产环境只能准备发布并等待具名发布负责人授权。Agent 作业运行在沙箱中，使用短期、范围受限的凭证，默认没有常驻生产权限。

回滚必须是整条流水线里演练最多的路径。它最好能由单条命令执行，并在 staging 定期练习；只有回滚已经被证明可用，Maintain 阶段才有资格在严重异常时调用它。

• 提交工件：PR、AI 审查发现、人类批准记录、发布与回滚日志。
• 机器证据：统一 review pass、Hook、branch protection、sandbox 和流水线检查。
• 人类 Gate：code owner 判断代码风险，发布负责人授权生产动作。
• 建议指标：首次审查时间、审查意见解决时间、各 Gate 等待时间和 DORA 指标。

六、Maintain：让生产异常重新变成 intent.md

Maintain 是六阶段中唯一从“由人启动 Agent”走向“事件自动唤醒 Agent”的部分。原文因此把成熟的前置条件放得很重：可观测性、稳定基线、低噪声触发、独立权限边界和已经演练的回滚，缺一项都不应直接上自动处置。

异常检测本身保持确定性。版本化脚本监控 CI 失败率、5xx、发布后错误率或流程指标；只有控制带被突破，才调用 Agent。轻度异常只记录，中度异常允许只读诊断，严重异常也只能开 PR 或触发预先批准的 runbook。

Agent 把异常、证据、受影响系统、建议结果和开放问题写成新的 intent.md，重新进入 Plan。修复发布后，事故加入 eval 集，生产反馈由此纳入研发系统。

原文还用 Claude Tag 展示事故频道中的完整闭环：晚上出现紧急消息后，Claude 以自己的身份加入讨论，读取频道历史、检查指标并提出诊断；生产动作等待人类明确授权。获得授权后，它执行已批准的回滚，用 MCP 确认指标恢复到基线，再把复盘写进版本化 lessons 文件。小而明确的问题直接形成 PR，范围更大的问题生成新的 intent.md。

原始案例图。频道里保留请求、诊断、人工授权、动作和验证记录，因此频道本身就是事故审计轨迹。

• 提交工件：诊断、事故记录、修复 PR、版本化复盘和新的 intent.md。
• 机器证据：确定性控制带、指标恢复验证以及事故对应的永久 eval。
• 人类 Gate：服务负责人分诊，批准高风险行动，并决定立即修、排期还是驳回。
• 建议指标：异常到 intent 的时间、发现转成合并修复的比例以及同类事故复发率。

实施顺序：12 个 play 不是六阶段清单

指南按六阶段讲解，但实际落地顺序由依赖决定。官方依赖图共有 12 个 play，不能机械地从 Plan 自动化一路做到 Maintain。

原图中的箭头表示采用依赖，不表示六阶段的运行顺序。

1. 基础层 · 可以并行开始 Capture intent · CLAUDE.md · Feedback loop · Hooks · Plan mode

   先得到可读输入、可运行证据和动作边界

2. 复用层 · 有基础后再扩展 Skills · Subagents · Evals

   让政策可复用、验证更独立、配置可回归

3. 组织层 · 接入正式交付 Requirements & design · PR review

   把工件与证据接进跨角色决策和代码审批

4. 自治层 · 最后开放 CI/CD · Closing the loop

   非交互运行到生产闸门，生产事件重新进入计划

第一层可以同时开始：Capture intent、CLAUDE.md、Feedback loop、Hooks 和 Plan Mode。它们先建立可读输入、项目上下文、可运行证据、动作边界和写代码前的计划。

第二层再加入 Skills、Subagents 和 Evals，让政策可复用、验证更独立、配置可以回归。第三层把这些能力接进 Requirements & design 和 PR review。第四层才进入非交互 CI/CD 与 Closing the loop。

原则很直接：先证明 Agent 能在局部任务里留下可信证据，再给它更长运行时间；先证明边界不可绕过，再给它更多工具和权限。直接从线上异常自动修复开始，等于跳过意图、测试、审批、权限和回滚的全部前提。

这份指南没证明什么，以及团队怎样开始

这份 Playbook 很实用，但有三条边界不能被厂商叙事冲淡。

第一，蓝图不是效果证据。原文建议观察周期、首次 CI、PR 审查、DORA 和事故复发率，却没有公布客户前后对照。团队必须用自己的试点数据验证。

第二，可追踪不等于已经合规。Git 和 PR 能留下记录，但可靠审计还需要身份、不可绕过的权限、事实源映射、日志保留、职责分离和组织认可。

第三，确定性不等于正确。Hook 会稳定执行写入的规则，CI 会稳定运行已有测试；规则或测试设计错误时，系统只会更可靠地执行错误判断。事故必须能反过来修改测试、eval、Skill 和权限策略。

因此，不要先建设覆盖六阶段的大平台。选择一种低风险、高频、容易验证的改动，例如文案修正、内部小工具或已有成熟测试的局部 Bug，先跑通下面四步。

验收时不要问 Agent 写了多少代码，而要看意图接受到 PR 的周期、Agent 自检后的首次 CI 通过率、人类审查时间与返工轮次、合并后的逃逸缺陷或回滚次数。周期缩短且质量和审查负担没有恶化，再逐步增加任务范围、平行会话和权限。

整份指南最终可以压回三个问题：每一阶段留下什么证据，什么边界不可绕过，谁为最后的判断负责。先让一种改动完整、可验、可追踪地走到 PR，再谈让整个循环自己运行。