Anthropic 的 AI-Native SDLC：重新定义软件开发生命周期，代码不再是瓶颈-Seo优化-塔城地区网站建设公司

代码不再是瓶颈。这句话从 Anthropic 官方嘴里说出来，不是愿景，是现状——Claude Code 工程主管 Fiona Fung 在 Code w/ Claude SF 2026 上说得很直白：默认每个 commit 都是 Claude 辅助的，最近四个月我没见过一个非辅助提交。

你八成也见过同样的错位：写代码突然变便宜了，可流程没变。同样的评审闸门、交接、策略，照样卡在 agent 生成的代码上。2026-08-21，Anthropic Applied AI 团队把他们的内部做法整理成《The AI-Native SDLC playbook》公开了，讲的就是一件事：当代码不再是瓶颈，软件开发流程该怎么重造。

这篇我按官方 playbook 拆到底，再补一层官方工程组织怎么改的（Fiona Fung 那场演讲），最后落到你从哪开始。

传统 SDLC 是为「写代码最贵」设计的

先看清楚要改的东西长什么样。传统 SDLC 六阶段——规划、设计、构建、测试、部署、维护——每一段都是独立阶段、不同角色所有。产品经理写需求，架构师把需求变设计，工程师把设计写成代码，QA 验证，发布团队上线，运维盯着生产。阶段之间靠文档、ticket、签认传递。

这套流程本质是为一个前提设计的：最贵最耗时的是写代码。

PRD、估时仪式、产品安全评审，这些东西存在的意义，是让动辄几周几个月的开发工作在动手前强制对齐。等代码本身变便宜了，问题就出来了。官方 playbook 给了三个必然结果：

瓶颈移到 build 左右两侧。plan、review/test、deploy 还在人速，build 塌缩到几小时。
控制对不上现实。一行行人工 review 的前提是代码是某个人写的；一旦 agent 写出大部分 diff，这套东西就跟不上了。
治理成本上升。例外照样要过周会月会的委员会。

拿安全举个例子就懂了。安全团队是按人速配置的，agent 把代码产出翻倍，结果要么 review 队列积压，要么代码在没看够的情况下上线。受监管的组织两条路都不能接受。

核心转变：线性流 → 循环，artifact 链即审计链

AI-native SDLC 不是把传统流程里每个环节替换成 AI，是换了一套组织逻辑。

传统 SDLC 是线性流：这个阶段结束、盖章、交给下个阶段。AI-native 变成一个环，AI 嵌在每个点上，阶段间靠自动化交接。每个阶段结束都往版本控制里提交一个 artifact，下一个阶段读它启动：

从 Plan 到 Deploy，前几个阶段的 artifact 是.md文件——因为产品负责人和 agent 能读同一个文件、在上面同一个意思上工作。从 Build 开始，artifact 变成代码和它的记录。提交链就是审计链：谁要了什么、agent 产出了什么、谁批准了什么，全在 git 历史里。

人没有被排除。官方反复强调：需要判断的决策永远由人负责，只是人的注意力跟着要审查的 artifact 走，集中在闸门上，而不是每个阶段从头再来一遍。

Stage 1-2 Plan + Design：想法一次成型，需求与设计压缩成一个 session

传统流程里，一个想法进 backlog，过用户故事、story points、细化会议，每次交接所有权转移一次，到工程手里已经离原意好几层。AI-native 的第一步是让想法以提出人自己的话记录下来，存成intent.md——一个人类可读、机器可执行的 proto-spec。

做法是：提想法的人直接跟 Claude 头脑风暴，描述现状哪里不行、谁受影响、更好的样子是什么、哪些不做。Claude 会像分析师那样追问：范围、用户、约束、成功标准。然后按组织模板（可编码成 skill）写成intent.md，本人纠正 Claude 误解的部分，提交到共享的 intent 目录。

长这样：

# Intent: claims status self-service Author: J. Ortiz (claims operations). Status: draft. ## Problem Customers phone the contact center to ask where their claim is. Handlers spend roughly a third of call time on status-only queries. ## Proposed outcome Customers see claim status, next step and expected date in the portal. ## Affected users and systems Claims handlers, portal team, claims-core API. ## Constraints No new PII in the portal session. Existing authentication only. ## Open questions Do third-party loss adjusters need access too?

产品负责人批准后，进入 Design：Claude 读intent.md，产出需求加设计合一的spec.md。注意这里是同一个 session 完成需求分析和设计——传统流程里分析师把想法写成需求、设计师再把需求解读回设计，分离是为了追责，但慢且有损。AI-native 让 policy 在写 spec 的时候就被应用：品牌、安全、合规、UX 标准以 skill 形式存在，作为约束参与生成。产品负责人审 spec，但不写 spec。

Governance 的要点：spec、生成它的 prompt、生效的 skill 版本全进版本控制。产品负责人逐个解决被标记的 concern（这些是分析师会升级的问题），再决定是否进入 build——高风险事项咨询技术负责人，但进不进入 build，永远由人拍板。接受 spec 的 merge 或 review 就是启动 build 的触发。

Stage 3 Build：没有验收的计划不实现，机构知识变成文件

Build 这一章信息量最大，官方给了一整套配套机制。

plan mode 是默认起点。工程师开 Claude Code 就进 plan mode，把spec.md交给 Claude，让它先产出实施计划再动手。传统做法是工程师读完设计直接写码，改动哪些文件、先做哪步、测什么，全在工程师脑子里。plan mode 强制把计划落成plan.md——文件清单、工作顺序、风险、证明——提交进版本控制，之后的 PR review 拿 diff 跟它比对。

对计划要审讯式提问：这个改动可能破坏什么？哪步风险最高？Claude 选了哪些别的方案但没做？改到「一个没见过对话的工程师，光看计划就能实现」为止。然后接受计划，让 Claude 实现——计划扎实的话，往往一次通过。实现偏离计划时，同一个 commit 里更新plan.md，甚至用 hook 强制两者同步。

guardrail 成熟后，routine 工作可以开auto mode：工程师批准计划，Claude 每个改动不再逐次询问。配套的 CLAUDE.md 收拢上下文、skills 编码策略、hooks 挡危险动作、测试套件能跑，auto-accept 就成了默认。

CLAUDE.md 是给 agent 的入职文档。用/init在仓库里生成初稿，然后砍到一页——构建/测试/lint 命令、真正要紧的约定、Claude 经常搞错的事。规则很朴素：Claude 同一个错误犯两次，就把修正写进 CLAUDE.md。一页是因为 Claude 每个 session 开头全量读它，任何过时的内容都在浪费上下文。

Skills 是机构知识。官方给了一条判断规则：必须一致执行的知识写成 skill；属于 CLAUDE.md 或提示词的东西别写成 skill。skill 是一个带SKILL.md的文件夹，frontmatter 写明什么时候触发，正文写该做什么。触发要测：换着法子让 Claude 做相关任务，确认 skill 每次都加载。策略变了，改 skill 让 policy owner 签认，工程师下一个 session 自动拿到新版本。

Hooks 是 build 期的护栏。skill 是建议性控制——让违反变罕见；hook 是确定性层——让违反几乎不可能。build 阶段 hook 最多：挡掉对生成类、冻结包的修改，文件编辑后自动跑格式化与 lint，防止凭据进 diff。原则是 build 期 hook 要快、只盯改动的文件；重活（全套测试）放 commit 或 PR。

并行 session + subagent。一个工程师可以同时开几个 Claude Code session，各自在独立 worktree 里做独立任务；重复出现的子任务固化成 subagent（.claude/agents/*.md定义，写明何时用、能碰哪些工具）。官方建议从两三个 session 起步，上限取决于你 review 跟不跟得上。工程师的活从打字变成编排——官方原话：最终变成构建和维护 loop。

Stage 4 Test：让 agent 自检，把评测变成 CI

传统流程里，代码好不好的信号来得很晚——CI 要几分钟、测试人员要几天、生产要几周。agent 时代这个信号晚到意味着一个人得查所有输出，这人就成了瓶颈。

官方第一条：给 Claude 反馈环。一个make test、一次构建、一张截图 diff，让 session 在给你看之前先自己检查、自己修。UI 工作给 Claude 浏览器或截图工具，实现→截图→对比→调整，两三轮很正常。还要把「验证」写进 done 的定义：报告完成前先跑测试，把输出贴出来。

写 bug 修复要先写失败的测试。让 Claude 把 bug 复现成测试、跑、确认它按你预期的原因失败，提交这个测试。然后才让它改到通过，并且不许碰测试文件——用 test-file hook 强制。一个修之前就存在、agent 又改不了的测试，就是 bug 已修的证据。反馈环本身也要保护：修代码的 agent 不能削弱检查它的东西。

Continuous evals 是 agent 时代的 stage-gate QA。平台工程师收集 20-50 个最近的真实任务及验收结果，每个写成 eval（prompt + 定义可接受的检查）。套件在 CI 上非交互跑，并且在 CLAUDE.md、skills、hooks 变更时也跑——配置在指挥 agent，该像代码一样被回归测试。一次生产事故写成一个 eval，进套件当回归测试，由事故所属团队写。这就是「评测取代 PRD」的落法：别写冗长需求文档，输出评测集。

Stage 5 Deploy：Review 是双车道，治理在 agent 行动时执行

Deploy 的核心是两条：AI 进 PR review 环，hooks 变成审批闸门。

AI 双向 review。Claude 既按组织策略审进来的 PR，也回应自己 PR 上的评论。技术负责人写REVIEW.md定义审查的 passes——bugs 逻辑错误、security 漏洞、compliance（对照spec.md/plan.md/设计原则）——以及什么算 Important、什么算 Nit、什么跳过。Claude 审完给分级发现，但发现本身不批准也不阻挡 PR，分支保护仍要求 code owner 审批。review 里 @claude 一条评论，Claude 回应并推送修复，PR 线程记录请求和变更。发现的错误犯第二次，就写进 CLAUDE.md，从下一个 PR 起被抓住。人从读每一行，上移一层：这个改动是不是计划要做的、风险接不接受。

Hooks 是审批闸门。build 期 hook 允许或阻止动作、不需要人；还有一种 hook 会暂停动作等人批准，这就是发布闸门。平台工程师把必须保留的人工审批（变更管理签认、发布授权、编辑受保护路径）逐条表达成 hook：脚本在 Claude 行动前运行，返回 allow / ask / block。team hook 进.claude/settings.json入库；不可协商的 hook 进托管设置，单个人关不掉。block 要能解释自己：拦下的动作、原因、审批路径都出现在 Claude 输出里。

CI/CD 集成。Claude Code 非交互跑在流水线里干「需要判断」的活——triage 一次构建失败、总结 flaky 测试、写 changelog。执行要沙箱化：容器 + 网络策略 + 短时作用域 token，默认不持有生产凭据。部署工具通过 MCP 暴露成工具，按环境分级：开发环境 agent 自由部署；生产环境 agent 准备发布、release manager 授权、hook 强制生产闸门；staging 居中。rollback 是流水线里最该演练的路径——单命令、agent 能跑、定期在 staging 演练。一条原则贯穿全部：agent 可以走到生产闸门前，但过不去。

Stage 6 Maintain：闭环自己转起来

前面每阶段都要人启动。Maintain 把环关上：触发无需人在调用路径上，agent 诊断完把发现写成intent.md，重新进 Plan。

实现是个确定性检测脚本：选一个基线稳定的指标（CI 测试失败率、post-deploy 5xx、PR cycle time），滚动窗口算均值和标准差，用 Western Electric 之类规则既能抓尖峰也抓慢漂移。脚本本身版本控制、单元测试、完全不涉模型。分级配置在bands.yaml：

metric: ci_test_failure_rate baseline: rolling_30d rules: western_electric tiers: 1sigma: { action: log } 2sigma: { action: diagnose, tools: "Read,Grep,Bash(gh run view *)" } 3sigma: { action: propose, routes: [pull_request, runbook:rollback-deploy] }

1σ 只记日志，2σ 只读诊断，3σ 可以行动——但只限于开 PR 进 review gate 或触发预先批准的 runbook。agent 无头、无状态地跑（CI runner 上非交互 step，或沙箱容器里的 Agent SDK 服务），环能开始也能结束，不需要任何人启动。agent 诊断写成 Plan 格式的intent.md：异常是什么、证据、提议的产出、受影响系统、开放问题。on-call 工程师 triage：修、排期、忽略——忽略在调 band 降噪。修复上线时，为这个事故加一条 eval。

同一章还有两块：Claude Security定期跑代码库扫描（调度而非事件，findings 逐个验证并带置信度，单个 PR 放得下的走 review gate、更大的写成 intent.md），和Claude Tag让 Claude 进 Slack 频道当 incident 第一响应人（指标回基线了在 thread 里确认、post-mortem 写进版本化 lessons 文件，channel 就是审计链）。

组织实践：验证、审查、安全成了新瓶颈

Fiona Fung 那场演讲补齐了机制之外的视角：写代码、写测试、重构很少再拖慢团队了，但验证、code review、安全取而代之。她讲了四个被重写的规范。

Planning：roadmap 改成 just-in-time。六个月的路线图三个月就过时，干脆不预设那么多。规划仪式从设计文档挪到 PR 里的讨论和原型里：先原型、放一批内部用户用、按反馈迭代。

Context gathering：先问 Claude，再问作者。以前查代码问题先找写代码的人。现在 PR 都是 Claude 辅助的，「谁改的」这个问题不够用了。你想知道的是更深的层：谁导致回归？谁懂这个客户问题？这个决策的上下文是什么？把这些问 Claude，它经常能直接答，还带着更多数据和上下文。然后习惯性多问一句：这事能自动化吗？

Code review：trust but verify。Claude 包掉 style、lint、PR 反馈请求、提交前抓 bug 和补测试。人留在真正需要 expertise 的地方：法务审核、信任边界和安全敏感代码、产品 sense 和 taste。而且这个平衡要持续评估——下一个模型出来，你需要人做的东西可能又不一样。

Team makeup：角色在模糊。PM 在写代码，工程师开始接手内容与设计。她招人重点放在两类：有产品 sense 的 creative builder，和有深系统功底的工程师。原话是：「raw throughput 不是我要的，模型处理那个。」

三个指标，她建议每个工程负责人现在就开始盯：onboarding ramp time 降、PR cycle time 降、Claude-assisted commits 升。最后那条注意别误解——吞吐不是成功，能解决问题的吞吐才是。

其实之前的系列我也写过

这套东西我不陌生。我此前写过一组《复杂软件系统的 Vibe Coding 实践》系列——第一篇《从需求到规格》就是 superpowers 实操，跟官方 Stage 1-2 的 brainstorming→spec 是同一条路；第二篇《拆计划与 TDD 实现》对应 Stage 3-4 的 plan 化 + 先写失败测试；第三篇《工具配置与迭代收尾》讲的就是把流程固化成 CLAUDE.md、skill、hook，跟 Stage 3 的机构知识文件化一个意思。

差别在粒度。官方 playbook 是组织级机制与治理：谁签认、哪些审批闸门必须保留、配置怎么托管、度量怎么算。我的实操系列是一个人或小团队能照走的路径：命令、skill、hook 怎么落地。社区把它进一步固化成流水线——claude-sdlc 用 15 个角色 skill 覆盖每个 SDLC 阶段（kickoff 到 production monitoring），uctm 用五个专职 agent（orchestrator/specifier/planner/builder/verifier）跑 spec-driven 开发加独立验证，sdlc-framework 用 worktree 并发和模型分级。方向一致，都在复刻官方这套「artifact 链 + 人在闸门」。

你从哪开始

官方给了一个极朴素的起点，Fiona 也说了同一句：挑你团队最吵闹的那个 workflow——最贵的、最让你头疼的、大家最不想参加的。问它还在不在服务它的目的。如果不在，问能不能自动化。

我按这套逻辑给你一条渐进路线，别一口气全上：

先 artifact 化。选一个项目，把想法、规格、计划落成 intent.md / spec.md / plan.md 进 git。这一步不碰任何 agent 配置，先让「提交链即审计链」成立。
再开 plan mode。让工程师的 Claude Code 默认从 plan 开始，计划落盘，实现不偏离。
加 feedback loop。给 Claude 自检手段，报告完成前跑测试贴输出。这是性价比最高的一步。
再上 review 双车道。REVIEW.md 三 pass + @claude 修评论，人上移一层。
最后才碰自动化闸门。hooks、CI/CD 集成、evals——这些是前面的机制跑顺之后加速用的，不是起点。

单人开发者可以直接从第 1、2 步开始，连团队都没有，artifact 链本身就是你的记忆和回看依据。