# AI 原生 SDLC 实战手册 · 备查手册

> **演讲**：AI 原生 SDLC 实战手册——当代码不再是瓶颈，六阶段闭环重构软件研发
> **场合**：WeClaw 技术分享 · AI 原生研发流程深度解读
> **日期**：2026-09-03 ｜ **时长**：约 25 分钟 ｜ **幻灯片**：29 页（带自动语音解说，打开后按 P 键）
> **来源**：Anthropic《The AI-Native SDLC Playbook》中文复刻解读（WeClaw 演示文件生成工具配套生成）

---

## 一、背景：代码不再是瓶颈

组织已经开始用 AI 以一年前难以想象的速度写代码，但**代码周边的流程并没有以同样的速度改变**。许多工程团队仍然保留着同样的审批门、评审、交接和政策，拖累了智能体编码（如 Claude Code）带来的生产力收益。

软件开发生命周期（SDLC）是把软件从想法带到生产的过程。多数组织都在跑同一套六阶段：规划、设计、构建、测试、部署、维护。传统上，每个阶段都是由不同角色负责的独立环节——产品经理写需求、架构师转成设计、工程师实现、QA 验证、发布团队上线、运维监控。工作通过文档、工单和签字在阶段之间流转。

传统 SDLC 是**流程重型**的，目的是在每一步保证问责与控制。但它是为「写代码最耗时、最昂贵」的时代设计的——PRD、估算仪式、产品安全审查，都是为了在可能长达数周、数月甚至数季度的开发工作里强迫大家对齐。**这个前提今天已经失效。**

当代码不再是瓶颈、构建阶段跑得比传统 SDLC 允许的还快时，三件事同时成立：

- **瓶颈转移**到构建阶段的左右两侧——主要是规划、评审/测试、部署，它们仍以人类速度运行。
- **控制失灵**——逐行人工评审在人写代码时合理，但当智能体写下大部分 diff 时就跟不上了。
- **治理成本上升**——例外情况仍要排队走每周或每月才开一次的会议与委员会。

以**安全评审**为例：安全团队是按人类产出定编的，当智能体成倍放大代码产出，要么评审队列积压，要么代码带病上线。受监管的组织两个结果都不能接受，因此它的安全与政策检查必须跟上智能体的速度。

---

## 二、什么是 AI 原生 SDLC

AI 原生 SDLC 是一种被重新构想的流程，它把**旧的控制目标**与**新的执行方式**结合起来。流程不再是一条直线，而变成一个**闭环**，AI 被嵌入到每一个节点上。它推动阶段之间的自动交接与自动触发，解决了传统 SDLC 阶段交接的手动与笨重。

你也会听到这种转变被称为**智能体 SDLC**、**AI SDLC**，或简称为**智能体软件开发**——标签不同，描述的却是同一件事。

### 六阶段：传统 vs AI 原生

| 阶段 | 传统 SDLC | AI 原生 SDLC（由 Claude 支撑） |
|------|-----------|-------------------------------|
| Plan 规划 | 委员会收集需求、人工撰写 PRD | Claude 从源头综合痛点，写入 `intent.md` |
| Design 设计 | 分析师写规格、设计师解析 | 一次带智能体的会话，用组织技能约束，产出 `spec.md` |
| Build 构建 | 手写代码与测试、事后补文档 | AI 生成，知识沉淀为 `CLAUDE.md` 与 Skills，Plan Mode 起步 |
| Test 测试 | 人工 QA 把关 | 反馈回路 + 持续评估（evals），跟上智能体产出 |
| Deploy 部署 | 人工审批、手动发布 | 钩子作为审批门，PR 审查回路自动化 |
| Maintain 维护 | 被动值守、人工响应告警 | 闭环自主运行，异常自动回写 `intent.md` |

多数组织都处在这两列之间的某个位置。

---

## 三、核心主线：版本化产物驱动闭环

贯穿右手边那一列的主线，是**被提交的产物（committed artifact）**。每个阶段结束时都向版本控制写入一件产物，下一个阶段开始时读取它：

```
intent.md → spec.md → plan.md → diff + tests → PR + 评审发现 → 事件记录 → (新 intent.md)
```

- 早期阶段以 `.md` 文件为主，因为产品负责人和智能体**都能读、都能改**同一份文件。
- 从 Build 起，产物是**代码及其记录**。
- **提交链本身就是审计轨迹**：谁要了什么、智能体产出了什么、谁批准了它。
- 人对每个需要判断的决策仍负有责任；在智能体 SDLC 世界里，人的注意力**随着必须评审的产物一起转移**。

一个阶段以提交一件产物结束，这次提交触发下一个阶段：被接受的 `intent.md` 触发需求与设计，被批准的 `spec.md` 触发 Plan Mode，被合并的 PR 触发流水线，生产中被突破的控制带写下下一个 `intent.md`——闭环就此持续。

---

## 四、Stage 1 规划 · 把想法变成 intent.md

`intent.md` 启动整个开发流程，它可以经不同路径进入：一个人有了想法、一张工单被登记、或一个告警浮出事件（见 Stage 6）。当人有想法时，他与 Claude 头脑风暴，产出一份 markdown 原型规格（proto-spec）——它人类可读、版本化，且能被下一阶段立即消费。

**执行步骤：**

1. 发起人**用自己的话**向 Claude 描述问题：今天做不到什么、影响谁、更好的样子是什么、什么不在范围内。无需正式语言。
2. **头脑风暴到具体**：Claude 会问分析师会问的问题——范围、用户、约束、成功长什么样。
3. 让 Claude 用组织模板把结果写成 `intent.md`（模板可编码为一个 Skill，由技术成员搭建、负责人签字）。覆盖：问题、期望结果、受影响用户与系统、约束、待解决问题。
4. 发起人**修正** Claude 理解错的地方。
5. 把 `intent.md` **提交**到共享库。作者与时间戳加入记录，产品负责人从此接手。

**案例 · intent.md（理赔状态自助查询）：**

```markdown
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact centre 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 库的 git 历史里。产品负责人批准，接受/拒绝的决策记录为合并或关闭评审。

---

## 五、Stage 2 设计 · 从 intent 到 spec

一旦产品负责人批准，Claude 拿到被接受的 `intent.md`，产出需求与设计规格 `spec.md`。这由组织在品牌、安全、合规、UX 方面的**技能（Skills）**引导。产品负责人**评审**这份规格，但不撰写它。目标是产出工程团队可以据以规划的规格，并标记出顾虑点。

前端工作是最清晰的例子：`intent.md` 被接受后，产品负责人在 Claude Design（beta）里用它做出原型、迭代，然后导出给 Claude Code 构建。

**执行步骤：**

1. 产品负责人在组织技能可用的会话里附上 `intent.md`。
2. 提示词指向 `intent.md`、点名约束、要求标记顾虑。先手工跑，再固化为组织级斜杠命令，最终让 `intent.md` 的合并成为触发器。
3. 同一位产品负责人对照想法评审规格：规格是否解决了所述问题？`intent.md` 里的待解决问题是否被回答或结转？
4. **优先处理被标记的顾虑**——它们是分析师本来会上报的点。产品负责人在工程看到规格前，与政策负责人逐个解决。
5. 把 `spec.md` 与 `intent.md` 一起提交，这对文件记录了「要什么」与「决定了什么」。
6. 产品负责人决定是否进入构建，高风险项咨询技术负责人。**这个决定始终由人来做**，接受规格就是启动 Stage 3 Plan Mode 的触发点。

**治理**：实时策略在写规格时就被读取并应用，问题不再在几周后的评审中才被发现。规格、产生它的提示词、生效的技能版本全部记录在版本控制里。

---

## 六、Stage 3 构建 · Plan Mode / CLAUDE.md / Skills / Hooks / 并行

### 6.1 Plan Mode 作为默认起点

工程师在 **Plan Mode** 下启动 Claude Code 会话，给它 Stage 2 批准的 `spec.md`，让它访谈自己，迭代计划直到满意。Plan Mode 自带护栏：**在工程师接受计划前，Claude 无法编辑文件。**

1. 在 plan mode 下启动会话。
2. 给出 `intent.md` 和 `spec.md`，要一份实现计划：改哪些文件、工作顺序、用什么测试证明。
3. **拷问计划**：改动会破坏什么？哪步最危险？放弃了哪些替代方案？
4. 迭代到**一个从没看过对话的工程师也能照计划实现**。
5. 把批准的计划提交为 `plan.md`，它加入审计轨迹，PR 审查会用它核对最终 diff。
6. 接受计划、放手实现。计划扎实时，实现往往一遍过。
7. 实现偏离计划时，在**同一次提交**里更新 `plan.md`（可用钩子强制二者同步）。

### 6.2 CLAUDE.md · 团队的共同记忆

`CLAUDE.md` 给 Claude 一个新同事所需的上下文：约定、命令、架构、团队最常犯的错误。过去藏在人脑和 wiki 里的知识，变成一个智能体每次会话开头都会读的文件。黄金规则：**Claude 犯两次同样的错，就把修正写进 CLAUDE.md**，并控制在一页以内。

```markdown
# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
  adapters/ talks to external systems.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.
```

### 6.3 Skills / Hooks / 并行会话 —— 三种控制机制

| 机制 | 定位 | 作用 |
|------|------|------|
| **Skills 技能** | 建议性控制 | 把制度知识变成显式、版本化、集中更新的可操作指令，让 AI 大概率遵守 |
| **Hooks 钩子** | 确定性控制 | 阻断受保护路径编辑、跑格式化与 lint、防凭据进 diff，让违规近乎不可能 |
| **并行 + 子代理** | 吞吐放大 | 一人驱动多个 worktree 会话；子代理做会话内受限专项任务 |

> **技能让违规变得罕见，钩子让违规近乎不可能。** 必须无条件成立的策略，背后一定要有确定性的钩子兜底。

**案例 · SKILL.md（安全 API 审查技能）：**

```markdown
---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event.
4. Data classification: fields tagged pii must never appear in logs.

Run scripts/check-endpoints.sh and include its output in your summary.
```

**并行会话**是另一个完整的 Claude Code 实例，在自己的 git worktree 里做独立任务；**子代理**运行在单个会话内，有自己的上下文窗口和工具限制，适合多任务里反复出现的工作（如验证应用是否正常运行）。两三个会话是合理的起点，实际上限是一个人能好好评审多少条流。

---

## 七、Stage 4 测试 · 反馈回路与持续评估

**始终给 Claude 一个自我验证的方式**——测试、构建或截图 diff。会话在工程师看到之前，先检查自己的工作、修自己的错。

- **目标要可量化**：「test_status.py 全部通过」「截图与原型一致」「接口返回 200 加新字段」。
- **修 bug 先写失败测试**：让 Claude 把 bug 复现为测试、运行、确认它因预期原因失败，提交；然后才让它在不改测试的前提下使测试通过（用测试文件钩子强制）。
- **UI 工作用视觉检查闭环**：给 Claude 浏览器或截图工具 + 原型，让它实现→截图→对比→调整，两三轮属正常。
- **保护回路本身**：修 bug 的智能体不能削弱对该代码的检查——用钩子阻断修复任务中对测试文件的编辑。

**反馈回路 ≠ verifier 子代理**：反馈回路贯穿整个任务、跑很多次；verifier 子代理是在会话认为完工后，用一个**全新的上下文窗口**做最终检查，让结论不被「产生代码时的假设」污染。

**案例 · verifier.md（验证子代理）：**

```markdown
---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.
```

**持续评估（evals）**是 AI 原生时代的 stage-gate QA：一套在智能体配置每次变化时都运行的评测。换新模型或改提示词时，eval 套件告诉你智能体是否仍以同样标准工作。平台工程师收集 20–50 个真实任务，写成 eval（提示 + 检查），在 CI 里对 `CLAUDE.md`/技能/钩子的任何变更非交互式运行，并用通过率阈值作为合并门。每个生产事故都补一个 eval，作为回归测试长期留在套件里。

---

## 八、Stage 5 部署 · PR 审查回路与审批门

### 8.1 AI 进入 PR 审查回路

Claude **既给评审也受评审**：按组织策略审传入的 PR，也处理自己 PR 上的评审评论。工程师得以把精力集中在**判断意图与风险**上。

- 技术负责人把审查策略写成仓库根目录的 `REVIEW.md`，分为组织关心的几类 pass：Bug、安全、合规（对照 `spec.md`/`plan.md`/设计原则），并定义何为「重要」、何为「nit」、什么该跳过。
- 发现本身**不批准也不阻断** PR；分支保护仍要求代码负责人批准。
- 评论里 `@claude` 即触发修复循环，PR 线程记录请求与改动。
- **职责分离**：写代码的智能体无法批准它自己的产出。

**案例 · REVIEW.md（审查策略）：**

```markdown
# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.
```

### 8.2 钩子作为审批门

构建阶段的钩子是无声的护栏（允许/阻断）；部署阶段的钩子还能**发问**——暂停动作直到特定人批准，这正是发布门禁需要的。团队钩子放 `.claude/settings.json`（进 git），不可协商的钩子放**托管设置**（工程师个人关不掉）。阻断要**自我解释**：原因和审批路径出现在 Claude 的输出里。

**案例 · production-gate.sh（生产部署审批门）：**

```bash
#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2   # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0
```

### 8.3 CI/CD 集成

在流水线里非交互式运行 Claude Code（`claude -p`），沙箱化执行，通过 MCP 暴露部署能力，并在智能体需要前演练回滚路径。**先只读判断步骤**（triage 失败构建、总结 flaky 测试、起草 changelog），**再在既有门后加写步骤**（修 lint、更新生成文档、处理评审评论）。智能体写出的任何东西都经分支保护成为 PR，**无直推 main 的路径**。按环境分级自治：开发环境自由部署，生产环境由发布经理授权、钩子强制门禁。

---

## 九、Stage 6 维护 · 闭环、扫描与 Claude Tag

前五个阶段每步都由人启动；维护阶段转向**自主运行以闭环**。一个持续运行的监控智能体，可以在 bug 工单被提出后创建 `intent.md`，流经需求、规划、构建、测试、评审各阶段。

### 9.1 闭环（Closing the loop）

一个**确定性脚本**监控生产，在控制带被突破时调用 Claude：

1. 选一个有稳定滚动基线的指标（CI 测试失败率、部署后 5xx 率、PR 周期时间）。
2. 写检测脚本（滚动窗口的均值与标准差 + Western Electric 等规则，既抓尖峰也抓慢漂移），版本化、单测，**检测完全确定性、不涉及模型**。
3. 在版本化配置里定义响应层级（`bands.yaml`）。
4. 触发层可以是 GitHub/GitLab 定时工作流、监控栈 webhook 或内网 Cron；Claude 无状态运行，闭环可以无人启动地开始与结束。
5. 智能体把诊断按 Stage 1 格式写成 `intent.md`，从此像其他任何需求一样流经管线。
6. 值守工程师分诊队列：立即修 / 排期 / 驳回；驳回用于调优阈值、降噪。
7. 修复上线后，为该事故补一个 eval。

**案例 · bands.yaml（监控 CI 测试失败率的分层响应）：**

```yaml
metric: 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 进评审门或触发预批 runbook）。即便是最高层级，智能体也**从不拥有直接改生产的权力**。

### 9.2 周期性代码库扫描

安全扫描是「特定模型下、某时刻代码库」的陈述，两半都会过期：代码每周在变，每代模型都能发现上一代漏掉的漏洞。AI 原生的答案是**按计划运行扫描、调用路径里没有人工**，发现走与其他改动相同的门。有界发现开建议补丁、经 PR 审查门；比一个补丁更大的（架构弱点、跨服务重复模式）写成 `intent.md` 从 Plan 起步。

### 9.3 Claude Tag 值守

事故也可能经 Slack/Teams 等沟通应用到来。Claude Tag（公测，当前在 Slack）让 Claude 以**自己的身份**成为这些频道的成员，每个新事故都有第一响应者，响应本身成为闭环与未来事故记忆的一部分。小而有界的修复作为 PR 经评审门到来，更大的写成 `intent.md` 交给 Stage 1——循环开始自我喂养。

---

## 十、治理贯穿全程

治理不是事后补丁，而是**内建于每个阶段**：

- **人类负责判断**：每个需要判断的决策，责任始终在人；注意力集中在「门」上，评审智能体标记出的东西，而非每阶段从零开始。
- **产物链即审计轨迹**：谁要的、智能体产出的、谁批准的，全程可追溯。
- **双层控制**：技能（建议性）+ 钩子（确定性），从「罕见违规」到「近乎不可能」。
- **职责分离**：写代码的智能体永远无法批准自己的产出，批准来自人 + 分支保护。
- **配置全部版本化**：`CLAUDE.md`/Skills/Hooks/`bands.yaml` 都可评审、可审计。
- **持续评估**为 QA 提供能跟上智能体产出的门，通过率阈值作为合并检查强制执行。

> **核心治理原则**：智能体可以一路行动到生产门禁前，但**绝不可能自己跨过这道门**。

---

## 十一、关键要点与行动清单

**理念三点：**

1. 代码不再是瓶颈 → SDLC 必须像实现阶段一样，来一次同等量级的转型。
2. 从直线到闭环 → 版本化产物驱动自动交接：`intent → spec → plan → diff → PR → 事件记录`。
3. 治理内建 → 人类判断 + 产物审计 + 双层控制 + 职责分离。

**最小起步（今天就能做）：**

- [ ] 给你负责的一个仓库写一份 `CLAUDE.md`：命令、约定、架构、「AI 老犯的错误」，控制在一页内。
- [ ] 挑一条团队执行得最不一致的策略（安全/API 设计/品牌），把它写成一个 `SKILL.md`。
- [ ] 给一条「必须无条件成立」的规则配一个钩子（如阻断冻结包编辑、防凭据进 diff）。
- [ ] 把一个可量化的验证目标写进 `CLAUDE.md`，让「跑测试并贴输出」成为「完成」的一部分。
- [ ] 选一个有稳定基线的指标，写一个确定性检测脚本，为将来的闭环打地基。

---

## 附：六阶段产物与触发速查表

| 阶段 | 关键 play | 产物 | 触发下一阶段 |
|------|-----------|------|--------------|
| Plan | 捕获意图 | `intent.md` | 被接受 → 需求与设计 |
| Design | 需求与设计 | `spec.md` | 被批准 → Plan Mode |
| Build | Plan Mode / CLAUDE.md / Skills / Hooks | `plan.md` + diff | 计划被接受 → 实现 |
| Test | 反馈回路 / 持续评估 | 测试 + eval 结果 | 全绿 → PR |
| Deploy | PR 审查 / 审批门 / CI-CD | PR + 评审发现 | 合并 → 流水线 |
| Maintain | 闭环 / 扫描 / Claude Tag | 事件记录 | 突破控制带 → 新 `intent.md` |

---

*本手册由 WeClaw 演示文件生成工具配套生成，内容解读自 Anthropic《The AI-Native SDLC Playbook》，供听众阅读与下载。*