本页目录11
- 把软件生命周期重组为 计划（Plan）/设计（Design）/构建（Build）/测试（Test）/部署（Deploy）/运维（Maintain） 六个阶段，每阶段产出可版本控制的 markdown 制品（intent.md、spec.md、plan.md），下一阶段直接读取上一阶段产物，commit 历史即审计轨迹。
- 构建阶段默认用 Claude Code 的 plan mode：先由 Claude 生成 plan.md（改动文件、工作顺序、验收测试），经确认后再生成代码；配合仓库级 CLAUDE.md（约定、命令、架构、常见错误）、Skills（机构知识固化为可触发指令）与 Hooks（阻止危险操作的构建期护栏）。
- 测试阶段强调给 Claude 反馈闭环：把测试/构建封装成单条命令，让 Claude 在提交前自验证；并建立 20-50 条真实任务组成的持续 eval 套件，在 CI 中按通过率把关，每次生产事故都变成永久回归用例。
- 部署阶段用 Claude 参与 PR 审查（按 Bugs/Security/Compliance 分类、按严重度排序），用 Hooks 作为审批闸门（如生产部署需 RELEASE_APPROVAL 授权），受监管企业可用 managed settings 做沙箱隔离、密钥读取拒绝、网络域名白名单等。
- 运维阶段由确定性监控脚本按控制带（1σ 记录/2σ诊断/3σ提议）触发 Claude，无需人工介入即可自动生成 intent.md 并回流到整个流水线；也可让 Claude 以团队成员身份加入 Slack/Teams 值班群做首响。
- 核心治理原则：人类判断始终高于闭环之上——制品链式传递、策略在创建时而非事后发现时生效、证据自动化（测试输出/构建日志/截图比对）、写代码的 agent 不能自我批准、一切纳入版本控制。
本文是对 Anthropic 官方文章 The AI-Native SDLC Playbook 的中文要点摘要，完整内容以原文为准：https://claude.com/blog/the-ai-native-sdlc-playbook
核心论点
随着 Claude Code 等 agentic AI 让代码生成速度大幅提升，传统软件开发生命周期（SDLC）的瓶颈已经从「写代码」转移到了计划、评审、测试、部署这些环节。原文提出一套「AI 原生 SDLC」框架，把生命周期重组为六个互相衔接的阶段，并用一条可版本控制的 markdown 制品链把它们串起来。
六阶段总览
- Plan（计划） — 把想法固化为 intent.md
- Design（设计） — 生成 spec.md
- Build（构建） — 以 plan mode 为默认工作方式
- Test（测试） — 给 Claude 反馈闭环 + 持续 eval
- Deploy（部署） — AI 参与 PR 审查 + Hooks 审批闸门
- Maintain（运维） — 确定性监控自动闭环
Plan：把想法写成 intent.md
头脑风暴的结果保存为版本化的 intent.md，包含问题陈述、期望结果、受影响的用户/系统、约束条件、待解决问题，由产品负责人评审后再进入下一阶段，省去多轮需求打磨会。
Design：一次会话产出 spec.md
Claude 基于已批准的 intent.md，结合组织内的 Skills（品牌、安全、合规、UX 规范）直接产出 spec.md，把原本分离的分析师阶段和设计师阶段合并成一次带提示的会话。
Build:plan mode 是默认起点
工程师带着 spec.md 以 plan mode 启动会话，Claude 先输出实现计划（改哪些文件、执行顺序、如何验证完成），提交为 plan.md 后再生成代码。关键基础设施包括：
- CLAUDE.md：仓库级上下文文件，记录构建/测试/lint 命令、语言与数据类型约定、架构概览、常见错误
- Skills：存放在
.claude/skills/<name>/SKILL.md，把机构知识变成可触发的机器可读指令（如「安全 API 评审」技能在创建端点时自动检查鉴权、校验、审计日志） - Hooks:
.claude/hooks/下的脚本，在 PreToolUse 时阻止编辑受保护路径、自动跑格式化/lint、拦截凭证泄露 - 并行会话与 subagents 可让单个工程师同时驱动多个独立 Claude 实例
Test：反馈闭环 + 持续 eval
把测试/构建封装成单条命令（如 make test），Claude 在会话内自行迭代直到检查通过，再交给工程师评审；UI 改动通过截图/浏览器工具做视觉核对。同时维护一套 20-50 条真实任务的持续 eval 套件，按计划及配置变更触发，通过率作为合并门槛，每次线上事故都沉淀为永久回归用例。
Deploy:AI 审 PR + Hooks 做审批闸门
Claude 依据组织策略审查所有 PR，按 REVIEW.md 定义的多轮（Bugs/Security/Compliance）分类，并按严重度（Important vs Nit）排序，工程师可通过 @claude 让其处理评论；人工批准仍是分支保护的硬性要求。生产部署等高风险操作通过 Hooks 设置审批闸门（如 .claude/hooks/production-gate.sh 要求 RELEASE_APPROVAL 授权才放行）。受监管企业可用 managed settings 实现拒绝读取密钥、命令白名单、OS 级沙箱隔离、网络域名白名单等。CI/CD 中 Claude 以非交互模式运行，凭证按作用域收缩，通过 MCP 暴露部署工具；开发环境自动部署、预发布环境折中、生产环境保留审批门。
Maintain：让 Claude 自动闭环
确定性监控脚本按控制带触发响应层级（1σ 记录 / 2σ 诊断 / 3σ 提议方案），无需人在触发路径中即可让 Claude 自动写出诊断性的 intent.md，重新流入整条流水线。此外 Claude 也可作为团队成员加入 Slack/Teams，充当事故首响者，借助 MCP 核实指标，较大的后续工作再沉淀为 intent.md。
制品链与治理原则
六阶段依赖一条被版本控制的制品链：intent.md → spec.md → plan.md → 带测试的 PR diff → 带严重度标签的评审记录 → 关联修复的事故记录。每个阶段消费上一阶段产出，commit 历史天然形成审计轨迹。原文总结的治理原则包括：人类判断始终居于闭环之上、策略在创建时而非事后发现时生效、证据自动化产生（测试输出/构建日志/截图比对）、写代码的 agent 不能自我批准（职责分离）、Hooks 明确升级与审批路径、一切（CLAUDE.md、Skills、Hooks、策略）纳入版本控制并保留历史。
与传统 SDLC 的对比
| 阶段 | 传统方式 | AI 原生方式 |
|---|---|---|
| Plan | 委员会式需求收集、多轮工作坊 | Claude 从多源信息综合生成 intent.md |
| Design | 分析师与设计师分阶段进行 | 一次会话内由 Skills 引导完成 |
| Build | 手写测试与代码，事后补文档 | 测试与代码同步生成，CLAUDE.md 持续版本化 |
| Test | 阶段边界处的 QA 关卡 | 持续 eval 贯穿实现全过程 |
| Deploy | 逐行人工评审，周级评审周期 | Agent 完成常规审查，人工聚焦关键/受监管代码 |
| Maintain | 人工盯盘生产环境 | Agent 基于确定性触发条件监控 |
小结
原文强调，这套框架不是要用 AI 取代人工判断，而是把人工判断保留在关键决策点上，同时用版本化制品链和 Hooks/Skills 等机制让治理成本不随 AI 生成速度的提升而失控。原文结尾的表述是：循环持续运转，人类判断始终高于循环之上。