过去两年，我们谈 AI 编程，关注点大多是：

• Claude Code 能不能写代码？
• Cursor 能不能提高开发效率？
• Agent 能不能自动修 Bug？
• AI 能不能代替一部分程序员？

但 Anthropic 在 Claude Academy 发布的《The AI-native SDLC Playbook》，把问题往前推进了一步：

如果 AI 已经能大幅提高编码速度，那么软件开发真正的瓶颈，还会是“写代码”吗？

答案很可能是否定的。

当 Coding 越来越快，需求、设计、测试、评审、安全、审批、发布和运维，反而可能成为新的瓶颈。

所以，真正的 AI-native Software Development，不是给程序员增加一个 AI 编程助手，而是重新设计整个软件开发生命周期（SDLC）。

一、从“AI 写代码”到“AI 参与整个 SDLC”

传统的软件开发流程通常是：

Plan → Design → Build → Test → Deploy → Maintain

Anthropic 并没有否定这几个阶段。

它改变的是每个阶段的工作方式。

新的思路更像这样：

需求 / Issue / Incident        ↓     intent.md        ↓      spec.md        ↓      plan.md        ↓    Code + Test        ↓      PR Review        ↓      Deploy        ↓Metrics / Incident        ↓新的 intent.md

这里最重要的变化，是把大量原本存在于会议、聊天和个人经验中的信息，变成了可版本化、可审查、可被 Agent 消费的 Artifact。

Agent 不再只是“接一句 Prompt，然后开始写代码”。

它开始进入一个有上下文、有计划、有验证、有治理的工程体系。

二、先把“意图”变成 Artifact

Anthropic 提出了一个很有意思的文件：

intent.md

它不需要像传统 PRD 那么庞大，只需要说明三件事：

What：想做什么？Why：为什么做？Constraints：有哪些约束？

它可以来源于：

• 产品需求；
• Issue；
• Ticket；
• 生产事故；
• 监控异常。

也就是说，人的模糊意图首先被结构化。

人的想法   ↓Agent 整理   ↓intent.md   ↓人工审核

然后再进入设计和实现。

这解决了 Agent 开发中一个非常常见的问题：

Agent 很擅长执行，但如果一开始就没有把“到底为什么做”说清楚，它只会更快地把错误的事情做完。

三、不要让 Agent 一上来就写代码

这份 Playbook 另一个非常重要的原则，是：

Plan before Code。

不是：

需求 → Claude → 开始修改代码

而是：

需求 ↓spec.md ↓Plan Mode ↓plan.md ↓人工 Review ↓Implement

plan.md 应该说明：

• 修改哪些文件；
• 为什么修改；
• 执行顺序是什么；
• 怎么测试；
• 风险在哪里；
• 如何验证最终结果。

这背后其实是一个非常成熟的工程思想：

人的注意力应该尽量放在“决策点”，而不是每一个机械执行步骤。

AI 负责展开，人负责判断。

四、知识库还不够，知识必须变成“可执行知识”

这部分尤其值得企业关注。

Anthropic 把 Agent 所需知识进一步拆成了几个层次。

CLAUDE.md

告诉 Agent：

这个项目平时是怎么工作的？

比如：

构建命令测试命令目录结构架构约束代码规范项目特殊约定

一个很实用的原则是：

Claude 同一个错误犯两次，就应该考虑把纠正规则写进 CLAUDE.md。

Skill

Skill 解决的是另一类问题：

我们这个组织做某类事情时，统一应该怎么做？

例如：

数据库迁移规范安全编码规范API 设计规范发布规范合规要求

换句话说：

项目经验 → CLAUDE.md组织经验 → Skill

这意味着企业知识库正在发生一个非常重要的变化：

从“给人看的文档”，逐渐演化成“Agent 可以直接调用的能力”。

五、Agent 真正的分水岭：能不能自己验证结果

AI 生成代码其实不难。

难的是：

它怎么知道自己做对了？

Anthropic 把 Feedback Loop 放在了非常重要的位置。

Agent 修改   ↓运行测试   ↓发现错误   ↓继续修复   ↓再次验证

验证可以来自：

• Unit Test；
• Integration Test；
• Build；
• Lint；
• API Test；
• Screenshot Diff；
• 数据库验证 SQL。

如果 Agent 没有验证路径，就会出现一个很典型的问题：

AI 产出越来越快       ↓人工检查越来越多       ↓人重新成为瓶颈

所以，AI-native 的核心不是生成能力，而是“生成—验证—修正”的闭环能力。

六、Skill 是软约束，Hook 是硬约束

当 Agent 真正进入企业生产环境以后，仅仅“告诉它应该怎么做”是不够的。

因此 Anthropic 又引入了 Hooks。

可以简单理解为：

Skill：告诉 Agent 应该怎么做。Hook：规定 Agent 什么绝对不能做。

例如：

DROP DATABASE      ↓     Hook      ↓    Block

或者：

生产环境变更      ↓必须存在审批单      ↓否则禁止执行

这实际上就是把过去写在制度里的要求，进一步变成：

Policy as Code。

Agent 可以越来越自主，但它的权限边界必须越来越明确。

七、真正的 AI-native，是一个闭环系统

这份 Playbook 最有想象力的一部分，是把 Maintain 再连接回 Plan。

例如：

生产环境异常   ↓确定性监控发现问题   ↓Claude 进行诊断   ↓生成新的 intent.md   ↓Plan → Design → Build → Test → Deploy

软件开发生命周期不再是一条一次性的流水线，而开始变成一个不断反馈、不断修正的闭环。

最后

如果把整份 Playbook 压缩成一句话，我认为是：

AI-native SDLC，不是让 AI 写更多代码，而是把软件开发变成一个 Artifact 驱动、知识可执行、结果可验证、权限可治理、持续反馈的工程系统。

再进一步，可以浓缩成五条：

1. Intent 要结构化。2. Plan 要先于执行。3. Knowledge 要可执行。4. Agent 必须拥有 Feedback Loop。5. Autonomy 必须受到 Eval、Hook 和 Human Gate 的约束。

未来真正拉开企业 AI 工程能力差距的，可能并不是谁先用了 Claude Code、Cursor 或 Codex。

而是谁最先完成了这一步：

把自己的工程经验、知识、流程和治理机制，改造成 Agent 能够理解、执行、验证和持续改进的系统。