代码不再是瓶颈。这句话从 Anthropic 官方嘴里说出来不是愿景是现状——Claude Code 工程主管 Fiona Fung 在 Code w/ Claude SF 2026 上说得很直白默认每个 commit 都是 Claude 辅助的最近四个月我没见过一个非辅助提交。你八成也见过同样的错位写代码突然变便宜了可流程没变。同样的评审闸门、交接、策略照样卡在 agent 生成的代码上。2026-08-21Anthropic 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?产品负责人批准后进入 DesignClaude 读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 个最近的真实任务及验收结果每个写成 evalprompt 定义可接受的检查。套件在 CI 上非交互跑并且在 CLAUDE.md、skills、hooks 变更时也跑——配置在指挥 agent该像代码一样被回归测试。一次生产事故写成一个 eval进套件当回归测试由事故所属团队写。这就是「评测取代 PRD」的落法别写冗长需求文档输出评测集。Stage 5 DeployReview 是双车道治理在 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.yamlmetric: 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、安全取而代之。她讲了四个被重写的规范。Planningroadmap 改成 just-in-time。六个月的路线图三个月就过时干脆不预设那么多。规划仪式从设计文档挪到 PR 里的讨论和原型里先原型、放一批内部用户用、按反馈迭代。Context gathering先问 Claude再问作者。以前查代码问题先找写代码的人。现在 PR 都是 Claude 辅助的「谁改的」这个问题不够用了。你想知道的是更深的层谁导致回归谁懂这个客户问题这个决策的上下文是什么把这些问 Claude它经常能直接答还带着更多数据和上下文。然后习惯性多问一句这事能自动化吗Code reviewtrust 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 monitoringuctm 用五个专职 agentorchestrator/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 链本身就是你的记忆和回看依据。结论这篇文章真正想说的不是「AI 能写代码」。那是 2025 年的话题了。Anthropic 官方这份 playbook 说的是更硬的东西代码不再是瓶颈之后你的流程必须按新成本结构重造重造的锚点是提交的 artifact重造的目的是把人的判断留在它该在的闸门上。环形流程转起来之后人的位置很明确——在环的上方。用官方一句话收尾The loop keeps running. Human judgement stays above it.如果你也在重写团队的流程现在卡在哪一环最痛plan、review 还是 deploy评论区报个阶段名我下一期就按它展开。觉得这份官方作业值得抄的点赞收藏不迷路这个系列我会继续拆 agent 时代的工程方法论。
