AI-Native SDLC 实战手册(中文精读版)

原文：The AI-Native SDLC playbook 作者：Louis Claxton 发布：2026-08-21 来源：https://claude.com/blog/the-ai-native-sdlc-playbook

说明：本文按原文结构整理为中文精读/译述版，保留关键图片与章节顺序，但不是逐字全文翻译。

代码已经不再是瓶颈

生成式 AI 和 Coding Agent 让“写代码”这一环节显著加速，但很多团队的需求、设计、审批、测试、安全审查和发布流程仍然按照传统人工节奏运行。

因此，真正的瓶颈开始从 Build（开发实现） 向两侧迁移：前面的规划与设计，以及后面的测试、评审、治理和部署。

这意味着，企业若只是给工程师增加 AI 编码工具，却不改造整个 SDLC，最终很容易出现“代码生成很快，但需求、评审和发布都在排队”的情况。

什么是 AI-Native SDLC？

AI-Native SDLC 不是简单地在传统流程中增加一个 AI 助手，而是把 AI Agent 嵌入软件生命周期的每一个阶段，并让阶段之间通过可被人和 Agent 同时读取的版本化产物自动衔接。

典型产物包括：

intent.md：为什么要做、要解决什么问题

spec.md：需求与设计

plan.md：实现计划

代码 Diff 与测试

PR 与自动化 Review 结果

事故/运行记录

这些产物既是下一阶段的上下文，也是完整的审计链。

核心变化

Playbook：六个阶段

原文把整个流程划分为六个并非完全线性的阶段：

① Plan

② Design

③ Build

④ Test

⑤ Deploy

⑥ Maintain

重点不是“从第一步机械执行到第六步”，而是逐步建立一套由版本化产物驱动、由 Agent 自动衔接、人类集中处理关键判断的闭环。

01 · Plan：把想法直接变成 intent.md

传统团队里，一个想法通常要经历需求池、用户故事、评审、估点和多轮会议。

AI-Native 的做法是：让最初提出问题的人直接与 Claude 讨论，由 Agent 帮助澄清：

问题是什么

谁受到影响

期望结果是什么

约束是什么

哪些内容不在范围内

还有哪些开放问题

最终形成 intent.md，由产品负责人审核后提交版本库。

关键点是：意图只捕获一次，而且尽量保留提出者的原始上下文。

02 · Design：需求与设计合并成一次 Agent 工作流

当 intent.md 被接受后，Agent 读取它，并结合组织内部的：

品牌规范

安全规范

合规要求

UX 标准

工程规范

生成 spec.md。

产品负责人主要承担“审核和决策”，而不是从零开始写规格说明。

AI 在这里承担的是压缩信息、应用规则、识别冲突与风险，人负责最终判断。

03 · Build：先计划，再生成代码

原文建议把 Claude Code 的 Plan Mode 作为默认入口。

Agent 先读取：

intent.md

spec.md

代码仓库

CLAUDE.md

然后生成 plan.md，明确：

哪些文件需要修改

修改顺序

风险点

测试方式

如何证明实现符合目标

工程师先审核计划，再允许 Agent 开始修改代码。

这样 Review 的重点从“代码已经写完以后才发现方向不对”，前移到“还没写代码时先确认实现路径”。

CLAUDE.md 的作用

CLAUDE.md 相当于给 Agent 的“团队入职手册”，用于沉淀：

Build / Test / Lint 命令

编码约定

系统架构

常见错误

项目特殊限制

一个很实用的维护原则是：

当 Agent 同一个错误犯了两次，就考虑把纠正规则写入 CLAUDE.md。

同时应尽量保持文件简洁，避免陈旧信息长期占用上下文。

04 · Test：把验证持续嵌入实现过程

AI-Native 模式下，测试不应只是开发完成后的独立 QA Gate。

更合适的方式是让：

单元测试

集成测试

Evals

静态检查

安全检查

持续伴随 Agent 的实现过程运行。

目标不是完全取消人工 QA，而是让机器先处理能够自动证明的部分，把人的注意力集中在真正需要判断的地方。

05 · Deploy：从“逐行人工 Review”转向分层治理

随着 Agent 生成的代码量增加，所有代码都靠人逐行审查会越来越难扩展。

更适合的模式是：

① 测试和规则自动检查

② Agent Review

③ 安全/合规策略检查

④ 风险分级

⑤ 关键或受监管代码再进入人工审批

Hooks、Skills、组织策略和 CI/CD 可以逐渐成为自动化治理机制。

人的角色从“检查所有动作”，转向“处理高风险、异常和最终审批”。

06 · Maintain：生产环境重新驱动需求循环

AI-Native SDLC 最终是一个闭环，而不是部署后结束。

运行中的：

错误

性能退化

SLA / SLO 越界

安全异常

用户反馈

都可以由 Agent 监控、归因和整理。

当某项控制指标被突破后，可以自动生成新的问题描述，重新写回 intent.md，再次进入 Plan → Design → Build → Test → Deploy。

也就是说：

Production → Intent → Spec → Plan → Code → Review → Production

成为持续循环。

一个非常重要的迁移原则：明确 Source of Truth

企业通常已经有 Jira、ServiceNow、Figma、需求系统、变更审批平台等工具。

AI-Native 并不要求立即把这些系统全部替换掉。

更重要的是，对每一种产物明确：

Git / Markdown 是权威来源；或

传统系统是权威来源；或

至少建立双向链接，例如 Ticket ID ↔ Commit SHA。

这样 Agent 工作流才能与现有审计、合规和团队协作方式共存。

这篇文章最值得带走的观点

AI 编码工具真正改变的并不只是“工程师写代码的速度”。

当 Build 阶段被极大压缩后，整个组织必须重新考虑：

如何捕获需求

如何给 Agent 提供 Context

如何沉淀组织知识

如何自动执行政策和治理

如何把测试前移

如何重新设计人工 Review

如何让生产反馈自动进入下一轮开发

所以，AI-Native SDLC 的核心不是 AI 帮你写更多代码，而是：

让整个软件交付系统围绕 Agent 的速度重新设计，同时把人的注意力保留给真正需要判断和负责的地方。