AI 原生软件开发到底是什么?当代码不再是瓶颈,整个开发流程都要重做

过去一年，AI 编程工具让写代码的速度大幅提升。

但很多公司的软件开发流程并没有同步改变：需求仍然要开会、设计仍然要层层交接、代码仍然等待人工逐行审查、测试仍然集中在流程末端，线上问题仍然要等人发现后再重新排进 backlog。

结果是，AI 把代码写得更快了，但项目整体并没有快多少。

Anthropic 最近发布了一份《AI-Native SDLC Playbook》，提出了一个核心判断：

当代码不再是最慢的环节，软件开发真正的瓶颈就会转移到代码两侧。

也就是需求、设计、测试、审核、发布和维护这些仍然按照人类速度运行的环节。

这份指南讨论的不是“如何让 AI 多写几行代码”，而是如何把整个软件开发生命周期改造成 AI 原生流程。

一、传统软件开发流程为什么开始跟不上了？

传统的软件开发生命周期，通常分为六个阶段：

计划；
设计；
开发；
测试；
部署；
维护。

每个阶段通常由不同角色负责：产品经理写需求，架构师出设计，工程师写代码，测试团队做验证，发布团队上线，运维团队监控生产环境。

这种分工并没有错。它的优点是责任明确、流程可追溯，也方便在大型组织中控制风险。

问题在于，这套流程诞生于“写代码最耗时”的时代。

过去，一个功能可能要开发几周甚至几个月。需求文档、估算会议、设计评审和安全检查，都是为了减少昂贵的返工。

现在，AI Agent 可能在几小时内生成大量代码。于是原本合理的流程开始暴露出新的矛盾：

工程师写代码变快了，但需求确认仍然要开很多会；

AI 一次生成大量代码，但人工审查能力没有同步增长；

测试集中在最后，问题仍然很晚才暴露；

安全团队按人类产能配置，审查队列却被 AI 生成的代码迅速填满；

发布和运维仍然依赖人工操作，成为新的等待环节。

因此，AI 带来的不是简单的“开发阶段提速”，而是整个流程的速度失衡。

二、什么是 AI 原生 SDLC？

AI 原生 SDLC，可以理解为一套围绕 AI Agent 重新设计的软件开发生命周期。

它和传统流程的最大区别有三个。

1. 从线性流程变成循环

传统流程通常像一条流水线：需求交给设计，设计交给开发，开发交给测试，测试交给发布，发布后进入维护。

AI 原生流程更像一个循环：生产环境的监控结果可以自动生成新的需求，需求经过设计、开发、测试和审核后再次发布。

2. 每个阶段都有 AI 参与

AI 不只负责写代码，还可以帮助整理需求、生成设计方案、制定实施计划、运行测试、检查 Pull Request、分析线上异常。

3. 每个阶段都留下机器可读的成果

每个阶段结束时，都要提交一个版本化的文件或代码成果，供下一个阶段读取：

intent.md

：想解决什么问题；

spec.md

：需求和设计规格；

plan.md

：具体实施计划；

代码和测试：实际实现；

PR 及审查意见：变更和治理记录；

事故记录：线上问题和改进结果。

这些成果共同构成一条审计链，记录“谁提出了什么、AI 做了什么、谁审核了什么、最后结果如何”。

三、第一阶段：Plan，把想法直接变成 intent.md

在传统流程中，一个想法通常要经过 backlog、用户故事、需求评审、估算和多轮 refinement，最后才可能到达工程团队。

问题是，经过多次转述之后，最初提出问题的人想要解决的事情，可能已经变形了。

AI 原生流程的做法是，让想法的提出者直接和 AI 对话，把问题整理成 intent.md。

这个文件不需要一开始就写得很专业，可以包含：

现在遇到了什么问题；

谁受到影响；

理想结果是什么；

涉及哪些系统；

有哪些约束；

哪些问题还没有答案。

例如，客服运营人员可以直接描述：客户经常打电话询问理赔进度，客服大量时间被状态查询占用，希望在门户中展示理赔状态、下一步和预计日期。

AI 再通过提问，帮助补充用户范围、约束条件和成功标准，最后生成结构化的 intent.md。

但这里有一个重要边界：AI 可以帮助整理，产品负责人仍然需要审核和修正，确认文件确实表达了真实意图。

四、第二阶段：Design，把需求和设计放进同一个工作会话

传统流程中，需求分析和设计经常由不同团队分阶段完成。分析师先写需求，设计师再把需求转成界面和交互，过程中会发生多次信息损耗。

AI 原生流程倾向于把这两部分压缩到一个工作会话中：AI 读取已经批准的 intent.md，结合组织的品牌、合规、安全和用户体验规范，生成 spec.md。

这份规格文件需要说明：

要解决的问题；

功能和交互如何工作；

需要改动哪些系统；

约束和依赖是什么；

哪些地方存在风险或冲突；

哪些问题仍需要人决定。

关键变化是：政策不再等到代码写完后才被发现，而是在设计阶段就被作为约束加载进来。

产品负责人不必亲自把整份设计文档写出来，但仍然需要检查：设计是否真的解决了最初的问题，AI 标出的风险是否得到处理，以及高风险事项是否交给了正确的负责人。

五、第三阶段：Build，先计划，再写代码

AI 原生开发并不等于“让 AI 直接开始改代码”。相反，这份指南强调：

没有被接受的计划，就不应该开始实现。

工程师可以让 Claude Code 先进入 Plan Mode，读取 intent.md 和 spec.md，生成一份 plan.md。

计划应该写清楚：

哪些文件会改动；

改动的先后顺序；

哪些测试能够证明功能完成；

可能破坏什么；

风险最高的步骤是什么；

为什么不采用其他方案。

工程师先审查和修改计划，确认一个没有参与前期讨论的人也能只看 plan.md 完成实现，然后才允许 AI 写代码。

这样做的好处是，设计方向错误时，修改一份文档远比修改一大批代码便宜。

把团队知识写进 CLAUDE.md

传统团队知识往往散落在 Wiki、聊天记录和老员工记忆中。

AI 原生团队会把新成员需要知道的内容整理到仓库里的 CLAUDE.md，例如：

如何构建、测试和运行项目；

项目使用哪些语言和框架；

目录和架构约定；

哪些做法被禁止；

AI 经常犯哪些错误。

一个实用原则是：如果 AI 在同一个问题上犯了两次错，就考虑把修正写进 CLAUDE.md。

但文件不宜太长。它应该像一个新成员入职第一天需要的工作手册，而不是把整个公司知识库都塞进上下文。

Skills 和 Hooks 分别负责什么？

这份指南把组织知识和自动化控制拆成了不同层次：

Skill：把安全、品牌、接口规范等知识写成 AI 能读取和执行的规则；

Hook：在 AI 即将执行某个动作时，自动允许、询问或阻止它。

Skill 更像“提醒和指导”，Hook 更像“真正的门禁”。对必须无条件遵守的政策，不能只依赖提示词或 Skill，还需要确定性的脚本、测试或审批机制。

六、第四阶段：Test，把反馈循环放进开发过程

传统流程往往在开发末尾集中测试。AI 原生流程则要求 AI 在工作过程中持续验证自己的结果。

这意味着项目要尽量提供一键运行的检查命令，例如：

make build

：构建成功；

make test

：测试全部通过；

make lint

：没有警告；

截图与批准的设计一致；

接口返回预期状态码和字段。

AI 完成一部分工作后，应该自己运行这些检查；失败后先修复代码，再让人看到结果。

对于 Bug 修复，指南建议先写一个能复现问题的失败测试，确认测试确实因为预期原因失败，再让 AI 修改代码使其通过。

这样，测试就不只是“检查结果”，也成为防止 AI 修改测试来掩盖问题的证据。

Continuous Evals：给 Agent 做持续评测

对于 AI Agent 本身，普通单元测试还不够。

团队可以收集 20—50 个真实任务，把“输入是什么、什么结果算通过”写成评测案例。

只要模型、Prompt、CLAUDE.md、Skill 或 Hook 发生变化，就自动运行这些评测，确认 Agent 的能力没有倒退。

线上发生的每个重要事故，也应该增加为新的评测案例，避免同类问题再次发生。

七、第五阶段：Deploy，让 AI 做审查，但保留人的最终责任

当 AI 生成的代码越来越多，人工逐行审查会成为新的瓶颈。

AI 原生流程的做法不是取消审查，而是把审查分层：

AI 对每个 PR 做一致性的基础检查；

检查 Bug、逻辑错误、安全漏洞和是否符合规格；

自动修复明确的审查意见；

人类把注意力集中在意图、风险和关键决策上；

受监管或高风险代码仍然要求人工审批。

例如，可以在仓库中维护 REVIEW.md，规定审查必须分为三类：

Bugs：逻辑错误和边界问题；
Security：注入、认证、敏感信息泄露等；
Compliance：是否符合 spec.md、plan.md 和团队设计原则。

AI 的审查结果本身不能替代代码所有者审批。真正重要的改变是：人类不必再把时间花在寻找机械性问题上，而是可以重点判断“这项变更是否值得上线，以及风险是否可接受”。

Hooks 作为发布门禁

对于生产环境部署、数据库迁移和基础设施修改等动作，可以通过 Hook 设置审批门禁。

AI 可以完成构建、测试、审查和准备发布，但在真正触及生产环境前，必须等待指定人员授权。

这保留了人类责任，同时避免让人类参与每一个普通文件编辑。

八、第六阶段：Maintain，让线上问题自动回到开发循环

传统维护通常是被动的：监控发出告警，某个人发现后创建工单，团队再决定什么时候处理。

AI 原生维护尝试把这条链路自动接起来。

例如，当测试失败率、线上 5xx 错误率或部署后的某个指标超出控制范围时：

确定性的监控脚本发现异常；
AI 读取日志、指标和最近的变更；
AI 生成诊断结果和 intent.md；
后续工作重新进入计划、设计、开发、测试和审查流程；
需要高风险操作时，通过 PR 或预先批准的回滚流程处理。

这里的关键是，AI 不应该自行决定所有事情。

更安全的做法是设置分级响应：

轻微偏差：只记录日志；

中等偏差：允许 AI 只读诊断；

严重偏差：允许 AI 提交修复建议或触发经过批准的运行手册；

生产环境修改：始终经过既定审批门禁。

这样，维护不再是生命周期的终点，而成为下一轮开发的起点。

九、AI 原生 SDLC 最核心的变化：从“审查动作”到“审查成果”

在 AI 编程早期，很多人会盯着 Agent 每一步做了什么：它打开了哪个文件、运行了什么命令、修改了哪一行。

当 Agent 能够运行更长时间、并行处理更多任务时，这种方式很难扩展。

AI 原生流程把关注点转向版本化成果：

intent 是否准确？

spec 是否满足需求和政策？

plan 是否完整、风险是否可接受？

代码和测试是否证明计划已经实现？

PR 审查是否覆盖关键问题？

线上事故是否进入新的评测和知识文件？

这就是“人类仍然负责，但不必监控每一个动作”的治理方式。

十、普通团队应该从哪里开始？

不要一上来就试图把六个阶段全部自动化。更现实的路径是从几个低风险动作开始。

第一步：建立一份短小的 CLAUDE.md

先写清楚项目如何构建、测试、运行，以及 AI 最容易犯的错误。把它提交到版本库，并像代码一样接受审查。

第二步：要求 AI 先给计划

对于中等以上的开发任务，先让 Agent 输出影响文件、实施顺序、风险和验证方式，再开始修改代码。

第三步：给 AI 一个反馈回路

确保项目有简单、稳定、可重复运行的测试、构建和截图检查命令。

第四步：让 AI 做基础 PR 审查

先从 Bug、明显安全问题和是否符合计划开始，不要一开始就让 AI 取代人工代码所有者。

第五步：把重复错误沉淀为规则

把反复出现的修正写进 CLAUDE.md 或 Skill；把必须强制执行的规则放进 Hook 或 CI。

第六步：再考虑自动触发

当前面的规则、权限、测试和回滚路径足够成熟后，再让监控、工单或合并事件自动触发 Agent。

AI 原生不是“让 AI 写更多代码”

Anthropic 这份 AI-native SDLC 指南最值得关注的地方，是它没有把 AI 编程理解成一个孤立的工具升级。

当代码生成速度发生数量级变化时，需求、设计、测试、审查、发布和维护也必须重新设计，否则效率只会堵在代码两端。

真正的 AI 原生开发流程，至少包含四个关键原则：

每个阶段都留下版本化、可追踪的成果；

AI 负责处理规模化、重复性和机械性的工作；

人类把注意力放在意图、风险和责任判断上；

能自动化的规则交给测试、Hook 和 CI，不能只靠口头约定。

未来的软件团队，可能不再是“一个人负责一个任务”，而是一个人同时协调多个 Agent、审查多个成果，并维护一套让 Agent 能安全工作的系统。

所以，AI 原生软件开发的核心问题不是：

AI 能不能替代工程师？

而是：

当 AI 可以承担更多执行工作后，我们如何重新设计一套让人类保持判断力、让系统保持可控性的开发流程？