【AI Native开发-00】AI Native开发到底是什么

摘要

本文回答三个问题：AI Native 开发是什么、它和 AI-enabled 产品与 AI Coding 有什么区别、以及为什么它必然要求引入 SDD。

核心论点：AI Native 开发改变的不是编码速度，而是软件变更的最小交付单元。 当生成代码的边际成本趋近于零，产能瓶颈会从“写不完”迁移到“审不完”，而唯一可持续的解法是让交付单元自带可验证的意图与证据。

阅读对象：技术负责人、架构师、测试负责人，以及正在把 AI 大规模引入研发流程的团队。

全文约定用同一个案例贯穿本系列：给一个 Astro 博客后台增加删除文章功能。它足够小，可以完整展示；也足够真实，包含权限、状态流转、不可逆操作和构建副作用。

术语约定

不同团队对这些词的用法差异很大，先固定本系列的定义，避免后文歧义。

其中最需要强调的是 Spec 与需求文档的区别：需求文档描述“我们想要什么”，Spec 描述“系统在什么条件下必须表现出什么行为”。前者无法转成测试，后者每一条都能。

先给结论：AI Native 改变的不是写代码速度

“AI Native”经常被理解成给产品加一个聊天框，或者让 Copilot 帮忙补全代码。这两个方向都有价值，但都没有触及问题的核心。

本文讨论的是第三种更容易被忽略的含义：产品本身仍然是博客、CRM、商城或管理后台，但软件的生产方式已经围绕 AI 重新组织。

我的判断是：

AI Native 开发真正改变的，不是代码由谁敲出来，而是软件变更的最小交付单元。

传统开发里，一个功能通常以代码提交或 Pull Request 作为交付单元。AI Native 开发里，一个可交付的变更至少应该包含：

业务意图
+ 可执行的 Spec
+ 受约束的 Plan
+ 实现代码与测试
+ 可复现的验证证据

只生成代码，不足以构成一次可靠的软件交付。

AI Native、AI-enabled 和 AI Coding 不是一回事

可以把三个概念拆开：

这三者可以同时存在，但不能混为一谈。一个产品可以是 AI-enabled，却仍然用传统方式开发；一个团队也可以使用 AI Coding，却仍然没有建立 AI Native 的生产流程。

本系列的范围是：**用 AI Native 的生产方式，结合 SDD，开发和测试传统软件产品。**这不是 AI Native 的全部含义，但它是一个可以被实践、观察和复盘的切入点。

一个判别工具：把 AI 拿掉会怎样

区分三者最快的方法是做一次思想实验：把 AI 完全移除，剩下的东西还成立吗？

AI-enabled 产品   → 拿掉 AI，产品功能残缺（智能摘要按钮失效）
AI Coding        → 拿掉 AI，流程不变，只是慢一些
AI Native 开发    → 拿掉 AI，流程本身失去意义（Spec 无人消费、
                    Plan 无人执行、验证规模无法维持）

这个检验法有个反直觉的推论：AI Coding 用得再重，也不会自动演进成 AI Native 开发。 因为前者拿掉 AI 只是变慢，说明流程结构从未改变。很多团队认为自己已经 AI Native，实际停留在“更快的传统开发”。

判断自己属于哪一类，可以问：过去三个月，有没有为了让 AI 更好地执行，而修改过流程、目录结构、文档规范或测试策略？如果没有，那基本还在 AI Coding 阶段。

为什么速度提升会自己撞墙

AI Native 的必要性不是理念偏好，而是一个可以推演的结论。设一次变更的总成本由三部分构成：

总成本 = 生成成本 + 审查成本 + 返工成本

AI Coding 只降低生成成本。当生成成本从 8 小时降到 20 分钟，另外两项会发生什么？

生成成本 ↓↓↓   代码产出量随之上升
审查成本 ↑↑     待审查的变更量成比例增加，而人类审查速度不变
返工成本 ↑↑↑   未被审出的错误进入生产，修复成本按阶段指数放大

关键在于审查是人类速度的、串行的、不可并行外包的。生成端提速 20 倍，审查端仍是原速，队列必然堆积。团队的真实体感通常是：需求交付快了，但线上问题变多了，Code Review 变成橡皮章。

因此 AI Native 开发的核心命题可以重新表述：

如何让审查成本不随生成量线性增长。

SDD 的答案是：把审查对象从“大量代码”换成“少量意图 + 自动化证据”。审查一份 40 行的 Spec 比审查 600 行 diff 快得多，而且判断质量更高 —— 因为人类擅长判断规则对不对，不擅长在几百行代码里逐行找漏掉的分支。

一个具体变化：从“写代码”到“管理变化”

假设需求是：

给博客后台增加删除文章功能。

如果直接交给 AI，它很可能立即做出一套看起来合理的实现：增加删除按钮、调用删除接口、刷新列表、补一个成功用例。

但真正需要决定的问题还没有出现：

• 普通用户能不能删？
• 已发布文章能不能删？
• 删除是物理删除还是归档？
• 删除失败时页面状态怎么保留？
• 重复点击会不会发出两次请求？
• 内容是数据库记录，还是 Git 管理的文件？

传统开发者也会遇到这些问题，但通常依靠个人经验、会议和口头沟通解决。AI Native 开发要求把它们变成 AI 可以消费、测试可以引用的显式产物：

角色：管理员可以删除未公开文章；普通用户和访客不能删除
状态：已公开文章不能直接删除
权限：服务端必须校验管理员身份
交互：删除前必须二次确认，取消不发请求
失败：删除失败时保留列表状态并给出重试提示
非目标：本次不做回收站、恢复、批量删除和审计日志

这里发生的变化不是“AI 取代了开发者”，而是开发者的主要工作从实现细节转向定义变化的边界，并判断变化是否正确。

AI Native 开发的四个角色

在这套模式里，人的职责不是消失，而是上移：

人：定义目标、业务规则、风险边界和最终责任
AI：研究代码库、提出方案、执行实现、生成测试
Spec：把“正确行为”固定成可讨论的契约
Verify：把“我觉得没问题”转换成可复现证据

AI 最擅长的是在已有约束下快速执行；它不应该在没有授权时替你决定产品规则。人的价值也不只是最后点一下“批准”，而是：

1. 判断哪些决策必须由业务方明确；
2. 判断哪些风险不能交给自动化流程；
3. 判断测试是否真的证明了用户行为；
4. 在失败时决定应该修改 Spec、Plan、代码还是测试。

责任矩阵：谁决定，谁执行，谁负责

角色描述容易流于抽象，用矩阵表达更清楚。下表的 D 表示决定（Decide）、E 表示执行（Execute）、A 表示最终负责（Accountable）：

有三行的 D 永远不应该落在 AI 上：判断测试是否充分、失败归因分层、发布决策。 原因一致 —— 这三件事都需要承担后果的能力，而 AI 不承担后果。把它们交出去，等于让一个不为结果负责的执行者决定风险边界。

自主性成熟度：L0 到 L4

“让 AI 做多少”不是二选一，而是一条光谱。团队可以按下表自评当前位置：

几点实践观察：

• L2 是当前多数团队的合理落点。 它的性价比最高：AI 承担执行，人保留方案与结果判断。
• 跳级是主要事故来源。 没有 L2 阶段积累的 Spec 规范与自动化覆盖，直接尝试 L3 会退化成“AI 自由发挥 + 人事后救火”。
• 级别是按模块而非按团队设定的。 同一个项目里，文案与样式可以跑 L4，支付与权限应当停在 L2 甚至 L1。用一个统一级别覆盖全仓库，必然要么过度笨重要么过度冒险。
• 升级的前置条件是证据能力，不是信心。 判断能否从 L2 升到 L3，标准是“该模块的自动化测试能否在无人观察时拦住回归”，而不是“最近 AI 表现不错”。

三种典型反模式

在实际推行中，失败的形态比成功更有规律：

反模式一：Spec 剧场。 团队要求每个变更都提交 Spec，但 Spec 是在代码写完后补的。产物齐全，决策却从未前移。识别信号是 Spec 的提交时间晚于实现代码。

反模式二：闸门橡皮章。 每个 Gate 都有人点通过，但没人真的判断准出条件。识别信号是拒绝率长期为零 —— 一个从不拦住任何东西的闸门不是闸门。

反模式三：全量重流程。 把改错别字也套进四阶段，团队被流程压垮后整体放弃。识别信号是开发者开始私下绕过流程直接提交。

这三种反模式的共同根源是把 SDD 当成合规要求，而不是降低审查成本的工具。一旦流程的收益不再大于它的开销，被绕过只是时间问题。

为什么必须有 SDD

AI 会把模糊的意图迅速变成具体代码，而具体代码会制造一种危险的确定感：系统已经有页面、接口和测试，看起来就像完成了。

SDD（Spec-Driven Development）提供的是一条可追踪的链路：

用户问题
  ↓
Spec：系统应该做什么
  ↓
Plan：当前项目准备怎么做
  ↓
Implement：按计划修改什么
  ↓
Verify：用什么证据证明正确

它的价值不是让文档变多，而是让每个决策有来源：

REQ-003 已公开文章不能直接删除
→ Plan-02 服务端状态校验
→ TEST-003 删除已公开文章返回 409
→ Verify-003 接口测试和人工验收通过

一条更现实的工作原则

AI Native 不等于所有任务都要写几十页 Spec。低风险的小改动可以快速完成；涉及权限、删除、支付、数据迁移和核心业务规则的改动，才需要完整闸门。

因此它更像一种风险分级的生产方式：

低风险：明确目标 + 快速验证
普通功能：轻量 Spec + Plan + 自动化测试
高风险功能：完整 Spec + 人工审查 + 可复现 Verify

真正成熟的团队不是让 AI 永远停下来等审批，也不是让 AI 永远自动执行，而是让流程强度与变更风险匹配。

风险分级的判定依据

“低风险”不能凭感觉。建议用四个可观察维度打分，任一维度命中高位即整体升级：

第四个维度最容易被忽略：错误暴露得越晚，前置流程越值得投入。 一个样式错位当天就会被发现，一个越权漏洞可能潜伏半年，两者不该走同一条流程。

本系列的边界与不适用场景

一份负责的方法论应该说明自己在哪里不成立。

本系列不覆盖：

• AI 产品本身的开发（模型训练、评测集、Prompt 工程作为产品功能）
• 纯研究性或探索性项目，需求在探索中才成形
• 一次性脚本与数据分析任务
• 团队规模为 1 且生命周期小于数周的项目

SDD 在以下情况会产生净负收益：

• 需求变化快于 Spec 的维护速度（此时 Spec 会持续过期，反而误导）
• 领域规则尚未被任何人理解清楚（应先做 Spike 或原型，而不是先写 Spec）
• 缺少自动化测试基础设施，Verify 无法产生证据（需先补基建）

一个诚实的前提： 本系列的方法建立在“业务规则可以被明确表达”这一假设上。存在一类问题的正确行为本身就模糊（推荐排序是否合理、文案是否得体），这类需求无法靠 Spec 消除歧义，只能靠评测集与人工判断。把它们硬塞进 SDD，会得到一份看起来严谨但毫无约束力的 Spec。

结语

如果只把 AI 当作更快的代码补全器，瓶颈会从“写不完”变成“审不完”。

AI Native 开发的核心判断可以浓缩成一句话：

代码是实现，Spec 是意图，测试是证据；可靠交付必须把三者连起来。

附录 A：团队现状自评表

逐条回答，记录“是 / 否 / 部分”。否的条目就是下一步的改进入口。

交付单元
[ ] 一次变更能否找到对应的业务意图记录
[ ] 一次变更能否找到验证证据，而不只是“测试跑过了”
[ ] 三个月后能否回答“这条规则当初为什么这样定”

决策前移
[ ] Spec 是否在实现之前产生
[ ] 业务规则的空白是否被显式列出，而不是被默认填充
[ ] AI 是否有权在歧义未解决时拒绝继续

审查可持续性
[ ] 审查对象是意图与证据，还是大段 diff
[ ] Code Review 的实际拦截率是否大于零
[ ] 审查是否已成为交付瓶颈

风险匹配
[ ] 是否区分了低风险与高风险变更的流程强度
[ ] 高风险清单（权限、删除、资金、迁移）是否明确
[ ] 不同模块是否允许不同的 AI 自主级别

证据能力
[ ] 关键路径是否有自动化测试
[ ] 测试断言的是用户可观察行为，还是内部实现
[ ] 验证过程能否被他人复现

一个参考解读：如果“证据能力”整组都是否，那么当前不该急于推行 SDD，而应先补测试基建 —— 没有证据产出能力的 Verify 阶段只会变成签字环节。

附录 B：最小交付单元清单

可以直接作为 Pull Request 模板使用：

## 业务意图
本次变更解决谁的什么问题（一到两句）

## Spec
链接：specs/<feature>/spec.md
关键规则：REQ-001 ... REQ-00N

## Plan
链接：specs/<feature>/plan.md
影响文件范围：
风险与回滚方式：

## 实现
变更文件清单（应与 Plan 一致，不一致需说明）
未在 Plan 中的改动及理由：

## 验证证据
需求追踪矩阵：REQ → 用例 → 自动化 → 结论
执行命令与环境：
未覆盖项与人工验收说明：
已知限制：

这份清单的作用不是增加填写负担，而是让缺失变得显眼。当“验证证据”一栏只能写“本地测试通过”时，问题已经暴露了。

下一篇不再抽象讨论 SDD，而是看一次具体的失败：AI 如何在没有得到授权的情况下，把一个合理的产品猜测直接做成生产代码。