The AI-Native SDLC playbook：把软件开发生命周期改成循环

Anthropic 的 Applied AI 团队写的《The AI-Native SDLC playbook》，讲怎么用 agentic AI 重新设计整个软件开发生命周期。下面是它的中文解读。

代码不再是最慢的环节

组织用 AI 写代码的速度，一年前还无法想象。但代码周围那套流程没跟上。

很多工程团队还在用同样的审批、评审、交接和政策，把 agentic coding（比如 Claude Code）带来的效率提升，卡在了流程上。

SDLC 是软件从想法到上线的过程。传统上分六段：规划、设计、构建、测试、部署、运维，各段由不同角色拥有。产品经理写需求，架构师做设计，工程师实现，QA 验证，发布团队发布，运维盯着线上。段与段之间靠文档、ticket、签字流转。

传统 SDLC 流程很重，是为了每步有问责和控制。但它是按"写代码最慢最贵"的时代设计的：PRD、估算仪式、安全评审，都是为了给那几周几个月的开发对齐。现在写代码不再是瓶颈了。

当构建阶段比传统 SDLC 允许的更快时，三件事随之成立：

• 瓶颈移到构建两头的步骤：主要是计划、评审/测试、部署，这些还在按人的速度跑。
• 控制手段跟不上现实，逐步不可收拾。逐行评审在"人写的时代"成立，一旦 agent 写了大部分 diff，就审不过来了。
• 治理成本上升，因为例外还是走每周每月开一次的会议和委员会。

Build 不再是最慢的环节，它周围按人类速度跑的步骤才是。中间几周的构建被压缩到几小时，但两头的阶段长度没变。

安全就是最典型的例子。安全团队按"人类产出"配人，当 agent 把代码量放大，要么评审队列越堆越长，要么代码带病上线。受监管的组织两者都不能接受，所以它的安全和政策检查必须跟上 agent 的速度。

什么是 AI-native SDLC

AI-native SDLC 是把旧的控制目标配上新的执行方式。它不是线性流程，而是一个环，AI 嵌在每个点上。它推动各阶段的自动交接和触发，解决传统 SDLC 阶段之间手动、笨拙的交接。

AI-native SDLC 的环形流程。

六段的转变

下表是传统 SDLC 和 AI-native SDLC（Claude 支撑）两端的光谱，大多数组织落在两者之间。

贯穿右列的那根线，是被提交的 artifact。每段结束写一个到版本控制（intent.md、spec.md、plan.md、diff 和它的测试、带 review 结论的 PR、incident 记录），下一段从读它开始。早期阶段 .md 是主要 artifact，因为产品负责人和 agent 能读同一份、改同一份；从 Build 往后，artifact 是代码和它的记录。commit 链也是审计轨迹：谁要的、agent 产了什么、谁批的。

人仍然对每个需要判断的决策负责。在 agentic SDLC 世界里，人的注意力跟着需要 review 的 artifact 转移。

Plays：手册的核心

plays 是手册的核心，分六段（计划、设计、构建、测试、部署、运维），合起来覆盖整个生命周期。每个 play 讲：改什么、怎么起步、具体实现步骤、治理考量、怎么衡量有没有用。

这些步骤是模块化的，组织可以按需在不同时间优先转型不同阶段。每个 play 在 Prerequisites 里点名它的依赖。

plays 按阶段列出，箭头是推荐的采用顺序。从没有箭头指向它的 play 开始；对其他 play，指向它的箭头就是采用前要先做的。

一个被接受的 artifact 触发下一个阶段：被接受的 intent.md 触发需求和设计；被批准的 spec.md 触发 plan mode；合并的 PR 触发流水线；生产中越界的控制带写下一条 intent.md，如此循环。

一开始每个步骤都靠人手工敲进来，终态是环：每个被接受的 artifact 触发下一道门。人的注意力集中在门上，review agent 标出来的东西，而不是每段从头开始。

Stage 1：计划（Plan）

想法不用再等人来写。意图被捕捉一次，用发起人自己的话，存成版本化的、下一段能直接执行的 artifact。

intent.md 可以从不同入口进来：一个人有想法，一个 ticket，或一个 incident 通过 alert 冒出来。当一个人有想法时，他跟 Claude 头脑风暴，产出一个 markdown proto-spec。传统 SDLC 里，这个人还得说服产品经理帮他写下来。Claude 生成的 proto-spec 人可读、版本化、下一段可直接消费。

不管 intent 来自事件触发还是 agent，步骤都一样：产品负责人 review 并纠正 agent 写的 intent.md，然后才 commit。

执行步骤：

1. 发起人用自己的话向 Claude 描述问题：现在做不到什么、影响谁、更好了是什么样、哪些不做，不需要正式语言。
2. 头脑风暴到想法具体。Claude 问分析员会问的问题：范围、用户、约束、成功是什么样。
3. 让 Claude 按组织模板（可编码成 skill）写成 intent.md，覆盖问题、预期结果、受影响用户和系统、约束、开放问题。
4. 发起人纠正 Claude 理解错的地方。
5. commit 到共享 intent home。作者和时间戳进记录，产品负责人从这里接手。

一个 intent.md 的样子：

# Intent: claims status self-serviceAuthor: J. Ortiz (claims operations). Status: draft.## ProblemCustomers phone the contact center to ask where their claim is.Handlers spend roughly a third of call time on status-only queries.## Proposed outcomeCustomers see claim status, next step and expected date in the portal.## Affected users and systemsClaims handlers, portal team, claims-core API.## ConstraintsNo new PII in the portal session. Existing authentication only.## Open questionsDo third-party loss adjusters need access too?

治理层面：证据就是提交的 intent.md，列了作者、时间戳、完整修订历史。产品负责人批准，接受/拒绝的决定记录为 merge 或关闭 review。

• 前置指标：从第一次对话到提交 intent.md 的时间，从 git 历史看，预期从数周降到几小时。
• 滞后指标：survival rate，即产品负责人接受进 Stage 2 的比例，以及同一变更在第一份 spec.md 提交后 intent.md 又被改了几次。

Stage 2：设计（Design）

需求和设计压进一次会话。政策在写 spec 时就应用，而不是几周后的 review 里才发现。

intent.md 被批准后，Claude 拿它产出需求和设计 spec，由组织的 brand/security/compliance/UX skill 指导。产品负责人 review 那份 spec，但不写它。目标是产出一份工程团队能据以规划、并标出风险点的 spec。

前端是最清楚的例子。intent.md 被接受后，产品负责人在 Claude Design（beta）里起稿 mock、迭代，再导出到 Claude Code 构建。

执行步骤：产品负责人开一个带组织 skill 的会话、附上 intent.md；prompt 指向它、点名约束、要求标出风险点，先手动跑再固化成 slash command，再让 intent.md 被接受成为触发，用非交互 job 在 merge 时跑、commit spec.md 成 PR；产品负责人拿 spec 对想法，先处理被标出的风险点；spec.md 和 intent.md 一起 commit，记录要了什么、决定了什么；产品负责人决定是否进 build，高风险咨询技术负责人，这始终是人做的决定。

用什么样的 prompt：

Read the attached intent.md and produce a requirements and design specfor integrating it into our existing codebase. Apply the skills availableto you so the plan conforms to our brand guidelines, security policiesand UX standards. Document the spec fully as spec.md, ready to hand tothe engineering team. Describe clearly any areas of concern, especiallywhere you cannot satisfy contradicting policies.

治理层面：政策在读 spec 时就被应用，而不是几周后才发现。spec、生成它的 prompt、生效的 skill 版本都记在版本控制里。

• 前置指标：intent.md commit 到 spec.md commit 的时间，对比老的需求加设计周期。
• 滞后指标：build 开始后的需求返工，数首次 plan.md commit 之后 spec.md 的 commit 数。

Stage 3：构建（Build）

没有一份被接受的 plan，就不实现。机构知识变成 agent 会读的文件，护栏以代码形式运行。

Plan mode 当默认起点

工程师用 plan mode 开 Claude Code，把批准的 spec.md 给它，让它迭代 plan，直到工程师满意。传统上工程师读设计就开写，怎么改、改哪些文件都留在脑子里，reviewer 第一眼看到的是完成后的 diff，想返工已经晚了。AI-native 是先有 Claude 在 plan mode 读代码、不改任何东西地产出书面 plan，工程师在写代码前纠正它。

执行步骤：给 Claude intent.md 和 spec.md，要一份点名改哪些文件、工作顺序、证明它的测试的 plan；审问它（会破坏什么、哪步最危险、哪些选项没选）；迭代到"一个没见过对话的工程师光靠 plan 就能实现"；commit 批准的 plan 为 plan.md，进审计轨迹；接受 plan 让 Claude 实现，plan 扎实的话常常一遍过；实现偏离时在同一 commit 更新 plan.md，可用 hook 强制同步。

治理层面：设计评审发生在任何代码生成之前，plan mode 强制这点：Claude 在你接受 plan 前不能改文件。常规变更工程师批，更高风险给技术负责人或架构师。

Auto mode

Claude Code 也能跑 auto mode：工程师批准 plan 后，Claude 逐个改而不逐个确认。当护栏成熟（调好的 CLAUDE.md、编码政策的 skill、阻止危险动作的 hook、Claude 能跑的测试），auto-accept 成为常规工作的默认：紧的 spec.md、小的爆炸半径、测试已覆盖的代码。

shift 是：从盯着 agent 改动作，变成 review 更长自主 session 之后的 artifact。auto-accept 配合 worktree 还能在个人和团队间并行，是让 SDLC 自主跑、并像 Stage 6 那样闭合循环的基础。

机构知识：CLAUDE.md 和 skill

CLAUDE.md 给 Claude 一个新加入者该有的上下文：约定、命令、架构、团队最常犯的错。以前在人脑袋和 wiki 上的知识，变成 agent 每次 session 开始读的文件，全体团队维护，每犯一次错迭代一次。

怎么弄：/init 生成初稿，砍到新加入者第一天需要的，check 进 git 让全团队共享，像代码一样被 review。一个有用的规则：Claude 同样的错犯两次，修正就进 CLAUDE.md。保持一页以内，因为 Claude 每次都读全部，过时的是占用上下文没好处。

一个 CLAUDE.md 的样子：

# Payments service## Commands- Build: make build- Test: make test (unit), make itest (integration, needs docker)- Lint: make lint (runs in CI; fix before pushing)## Conventions- Java 21, Spring Boot 3. No new Lombok.- Money is always BigDecimal, never double.## Things Claude gets wrong- Do not bump dependency versions; the platform team owns them.- The legacy v1/ package is frozen; changes go in v2/.

skill 是让机构知识可操作的方式：指令明确、版本化、应用广泛、政策变化时集中更新。规则：为必须一致应用的机构知识写 skill；属于 CLAUDE.md 或 prompt 的组件不要写成 skill。skill 是控制，但只是建议性，它让 Claude 更可能写代码时就应用政策，无法强制。必须始终坚持的政策，背后需要 hook 或 PR review 再查一遍。

Hook 当构建期护栏

skill 是建议性控制，hook 是背后的确定性层。Claude 大部分动作是文件编辑和 shell 命令，所以 build 阶段是 hook 最常触发的地方。build 期 hook 可以：阻止改受保护路径、每次文件编辑后跑 formatter/linter、把凭据挡出 diff。需要征求人批准的 hook 属于 Stage 5 的 gate，因为 build 期弹审批框会把一个人放回所有并行 session 的关键路径上。

并行 session 和 subagent

一个人能同时驱动几股工作流。并行 session 是另一个完整的 Claude Code 实例，在它自己的 git worktree 里干独立任务；subagent 在单个 session 里跑，是带自己上下文窗口和工具限额的限定助手。

怎么弄：把工作拆成碰不同文件的任务（共文件的同一 session 串行）；每个并行任务一个 worktree；两三个 session 是合理起点，上限是"一个人能 review 过来的数"；重复的活变成 subagent，定义在 .claude/agents/ 的 markdown 里，check 进 git。

给 Claude 一个反馈闭环

总得给 Claude 一个验证自己活儿的方式：测试、build，或者截图 diff。session 自查、自修，在人看到之前。反馈闭环别和 verifier subagent 搞混：闭环贯穿整个任务跑很多次；verifier subagent 是把最终检查打包成一种方式，在 session 认为完成后新开一个全新上下文跑一遍，结论不被产生代码的假设染色。

Stage 4：测试（Test）

传统上"代码能用"的信号来得晚：CI 几分钟后，测试之后，生产几周后。当 agent 产出代码时，晚信号意味着人得检查它所有输出，那个人成了瓶颈。AI-native 是给 session 一种在人看到之前自查的方式：跑测试、跑 build、截图，Claude 迭代到通过。

执行要点：把检查工作的序列包成单个目标（make test、npm test），失败非零退出；在 CLAUDE.md Commands 里列出每条命令和一个健康输出示例；把目标量化（"test_status.py 全过"、"截图匹配 mock"、"端到端返回 200"）；修 bug 先写失败测试，让 Claude 复现、确认按预期失败、commit，再让它不改测试地改到绿，用测试文件 hook 强制；UI 活给 browser 或截图工具、给 mock，让它迭代，两三轮正常；把验证变成"完成"的一部分。

最后环本身要保护：修代码的 agent 不能削弱对它的检查，用 hook 挡 fix 期间编辑测试文件，或 review diff 时拒绝任何碰测试的变更。

## Verifying your work- Build: make build (must finish with "Build succeeded")- Test: make test (all green; never skip or delete a failing test)- Lint: make lint (zero warnings)Run all three before reporting any task complete, and paste the output.If a test fails, fix the code, not the test.

CI 里的持续 eval

eval 是 AI-native 版的阶段关 QA：一套在 agent 配置变化时跑的套件。换模型、重写 prompt 时，eval 套件说 agent 还做不做到同标准。eval 要当活套件用：模型变强，曾经区分度高的用例不再区分，要从持续监控里加新用例。

怎么执行：平台工程师从近期工作收 20 到 50 个真实任务及期望结果，每个写成一个 eval（prompt 加判定标准）；套件在 CI 非交互跑，定计划并在 CLAUDE.md、skill、hook 变化时跑；用结果 gate 配置变更，skill 变更让通过率下降就 review 再 merge；每个生产 incident 变成一个 eval，留在套件当回归测试。

Stage 5：部署（Deploy）

review 双向跑，治理在 agent 行动时执行。agent 一直做到生产 gate，gate 之后一步不越。

AI 进 PR review 环

Claude 既给 review 又收 review。它按组织政策 review 进来的 PR，也处理自己 PR 上的 review 评论。这让工程师的 PR review 聚焦行为：判断意图和风险。

传统上评审容量按人类产出规划，PR 等 reviewer 全读完，质量随负荷波动。AI-native 是所有 PR 拿到同一套 review pass，按严重度排 findings，人的注意力上一层：变更是否达成 plan 意图、风险是否可接受。

执行要点：用托管 Code Review 服务最快起步；需要控制流水线或走自己云合同时用 claude-code-action 在自家 CI 跑；技术负责人把 review 政策写成根目录 REVIEW.md，分成组织在意的 pass（bug 和逻辑错、安全和漏洞、对照 spec.md/plan.md/设计原则的合规），定义 Important 和 Nit 的区别；findings 不单独批或不单独 block，branch protection 还是要 code owner 批准；reviewer 或作者 @claude 时处理评论并 push 修复；findings 回流进 CLAUDE.md，某错误第二次被抓到就进修正；每月给 findings 评级让 reviewer 变好、封顶 Nit 量。

治理：职责分离保住了：写代码的 agent 没法批准自己。REVIEW.md 政策套在所有 PR 上，findings、修复、评级、批准都记在 PR 历史，PR 就是审计记录。

Hook 当审批门

build 期 hook 允许或阻止动作、没人参与。hook 也能"问"：暂停动作直到某个具体的人批准，这是 release gating 需要的。要保留的人审门（change management 签核、发布授权、受保护路径编辑），由平台工程师表达成 hook，团队 hook 进 git，不可协商的放 managed settings，individual 工程师关不掉。block 要解释自己：hook 停住动作时，原因和通往批准的路径出现在 Claude 输出里。

CI/CD 集成和部署

在 CI/CD 流水线里非交互跑 Claude Code，沙箱执行让长跑 agent 安全，把部署能力通过 MCP 暴露出来，在 agent 需要前先练好回滚路径。

传统上流水线跑确定性脚本，任何需要判断的都等人。AI-native 是 Claude 在流水线里非交互跑判断步骤；部署工具通过 MCP 暴露给 agent，所以写和测变更的 workflow 也能发和回滚它，在组织按环境定义的 gate 内。

执行要点：从只读判断步骤开始（claude -p triage build 失败、总结 flaky test、起草 changelog）；在既有 gate 后加写步骤，agent 写的东西以 PR 进 branch protection，没有直推 main 的路；执行沙箱化（短时 scope token、默认没有生产凭据）；部署通过 MCP 暴露成按环境 scope 的工具，agent 的部署能力是 allowlist 而不是带凭据的 shell script；按环境分层自主：dev 自由、production 准备发布、release manager 授权、hook 强制 production gate；回滚是流水线里排演最熟的路，定期在 staging 练。

治理的原则就是：agent 可以做到生产 gate，不能越过它。branch protection 把 agent 写的都变 PR；production deploy hook 在命名 release manager 授权前 block 发布；非交互 run 以 agent 自己身份跑，流水线 log 把 agent 做的和触发它的工程师做的分开。

Stage 6：运维（Maintain）

环闭合。触发调用 Claude 时调用路径里没有真人，它发现的以 intent.md 重新进流水线。

各段 Claude 进 SDLC 都要人发起初始步骤，这一段聚焦自动跑 Claude 来闭合环。比如一个持续跑的监控 agent，在 bug ticket 提出后创建 intent.md，流经需求、计划、build、test、review。Stage 6 无头运行，段间有独立信心 gate：确定性检查或对抗性 review agent，决定上一段输出继续还是升级给人。

传统上运维是被动的：凌晨 3 点的 alert 可能被漏掉，ticket 躺在 backlog，post-mortem 行动可能进不了代码库。AI-native 是一个触发（控制带越界、ticket、频道消息、调度）在无人路径里调用 Claude，Claude 诊断、只走有 gate 的路、写成新 intent.md。人 triage 和 review，不用再启动它。

闭合环

一条确定性脚本看着生产，越界时调用 Claude。监控越界是"环自动跑"的好例子，Claude Tag 覆盖从别的频道进来的活。

执行要点：选一个有稳定滚动基线的指标（CI 测试失败率、发布后 5xx 率、PR 周期时间）；写检测脚本，通常是滚动窗口的均值和标准差加规则，让 band 能抓慢漂移也别漏 spike，脚本版本化、单测、完全确定性、不用模型；响应层级定义在版本化 config，1σ 只记日志、2σ 调 Claude 只读诊断、3σ Claude 能动（但只通过开 PR 进 review gate 或触发预先批准的 runbook）；触发层可以是 GitHub/GitLab 定时 workflow、监控栈 webhook、或 Cron Job，Claude 无状态跑；因为 run 无状态非交互，环能在没人启动的情况下开始和结束；agent 把诊断按 Stage 1 意图格式写成 intent.md；on-call 工程师 triage 队列，产品相关的转产品负责人，修现在、排期或关闭；修复上线后为 incident 加一个 eval。

一个 band.yaml（监测 CI 测试失败率）：

metric: ci_test_failure_ratebaseline: rolling_30drules: western_electrictiers:1sigma: { action: log }2sigma: { action: diagnose, tools: "Read,Grep,Bash(gh run view *)" }3sigma: { action: propose, routes: [pull_request, runbook:rollback-deploy] }

治理：层级边界由版本化 config 强制，permissions/managed settings 挡生产访问。调用、发现、triage 决定都带时间戳记录。agent 可触发的 runbook 预先批准。

几个例子：CI 测试失败率越 3σ，agent 隔离 flaky test 或开 revert PR；发布后 5xx 率越 3σ 且窗口内有部署，agent 触发既有回滚流水线；PR 周期时间触发漂移规则，agent 为工程领导写 report。

Claude Tag 当 on-call

Incident 也能从工作沟通 app 进来，比如晚上 10 点 incident 频道里一条紧急修复的消息。Claude Tag（Slack 里 public beta）让 Claude 以自己身份成为频道成员，每个新 incident 都有 first responder，响应本身变成未来 incident 的环和记忆。

对话和机构知识留在频道，任何成员能指导并行动响应。通过 MCP，Claude 验证指标回到基线并在线程里确认，把 post-mortem 写进版本化的 lessons 文件，未来调查能读。

Incident 不是仅有的活。在 ticket 上被 tag（走 MCP）或在频道里被问，Claude 一样 triage。小而清晰的修复以 PR 进 review gate，更大的写成 intent.md 给 Stage 1，环开始喂自己。

频道就是审计轨迹：request、diagnosis、人授权、fix，都停在 incident 处理的地方。

结语

模型和 harness 越来越强，组织不仅能改变产出代码的方式，还能重塑整个软件开发生命周期。这个转型让人还是那些需要判断的决定的主人，同时兼顾大型企业的治理和监管要求。

这份手册汇集了 Applied AI 团队在客户那里落地的做法。环一直跑，人在上面做判断。

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