AI 原生软件开发生命周期实战手册（中文翻译）

原文：The AI-Native SDLC Playbook
作者：Louis Claxton（Anthropic Applied AI 团队）
原文链接：https://claude.com/blog/the-ai-native-sdlc-playbook

目录

• 代码不再是瓶颈
• 什么是 AI 原生 SDLC？
• 转变概览
• 实战 Play
  • 第一阶段：计划（Plan）
  • 第二阶段：设计（Design）
  • 第三阶段：构建（Build）
  • 第四阶段：测试（Test）
  • 第五阶段：部署（Deploy）
  • 第六阶段：维护（Maintain）
• 结语

代码不再是瓶颈

许多组织已经开始用 AI 编写代码，速度在一年前还难以想象。然而，围绕代码的开发流程却没有同步变化。

大量工程团队仍在沿用原来的审批节点、代码评审、团队交接和内部政策。这些环节正在拖累 Claude Code 等智能体编程工具带来的效率提升。

软件开发生命周期（Software Development Lifecycle，简称 SDLC）指软件从一个想法走向生产环境的完整过程。多数组织采用的流程包含六个阶段：计划、设计、构建、测试、部署和维护。

在传统模式下，每个阶段彼此分开，由不同角色负责：产品经理编写需求，技术架构师把需求转化为设计，工程师完成开发，QA 团队负责验证，发布团队完成上线，运维团队监控生产环境。工作通过文档、工单和审批记录在各阶段之间传递。

传统 SDLC 设置了大量流程，目的是确保每一步都有明确责任并受到控制。这套流程形成于一个特定时期，当时最耗时、成本最高的环节是编写和实现代码。如今，这个前提已经发生变化。PRD、工作量估算和产品安全评审，原本都是为了让参与者在持续数周、数月甚至数个季度的开发过程中保持一致。

传统 SDLC 还默认每一步都由人完成。目前，从 AI 中获得最大价值的组织，已经开始按照智能体式 AI 的能力重新设计流程，同时把人的判断保留在关键环节。

本文总结了 Anthropic 应用 AI 团队在组织内部将 Claude 融入 SDLC 各阶段的实践。这些做法也来自团队与客户合作时积累的经验，目的是加快开发速度，让整个流程更高效。

当代码不再是瓶颈时，会发生什么？

当构建实现的速度超过传统流程能够承受的节奏时，会出现三个结果：

1. 瓶颈转移到构建前后的环节
   主要包括计划、评审与测试、部署。这些环节仍按人的速度运行。

2. 原有控制措施开始脱离现实
   代码由人编写时，逐行人工评审还有可行性。当大部分代码差异都由 AI 智能体生成后，这种方式很快就会跟不上。

3. 治理成本上升
   例外情况仍然需要经过每周或每月才开一次会的委员会处理。

安全团队是一个典型例子：安全团队通常按人类产出规模配置人力。当智能体把代码产出放大数倍后，要么审查队列越堆越高，要么代码未经充分审查就发布——受监管的组织两者都不能接受。因此，安全与策略检查必须跟上智能体的速度。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一个重新设计的过程，将旧的控制目标与新的执行机制结合起来。

它不是线性流程，而是一个循环。AI 嵌入在流程的每一个环节。AI 原生 SDLC 提倡各阶段之间自动交接、自动触发下一步动作，以解决传统 SDLC 中阶段之间手动交接的笨拙和低效问题。

贯穿整个 AI 原生 SDLC 的核心是已提交的产物（committed artifact）。

每个阶段结束时，都会把某种产物写入版本控制：

• 计划阶段输出 intent.md
• 设计阶段输出 spec.md
• 构建阶段输出 plan.md、代码差异和测试
• 部署阶段输出 PR 及其评审记录
• 维护阶段输出事件记录

下一个阶段开始时，会读取上一个阶段留下的产物。

对于早期阶段，.md 文件是主要产物，因为产品经理和智能体都能阅读并作用于同一个文件。从构建阶段开始，产物变为代码及其记录。

这一连串提交也构成了审计线索：谁提出了什么需求、智能体产出了什么、谁批准了什么。人类仍然需要对需要判断的决策负责。

在智能体 SDLC 中，人类注意力会随需要评审的产物而转移。每个阶段提交一个可被下一阶段读取的产物。intent、spec、plan、diff 和评审记录共同构成审计线索。

转变概览

下表对比了传统 SDLC 与由 Claude 支持的 AI 原生 SDLC 之间的差异。大多数组织目前处于两列之间的某个位置。

贯穿右侧列的主线是已提交的产物。每个阶段结束时都会向版本控制写入一个产物，下一个阶段开始时读取它。

实战 Play

Play 是本手册的核心，分为六个非线性阶段：Plan、Design、Build、Test、Deploy、Maintain，共同覆盖完整的生命周期。

每个 Play 包含：

• 什么发生了变化
• 前置条件
• 起步方式
• 具体实施步骤
• 治理考量
• 如何衡量效果

这些步骤是模块化的，组织可以根据自身需要，选择优先改造不同的阶段。

每个 Play 在「Prerequisites」下列出依赖关系。一个阶段结束时，通过提交产物来触发下一个阶段：

• 被接受的 intent.md 触发需求与设计阶段
• 被批准的 spec.md 触发 plan 模式
• 被合并的 PR 触发部署流水线
• 生产环境中超出的控制带会写出下一个 intent.md

最初，你需要手动提示每个步骤；最终目标是一个循环，其中每个被接受的产物自动触发下一道门。人类注意力集中在这些门上，评审智能体标记的内容，而不是从头开始每个阶段。

第一阶段：计划（Plan）

发生了什么变化？

传统上，一个想法在工程团队看到之前，要经过 backlog 条目、用户故事、故事点和多次细化会议。等到工程团队看到时，它已经偏离了提出者最初的意思好几个层级。

在 AI 原生 SDLC 中，想法提出者直接与 Claude 进行头脑风暴，并将结果作为 proto-spec（原型规格）用自己的话提交下来。

关键产物：intent.md

intent.md 是人类可读、机器可执行的意图文件。它捕捉：

• 问题或机会
• 利益相关者的痛点
• 预期结果
• 约束条件
• 成功标准

实施步骤

1. 从对话开始
   让想法提出者与 Claude 对话，探索问题空间。Claude 会提问、澄清、挑战假设。

2. 综合痛点
   Claude 直接从源头（聊天记录、会议记录、支持工单、用户反馈）综合痛点，避免信息在传递中失真。

3. 写入 intent.md
   将结果提交到版本控制中的 intent/ 目录。文件应使用提出者自己的语言，保持可理解性。

4. 人工审查与接受
   产品经理或相关负责人在 intent.md 被接受前审查它。接受后，它自动触发设计阶段。

治理考量

• 人类仍然对业务目标和约束负责
• intent.md 是智能体后续所有工作的合同基础
• 避免让委员会在前期反复开会

衡量指标

主要指标：从第一次对话到提交 intent.md 的时间。

目标：从数周的需求收集周期缩短到数小时。

第二阶段：设计（Design）

发生了什么变化？

在传统 SDLC 中，需求文档交给分析师，分析师再写出规格，设计师再解析规格。在 AI 原生 SDLC 中，需求定义和架构设计被压缩为一次与智能体的工作会话。

关键产物：spec.md

spec.md 是一份统一的规格文档，由 Claude 根据 intent.md 和组织约束生成。它包含：

• 需求总结
• 架构方案
• 数据模型
• API 设计
• 用户体验要求
• 安全与合规约束
• 验收标准

实施步骤

1. 读取 intent.md
   Claude 读取已接受的 intent.md，理解业务意图。

2. 应用组织标准
   通过编码为 Skills 的标准来引导 Claude。Skills 可以包含品牌规范、安全要求、UX 模式、代码风格等。

3. 生成功能完整的 spec.md
   在一个工作会话中，Claude 与工程师/产品经理协作，生成可直接进入构建阶段的规格。

4. 版本化与审批
   将 spec.md 提交到 git。产品负责人在实现开始前签字批准。

治理考量

• Skills 是可执行的规则书，不能被随意争辩，只能被重新训练
• spec.md 成为智能体后续被评估的合同
• 人类注意力集中在设计决策和例外情况上

衡量指标

• 从 intent.md 到批准的 spec.md 的时间
• 规格返工率
• 构建阶段发现的设计缺陷数量

第三阶段：构建（Build）

发生了什么变化？

传统构建阶段中，工程师手写代码和测试，文档常常在开发完成后补写。在 AI 原生 SDLC 中，智能体生成代码和测试，机构知识通过版本化的 CLAUDE.md 文件和 skills 来维护。

关键产物

• plan.md：实现计划
• 代码 diff
• 测试
• CLAUDE.md：机构知识文件

实施步骤

1. 进入 Plan 模式
   Claude Code 读取 spec.md，向工程师询问仓库相关问题，然后生成 plan.md，包含拟修改的文件、测试要求、依赖项和风险。

2. 批准实现
   工程师审查 plan.md，确认方案后授权 Claude Code 执行。

3. 生成代码与测试
   Claude Code 根据计划修改文件、生成测试，并将机构知识写入 CLAUDE.md。

4. 维护 CLAUDE.md（两次规则）
   CLAUDE.md 给智能体提供新员工需要了解的信息：约定、命令、架构、常见错误。

   工作规则：当 Claude 犯同样的错误两次时，就把修正写进 CLAUDE.md。保持文件在一页以内，因为智能体每次会话开始时都会读取它。

治理考量

• 详细指令应放在目录级规则或 Skills 中，避免上下文膨胀
• 人类工程师从机械编辑转向评估意图、批准计划、审查异常
• 建议每个工程师先从 2-3 个并行的 Claude Code 会话开始

衡量指标

• 从批准的 spec.md 到可合并 PR 的时间
• 测试覆盖率
• CLAUDE.md 更新频率
• 相同错误的重复次数

第四阶段：测试（Test）

发生了什么变化？

传统 SDLC 在阶段边界设置 QA 门禁。AI 原生 SDLC 将质量工作嵌入实现循环，使用持续评测（continuous evals）。

关键产物

• 自动生成的单元测试
• 自定义 eval 套件
• 评测结果记录

实施步骤

1. 生成单元测试
   Claude Code 在编写代码时同步生成单元测试。

2. 建立 Eval 套件
   从近期开发工作中抽取 20-50 个真实任务，构建自定义 eval 套件。这些任务测试智能体完成代表性工程工作的能力，而不是仅衡量覆盖率。

3. 在实现过程中运行 Eval
   将 eval 作为 CI 的一部分持续运行，而不是等到最后才检查。

4. 根据结果迭代
   当 eval 失败时，将修复反馈到 spec.md、Skills 或 CLAUDE.md 中。

治理考量

• 评测只能衡量你写下来的内容——糟糕的 eval 不是移动了门禁，而是移除了门禁
• Eval 应反映真实工作负载，而不是人为构造的基准
• 人类保留对 eval 设计和解释的审批权

衡量指标

• Eval 通过率
• 生产环境中回归 bug 数量
• 从发现缺陷到修复的时间
• 测试生成覆盖率与真实任务覆盖率的对比

第五阶段：部署（Deploy）

发生了什么变化？

传统部署中，人类逐行审查每行代码，治理在评审周期中进行，且常常不一致。AI 原生部署使用多层智能体审查，仅在受监管、高风险或核心架构代码上保留人工审查。治理通过 Git hooks 等机制在智能体行动时强制执行。

关键产物

• 通过审查的 Pull Request
• 审查发现记录
• 部署授权记录

实施步骤

1. AI 初审
   智能体根据 plan.md、安全标准和组织策略审查 diff。

2. Git Hooks 强制执行策略
   使用 Git hooks 执行程序化策略，例如：

   • 计划是否与 PR 匹配
   • 是否包含必要的测试
   • 是否触碰了受保护文件
   • 是否需要额外的人工批准

3. 分层审查

   • 低影响半径 + 测试通过 → 可能自动接受
   • 高风险、受监管、核心架构 → 必须人工批准

4. 部署与审计
   部署后，PR、审查记录和批准记录共同构成审计线索。

治理考量

• 人类从「每行都看」转向「只看关键代码」
• Hooks 是确定性的批准门禁，不能被绕过
• 治理在行动时执行，而不是在周期末的会议上

衡量指标

• 平均合并时间
• 人工审查占比
• 部署失败率
• 绕过策略的尝试次数

第六阶段：维护（Maintain）

发生了什么变化？

传统维护中，人类盯着生产环境找 bug。AI 原生维护让智能体监控线上部署；当异常超出定义的控制带时，智能体会诊断问题，并将结果作为新的 intent.md 写回循环。

关键产物

• 监控告警
• 智能体生成的事件记录
• 新的 intent.md

实施步骤

1. 设置控制带
   为关键指标（错误率、延迟、成本、业务指标）定义可接受范围。

2. 智能体监控
   让智能体持续查看日志、指标和告警。

3. 首次响应
   使用 Claude Tag 等工具处理 CI/CD 失败和 bug 分类的首次响应工作。

4. 写回循环
   当异常超出控制带时，智能体起草新的 intent.md，重新启动 SDLC 循环，而不是让事件停留在独立的工单队列中。

治理考量

• 人类定义控制带和升级策略
• 智能体可以诊断和起草，但关键修复仍需人类批准
• 事件记录成为审计线索的一部分

衡量指标

• 平均检测时间（MTTD）
• 平均修复时间（MTTR）
• 由智能体写回的 intent.md 数量
• 重复事件数量

结语

AI 原生 SDLC 不是关于更快写代码的手册，而是一份关于瓶颈转移的地图。

当代码不再是约束时，真正的慢点会出现在规划、审查、部署和维护等环节。组织需要重新设计这些环节，使其与智能体的速度相匹配，同时保留人类在关键环节的判断。

核心原则可以总结为：

1. 把控制目标留下来，换一套执行机制
   不要丢弃治理要求，而是用自动化、可审计的方式实现它们。

2. 每个阶段都提交一个产物
   intent.md、spec.md、plan.md、diff、PR 记录、事件记录——它们构成审计线索。

3. 让循环自动流转
   被接受的产物自动触发下一阶段，人类注意力集中在门禁和例外上。

4. 把机构知识编码为机器可读的规则和上下文
   CLAUDE.md 和 Skills 让智能体在每次会话中都能获得一致的指导。

5. 人类判断保留在环上
   人类负责意图、设计审批、关键代码审查、控制带定义和异常升级。

最终，AI 原生 SDLC 让工程师花更少时间做机械性编辑和例行审批，花更多时间评估意图、批准设计、审查异常，并批准高风险变更。这正是从「个体贡献者」向「编排者」转变的体现。

原文链接：The AI-Native SDLC Playbook