AI-native 开发工作流

“AI-native 开发”这个词现在被用得很大，但大部分时候它只被当成“用没用 AI 写代码”来理解。这个理解是有问题的：一个人用 Copilot 补全几行代码，和一个人把整个需求丢给 Agent 然后只做验收，这两件事在工程上是完全不同的物种。混为一谈，会导致既高估了前者的收益，也低估了后者的代价。

这篇文章想干一件事：把 AI-native 开发拆成一套可执行的工作流，讲清楚每一步人和 Agent 各干什么、边界在哪、哪里最容易翻车。

（文中的 Agent 泛指 Claude Code、Cursor Agent、Codex 这类能自主读写文件、执行命令的工具，不特指某一家。）

一、先立定义：什么才算 AI-native

判断标准不是“有没有用 AI”，而是这两个问题：

1. 分解权在谁手里——把一个模糊需求拆成可执行步骤，这件事谁在做？
2. 验证责任在谁手里——凭什么相信产出是对的？

按这两条，可以把开发形态分成三档：

形态	粒度	分解权	验证方式	典型工具形态
AI 辅助	行 / 函数	人	人读代码	补全、单文件改写
AI 协作	任务	人定任务，AI 定实现	人审 diff	对话框里改一个文件
AI 原生	目标	AI 主导，人给约束	自动化 + 人做事实核验	能自己跑测试、自己改多文件的 Agent

关键差别在交付单元的粒度。补全的交付单元是几行代码，你天然会读；Agent 的交付单元可能是“一个新接口 + 迁移脚本 + 一堆测试”，几百行 diff，你不可能逐行读。所以 AI-native 的整个方法论，本质是回答一个问题：

当我没法逐行审查产出时，我靠什么保证质量？

答案只有两个：规格和验证。这也引出了全文的核心转变。

几个自检问题

想判断自己是不是在做 AI-native，问自己：

• 需求进来，第一反应是“我去写”，还是“我去描述清楚 + 想好怎么验收”？
• 你对自己代码的信心，来自“我逐行读过”，还是“测试过了、也手动点过了”？
• 你的瓶颈是打字速度，还是规格写得清不清楚？

如果第三问的答案是“打字速度”，那你还在 AI 辅助阶段。AI-native 的瓶颈一定在规格和验证上。

一个反直觉点

AI-native 不是“少写代码”，是把工作量从键盘挪到了规格和验证。少了键盘那部分，多了规格和验证那部分，总量不一定减少，但产出结构和返工成本完全不同——方向对的时候快很多，方向错的时候也贵很多（因为错的东西是被批量生产出来的）。

所以“省事”这个预期本身是错的。省下来的打字时间，应该全部投到“怎么描述清楚”和“怎么验出来”上。投入不足，就是又快又烂。

二、核心转变：规格是新的编程语言，验证是新的编译

2.1 规格是新的编程语言

给 Agent 的规格和给人写的需求文档不是一回事。人写需求文档，可以留模糊，因为下游的人是会自己补全常识的同事；Agent 不会补全，它会自信地按字面理解执行。

一份能被 Agent 执行的规格，至少包含四块：

1. 目标：要达成什么，用可观察的结果描述。不要写“优化一下性能”，要写“这个接口 P99 从 800ms 降到 200ms 以内”。
2. 约束：什么不能动。现有的接口签名、数据结构、命名约定、依赖版本。约束比功能更重要，因为功能没做对会被测试拦住，约束被破坏了往往悄无声息。
3. 验收标准：怎么算完成。理想情况是可执行的——一条能跑的命令、一个能点的页面、一条能看的数据。
4. 明确不做什么：范围边界。Agent 天然倾向于“顺手多做点”，不划边界它会扩大战场。

一个粗糙但有效的检验方式：把规格丢给另一个人，他能不能只靠这段话判断你做完了没有？ 不能，就是规格没写够。

2.2 验证是新的编译

在传统开发里，编译器帮你挡住低级错误，所以你的注意力可以放在逻辑上。在 AI-native 里，验证就是那个编译器——它是唯一能拦住“看起来很对”的东西。

两条不变量：

• 没有验证的产出等于没有产出。 不是“先合了再说”，是它根本不存在。
• 证据优于断言。 不接受“我已经改好了”“测试应该没问题”，只接受“这是命令和输出”。

第二条值得展开，因为它违背人的社交直觉。人是倾向于相信口头承诺的，Agent 的语气又极其笃定。Agent 的自信程度和它的正确率没有相关性——这是整篇文章里最需要内化成肌肉记忆的一条。

三、工作流骨架

把一次开发拆成五步。每一步都明确：Agent 干什么、人干什么、以及这一步出问题的信号是什么。

📐 另有一份按研发全生命周期切的十阶段设计（十阶段能力地图 + 端到端执行流程图，逐节点可点开）→ 《AI 原生研发 · 十阶段融合设计》
它的框架参照 Anthropic 的 《The AI-native SDLC playbook》（Louis Claxton，2026-08-21）—— 想看上游原文，直接点这个。

3.1 探索：搞清楚现状

Agent 做：读代码、找调用链、定位相关文件、总结现有实现。这一步 Agent 比人快一个数量级，因为它可以毫无怨言地把 200 个文件翻一遍。

人做：定方向。告诉它“我们关心的是 A 这条路径，不是 B”，否则它会给你一份详尽但无用的全量报告。

翻车信号：Agent 在没有读任何代码的情况下就开始给方案。出现这种情况，说明你的指令里没有“先看，再说”，直接打断。

这一步的产出是一份共识：你确认它理解了现状，而不是它猜对了现状。

3.2 计划：先看图纸再动工

人做：审计划。这是整个流程里投入产出比最高的一次介入。计划阶段改一句话，等于实现阶段改一百行。

Agent 做：给出步骤、涉及文件、验证方式。

要看什么：不是看它写得对不对，是看有没有你没说过的假设。计划里的每一个“我假设……”，都是潜在的返工点。

翻车信号：计划里出现了你没要求的重构、没提过的依赖、范围明显膨胀。这时候砍掉，别想着“反正它自己会做”。

3.3 实现：Agent 的主力战场

Agent 做：写代码、改文件、跑命令、迭代。

人做：不打断，但设边界。提前说清楚哪些操作要先问（删文件、改依赖、动配置、联网、提交）。

翻车信号：

• 同一类错误连续修三轮还没过——这不是在收敛，是在打转。停下来回滚重来，比继续 debug 便宜。
• diff 规模超出计划里说的范围——它跑偏了。

3.4 验证：这一步不能外包

人做：事实核验。跑一遍它说的命令，点一遍它说的页面，看一眼它说改了的地方。

Agent 做：提供证据。命令、输出、失败时的报错原文。

翻车信号：它说“测试通过”但给不出命令和输出。这就是纯断言，等同于没做。

详见 4.3，验证是全文最容易自欺的一步。

3.5 交接：写给人看的东西

人做：提交信息、文档、给同事的解释。这部分不要外包给 Agent。

原因很实际：这些东西的唯一读者是未来的你和你的同事，而未来你在读它的时候，需要的是当时的决策理由，不是对代码的复述。Agent 能写出准确的 diff 摘要，但写不出“为什么当时选了这个方案而不是那个”。

翻车信号：提交信息是“update files”或一段漂亮的废话。这说明结尾这一步没人管。

3.6 完整的执行流程

上面五步是压缩后的骨架。真实交付链上，每一步之间还夹着门禁和人的判断点——完整原版里把这条链路摊成了三列：AI 执行、规则门禁（Gate）、人的判断/审批。

这里最值得单独拎出来的是门禁的分层：规则检查交给机器（完整性、一致性、覆盖率阈值），意图与风险的判断留给人。这两件事要分开留证，并且都绑定到被批准的那个版本——否则“批过了”会退化成一个模糊的口头状态，既说不清批的是哪一版，也追不回是谁批的。

完整原版里这条流程是逐节点可点开的 → 《AI 原生研发 · 十阶段融合设计》

四、四个关键实践

4.1 上下文工程

Agent 的能力上限，很大程度取决于你喂了什么、以及你挡住了什么。

常驻上下文：项目约定文件（CLAUDE.md / AGENTS.md 之类）

放代码里读不出来的东西：

• 构建、测试、启动的准确命令（包括那些反直觉的参数）
• 目录约定和分层规则
• 禁止事项（“不要动 vendor/”“不要引入新依赖”“不要用 X 库”）
• 外部系统入口（测试环境地址、日志位置、相关仓库）

不要放：目录树的复述、能从代码里读出来的架构描述、大段通用最佳实践。上下文里每一条不相关的信息，都在稀释相关信息的权重。

三层结构

层	内容	获取方式
常驻	约定、禁区、命令	约定文件，每轮都加载
按需	当前任务相关的文件	明确指定，让它读
检索	全库搜索	让它自己搜

原则：能靠搜索拿到的，不要常驻；会变的，不要写死。 常驻上下文应该是“稳定的、跨任务的、读代码看不出来的”。

反向操作同样重要

明确告诉它不要读什么。大仓库最大的浪费是它把时间花在翻无关目录上，然后把噪音带进上下文。给出排除范围，收益常常比多给资料更大。

4.2 任务切分与并行

切分的唯一依据：能否独立验证。

不要按“功能模块”切，要按“可验证边界”切。两个任务如果共享同一个测试、同一份状态，并行只会互相污染。切到每个任务都能单独跑通验证，才算切对了。

共享状态是并行的敌人。

同一个文件的编辑、有先后依赖的迁移、互相引用的重构——这些都不该并行，只能串行。想并行，先做物理隔离：独立的 git worktree、独立的分支、独立的数据库 schema。

什么时候值得用子 Agent

• 任务是只读的（搜索、调研、代码审查）
• 任务独立，不共享状态
• 你只关心结论，不关心过程（它的探索过程会污染你的上下文，交给子 Agent 正好能隔离掉）

什么时候不要

• 同一批文件的修改
• 需要来回对齐的协作型任务
• 你自己都还没想清楚的事（这时候并行只是把混乱复制了 N 份）

4.3 验证优先

先写失败的测试，再让它实现。

TDD 在 AI-native 里比在传统开发里更值钱。原因很直接：Agent 太容易产出“看起来完成了”的东西了。一个先写好的、当前为红的测试，是唯一能证明它真的做了事、且做对的方法。没有测试，你只能在“它很自信”和“代码看起来没问题”之间做判断，这两个都不是证据。

三层验证，缺一不可

1. 自动化测试——能挡住回归，挡不住“测试测错了”
2. 手动冒烟——点一遍关键路径。Agent 改的东西经常能用但用起来别扭，这个只有人能发现
3. 事实核验——它说改了 A，你去看 A 到底改了没

完整的参考设计把验证进一步拆成了三个互相独立的角色，比上面三层更严格：执行器边做边自验证（构建、检查、修复构成小闭环）；独立器用和实现无关的视角去审视，专门补“同源盲区”；AI 配置验证则检查提示词、规则、skill 的变更有没有让流程整体退化。

第三条最容易被忽略：改了规则却不验证规则，等于把回归风险藏进了流程本身。你的规则、skill、配置都是代码，它们同样需要测试。

警惕同源验证。

让 Agent 自己验证自己的产出，等于没验证。它会用和写代码时完全相同的错误假设去检查代码。写和验最好不是同一个上下文——换个 Agent、换个会话、或者换成人。

“完成了”和“证明了”的区别

说法	可信度
“我已经修复了这个问题”	0，这是断言
“我加了校验，应该不会再抛异常了”	0，“应该”就是没跑过
“跑 npm test，输出：12 passed，新增用例在 test/foo.spec.ts:31”	可用，可复现
你自己跑了一遍同样的命令，输出一致	确认

只接受第三和第四种。

4.4 权限与边界

Agent 有能力做破坏性的事，因为它有 shell 和文件写权限。边界要提前设，不要事后追。

最小权限

能读的别给写，能预览的别给提交，能沙箱的别给真机。按任务临时提权，而不是一次给到底。

必须先确认的操作

• 删除文件或目录
• git push --force、reset --hard、改历史
• 动生产环境、动数据库
• 任何把内容发到外部的动作（发请求、发邮件、推公开仓库）
• 安装 / 升级依赖

凭据

密钥、token、连接串不进 prompt，不进仓库，不进日志。需要凭据的操作让它引用环境变量，而不是把值告诉它。

隔离

不确定的操作用容器或临时目录。代价很低，但能避免“它把我工作区删了”这类不可逆事故。

留痕

谁改的、为什么改、什么时候—要能追溯。AI 产出混在人产出里且没有标注，几个月后没人分得清哪段是为什么写的。

五、常见失败模式

现象	根因	对策
说改了，其实没改	幻觉 + 你没核验	只认证据，不认断言
说测试过了，其实没跑	同上	要求命令 + 输出原文
长会话里目标被冲淡	上下文漂移	一个会话一个目标；漂了就开新会话
改一处坏三处	规格里没有约束	约束前置；让它先列影响面
diff 太大没人真看	任务切太大	按可验证边界重切
同一个 bug 修了五轮	方向错了打转	及时回滚重来，别恋战
方向错了却跑得很快	计划阶段没人审	计划是一次高杠杆介入点
自动化全绿但功能不对	测试和实现同源	人做冒烟；换上下文做验证
测试用例没价值，只是为了过关	目标退化成“让测试变绿”，而不是“验证行为”	先写会红的测试；断言行为而非实现
队友看不懂 AI 提交的代码	交接外包了	决策理由人来写

单独说一下“为了过关而写的测试”。

这是 AI-native 里最隐蔽的一种失败，因为它的表现不是报错，而是一片绿。Agent 写测试时的目标函数很容易悄悄退化：从“验证这段代码对不对”变成“让这条命令返回 0”。于是它会——断言实现细节（实现一改测试就碎）、写恒真的断言、绕开不好覆盖的分支，甚至在测试挂掉时去改测试而不是改代码。

一片绿不代表被验证过，只代表有人写出了能让它绿的代码。

判断方法很简单：这个测试红过吗？ 一个从来没红过的测试，等价于没有测试。所以“先写会失败的测试、再让它实现”这个顺序不能反——这不只是工程习惯，它是唯一能证明测试本身有约束力的办法。

六、落地清单

开工前

• 目标写成了可观察的结果（不是“优化一下”）
• 写清楚约束：不能动什么
• 写清楚验收标准：跑什么命令 / 点什么页面算过
• 划范围：明确不做什么
• 确认仓库里有约定文件（命令、禁区、目录规则）

实现中

• 计划看过了，尤其看有没有你没说过的假设
• 危险操作设了确认门槛
• 任务按可验证边界切分，共享状态的任务不同时跑
• 连续三轮同一类错误不过 → 停下回滚，不要继续钻

收尾

• 测试自己跑过一遍，输出我看过
• 关键路径手点过一遍
• 它说改的地方，抽查过几处确实改了
• 提交信息和文档由人写，说清为什么
• 这次产生的可复用约定，回写进约定文件

七、面试视角

这个话题在面试里越来越常见，尤其是做 Agent 相关岗位。答好它的关键不是展示你用过多少工具，而是展示你如何控制质量。

高频问题

• 你用 AI 写代码，怎么保证质量？
• AI 产生幻觉、编造代码怎么办？
• 你怎么划分人和 AI 的边界？
• 团队里怎么落地这套东西？

答题骨架：规格 → 验证 → 边界 → 度量

1. 规格：我怎么把需求变成 Agent 能执行的规格，约束和验收标准怎么定
2. 验证：自动化 + 人工冒烟 + 事实核验三层；不接受断言只接受证据；写和验不同源
3. 边界：什么交给 Agent、什么必须人做；危险操作的确认门槛
4. 度量：怎么知道这套流程是有效的——返工率、diff 审查时长、线上缺陷来源占比

加分点

• 主动讲代价：审查成本上升、上下文维护成本、团队约定需要持续投入。只讲好处会显得你只停在“觉得很爽”的阶段。
• 能区分“AI 辅助”和“AI-native”的粒度差异，并解释为什么粒度一变，方法论就必须变（因为无法逐行审查了）。
• 提到可回滚性：AI-native 里“快速产出一版正确的”固然好，但更重要的是“快速发现并撤销一版错误的”。

减分点

• 只说工具名，说不出质量控制。
• “AI 写的代码我都会逐行 review”——如果真是这么大的产出量，这句话要么不成立，要么说明你把 AI 用成了补全。
• 回避代价，把它讲成纯收益。

相关笔记可以配合 《Agent 与 Harness》 一起看，那篇偏 Agent 侧的实现细节，本篇偏使用侧的工作流。

小结

AI-native 开发的本质，是把工作重心从写转移到描述和验证。

• 规格是新的编程语言：模糊的规格会被自信地执行成错误的东西
• 验证是新的编译：没有验证的产出等于没有产出
• 证据优于断言：Agent 的自信程度和正确率不相关
• 边界要前置：不可逆的事，提前设门槛
• 交接不能外包：为什么做这个决定，只有人能写

最后一条也是最容易被忽略的：这套流程的瓶颈永远在人身上。Agent 已经足够快，快到你如果没想清楚，它会很快地把你带到错误的地方。

参考

• Anthropic，《The AI-native SDLC playbook》（Louis Claxton，2026-08-21）—— claude.com/blog/the-ai-native-sdlc-playbook

  第三章提到的那份十阶段设计，框架参照自这份 playbook。想看 Anthropic 自己怎么描述 AI 原生研发流程，直接读原文。