如果你是软件互联网行业从业者，或者正在用 AI 写代码，

你有没有想过，AI 加持下的软件研发流程应该是怎样的呢？

Anthropic 刚发了一份《AI 原生软件开发生命周期（AI‑Native SDLC）实操手册》，分享了他们实践得出的面向 AI 彻底重构后的研发流程。

三种不同的模式

我自己的观察，GenAI 爆发前后，软件研发生命周期有三种典型的模式。

第一档，传统模式。

没有 AI，阶段分得很细，产品经理、前端、后端、架构师、测试、运维，各管一段。

各自按自己的标准输出交付物，然后交接给下一段。

人是唯一的执行者。

第二档，AI 结合模式。

流程还是那套流程，人还是那批人，只是在某个节点上，让 AI 搭了把手。

比如用 AI 写代码、写文档。

本质没变，只是把传统流程跑快了一点。

这是中间态。

第三档，AI 原生模式。

它不是给旧流程打补丁，是整套重构。

我认为最大的变化是这三项：

参与方变了，主要执行者从人变成 AI；

交付物变了，全部面向 AI 设计；

人的角色变了，从"做"变成"审、管、定标准"。

很多团队以为自己已经到了第三档，其实一直停在第二档。

Anthropic 的 AI‑Native SDLC

那 Anthropic 的第三档到底长什么样？

你可能以为，它是不是把流程结构整个推翻了？

恰恰相反。

它的流程骨架：计划、设计、构建、测试、部署、维护，

还是那六个阶段，一个没少。

而在每个阶段内部，有三样东西彻底换了：

交付物是什么、谁来做、人的职责是什么。

下面按六个阶段，逐个拆这三个变化。

计划

先看计划。

传统模式里，产品经理把需求写成 PRD，一份纯给人看的文档。

AI 原生模式里，交付物变成了 intent.md，一份意图文件。

区别在于：它人和 AI 都能读，都进 Git。

谁提需求，谁直接跟 Claude 说清楚，不用任何模板，Claude 把它整理成 intent.md：问题、目标、影响范围、约束、待定项。

参与者变了：写需求的不再是产品经理，是提这个想法的人，哪怕他完全不懂技术。

产品经理的职责，从"写需求"变成"审意图"。

这个阶段做得对不对，看"从有想法到 intent.md 提交"花了多久。

传统是几周，目标是压到几小时。

不过我自己的体验，让 AI 辅助写需求产出质量一般，创新性、个性化的需求还要靠人。那种无数项目做过的普遍性需求除外

设计

设计阶段更明显。

传统是需求、设计两个团队接力：分析师把需求形式化成规格，设计师再把规格翻译成设计。

AI 原生把这两步压成一次会话：Claude 读完 intent.md，直接产出 spec.md，需求和技术设计一次定了。

职责转变在这里看得最清楚：

产品经理不再写规格，而是审规格。

组织的安全、合规、品牌、UX 规范被做成 skill，在 Claude 写规格的当下就约束它，不是写完了、评审会上才发现不合规。

它还会主动把风险点标出来，尤其两条规范冲突的时候。

构建

构建阶段，是人和 AI 职责切换最彻底的一段。

交付物从"人写的代码"，变成"AI 写的代码 + 一份 plan.md 实施计划"。

你给 Claude intent.md 和 spec.md，它先输出 plan.md：

改哪些文件、什么顺序、有什么风险、怎么验证。

你审完这份计划、认可了，它才动代码。

先审计划，比等它写完几十个文件再返工，成本低一个量级。

工程师的职责，从"写代码"变成"审计划、把方向"。

配套资产也要跟上。

CLAUDE.md 放仓库根目录，相当于给 AI 的新人手册，架构、命令、规范，连"AI 常犯的错误"都记进去。

Skills 把组织规范版本化，AI 干活自动加载。

Hooks 是硬拦截，危险操作直接挡下。

还有个反馈闭环：AI 把活交给你审之前，先自己跑一遍构建、单元测试、UI 截图，错了自己改。

测试阶段

测试阶段，交付物从"QA 手写的测试用例和报告"，变成"持续评估的 evals 套件"。

做法是：拿 20 到 50 个真实的历史任务做成评估用例，每个用例一条 prompt、一条"怎样算通过"的判定。

模型、skill、Hooks，有改动，这套评估自动跑，不通过就不让合并。

QA 的职责，从"手动测"变成"维护评估用例"。

而且每次线上出事故，就把这次事故做进用例。

同类问题，以后在 CI 里直接被拦下，不会第二次上线。

这个阶段我个人体会，也不能过度依赖 AI。这种 LLM-as-a-judge 可能适合 GenAI 类项目，或者一些简单固定的场景。

部署

部署阶段，交付物从"人逐行审的代码"，变成"AI 双向评审 + 自动化的审批闸门"。

评审变成双向的：AI 既评审别人的 PR，也处理别人对自己 PR 的意见。

所有 PR 跑同一套评审：bug、安全、符不符合 spec 和 plan，问题按严重度排好。

人只回答两个问题：这改动是不是计划里想要的？风险能不能接受？

治理不再靠评审会，靠 Hooks 当闸门。

Hooks 有三种行为：阻止、询问审批、放行。

改生产配置、跑迁移脚本这种高风险动作，强制走人工审批。

底线一句话：AI 可以做到通往生产的所有步骤，但绝不能越过上线这道闸门。

开发环境放开让它跑，生产环境必须人工授权，回滚提前演练。

维护

维护阶段，交付物从"一条条告警"，变成"诊断结果 + 一份新的 intent.md"。

监控系统用统计学的控制带盯着指标，一旦突破阈值，自动触发 Claude。

Claude 分级处理：先只记录，再只读诊断，最后提修复 PR 或触发预设回滚。

诊断结果写成一份标准的 intent.md，重新流进计划、设计、构建整条链路。

参与者也变了：运维不再盯着屏幕等人报 bug，变成值班筛选，这个修、那个排期、还有个阈值设太敏感了要调。

还有个工具叫 Claude Tag，接进 Slack 或 Teams，聊天里的告警直接变成工单或 intent.md，聊天记录就是审计证据。

四个治理原则

最后，这套东西背后有四个治理原则。

第一，制品即证据，所有文件、技能、钩子都进 Git，提交历史就是审计链。

第二，两层防护：Skills 是建议性的，提升合规概率；Hooks 是强制性的，拦不能妥协的红线。

第三，人守在判断位：AI 管生成、执行、机械校验，高风险和最终批准永远归人。

第四，不用推翻现有工具，Jira、Figma 可以继续用，仓库里的 Markdown 当真相源，两边互记 ID 关联。

落地也不激进：分阶段改，别想一次重构全部。

先上最轻的 intent.md 和 CLAUDE.md 模板，再逐步加技能、钩子、评估、闭环。

核心就一句

用 AI 改造的是整个 SDLC，不是只拿它写代码；人的判断，永远高于自动化。

如果你在做 AI 编程，或者想把团队流程改对方向，这份手册值得完整读一遍。

原始内容在这里（对网络有要求）：https://claude.com/blog/the-ai-native-sdlc-playbook

用 AI 翻译了一份中文版，私信发【260822】自动获取。