一年前写代码还是软件研发里最慢、最贵的一环。今天AI 写代码的速度已经快到流程追不上。Anthropic 的 Applied AI 团队在 2026 年 8 月发布了一份《The AI-Native SDLC playbook》AI 原生软件研发流程手册用 46 分钟的篇幅讲清楚了一件事当代码不再是瓶颈整个软件研发流程需要被重新画一遍。01 先搞清楚一个问题为什么流程比代码更慢几乎所有公司的软件研发都跑同一套流程六个阶段规划Plan、设计Design、构建Build、测试Test、部署Deploy、维护Maintain。传统上每个阶段由不同角色负责产品经理写需求架构师画设计工程师写代码测试团队验证发布团队上线运维团队盯生产。阶段之间靠文档、工单和签字交接。这套流程的设计初衷是好的——每一步都有人负责、可追溯。但它的前提是整个研发周期里最慢、最贵的是“写代码”这个环节。现在这个前提不成立了。AI 代理比如 Claude Code把构建阶段从“几周”压缩到“几小时”但流程的其他部分还停在人类速度于是三个问题同时出现瓶颈转移——慢的变成了构建前后的规划、评审、测试和部署控制失效——逐行审查在代理产出面前跟不上人工评审成为瓶颈治理成本上升——例外情况仍要等每周、每月一次的会议拍板。一句话流水线的中间环节被 AI 提速了两端和中间的闸门却没跟上。02 AI 原生研发流程从一条线到一个环Anthropic 给出的答案叫“AI 原生 SDLC”也有人叫 Agentic SDLC、AI SDLC说的是同一件事。它不是简单地在每个环节塞一个 AI 工具而是把线性流程改造成闭环让 AI 嵌入每一个环节同时保留传统流程的控制目标用新的方式去执行。传统流程是一条线Plan、Design、Build、Test、Deploy、Maintain走完一遍算一个发布周期再走一遍是下一个周期。AI 原生流程是一个环六个环节首尾相连AI 在环里执行人类在环的上方——发起任务、指导方向、做最终管控。手册里有一句很形象的话传统流程以“周”为单位AI 原生流程以“小时”为单位。03 贯穿全程的秘密每完成一步就提交一份“工件”这个闭环能转起来靠的是一个容易被忽略的机制提交工件committed artifact。每个阶段结束时都要向版本控制提交一份文件下一个阶段读取它开始工作规划阶段提交intent.md——用发起人自己的话记录“想要什么、为什么、在什么约束下”设计阶段提交spec.md——需求和设计合并成一份规格说明构建阶段提交plan.md——批准后的实施计划连同代码和测试部署阶段提交PR 和评审结论维护阶段提交事故记录。这一连串提交本身就是审计轨迹谁提的需求、AI 产出了什么、谁批准了全部有据可查。这也是这套方法与传统流程最大的区别传统流程用会议和签字来对齐新流程用文件之间的先后触发来自动衔接。04 六个阶段各自怎么改Plan 规划把需求会议变成一次对话传统做法想法要经过需求池、用户故事、故事点估算、评审会层层转手到工程师手里已经离原始意图很远了。新做法发起人用自己的话和 Claude 聊Claude 像分析师一样追问范围、用户、约束和成功标准聊完直接生成一份结构化的 intent.md产品负责人修改确认后提交。从第一次对话到形成可执行的意图文件从几周缩短到几小时。Design 设计需求和设计合并成一次会话传统做法分析师写需求设计师再解析成设计两套人马、两个阶段慢而且有信息损耗。新做法Claude 拿到 intent.md 后直接产出“需求设计”合并的 spec.md。组织的品牌、安全、合规、UX 规范被编码成 skills在生成时就生效而不是几周后的评审才发现问题。产品负责人只评审、不撰写。Build 构建先批准计划再写代码新做法把“先计划后动手”变成硬规则工程师用 Claude Code 的 plan mode 开始工作Claude 先读代码库、产出一份实施计划改哪些文件、按什么顺序、用什么测试证明工程师反复质问这份计划直到满意才批准批准后的计划提交为 plan.md。手册还配套了几个关键组件CLAUDE.md团队知识文件AI 每次开工先读它、skills把制度变成可执行的约束、hooks构建期护栏比如禁止改受保护文件、并行会话和子代理一个工程师同时开几个工作流。Test 测试让 AI 先自测再交给人类核心原则每个会话都要有验证自己工作的方式——跑测试、跑构建、截图对比。AI 在把结果交给工程师之前先自己迭代到通过。更进一步CI 里跑“持续评测”把 20 到 50 个真实任务收集成考卷每次模型或配置变化都考一遍防止 AI 越改越差。生产事故也会变成新的考题防止同类问题再犯。Deploy 部署AI 能到生产门前但过不了门评审双向化AI 既按组织策略评审别人的 PR也在自己 PR 上回应评审意见。人类评审从“逐行看代码”上移到“判断意图和风险”。审批门自动化hooks 变成放行、询问、拦截三道闸关键闸门如生产发布必须由指定的人批准。边界清晰CI/CD 里 AI 可以非交互运行、做判断类工作分析失败构建、写变更日志部署工具通过 MCP 暴露成受控工具按环境分级自治——开发环境放手生产环境必须人工授权。手册的原则是代理可以做一切直到生产门前人类守住门。Maintain 维护闭环自己转起来一个确定性脚本盯着生产指标比如 CI 失败率、发布后 5xx 错误率用控制带分级1σ 只记录2σ 唤起 AI 只读诊断3σ 允许 AI 提修复方案走 PR 评审或触发预先批准的应急预案。AI 的诊断结果写成 intent.md重新进入规划阶段——于是整个环自己转起来人负责分诊和批准不再负责“启动”。另外还有定期的代码安全扫描Claude Security和值班机器人Claude Tag在 Slack、Teams 里以自己身份响应事故。05 最容易误读的三件事误读一AI 原生等于全自动人没事干了。恰恰相反。手册反复强调“人类留在环上”发起、指导、管控都由人来做判断性决策和最终审批保留给人。AI 提升的是执行速度不是决策责任。误读二有了 AI 评审人工评审可以取消了。不是取消是上移。逐行看代码交给 AI 的策略评审人聚焦在“这个改动是否符合意图、风险是否可接受”。评审没有消失只是换了位置。误读三这是 Anthropic 在推销自家产品。手册确实用了自家工具举例但核心是一套方法论工件链、反馈环、分级审批、闭环监控。这些做法是产品无关的用其他 AI 编程工具同样可以落地。06 这套流程适不适合你看三个变量如果你的团队正在用 AI 写代码可以从三个角度判断第一代码产出是否已经超过流程消化能力如果 AI 写出的代码在评审和部署环节排队说明流程需要改造第二是否有可靠的测试和验证基础反馈环是这套方法的地基没有测试AI 无法自证工作质量第三团队是否愿意把知识写进文件CLAUDE.md 和 skills 的维护是持续投入需要把“存在人脑子里的知识”变成“AI 每次开工读的文件”。行动建议很朴素不要一次性改造全部六个阶段从 Plan 或 Build 单点试点先把一个环转起来。