代码不再是瓶颈：Anthropic 手把手教你用 AI 重构整个软件开发流程

本文基于 Anthropic 官方《The AI-Native SDLC Playbook》及行业公开数据整理，尽量做到通俗易懂、有干货、能上手。建议收藏，适合正在用 AI 写代码但感觉“快不起来”的团队阅读。
一、先看一个扎心的现实

我有个朋友，年初公司全面接入 AI 编码工具，老板兴奋地宣布“产能要翻倍”。三个月后，需求排期没缩短，线上事故反而多了两起。老板很困惑：明明代码写得快了，怎么交付更慢了？

这不是孤例。

DORA 2025 年报告显示：AI 采用率每提升 25%，交付吞吐量反而下降 1.5%，交付稳定性下降 7.2%。LinearB 分析了 810 万个 PR：AI 用得越猛的团队，合并的 PR 多了 98%，审查时间却涨了 91%，PR 体积膨胀了 154%。

工具没错。代码也没错。错的是流程。

2026 年 8 月 21 日，Anthropic 应用 AI 团队发布了一份重磅实践指南——《The AI-Native SDLC Playbook》，系统阐述了如何将 AI 融入软件开发生命周期的每一个环节。这份指南开篇就扔出一个核心判断：代码不再是瓶颈了。

这篇文章，就是我对这份指南的消化笔记，加上一些我自己的理解和落地建议。

二、传统 SDLC 是给“代码很贵”的时代设计的

传统软件开发生命周期（SDLC）有六个阶段：规划、设计、构建、测试、部署、维护。

这套流程能沿用几十年，是因为它建立在一个前提上：写代码是最耗时、最贵、最容易出错的环节。

于是，产品经理写需求，架构师画设计，工程师写代码，QA 做验证，发布团队上线，运维盯着生产。每一道门都在严防死守，生怕错误被带到下一环。PRD、估时会议、产品安全审查——这些东西存在的意义，是在可能长达数周甚至数月的开发周期里，让所有人对齐认知。

现在这个前提不成立了。

当 AI 能批量生成高质量代码时，这条流水线上最窄的喉咙突然变粗了。Anthropic 内部的数据是：Claude 已经编写了超过 80% 的合入代码，工程师季度交付量达到 2021-2025 年间的约8 倍。

但问题也来了：代码写得飞快，周围的流程还是人肉速度。整个流程变成了沙漏形——中间快、两头慢。

打开网易新闻 查看精彩图片

瓶颈转移了。从“写代码”变成了“规划、审查、部署”这些人类速度的环节。

控制手段失效了。代码是人写的时候，逐行审查是合理的。但当 AI 产出了大部分代码，逐行审查根本跟不上。

治理成本飙升了。例外情况还是要走每周一次的会议和委员会审批。

用一句话总结：你给一辆马车换上火箭发动机，然后继续走原来的土路，过原来的收费站。发动机再猛，也快不起来。

三、AI 原生 SDLC：把流程从线性变成闭环

Anthropic 提出的解法不是废除六阶段模型，而是保留控制目标，换一套执行方式。

核心变化有三点：

  1. 流程从线性变成循环。传统是走完就结束了，AI 原生是持续转圈——线上出问题，诊断结果直接写回规划阶段，开始新一轮。
  2. AI 嵌入每一个环节。不是只在“写代码”这一步用 AI，而是规划、设计、测试、部署、维护全都有 AI 参与。
  3. 产物驱动，而不是会议驱动。每个阶段结束时往版本控制里提交一个文件，下个阶段从读取这个文件开始。

贯穿全文的一条主线是：

intent.md → spec.md → plan.md → 代码 + 测试 → PR + 评审 → 事故记录 → 回到 intent.md

提交链本身就是审计记录：谁提了什么需求，Agent 产出了什么，谁批准了它。

这张图是整个 AI 原生 SDLC 的核心循环，建议多看几遍：

打开网易新闻 查看精彩图片

四、六阶段实战指南（完整可上手版）

下面我们一个阶段一个阶段拆开讲。每个阶段我都会说清楚：传统做法有什么问题、AI 原生怎么做、具体步骤、示例、治理要点和度量指标。

阶段一：规划 —— 用 intent.md 捕获意图

传统做法：需求要经过委员会收集、研讨会蒸馏、层层签批，然后工程团队才开始干活。一个需求从提出到排期，可能要走两三周。

AI 原生做法：发起人直接和 Claude 头脑风暴，产出 intent.md——一份用发起人自己的语言写成的原始规格。不需要等委员会，不需要写正式 PRD。

具体怎么操作：

  1. 发起人用自然语言向 Claude 描述问题
  2. 反复讨论直到想法具体化
  3. Claude 按组织模板将结果写成 intent.md
  4. 发起人纠正理解偏差
  5. 提交到共享的版本控制仓库

intent.md 长什么样：

# 意图：理赔状态自助查询作者：J. Ortiz（理赔运营）。状态：草稿。## 问题客户打电话到联络中心询问理赔进度。客服约 1/3 的通话时间花在纯状态查询上。## 预期成果客户在门户网站上可以看到理赔状态、下一步操作和预计日期。## 受影响的用户和系统理赔客服、门户团队、理赔核心 API。## 约束门户会话中不引入新的 PII。仅使用现有认证。## 待确认问题第三方损失评估师是否也需要访问权限？

治理要点：产品负责人审批，决策以 git 历史中的合并或关闭评审记录下来。没有审批的 intent.md 不会进入下一阶段。

度量指标：

  • 先导指标：从第一次对话到提交 intent.md 的时间
  • 滞后指标：被接受进入阶段二的 intent.md 存活率
我的理解：intent.md 的本质是把“需求方脑子里的东西”快速结构化，但不追求完美。它允许模糊和待确认问题，这比传统 PRD 更接近真实世界的需求状态。
阶段二：设计 —— 需求和设计合并为一次会话

传统做法：分析师写需求规格，设计师再反过来解读需求做设计。两个阶段，又慢又有信息损耗。信息每传递一次，就损失 20%。

AI 原生做法：两者合并在一次 prompt 会话中完成。Claude 读取 intent.md，在组织 Skills 的约束下产出规格。

具体怎么操作：

  1. 产品负责人打开会话，加载组织 Skills
  2. 附上 intent.md，要求标记出关注点
  3. 产品负责人对照原始想法审查规格
  4. 与策略负责人一起解决标记出的关注点
  5. 将 spec.md 连同 intent.md 一起提交
  6. 产品负责人决定是否推进到构建阶段

Prompt 模板：

读取附件中的 intent.md，为将其集成到我们现有代码库中产出需求和设计规格。应用你可用的 Skills，使方案符合我们的品牌指南、安全策略和 UX 标准。将规格完整地写成 spec.md，可以直接交给工程团队。明确描述任何关注点，尤其是策略之间存在矛盾的地方。

治理要点：规格撰写过程中实时应用组织策略。Skills、Prompts 和 Skill 版本都记录在版本控制中。

度量指标：

  • 先导指标：intent.md 和 spec.md 提交之间的耗时
  • 滞后指标：构建开始后的需求返工次数
我的理解：这个阶段最大的价值是消除信息损耗。传统上需求和设计是两拨人，现在一个会话直接产出可用的 spec，产品负责人只需要做判断题，不用做翻译题。
阶段三：构建 —— 没有被接受的计划，就不开始实现

传统做法：工程师读完设计文档就开始写代码，实现计划只存在于工程师的脑子里。AI 来了之后，很多人直接让 AI 写代码，结果 AI 写出来的东西方向经常跑偏。

AI 原生做法：工作从 Claude 在Plan 模式下产出的书面计划开始。Plan 模式下 Claude 可以读取代码库但不能修改。

为什么 Plan 模式这么重要？因为 Plan 模式强制要求 AI 在动手之前先想清楚——列出需要改哪些文件、按什么顺序改、可能有什么风险、怎么验证。这就避免了很多团队遇到的“AI 写了一堆代码但方向全错了”的问题。

具体怎么操作：

  1. 工程师在 Plan 模式下启动 Claude 会话
  2. 提供 intent.md 和 spec.md
  3. Claude 创建计划，列出需要修改的文件、工作顺序和验证测试
  4. 工程师质询计划（什么可能出问题？风险最高的步骤？有其他方案吗？）
  5. 反复迭代，直到一个新人仅凭计划就能实现
  6. 将已批准的计划作为 plan.md 提交
  7. 接受计划，让 Claude 开始实现
  8. 实现过程中偏离计划时，在同一个 commit 中更新 plan.md

plan.md 示例：

# 计划：理赔状态自助查询（来自 intent.md 2026-06-02）## 需要修改的文件portal/src/claims/StatusPanel.tsx（新增），claims-api/routes/status.py，claims-api/tests/test_status.py## 工作顺序1. 在现有认证之后添加状态接口2. 针对接口开发面板3. 接入门户导航## 风险理赔核心 API 限速 50 rps，面板需要做缓存## 验证test_status.py 覆盖四种理赔状态；截图与批准的设计稿一致

CLAUDE.md——组织知识文件：放在仓库根目录，给 AI 提供新人入职时需要的全部上下文：

# 支付服务## 命令- 构建：make build- 测试：make test（单元），make itest（集成，需要 docker）- Lint：make lint（CI 中运行，推送前必须修复）## 约定- Java 21，Spring Boot 3。不引入新的 Lombok- 金额永远用 BigDecimal，不用 double- 每个接口都需要集成测试，放在 src/itest## 架构- api/ 放 REST 控制器，core/ 放领域逻辑，adapters/ 与外部系统通信- Kafka 事件定义在 schemas/ 下，不要编辑生成的类## Claude 容易犯的错- 不要升级依赖版本，这由平台团队管- 遗留的 v1/ 包已冻结，改动放到 v2/

Skills——组织级别的策略：一个安全 API 审查 Skill 的示例：

---name: secure-api-reviewdescription: 应用 API 安全标准。在创建或修改面向外部的接口、审查 API 代码或生成 OpenAPI 规格时使用# 安全 API 审查当你创建或修改 API 接口时：1. 认证：每个接口都需要网关 JWT，/health 之外不允许匿名路由2. 输入验证：根据 OpenAPI schema 验证请求体，拒绝未知字段3. 审计：每个状态变更接口都必须发出审计事件，包含操作者、操作、实体、时间戳4. 数据分类：schema 中标记为 pii 的字段不得出现在日志或错误消息中运行 scripts/check-endpoints.sh 并在摘要中包含其输出

治理要点：设计评审发生在代码生成之前。Plan 模式强制执行这一点，因为工程师接受计划之前 Claude 无法修改文件。

度量指标：

  • 先导指标：首次通过就合并的变更比例；从计划批准到 PR 合并的时间
  • 滞后指标：每个变更的返工次数；合并后的 diff 与提交的 plan.md 匹配程度
我的理解：Plan 模式是“AI 原生 SDLC”里最容易被忽视但最实用的一步。它把“设计评审”从会议变成了一个可版本化的文件。新人也能根据 plan.md 理解上下文，这对团队协作是巨大的提升。
阶段四：测试 —— 每次会话都要自检工作

传统做法：代码能用的信号来得很晚（CI、测试、生产环境），Agent 生成的代码必须由人完整审查。

AI 原生做法：会话有办法在人类看到之前自检工作。Claude 反复迭代直到检查通过。

具体怎么操作：

  1. 把工作检查封装成一条命令：make test 或 npm test
  2. 在 CLAUDE.md 的命令部分列出，并给出健康输出的示例
  3. 设定可量化的目标：「所有测试通过」「截图与设计稿一致」
  4. 修 bug 时：先写失败测试，让 Claude 把 bug 复现为测试，确认测试失败，提交测试，然后才让 Claude 修复（且不能修改测试）
  5. UI 相关的工作：给 Claude 浏览器/截图工具和设计稿，反复迭代（通常 2-3 轮）
  6. 把验证变成 CLAUDE.md 中「完成」指令的一部分
  7. 用 Hook 阻止 Agent 在修复任务中编辑测试文件

验证配置示例：

## 验证工作- 构建：make build（必须以 "Build succeeded" 结束）- 测试：make test（全部通过，不得跳过或删除失败的测试）- Lint：make lint（零警告）在报告任何任务完成之前运行以上全部三项，并粘贴输出。如果测试失败，修代码，不修测试。

CI 中的持续 Evals：Evals 是 AI 原生世界里的阶段门禁 QA。它把“人工 QA”变成了“自动化回归测试”。

  1. 平台工程师收集 20-50 个带有预期结果的真实任务
  2. 将每个写成 eval：prompt + 定义可接受结果的检查项（测试通过、lint 干净、行为不变、策略遵循）
  3. 套件按计划运行，也在 CLAUDE.md、Skills 或 Hooks 变更时运行
  4. 配置变更需要通过 eval 门禁
  5. 每个生产事故都变成一条 eval，成为永久的回归测试

CI 工作流示例：

name: Agent evalson:pull_request:paths: ['CLAUDE.md', '.claude/**']schedule:- cron: '0 2 * * *'jobs:evals:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- run: npm install -g @anthropic-ai/claude-code- name: Run eval suiteenv:ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}run: |for eval in evals/*.json; doclaude -p "$(jq -r '.prompt' $eval)" \--allowedTools "Read,Edit,Bash(make test)" \--output-format json > result.json./evals/check.sh "$eval" result.jsondone

治理要点：Evals 提供了跟得上 Agent 产出速度的 QA 门禁。通过率阈值作为合并检查强制执行；运行结果记录以便随时间比较。

度量指标：

  • 先导指标：Eval 通过率随时间的变化；从生产事故到永久 eval 的时间
  • 滞后指标：CI 中捕获的回归 vs. 逃逸到生产环境的回归
我的理解：这一步是“把 QA 从人肉变成代码”的关键。传统 QA 的人力瓶颈在 AI 时代会进一步放大，Evals 是唯一能跟上 AI 产出速度的质量保障方式。
阶段五：部署 —— 评审双向运行

传统做法：评审能力按人类产出的速度规划。PR 等待审查人；质量随负载波动。AI 写得越快，PR 堆积越严重。

AI 原生做法：所有 PR 都获得一致的、按严重程度排序的评审。人类的注意力转向行为和风险。

Claude 既给出评审，也接受评审。它按策略审查传入的 PR，同时也处理自己 PR 上收到的评审意见。

具体怎么操作：

  1. 启用托管的 Code Review 服务或在 CI 中运行 claude-code-action
  2. 技术负责人把评审策略写成 REVIEW.md
  3. 技术负责人设定人工阈值——评审发现不会自动批准或阻止合并
  4. 在评审评论上 @claude，Claude 处理并推送修复
  5. 评审发现反馈到 CLAUDE.md
  6. 每月调优：评估发现的质量、控制小建议数量、排除生成路径

REVIEW.md 示例：

# 评审指令## 检查轮次运行三轮检查，每轮标注类型：- Bug：逻辑错误、边界条件遗漏、隐蔽的回归- 安全：注入风险、认证漏洞、日志中的 PII- 合规：变更是否符合 spec.md、plan.md、设计原则## 什么是「重要」「重要」仅用于会破坏行为、泄露数据或违反策略的发现。风格和命名属于小建议。## 控制小建议数量每次评审最多报告五个小建议，其余汇总为数量。## 不需要报告的src/gen/ 下的生成文件，以及 CI 已经在检查的内容。

Hooks 作为审批门禁：Hooks 可以阻止、放行或暂停（等待审批）。发布门禁是最典型的场景。

生产环境门禁 Hook 示例：

#!/bin/bash# 生产部署需要具名的发布授权cmd=$(jq -r '.tool_input.command' < /dev/stdin)if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; thenif [ -z "$RELEASE_APPROVAL" ]; thenecho "Production deploys need a release authorization." >&2exit 2fifiexit 0

CI/CD 集成与部署：在流水线中以非交互模式运行 Claude，沙箱化执行，通过 MCP 集成暴露部署能力，预演回滚路径。

  1. 从只读的判断步骤开始（分诊失败的构建、汇总不稳定的测试、起草变更日志）
  2. 在现有门禁之后添加写入步骤（修复 lint、更新生成的文档、处理评审意见）
  3. 执行沙箱化在容器中，使用短期限定作用域的令牌，没有长期的生产凭据
  4. 通过 MCP 暴露部署能力，按环境限定作用域
  5. 按环境分级自治权：开发环境（Agent 自由部署）、预发布（中间地带）、生产（Agent 准备，管理者授权，Hook 强制门禁）
  6. 定期演练回滚

治理要点：写代码的 Agent 无法批准自己的代码。评审策略统一应用于所有 PR。发现记录在 PR 历史中，形成审计记录。人类通过分支保护规则进行审批。

度量指标：

  • 先导指标：首次评审响应时间；无需人类碰分支就解决的评论比例
  • 滞后指标：合并前捕获的缺陷/漏洞 vs. 逃逸到生产的
我的理解：部署阶段的核心是信任但验证。AI 可以做大部分评审工作，但最终批准权必须留在人手里。Hooks 是最后一道防线，确保没有人类授权，AI 不能碰生产。
阶段六：维护 —— 循环闭合

传统做法：维护是被动的。工单和事故等着人来处理，然后重启流程。

AI 原生做法：触发器（控制带突破、工单、频道消息、定时任务）直接调用 Claude，无需人介入。Claude 诊断问题，通过有门禁的路径执行操作，并把结果写成 intent.md，进入上述各阶段的循环。

监控与闭环：确定性脚本监控生产环境，在控制带被突破时调用 Claude。

  1. 服务负责人选择一个有稳定基线的指标（CI 测试失败率、部署后 5xx 率、PR 周期时间）
  2. 编写检测脚本，使用滚动窗口的均值/标准差。采用规则（Western Electric 规则）来捕捉缓慢漂移和突增
  3. 在版本控制的 bands.yaml 中定义响应层级：1σ：仅记录2σ：调用 Claude 进行只读诊断3σ：Claude 可以采取行动（提 PR、触发预批准的运维手册）
  4. 触发层：定时工作流、来自监控栈的 webhook 或 Cron Job。Claude 以无状态方式运行（非交互的 CI 步骤或沙箱化容器中的 Agent SDK 服务）
  5. Agent 将诊断写成 intent.md（异常与证据、建议的结果、受影响的系统、待确认问题）
  6. 服务负责人或值班工程师分诊队列，路由给产品负责人或直接关闭
  7. 修复上线后，为该事故添加 eval，防止回归

bands.yaml 示例：

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] }

Claude Tag 处理事故：Claude Tag 让 Claude 作为频道成员以自己的身份参与。每个事故都有了第一响应者，响应本身成为循环和记忆的一部分。频道审计记录对话和组织知识留在频道中。Claude 通过 MCP 访问验证指标是否回到基线，并在线程中确认，然后把事后复盘写入版本控制的经验教训文件。

小型的、边界清晰的修复以 PR 的形式通过评审门禁；更大的工作则写成 intent.md 进入阶段一。

治理要点：层级边界从版本控制的配置中强制执行。权限和托管设置拒绝生产环境访问。调用、发现、分诊都带时间戳记录。服务负责人分诊和审批。运维手册预先批准。现有的 PR 评审门禁决定变更是否通过。

度量指标：

  • 先导指标：从控制带突破到 intent.md 进入分诊队列的时间
  • 滞后指标：转化为合并修复的发现比例；同类事故的重复率
我的理解：这一阶段让 SDLC 真正变成了闭环。线上问题不再是“救火”，而是自动生成下一个迭代的输入。事故记录直接变成 intent.md，避免了“同样的问题反复发生”的恶性循环。
五、三层控制：从“建议”到“强制”

Anthropic 的指南里有一个非常关键的治理思路：不是所有规则都用同一种方式执行。

打开网易新闻 查看精彩图片

第一层：CLAUDE.md + Skills（建议层）

放在仓库根目录的 CLAUDE.md 和 Skills 是“建议”——告诉 AI 应该怎么做。Skills 把团队的编码标准、安全红线、架构约定统统封装成可复用的规则包。AI 在动手之前先加载这套技能，出来的代码自然贴团队口味。

第二层：Hooks（确定性层）

“一个必须永远成立的策略，需要在 Skill 背后放一个确定性的东西，比如一个能阻止行动的 Hook。”

Hooks 是在 AI 行动之前执行的确定性检查——不是“建议”，是“门禁”。路径权限、凭据检查、部署审批，这些必须绝对控制的事情用 Hooks 来强制执行。

第三层：Evals + CI（回归测试层）

配置本身也要被回归测试。每次 CLAUDE.md、Skills 或 Hooks 变更时，eval 套件自动运行，确保新的配置没有破坏已有的行为。

三层控制的关系是：Skills 让违规变得少见，Hooks 让违规变得几乎不可能。

六、关键产物与版本控制链

贯穿 AI 原生 SDLC 的主线是提交的产物。每个阶段结束时写入一个到版本控制中，下一个阶段从读取它开始：

产物

产生阶段

内容

下一阶段读取

intent.md

问题、预期成果、约束

设计

spec.md

设计

需求和设计规格

构建

plan.md

构建（Plan模式）

实现计划

实现

diff + 测试

构建

代码变更和测试

评审

PR + 评审发现

部署

评审结论和审批

部署

事故记录

维护

生产事件诊断

回到规划

提交链就是审计记录：谁提了什么需求，Agent 产出了什么，谁批准了它。

这个设计最巧妙的地方在于：它不需要额外的审计系统。git 历史本身就是审计日志。任何一次变更，你都能追溯到对应的 intent.md、spec.md、plan.md，以及所有相关评审和批准。

七、遗留系统集成：三种方案

对于流程产出的每一个产物，要指定一个系统作为唯一真实数据源：

方案一：仓库作为唯一数据源（最干净）

Markdown 产物是权威记录，遗留系统引用 commit 中的文件。所有记录在一个工具中，有统一的时间戳权威。适合工程主导的组织。

方案二：遗留系统作为唯一数据源

Jira、ServiceNow 或需求工具持有权威记录，Markdown 产物是工作副本。Claude 在会话开始时读取记录，通过 MCP 连接器将结果写回。适合强流程管控的组织。

方案三：链接作为最低标准（过渡方案）

所有产物标注记录 ID，所有遗留记录包含 Markdown 文件的 commit SHA。接受两个数据源并存，逐步迁移。

我的建议：如果团队刚开始，建议直接选方案一。仓库作为唯一数据源，简单、可审计、没有同步问题。等流程跑顺了，再考虑和 Jira 等工具打通。
八、实施建议：从哪里开始？

这六个实践是模块化的，组织可以根据需要优先改造不同的阶段。

依赖关系：

  • 阶段一（规划）：没有前置要求，可以从任何地方开始
  • 其他阶段依赖于依赖图中箭头指示的前置阶段

推荐路径：

  1. 先改造「构建」阶段——最容易上手，效果最明显。在代码库里放一个 CLAUDE.md，教会 AI 你的团队规范，用 Plan 模式替代“直接写代码”。
  2. 然后改造「测试」阶段——把验证工作封装成命令，让 AI 在提交前自检。这一步能大幅减少人工审查的负担。
  3. 再改造「规划」和「设计」——用 intent.md 和 spec.md 替代冗长的 PRD 和设计文档。这一步需要产品和工程的配合，但一旦跑通，需求到代码的流转会顺畅很多。
  4. 最后是「部署」和「维护」——用 Hooks 做门禁，用 Evals 做持续 QA，让线上事故自动变成下一轮的需求。

人类的注意力集中在门禁上，审查的是 Agent 标记出来的内容，而不是从头开始每个阶段。

九、写在最后

Anthropic 这份指南最值得看的，不是“让 Claude 多写一些代码”。它真正改造的是软件开发的运行系统。

过去二十年，软件工程的所有管理方法都在围绕一个假设：写代码是最慢、最贵、最容易出错的环节。现在这个假设不成立了。

模型和工具已经进化到了一个新的水平，组织不仅可以改变代码的生产方式，还可以改变整个软件开发生命周期。

这份转变把人类的判断力保持在流程的核心位置，同时兼顾了大型企业组织的治理和合规要求。

循环持续运转。人类的判断力应始终在它之上。

原文：The AI-Native SDLC Playbook
作者：Louis Claxton（Anthropic 应用 AI 团队）
日期：2026 年 8 月 21 日
原文链接：https://claude.com/blog/the-ai-native-sdlc-playbook