Claude AI-Native SDLC Playbook 深度解读：六阶段实战剧本与制品链

Claude AI-Native SDLC Playbook 深度解读：六阶段实战剧本与制品链

来源：Anthropic 官方博客，2026 年 8 月 21 日发布，作者 Louis Clifton（Applied AI 团队），阅读时长 46 分钟。

核心论点：代码不再是瓶颈

Anthropic 的 Applied AI 团队在服务大量企业客户后发现了一个共性现象：组织已经开始用 AI 以一年前不可想象的速度写代码，但围绕代码的流程没有同步演进。

传统的审批门、评审、交接和策略仍然停留在人工节奏，严重制约了 agentic coding 工具（如 Claude Code）带来的生产力提升。

传统 SDLC 的六大阶段——规划、设计、构建、测试、部署、运维——在代码编写是最耗时阶段的时代被设计出来。PRD、估算仪式、产品安全评审，都是为了在数周、数月甚至数季度的开发周期中强制对齐。

当代码不再是瓶颈时，三件事变成现实：

  1. 瓶颈向左右两侧移动：构建阶段压缩到小时级，但规划、评审/测试、部署仍以人工速度运行
  2. 控制措施与现实脱节：逐行人工评审在人写代码时合理，但 Agent 写了大部分 diff 后无法跟上
  3. 治理成本上升：例外仍然走每周或每月的会议和委员会审批

AI-Native SDLC 的定义

AI-Native SDLC 是一个重新设计的流程，将旧的控制目标与新 enforcement 方式结合。不再是线性流程，而是一个循环——AI 嵌入每个节点，自动交接和触发后续步骤。

六阶段对比：传统 vs AI-Native

阶段 传统 SDLC AI-Native SDLC
Plan 委员会收集需求，工作坊蒸馏，手工签署 Claude 直接从来源合成痛点，写入 intent.md——人可读、机器可执行
Design 分析师写规格，设计师解析 需求和设计压缩为一次与 Agent 的工作会话，由 Skills 编码的标准引导，版本控制在 git
Build 手写测试和代码，文档事后补 AI 生成测试和代码，制度知识以版本化的 CLAUDE.md 文件和 Skills 维护
Test 阶段边界的 QA 门禁 持续评估 woven 贯穿实现过程
Deploy 人工逐行评审，治理在评审周期中 多层 agentic review，人工评审保留给受监管和关键代码。治理在 AI 行动时通过 Hooks 强制
Maintain 人工监控生产环境 Agent 监控实时部署，任何突破控制带的问题被诊断并写回循环作为新 intent.md

制品链：贯穿全流程的审计轨迹

这是 Playbook 最核心的设计理念——每个阶段结束时提交一个制品到版本控制，下一阶段开始时读取它：

intent.md  →  spec.md  →  plan.md  →  diff + tests  →  PR + review  →  incident record
   ↑                                                                    │
   └────────────────────────────────────────────────────────────────────┘
制品 提交阶段 内容 读者
intent.md Plan 问题、预期结果、受影响用户/系统、约束、开放问题 产品负责人 + Agent
spec.md Design 需求和设计规格，标注关注区域 产品负责人 + 工程
plan.md Build (Plan Mode) 技术实现计划，依赖分析 工程师 + Agent
diff + tests Build 代码变更和测试 评审者 + CI
PR + review findings Deploy 评审发现和审批记录 发布团队
incident record Maintain 生产事件诊断和修复 运维 + 下一轮 intent

关键原则：对于早期阶段，.md 文件是主要制品，因为产品负责人和 Agent 都能读写同一文件。从 Build 开始，制品是代码及其记录。提交链就是审计轨迹——谁要求了什么、Agent 生产了什么、谁批准了什么。

六阶段 Plays 详解

Stage 1: Plan — intent.md

核心变革：想法不再等待有人来写。意图在提出者自己的语言中被捕获一次，作为版本控制的制品。

执行步骤：

  1. 提出者用自己的话向 Claude 描述问题——什么是今天做不到的、谁受影响、更好的样子、什么不在范围内。不需要正式语言
  2. 头脑风暴直到想法具体化。Claude 问分析师会问的问题：范围、用户、约束、成功标准
  3. 让 Claude 用组织模板写 intent.md（可编码为 Skill），覆盖问题、预期结果、受影响用户和系统、约束、开放问题
  4. 提出者修正 Claude 误解的内容
  5. 提交 intent.md 到共享仓库。作者和时间戳加入记录

intent.md 示例：

# 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?

度量：
- 领先指标：从第一次对话到提交 intent.md 的时间——预期从数周降至数小时
- 滞后指标：intent.md 被产品负责人接受进入 Design 的存活率

Stage 2: Design — spec.md

核心变革：需求和设计压缩为一次会话。策略在写规格时应用，而非在数周后的评审中发现。

执行步骤：

  1. 产品负责人打开带组织 Skills 的会话，附上 intent.md
  2. Prompt 指向 intent.md，命名约束，要求标注关注区域
  3. 前端工作可在 Claude Design 中从 intent.md 直接出 mock，迭代后导出到 Claude Code 构建
  4. 产出 spec.md——工程师可以据此规划的规格

Skills 体系：组织的品牌、安全、合规和 UX 策略被编码为 Skills（Claude Code 的技能系统），Agent 在生成规格时自动遵守。这实现了策略在写规格时执行，而不是在评审时发现违反。

Stage 3: Build — plan.md → code + tests

核心变革：代码和测试由 AI 生成，制度知识以 CLAUDE.md 文件和 Skills 版本化维护。

Plan Mode：Claude Code 的 Plan Mode 先产出 plan.md——技术实现计划，包含依赖分析、文件修改清单、测试策略。工程师审批计划后 Agent 开始编码。

CLAUDE.md：项目的制度知识（架构约定、代码规范、安全策略）以版本化的 CLAUDE.md 文件维护。Agent 读取这些文件来确保生成的代码符合团队约定。这取代了过时的 Confluence 文档和口头知识。

关键设计：
- intent/ 文件夹放在产品仓库中，保持制品链与代码相邻
- 非工程师贡献者不需直接使用 git——通过 GitHub Connector 让 Claude 从 claude.ai 或 Cowork 提交 markdown 文件
- 单产品最简单的 intent home 是仓库中的 intent/ 目录；跨仓库时用独立 intent 仓库

Stage 4: Test — 持续评估

核心变革：从阶段边界的 QA 门禁，变为贯穿实现过程的持续评估。

传统测试在构建完成后运行；AI-Native 在代码编写时就同步运行评估——Agent 生成测试用例、检测回归、维护覆盖率。评估结果作为 Build 阶段的制品之一。

Stage 5: Deploy — 多层 Agentic Review + Hooks

核心变革：多层 agentic review，人工评审保留给受监管和关键代码。治理在 AI 行动时通过 Hooks 强制。

Hooks 系统：Claude Code 的 Hooks 机制在 Agent 执行操作时触发审批门——例如 Agent 尝试修改生产配置时触发安全评审 Hook，Hook 可以批准、拒绝或要求人工审批。

分层评审策略：
- 低风险变更：Agent 自动评审，快速通道批准
- 中风险变更：Agent 评审 + 人工 spot-check
- 高风险/受监管变更：完整人工评审
- 这解决了"AI 能生成 2000 行 PR，但逐行人工评审跟不上"的瓶颈

Stage 6: Maintain — Agent 监控 + 反馈循环

核心变革：Agent 监控实时部署，任何突破控制带的问题被诊断并写回循环作为新 intent.md。

运维不再是被动响应告警，而是：
1. Agent 持续监控生产指标
2. 检测到控制带突破时自动诊断
3. 生成事件记录和修复建议
4. 将问题写回为新的 intent.md，触发下一轮 Plan→Design→Build 循环

这形成了完整的闭环——从生产环境回到规划，AI-Native SDLC 是一个自调节的循环系统。

采纳顺序与依赖图

Playbook 强调 Plays 有采纳顺序的依赖关系。从任意"粘土"Play 开始（没有前置依赖），然后按箭头方向推进：

                    ┌──────────┐
                    │  Plan    │  ← 起点（无依赖）
                    │ intent.md│
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │  Design  │
                    │ spec.md  │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │  Build   │
                    │ plan.md  │
                    │ + code   │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │   Test   │  ← 可与 Build 并行
                    │  evals   │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │  Deploy  │
                    │  PR+hooks│
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │ Maintain │
                    │ incident │
                    └────┬─────┘
                         │
                         └──→ 回到 Plan（新 intent.md）

渐进式转型：首先手动 Prompt 每一步，最终状态是每个被接受的制品自动触发下一个门。人类注意力集中在门上——评审 Agent 标注的内容，而非从头开始每个阶段。

治理哲学

人类始终负责判断

"Humans remain accountable for every decision that requires judgment. In the agentic SDLC world, the human attention shifts along with the artifacts that must be reviewed."

人类不写 intent.md、不写 spec.md、不写代码——但人类审批每一个制品。注意力从"执行"转向"判断"。

治理即代码

  • Skills = 组织策略编码为可执行的 Agent 技能（品牌、安全、合规、UX）
  • Hooks = Agent 行动时的审批门（可批准、拒绝或要求人工审批）
  • 提交链 = 审计轨迹 = 谁、何时、什么、谁批准
  • 控制带 = 生产环境的可接受范围，突破时自动触发诊断

度量体系

指标类型 示例 说明
领先指标 从第一次对话到 intent.md 提交的时间 预期从数周降至数小时
滞后指标 intent.md 的存活率（被接受进入 Design 的比例） 衡量需求质量
过程指标 spec.md 首次提交后对 intent.md 的修改次数 衡量需求-设计对齐度
治理指标 Agent 行动被 Hook 拦截/人工审批的次数 衡量治理有效性

与上一篇文章的对比

本文（Anthropic 视角）与上一篇综合 CircleCI/Ideas2IT/EPAM 的文章在多个维度形成互补：

维度 Anthropic Playbook 上篇（三方综合）
视角 平台方（Claude 产品团队） 行业综合（CI/CD + 工程服务 + 企业 AI）
方法论 制品链驱动的具体 Play 趋势分析 + 阶段变革描述
可操作性 极高——每个 Play 有具体步骤、前置条件、度量指标 中高——方向清晰但需自行设计执行
治理 Skills + Hooks = 治理即代码 审查委员会 + Agent 章程
核心概念 intent.md → spec.md → plan.md 制品链 多 Agent 分布式团队
独特贡献 版本化制品 = 审计轨迹；非工程师可直接贡献 从 Copilot 到 Agentic Team 的三代演进

两篇合在一起读：上篇回答"为什么要 AI-Native SDLC"和"方向是什么"，这篇回答"具体怎么做"和"怎么治理"。

总结

Anthropic 的 AI-Native SDLC Playbook 是目前最具体可操作的 AI-Native 开发方法论。它的核心贡献不在于"AI 可以写代码"——这已经是共识——而在于重新设计了围绕代码的整个流程：

  1. 制品链：每个阶段产出版本化制品（.md 文件 → 代码），形成审计轨迹
  2. 非工程师可贡献：通过 Cowork 和 GitHub Connector，产品人员直接提交 intent.md
  3. Skills = 策略即代码：组织约定编码为 Agent 技能，在生成时执行而非评审时发现
  4. Hooks = 治理门：Agent 行动时触发审批，分层评审聚焦高风险变更
  5. 闭环反馈：生产事件自动写回为新 intent.md，形成自调节循环
  6. 渐进式采纳：按依赖图推进，从任意"粘土"Play 开始

核心洞察：传统 SDLC 的控制目标（问责、控制、可审计）没有变——变的是 enforcement 方式。从"人工逐行评审"到"Agent 生成 + Hooks 门控 + 人工聚焦判断"。治理不是被削弱，而是被重新设计为与 AI 速度匹配的自动化。

来源：The AI-Native SDLC Playbook — Claude Blog
作者：Louis Clifton，Anthropic Applied AI 团队
发布日期：2026 年 8 月 21 日

posted @ 2026-08-29 09:42  iTech  阅读(98)  评论(0)    收藏  举报