AI Native 研发流程解析：从 Anthropic AI-Native SDLC 到可落地的 Agent 工作流

最近大家聊 AI Native，很容易把它理解成“产品里有 AI”或者“团队开始用 Claude Code、Codex 了”。

这两个理解都不算错，但都还不够。

先把边界说清楚：AI Native 是一个比 AI Coding 更大的概念。一个客服系统让 Agent 默认完成分流、查询和人工升级；一家运营团队让 Agent 持续发现异常、提出行动方案并在授权后执行；一个内容产品把 AI 放进创作、审核、分发和反馈闭环——它们都可以是 AI Native。共同点不是“用了聊天框”，而是 AI 被设计进价值交付的核心工作流，而不是后来贴上的一个功能。

本文不试图覆盖所有行业的 AI Native。 我们选择其中最容易看清结构、也最贴近开发者的一支：AI Native 在软件研发和交付中的形态，也就是 Anthropic 所说的 AI-native SDLC。后文的 Agent、规格、测试、PR、发布和复盘，都是这个研发语境下的具体答案。

很多团队已经能让 Agent 很快写出代码，交付却没有同样变快：需求没对齐，方案没人确认，测试不完整，PR 堆着没人看，生产环境更不敢让 Agent 碰。代码速度上来了，研发的瓶颈只是换了位置。

Anthropic 在 2026 年 8 月发布的 The AI-Native SDLC playbook，讨论的正是这件事。它的重点不是“怎样让 Claude 多写代码”，而是：当 Agent 已经能参与实现，研发流程应该怎样重做，才能既更快，也不丢掉质量、责任和发布控制。

先说本文在研发语境下的结论：AI Native 不是取消研发流程，而是把研发流程改造成 Agent 能在明确边界内持续推进、人能在关键判断点授权、每一步都有可验证产物的系统。

传统 SDLC 与 AI Native SDLC：从人手交接的线性流程，转向由提交产物和门禁驱动的闭环

为什么要从 SDLC 讲起

SDLC 是 Software Development Life Cycle 的缩写，中文一般叫“软件开发生命周期”。它不是单指工程师写代码，而是软件从一个想法变成线上产品、再被持续维护的整条生产线。

一条典型 SDLC 大致有六个阶段：

规划 Plan → 设计 Design → 构建 Build → 测试 Test → 发布 Deploy → 运维 Maintain

比如，“客户总要打电话问理赔进度”是一个业务问题；澄清谁受影响、要解决什么、哪些数据不能暴露，属于规划；把它变成接口、页面、权限和交互方案，属于设计；前后端实现是构建；单测、集成测试和验收是测试；灰度、审批、上线是发布；线上监控、告警和复盘则属于运维。

传统 SDLC 之所以重，是因为它要解决真实问题：不同角色如何对齐、质量谁负责、合规如何留证、生产变更谁批准。不要把它简单理解为“低效的老流程”。

问题在于，这套流程默认“写代码和实现代码最慢，而且主要由人完成”。Agentic Coding 把构建阶段压缩后，规划、评审、测试和发布依然按人速运行，于是新的拥堵出现了：代码产出更多，安全审查队列更长；改动更快，口头知识更容易跟不上；生产风险也不会因为代码是 AI 写的就自动消失。

这就是 Anthropic 提出 AI-native SDLC 的背景。它不是要废除旧流程的控制目标，而是要给“质量、责任、合规、授权”换一套能跟上 Agent 速度的执行方式。原文把这个变化概括得很清楚：代码不再是主要约束，约束转移到了构建前后的人工环节。

AI Native 到底是什么

这里可以先把三个容易混淆的词分开：

方式	AI 在做什么	去掉 AI 后会怎样
AI-assisted	补全代码、总结文档、生成局部测试	原有流程照样能跑，只是人更慢
AI-first	遇到问题优先让 AI 参与调研、写初稿或给建议	核心协作与交付仍主要靠人工推进
AI Native	Agent 是工作流中的执行参与者，能消费产物并推进下一步	原有交付方式会失去一块核心执行能力

所以 Native 不是“模型原生”，也不等于“自己训练大模型”。它说的是流程：需求、规则、执行和反馈从一开始就被设计成 AI 可以参与的东西。换到客服、销售、供应链或内容业务，这个判断依然成立；只是本文接下来只把它展开到研发流程。

为了便于理解，本文把成熟的 AI Native 研发系统归纳成一个框架。注意，这不是 Anthropic 发布的官方公式，而是根据其文章及公开项目做的总结：

AI Native =
结构化意图与规格
+ 可行动的 Agent
+ 可执行的组织知识
+ 独立验证与权限门禁
+ 线上反馈回写流程

少了任何一层，都可能“看起来很 AI”，但很难稳定地交付。只有 Agent，没有门禁，叫风险放大器；只有 Markdown 文档，没有可行动的 Agent，还是传统流程；只有自动化，没有独立验证，速度快只是更快地把问题带到线上。

Anthropic 的核心想法：每一步都留下下一个阶段能消费的产物

Anthropic 方案里最值得借鉴的概念是 committed artifact，可以理解为“提交进版本控制、可被下一阶段读取的产物”。

intent.md → spec.md → plan.md → 代码与测试 → PR 与评审结论 → 事故记录

早期阶段用 Markdown，不是为了多写文档，而是让产品负责人和 Agent 读取同一份意图。进入构建阶段后，代码、测试输出、PR 和 CI 结果继续成为证据。于是，团队不必依赖“上个人在会议里讲过什么”，Agent 也不会只拿到一句模糊的“把这个功能做一下”。

Anthropic 文章中几个文件的职责可以这样理解：

产物	它解决什么问题	谁应该最终负责
intent.md	为什么要做、影响谁、约束是什么	需求发起人与产品负责人
spec.md	要做成什么样、哪些规则要满足	产品负责人，必要时会同安全/设计负责人
plan.md	改哪些文件、按什么顺序、如何证明完成	工程师
代码、测试、截图、日志	改动实际做了什么、是否验证过	实施者与代码所有者
PR、批准、发布记录	谁审过、谁承担风险、何时上线	审查者与发布责任人

这条链的价值有两层：一层是效率，下一阶段可以直接读取上一阶段；另一层是治理，任何时候都能回答“谁提出、Agent 做了什么、谁批准、验证证据在哪”。

AI Native 研发系统的五层：从意图与规格，到 Agent、组织知识、门禁验证，再回到线上反馈

不是把规则写给人看，而是让 Agent 真能用到

很多团队的规范放在 Wiki、飞书文档或某位同事脑中。人加入项目后，靠培训和 code review 慢慢学；Agent 加入项目后，如果没有明确上下文，就会一本正经地猜。

Anthropic 把这部分分成三种东西：

• CLAUDE.md：新同事第一天需要知道的命令、架构、约定，以及 Agent 经常犯的错；
• Skills：安全审查、API 规范、设计规则、发布检查等可复用工作流；
• Hooks：不能只靠“建议遵守”的规则。例如禁止改受保护目录、禁止把凭证写进 diff、生产发布需要指定负责人批准。

这里的边界很重要：Skill 能提高遵守规则的概率，但它不是强制执行。必须永远成立的规则，要落到 Hook、CI、分支保护、权限系统或发布平台中。Anthropic 也明确把生产门禁放在人类授权处：Agent 可以准备和推进，不能自己越过最终发布边界。

AI Coding 实例一：Microsoft 的课程仓库如何“自己用自己”

Microsoft 的开源项目 learn-ai-native-dev（ https://github.com/microsoft/learn-ai-native-dev ） 明确以 AI-Native Development 命名，并把自己描述为一套“在公开协作中形成的 agentic coding 课程”。它最有意思的不是课程内容，而是仓库本身的贡献流程。

仓库文档公开展示了这样一条链：

Idea / Fix
→ Copilot Chat 中的 slash prompt
→ Agent 搭建改动
→ 打开 PR
→ reviewer / docs-auditor 自动参与
→ 人批准
→ 合并并部署

这个案例要准确理解。它证明的是一个公开仓库如何把“想法、实现、PR、审查和部署”留在同一条 Git 产物链中；它并不能单独证明大型企业的安全、合规和生产治理已经完整解决。

但它给普通团队一个很好的起点：不要先追求全天候自治。先让每次 Agent 改动都能说清四件事——任务从哪里来、改动依据是什么、谁审过、验证结果在哪里。

AI Coding 实例二：Superpowers 如何把 Coding Agent 变成有工程纪律的执行者

Superpowers（ https://github.com/obra/superpowers ） 没有把自己直接定义为 AI Native 平台。它的官方定位是“由可组合 Skills 构成的 Coding Agent 开发方法论”。但它比单纯的代码生成工具更适合用来解释 AI Native 的中间层：Agent 不应该一收到需求就冲去改代码。

它描述的核心路径是：

想法
→ 澄清真正目标，形成可读设计
→ 人确认设计
→ 写出实施计划
→ 按任务执行
→ TDD 与独立检查
→ 评审后完成

它的价值不在于某个神奇 prompt，而在于把“先弄清楚、再计划、必须测试、最后自检”做成会自动触发的 Skills。对 Agent 而言，这些就是工作方法；对团队而言，它们是可复用、可维护的工程纪律。

这和 Anthropic 的思路正好对应：plan.md 避免在方向不清时直接生成代码；Skills 把重复经验变成上下文；测试和审查把“模型觉得没问题”变成可以检查的证据。

如果要补一个工具位置，可以在这里提到 GitHub Spec Kit（ https://github.com/github/spec-kit ）：它更偏“结构化规格的脚手架”，将 specify → plan → tasks → implement → converge 做成可装配命令。它本身不等于 AI Native，但很适合承担上面公式中的第一层：把模糊意图压缩成 Agent 能执行的规格与计划。

业务场景：理赔进度自助查询，为什么不只是加个聊天机器人

Anthropic 原文给了一个很好懂的业务例子：客户频繁打电话询问理赔进度，客服把大量时间花在状态查询上。

“加一个问答机器人回答理赔进度”可能是 AI-assisted；而用 AI Native 的方式处理，则是一条完整的改进链：

1. 业务发起人和 Agent 一起写 intent.md：客户为什么来电、希望客户在门户看到什么、涉及哪些系统、不能新增哪些 PII、哪些问题尚未确认。
2. 产品负责人审查意图；Agent 在安全、UX 和合规 Skills 约束下生成 spec.md。
3. 工程师用 plan.md 审查接口、缓存、权限、页面和测试路径，再授权实施。
4. Agent 编写代码和测试，附上测试输出、截图或日志；PR 根据规则接受自动审查和人工审查。
5. 发布仍经过授权门禁。上线后，5xx、登录失败率、状态查询完成率等指标进入监控。
6. 如果告警出现，确定性检测先判断是否越过阈值；Agent 在限定权限内诊断、写新的意图或开修复 PR，最终仍由人批准。

这时 AI 并不是一个漂在业务旁边的对话窗口，而是参与了“发现问题 → 定义变更 → 交付变更 → 验证结果 → 继续改进”的业务闭环。

AI Native 不止研发：放到业务里，它是一条能持续交付结果的闭环

上面的 AI-native SDLC 是研发场景。但同一套判断可以迁移到业务：不要只问“有没有接入大模型”，而要问“AI 能否在已授权的边界内，把一个业务信号推进到可验证的结果，并将结果回写到下一轮”。

下面三个是帮助理解的业务场景示意，不是某家公司的公开客户案例：

场景	只加一个 AI 功能	更接近 AI Native 的闭环
客服与履约	聊天窗口回答常见问题	客户问题、订单状态、知识库和权限共同形成案件上下文；Agent 完成查单、归类、起草回复或发起工单；退款、赔付和敏感承诺仍由规则与人工授权；满意度、重复来电率和升级原因再回写知识库与流程
增长与运营	AI 帮运营写一条活动文案	指标异常或用户反馈触发分析；Agent 汇总证据、提出实验方案和影响范围；负责人批准后进入受控实验；转化、留存和投诉数据决定扩大、回滚或产生下一轮实验
内容生产与审核	AI 一次性生成文章或海报	选题、资料来源、品牌规则、审核清单和分发渠道成为共享上下文；Agent 生成草稿并标出不确定项；编辑授权发布；阅读、纠错和转化反馈沉淀为选题规则、事实核查清单或下一篇内容意图

三个场景的共同结构其实很朴素：

业务信号 / 用户请求
→ 结构化上下文与目标
→ Agent 在权限范围内执行
→ 规则、人工或系统门禁决定关键动作
→ 结果指标与异常回写下一轮

这也是为什么“客服机器人”“文案生成器”不必然是 AI Native：如果它不能消费真实业务上下文、不能在边界内推动后续动作、也没有用结果改进流程，它只是一个独立功能。反过来，即便业务里没有显眼的聊天窗口，只要 AI 已经成为价值交付闭环中的默认执行参与者，也可以称为 AI Native。

今天就能开始：别先追求全自动

AI Native 并不要求第一天就让 Agent 自主上线。更稳妥的路径是从一条窄而高频的链路开始。

阶段	先做什么	完成标准
第一步	选一种重复发生的改动，例如新增 API、修线上 bug、发一篇技术文章	有固定输入、明确负责人和稳定的验收方式
第二步	引入 intent.md 或轻量 Spec，要求 Agent 先写计划	每次改动能说清范围、风险、测试和回滚方式
第三步	把构建、测试、预览、lint 封装成 Agent 可运行命令	Agent 的完成报告包含真实输出，而不是“我已验证”
第四步	把最常见的坑写入项目说明或 Skill	同类错误不再靠口头重复提醒
第五步	给高风险操作加确定性门禁	Agent 没有绕过生产、凭证、受保护数据的路径
第六步	将事故和评审问题沉淀为测试、Eval 或规则	系统不是反复犯同一种错，而是在累积能力

这里有个很实用的判断：如果 Agent 改完代码后，你仍需要从头猜它动了什么、为什么这么动、有没有跑过验证，那么这还只是“更快地生成代码”。当这些答案可以从计划、diff、测试输出、PR 和发布记录里直接找到，AI Native 才开始真正落地。

总结：AI Native 的核心不是自动化，而是可控的持续推进

AI Native 最容易被包装成“让 AI 取代研发团队”。但从 Anthropic 的思路和这些开源实践看，真正发生的变化恰好相反：人的职责变得更清晰。

人负责定义问题、取舍目标、判断风险、接受例外和批准生产；Agent 负责在明确边界内读取上下文、推进任务、生成产物、运行验证、提出下一步。系统负责把规则、权限和证据固定下来。

因此，判断一个团队是否接近 AI Native，不必问“用了多少个 Agent”，可以问下面六个问题：

• 需求是否有 Agent 与人都能理解的结构化产物？
• Agent 是否能基于规格推进到代码、测试或 PR？
• 团队规则是否版本化，而不是只存在于口头和 Wiki？
• 高风险动作是否有不可绕过的权限与发布门禁？
• 每次完成是否附带测试、构建、截图、日志等验证证据？
• 线上事故和评审问题会不会沉淀为新的规则、Eval 或下一轮意图？

如果你们已经让需求、计划、代码、测试、评审、发布和复盘共享同一条可追溯工作流，那么做的就不只是“AI Coding”。更准确的说法是：你们正在建设一套以 Agent 为执行参与者、以人类判断为最终责任、以验证证据为协作接口的 AI Native 研发系统。