解读 Anthropic《AI 原生 SDLC 手册》

作者：meng shao（@shao__meng） 原文：The AI-Native SDLC playbook 原文作者：Louis Claxton（Anthropic Applied AI 团队） 原文发布：2026 年 8 月 21 日

2026 年 8 月 21 日，Anthropic 在 claude.com 博客上发布了一篇题为 The AI-Native SDLC playbook 的长文。文章标注阅读时间 5 分钟，实际正文接近一万个英文单词，附带十几段配置和 prompt 示例。

它更接近一份操作手册，把 Anthropic 在企业客户那里落地 Claude Code 时积累的做法，按软件开发生命周期的六个阶段整理成了一组可以逐个采用的 play。这篇文章值得认真读，原因在于它讨论的问题已经在很多团队里出现：AI 写代码的速度上去了，但代码周围的流程没有跟上。

下面按原文的顺序把它的论证、做法和隐含的假设梳理一遍，最后给出我的判断。

一、问题出在流程，而不在代码

作者的起点是一个观察。过去一年，组织用 AI 生成代码的速度发生了变化，但审批、评审、交接、策略这些环节还是原来的样子。Claude Code 之类的工具带来的效率提升，在流程里被消耗掉了。

作者对传统 SDLC 的解释是：这套流程之所以在每一步都设文档、签字和会议，是因为它诞生在写代码最贵、最慢的年代。PRD、估点仪式、安全评审的存在，是为了在一个要持续几周到几个季度的开发周期之前，把所有人的理解强制对齐。另一个隐含的前提是每一步都由人来做，所以控制手段也都是针对人设计的。

当构建阶段从几周压缩到几小时，作者列出了三个后果：

• 瓶颈转移。计划、评审、测试和部署位于构建的两侧，这些阶段仍然按人的速度运行。
• 控制手段和现实脱节。人写代码时逐行审查说得通，agent 写了大部分 diff 之后审查就跟不上了。
• 治理成本上升。例外情况还要走每周或每月才开一次的委员会。安全团队是文中的例子：安全团队的人力是按人的产出配置的，agent 让代码量翻倍以后，要么审查队列积压，要么代码没审够就上线。受监管的组织两个结果都接受不了，所以安全和策略检查必须跟上 agent 的速度。

文章由此得出结论：实现阶段经历了什么样的变革，整个 SDLC 都需要经历同等程度的变革。

二、AI 原生 SDLC 的三个机制

作者对 AI 原生 SDLC 的定义是：保留原来的控制目标，换一套执行方式。

读完全文，可以把它归纳为三个相互支撑的机制。

1. 流程从线性变成循环

维护阶段发现的问题直接写成新的意图文件，重新进入计划阶段，而不再是“报一个 bug 等人来处理”。

2. 每个阶段以提交一个产物结束

每个阶段向版本控制提交一个产物；下一个阶段从读取这个产物开始：

早期阶段用 Markdown，理由是产品负责人和 agent 都能读、都能改同一个文件；从构建阶段往后，产物就是代码和它的记录。作者认为这条提交链本身就是审计轨迹，能够回答谁提了什么要求、agent 做了什么、谁批准的。

3. 人的注意力集中在门上

一个产物被接受，就触发下一阶段。一开始每一步都由人手动 prompt，目标状态是每个被接受的产物自动触发下一道门，人只在门口审阅 agent 标记出来的问题。

文中有一张传统与 AI 原生的对照表，Deploy 一行最能说明作者的思路：

作者也说明，大多数组织处在两列之间。

三、六个阶段

每个 play 按同样的结构书写：改变了什么、前置条件、需要的基础设施、执行步骤、治理考量、领先指标和滞后指标。这个结构本身值得借鉴，它把经验写成了可验证、可度量的东西。

以下按阶段梳理，重点放在具体做法和作者给出的理由。

Stage 1 · 计划：用 intent.md 捕获意图

传统流程里，一个想法要经过 backlog、user story、故事点、refinement 会议，每一次交接都换一个负责人，到工程团队手里时已经离原始想法隔了好几层。

文章的替代方案是让发起人直接和 Claude 讨论，用自己的话写成 intent.md，内容包括：

• 想要什么、为什么
• 有哪些约束
• 影响哪些用户和系统
• 还有哪些没想清楚的问题

实施上有几个细节。非工程师通过 claude.ai 或 Cowork 使用 Claude，不需要会 git，通过 GitHub connector 代为提交。单个产品最简单的做法是在产品仓库里放一个 intent/ 目录，让意图文件和后面派生出来的代码挨在一起；单独的 intent 仓库只在意图跨多个仓库时才划得来。

模板可以写成 skill，由技术人员搭建、负责人签字。产品负责人审阅并修正 agent 写的 intent.md，然后提交，接受或拒绝以 merge 或关闭 review 的形式留下记录。

度量。 领先指标是从第一次对话到 intent.md 提交的时间，作者预期从几周降到几小时。滞后指标是被产品负责人接受进入设计阶段的比例，以及 spec.md 第一次提交之后 intent.md 又被修改了几次，后者用来观察意图是否稳定。

Stage 2 · 设计：需求和设计合并为一次会话

传统做法里需求和设计是两个团队、两个阶段：分析师把想法写成需求，设计师再把需求解析回设计。作者承认这种分离是为了问责，但认为它慢且有损耗。

替代方案是让 Claude 读取已接受的 intent.md，在组织的品牌、安全、合规、UX skill 约束下一次产出需求和设计规格，并把有问题的地方标出来。产品负责人只审不写。

文章给出了一条演进路径：

1. 先手动运行这个 prompt。
2. 固化成组织级的 slash command。
3. 让 intent.md 在意图目录里被合并这件事成为触发器，由非交互任务自动生成 spec.md 并以 PR 形式提交。

到第三步，产品负责人第一次介入就是审这个 PR。审阅时先处理被标记的关注点，因为这些就是分析师原本会上报的问题，由产品负责人和对应的策略负责人逐个解决，在工程团队看到规格之前完成。

前端工作作者举了一个具体流程：从 intent.md 在 Claude Design 里出原型，迭代满意后导出到 Claude Code 构建。高风险的东西要咨询技术负责人，但决定由人做，接受规格这个动作就是构建阶段的起点。

治理。 策略在写规格时被读取和应用，而不是几周后在评审中被发现。规格、生成它的 prompt、当时生效的 skill 版本都在版本控制里。

度量。 领先指标是 intent.md 和 spec.md 两次提交的时间差；滞后指标是构建开始后的需求返工，具体做法是数 plan.md 首次提交之后又出现了几次 spec.md 提交，git log 直接能查。

Stage 3 · 构建：没有被接受的计划就不写代码

这是篇幅最长的阶段，包含六个 play。

Plan mode 作为默认起点

工程师用 plan mode 开启会话，把 spec.md 交给 Claude，让 Claude 反过来向工程师提问，迭代出实现计划。作者给的合格标准是：一个没看过对话的工程师能只凭这份计划把事做完。

计划提交为 plan.md，后续的 PR 评审要对照它检查 diff。实现过程偏离计划时，在同一个 commit 里更新 plan.md，可以用 hook 强制两者同步。这一步的治理价值在于设计评审发生在代码生成之前，那时改方向只是改文档。plan mode 本身就是执行机制，因为计划没被接受，Claude 不能修改文件。

Auto mode

等后面几个 play 的护栏成熟了，也就是有了调整过的 CLAUDE.md、编码了策略的 skill、能拦截不安全操作的 hook、Claude 能自己运行的测试，自动接受就成为日常工作的默认方式。

作者描述的变化是：从看着 agent 逐条改、逐个动作审，转为长时间自主运行之后审阅产物。这是后面并行工作和闭环自治的基础。

遗留系统和事实来源

这一节相当务实。Jira、ServiceNow、Figma、变更委员会不会因为你要做 AI 原生就消失，审计员和监管方已经认可这些系统，其他团队也依赖它们。作者给了三种配置：

CLAUDE.md

CLAUDE.md 的定位是新人第一天需要知道的东西：命令、约定、架构、常见错误。工作规则是：Claude 同一个错犯两次，修正就写进去。

文件保持在一页以内，因为每次会话都全量读取，过时的内容白占上下文。

Skill

作者给的经验法则是：必须一致应用的制度知识写成 skill，属于 CLAUDE.md 或 prompt 的内容不要写成 skill。

文章对 skill 的性质有一个清楚的界定：skill 是一种控制，但是建议性的控制。 它让 Claude 大概率在写代码时应用策略，但没有东西强迫会话遵守。必须始终成立的策略需要 skill 背后有确定性的东西，比如拦截操作的 hook，或者在 PR 阶段重新检查的评审。Skill 让违规变少，hook 让违规几乎不可能发生。

Hook 作为构建期护栏

构建阶段 Claude 做的大多是修改文件和运行 shell 命令，所以 hook 在这里触发最频繁。用途包括：

• 拦截对受保护路径的编辑（生成类、冻结的包）。
• 改完文件自动运行 formatter 和 linter。
• 把凭据挡在 diff 之外。

构建期 hook 要快，只作用于改动的文件，重型检查放到 commit 或 PR。作者特意说明，需要人审批的 hook 不该放在构建阶段，因为它会把人放回所有并行会话的关键路径上。

并行会话和子代理

两者的区别：

• 并行会话是另一个完整的 Claude Code 实例，在自己的 worktree 里做独立任务，彼此互不知晓，唯一的共享点是操作它们的工程师。
• 子代理在一个会话内部运行，有自己的上下文窗口和工具限制，适合重复性工作，比如验证应用能跑、清理多余的复杂度、探索代码库然后汇报。

作者建议两三个会话起步，上限看一个人能认真审阅多少条工作流，审得过来再加。工程师的工作变成编排，最终变成搭建和监控循环。

Stage 4 · 测试：每个会话先检查自己的工作，给 Claude 反馈回路

作者的论证是：传统流程里代码能不能跑的信号来得晚，CI 几分钟后、测试人员几天后、生产几周后。当 agent 产出代码时，信号晚意味着一个人要检查全部输出，这个人就成了瓶颈。

所以要让会话自己运行测试、运行构建、截图对比，迭代到通过，工程师看到的东西已经过了检查。几个具体做法值得记下来：

• 验证包装成单个命令，失败时非零退出。
• 目标要可量化，让 Claude 不用问人就能判断有没有做完。
• 修 bug 先写失败的测试。 让 Claude 把 bug 复现成测试，确认它以预期的原因失败，提交这个测试，然后才让 Claude 在不能修改测试文件的约束下让它通过。一个在修复前就存在、agent 改不了的测试，就是 bug 已经修好的证明。
• 回路本身也要保护。修代码的 agent 不能有能力削弱对这段代码的检查，做法是用 hook 阻止修复任务中对测试文件的编辑。

作者还区分了反馈回路和验证子代理。反馈回路贯穿整个任务反复运行；验证子代理是在会话认为完成之后，用一个新鲜的上下文窗口做终检，这样结论不受产出代码时的假设影响。

CI 里的持续评估

作者把 eval 叫作阶段门 QA 的 AI 原生对应物。eval 套件在 agent 的配置变化时运行，换模型、改 prompt、改 CLAUDE.md、改 skill、改 hook 都算。理由是：这些配置在引导 agent，应该得到和代码一样的回归测试。

做法：

1. 从近期工作里收集 20 到 50 个真实任务和可接受的结果。
2. 写成 prompt 加检查项（测试通过、lint 干净、行为不变、策略遵守）。
3. 定时运行，并在配置变更时运行。
4. 用通过率把关配置变更的合并。
5. 每个生产事故都变成一个 eval 留在套件里。

作者也提到 eval 套件是活的，模型进步之后有些用例会失去区分度，需要不断补充。

Stage 5 · 部署：agent 做到生产门之前，不能越过去

这一阶段的总原则是：agent 可以完成生产门之前的一切工作，但不能跨过这道门。

AI 进入 PR 评审

Claude 既评审别人的 PR，也回应自己 PR 上的评审意见。所有 PR 得到同一套评审，发现按严重度排序，人的注意力转向变更是否符合计划意图、风险是否可接受。

技术负责人在仓库根目录写 REVIEW.md，分成几个 pass：

• bug 和逻辑错误
• 安全漏洞
• 与 spec.md 和 plan.md 的一致性

同时定义什么算 Important、什么是 Nit、什么跳过。评审发现本身不批准也不阻塞 PR，分支保护仍然要求 code owner 批准。评审发现回流到 CLAUDE.md，第二次被标记的错误就写进去。

作者指出：职责分离得以保留，因为写代码的 agent 没有途径批准它。

Hook 作为审批门

构建期 hook 只有允许和阻止两种结果；hook 也可以“询问”，暂停操作直到指定的人批准，这正是发布门需要的。

做法是工程领导层和变更管理、合规一起列出必须保留的人工审批（变更签字、发布授权、受保护路径的编辑），平台工程师把每个门写成 hook。团队级 hook 放在 .claude/settings.json，不可协商的 hook 放在托管设置里，工程师关不掉。阻止时要说明原因和申请审批的途径。

受监管企业的托管设置

文章给了一份完整的托管设置，并逐条解释每一项在控制上的含义：

作者说这份配置是裁剪的起点，每一条 deny 都以能力为代价，平衡点取决于仓库的数据分级。

CI/CD 集成

Claude 用 claude -p 在流水线里非交互运行，承担需要判断的步骤。演进路径分两步：

1. 只读判断：分析失败的构建、总结 flaky 测试、起草 changelog。
2. 门后写操作：修 lint、更新生成的文档、响应 @claude 评论。

agent 写的一切都以 PR 形式经过分支保护，没有直接推 main 的路。执行沙箱化，使用短期的 scoped token，默认不持有生产凭据。部署通过 MCP 暴露为工具，按环境分级：开发环境自由部署，生产环境由 agent 准备发布、发布经理授权、hook 强制执行。

作者强调：回滚应当是流水线里演练最多的路径。 因为维护阶段的闭环会在指标越界时调用它，必须事先证明可用。

Stage 6 · 维护：闭环

前五个阶段都需要人来启动，这一阶段讨论 Claude 的自主运行。

闭环的核心模式

一个确定性脚本监控生产指标，用滚动均值和标准差加 Western Electric 规则检测慢漂移和尖峰，检测过程完全不涉及模型。响应分级写在版本控制的 bands.yaml 里：

Claude 把诊断写成计划阶段格式的 intent.md，从这里进入正常流程。服务负责人分诊队列，决定现在修、排期、或驳回；驳回用于调整控制带、减少噪音。修复上线后为这个事故增加一个 eval。

文中给了三个例子：

• CI 测试失败率突破 3σ，agent 隔离 flaky 测试或开回滚 PR，由评审门决定。
• 部署后 5xx 率突破 3σ 且时间窗口内有部署，触发现有的回滚流水线。
• PR 周期时间触发漂移规则，agent 给工程领导写一份报告。

第三个例子是想说明这套机制对流程指标同样有效。

定期代码库扫描

作者的论证是：安全扫描是特定模型下对代码库的一次时点判断，两个条件都会过期：代码每周在变，每一代模型都能找到上一代漏掉的漏洞。所以扫描要按计划运行，不需要人启动，发现走和其他变更一样的门。

能在一个 PR 内修完的走建议补丁加评审门，架构级的写成 intent.md 从计划阶段开始。确定性检查留在 CI 里，模型扫描覆盖那些检查不擅长的、依赖上下文的漏洞。

这一节介绍的 Claude Security 是 Claude Enterprise 的公测功能，需要安装 GitHub App，按消耗计费。

Claude Tag 值班

Claude 以自己的身份加入 Slack 事故频道，每个新事故都有一个第一响应者。频道里任何人都能引导和参与响应，频道历史就是审计记录。小修复以 PR 走评审门，大问题写成 intent.md。

四、贯穿全文的设计原则

把六个阶段放在一起看，有几条原则反复出现，它们比任何单个 play 更能代表这篇文章的思路。

• 建议性控制和确定性控制分两层。 Skill、CLAUDE.md、prompt 属于建议层，让正确行为成为大概率事件；hook、沙箱、分支保护、托管设置属于确定层。凡是“必须成立”的策略，建议层后面都要有确定层。
• 检测用确定性脚本，响应分级，行动受门约束。 模型只在指标越界之后被调用，能做什么由层级决定，行动只能通过 PR 或预批准的 runbook 进行。
• Agent 不能批准自己的工作，也不能削弱对自己工作的检查。 写代码的 agent 没有批准 PR 的途径，修 bug 的 agent 不能改测试，终检由一个新上下文的子代理完成。
• 引导 agent 的配置和代码同等对待。 CLAUDE.md、skill、hook、REVIEW.md 全部进 git，走 code review，跑回归 eval。
• 度量来自已有系统。 几乎所有指标都从 git 时间戳、PR 元数据、CI 日志、OpenTelemetry 导出、事故追踪器里获取，不新建度量体系。
• 人不在并行会话的关键路径上。 构建期不设人工审批 hook，人的审批集中在发布门和产物评审。

五、评价

长处

这篇文章正面回答了受监管企业最关心的问题：agent 写了大部分代码之后，问责、审计、职责分离、变更管理怎么办。

它的答案是把这些控制目标全部映射到 git 产物、hook、分支保护和托管设置上，而不是取消它们。对合规、安全、平台工程的读者来说，这比“提效”的说法更有说服力。

另一个长处是演进路径写得务实：几乎每个 play 都有先手动、再固化为命令、再自动触发的分步；遗留系统那一节直接承认 Jira 不会消失；托管设置那一节明确说是起点，不是推荐。

需要留意的地方

这是一篇产品文章。 作者来自 Anthropic，全文以 Claude Code、Claude Design、Claude Security、Claude Tag、Cowork 为载体，其中 Claude Security 和 Claude Tag 还在公测，且限于 Enterprise 订阅。框架本身是工具无关的，但落地细节绑定 Claude 生态。读的时候要把原则和具体产品分开。

前置条件不轻。 整套体系依赖一个能单命令运行的测试套件、可靠的构建、清晰的代码所有权和成熟的 CI/CD。对测试薄弱、构建不稳定的遗留代码库，“给 Claude 反馈回路”这一步本身就是一个大工程，文章对此谈得不多。

人的评审是隐含的上限。 文章多次说并行会话数以评审跟得上为限，人的注意力转向意图和风险。但当所有 PR 都附带 agent 评审、所有测试都是绿的之后，人能否保持批判性而不是走过场，这是一个组织行为问题，文章没有展开。

eval 套件的维护成本可能被低估。 20 到 50 个 eval，每次配置变更都跑，每个事故都加，API 消耗和维护精力都不小，文章只提到需要一个有预算的 API key。

从 intent.md 到 spec.md 的自动化对产品组织要求很高。 品牌、安全、合规、UX 策略要先写成 skill，并有明确的负责人，很多组织在这一步本身就有缺口。

适用范围

总的来说，这份手册适合已经在用 agentic 编码工具、正感到流程跟不上代码的中大型工程组织，尤其是受监管行业。

它的贡献在于给出了一套把旧的控制目标翻译为新的执行机制的完整词汇：产物链、门、hook、eval、闭环。即使不用 Claude，这套词汇也可以借用。

小团队或早期产品可以只取其中几个 play，比如 plan mode、CLAUDE.md、反馈回路、AI 评审，不必追求完整的闭环。

相关资源

• 原文：The AI-Native SDLC playbook
• 解读作者：meng shao（@shao__meng）

延伸讨论

“人只在门口审阅”这个设计的前提是产物本身得带得住审阅。如果每阶段只交结果、不交“为什么这么做、否决过什么方案”，人在门口其实只能看对不对，看不出决策路径埋的坑。见过一种做法是每个阶段的产物强制带一条决策记录，下一阶段先读它再动手，审阅者也读这条——门槛才立得住。

— ethan du（@du_ethan3954）