什么是 AI Native | AI 学习路线

开场：又一个「全面拥抱 AI」的故事

这两年你一定听过无数次类似的发布会话术：「我们的产品已全面接入 AI」。点开一看，通常是这么几样东西——右下角多了个聊天机器人，编辑器里多了个「AI 帮我写」按钮，报表页多了个「智能摘要」。

这些东西有没有用？有些确实有用。但它们是 AI 功能（AI Feature），不是 AI 原生（AI Native）。两者的差别不是程度上的，而是物种上的：一个是给旧躯体贴了块新器官，另一个是围绕新器官长出来的整个生物。

混淆这两个概念的代价很真实。创业者的 PPT 写着「AI Native」，产品却是个套壳聊天框；大厂团队忙了半年「AI 化」，最后交付的是没人点的摘要按钮；投资人按原生逻辑给功能型产品估值，然后一起傻眼。所以这一章值得花点时间，把三个问题讲透：

AI 功能和 AI 原生的分界线到底在哪？
为什么说 AI Native 的交互是「意图驱动」而不是「界面驱动」？
拿到一个产品，怎么快速判断它是不是真原生？

在展开之前，先讲一个历史故事——因为 AI 今天正在发生的事，移动互联网当年一模一样地发生过。那段历史有完整的起承转合，是我们手里最好的一张地图。

移动原生：一段值得逐帧复盘的历史

第一阶段：移植思维的惨败

2007 年 iPhone 发布，2008 年 App Store 上线。之后两三年里，整个行业的「移动化」思路出奇一致：把已有的东西缩小，塞进手机屏幕。

具体做法有三种，死法也各不相同：

WAP 网页和 m 站：把 PC 网页砍功能、缩排版，弄出一个「手机版」。能看，但极其难用——按钮小得点不准，依赖鼠标悬停的下拉菜单全部失效，填个表单像在做眼科手术。
桌面软件的迷你移植：把 PC 软件的界面等比缩小搬上手机，菜单层级一层不少，只是每层的点击目标都小到反人类。
网页套壳 App：图标是原生图标，点开是个内嵌浏览器。最有名的失败案例是 Facebook：它曾把移动战略押在 HTML5 上，一个代码库通吃所有平台，结果 App 卡顿到评分跌到两星。2012 年扎克伯格公开承认「赌 HTML5 而非原生，是公司犯过的最大错误」，随后推倒重写原生 App，体验和商业指标才一起爬回来。

这批产品的共同问题是：它们把新平台当成了旧产品的容器。手机被理解成「一台更小的电脑」，而不是「一台有触屏、GPS、摄像头、陀螺仪、永远在线、长在身上的新设备」。

第二阶段：原生设计原则的成型

真正的移动原生，是从一群设计师和工程师重新提问开始的：围绕这块触摸屏和这些传感器，交互应该长什么样？ 答案不是某天才的灵光一闪，而是整个社区踩了三五年坑才沉淀下来的原则：

为手指而非鼠标设计。 苹果的《Human Interface Guidelines》给出了 44×44pt 的最小触控目标——这不是美学建议，而是承认「手指是粗糙的指针」这个生理事实。整个信息架构随之改变：少层级、大目标、宽间距。
手势取代按钮。 滑动切换、捏合缩放、下拉刷新（2009 年 Tweetie 发明，后来被无数 App 抄成了事实标准）——操作本身变成内容的一部分，屏幕空间让位给内容而不是控件。
传感器成为一等输入。 GPS 让「你在哪里」成为默认参数，摄像头让「你正看见什么」成为内容来源，陀螺仪和加速度计让设备姿态也能参与交互。
推送重构了留存模型。 手机 App 不再等用户「来访」，而是主动在合适的时刻出现——这彻底改变了产品与用户的关系节奏。

原则成型之后，才轮到赢家登场：Instagram 不是「把相册网站搬到手机」，而是围绕手机摄像头重新发明了拍照分享；Uber 不是「把出租车公司的网站搬到手机」，而是围绕 GPS 和实时派单发明了全新的出行形态——在 PC 网页时代，这个产品根本不成立；抖音围绕竖屏和「上滑」一个手势重构了内容消费，桌面端反而是它的移植劣化版。

第三阶段：历史留下的三条教训

把这段历史压缩成三条可迁移的教训：

平台能力决定产品形态。 赢家问的是「新能力让什么新产品成立」，输家问的是「旧产品怎么塞进新平台」。
移植期红利是陷阱。 套壳和移植起步快、成本低，但它把产品的天花板锁死在旧形态里，等平台生态成熟后会被原生物种降维打击。
原生原则要等社区踩坑沉淀。 没有人生来知道 44pt 触控目标，AI 也一样——今天的「AI 交互最佳实践」同样处在踩坑期，这是正常的历史进程，不必焦虑，但要保持观察。

把这三条里的「移动」换成「AI」，几乎一字不差地成立。

AI 功能 vs AI 原生

先给出定义：

AI 功能：在现有产品上做加法，AI 是增强项。拿掉 AI，产品照常运转，只是少了个亮点。
AI 原生：产品的核心价值由大模型的能力直接生成。拿掉 LLM，产品不只是变难用，而是根本不成立。

对照着看几个例子，分界线就很清楚了：

产品	AI 是什么角色	拿掉 LLM 后
Notion 的 AI 摘要	笔记软件上的增强按钮	还是一个好用的笔记软件
电商 App 的 AI 客服	客服系统的降本工具	转人工客服，业务照跑
Duolingo 的 GPT 对话练习	语言学习 App 的新课程形态	核心课程和打卡体系完好
ChatGPT / Claude	产品本身就是对话模型	什么都不剩，产品不存在
Perplexity	答案引擎，搜索只是原料	没有 LLM 就没有答案，产品不存在
Cursor / Claude Code	围绕模型能力重构的编程流程	退化成普通编辑器，核心卖点消失
Midjourney	产品就是生图模型本身	没有模型就没有任何内容

再看「命运差异」，更能理解为什么这个区分生死攸关：

被替代者：Chegg。 这家做课后题解答的公司，核心价值是「学生提问，得到答案」——而这恰好是 ChatGPT 直接免费供给的能力。Chegg 也加了 AI 功能，但没用：当 AI 替代的是你的核心价值本身，贴多少 AI 补丁都救不回来，其市值在 ChatGPT 发布后蒸发了绝大部分。类似的还有 Stack Overflow，「搜报错信息找答案」这个入口被 AI 助手大幅分流，流量持续下滑。
被增强者：Adobe。 设计师的核心诉求「做出好作品」没有被 AI 替代，AI 只是让创作更快。Adobe 把 Firefly 塞进 Photoshop 做生成式填充，是典型的 AI 功能策略——而且是对的策略：地基没被抽走的人，不需要推倒重建。
原生物种：Cursor。 同样是写代码，「给 IDE 加一个代码补全按钮」是 AI 功能，而 Cursor、Claude Code 这类工具是围绕「模型能理解整个代码库、能自己动手改代码」这个能力，把编程流程重新设计了一遍：对话即编辑器，diff 即审阅对象，人写意图、模型写实现。这就是原生和功能的分水岭。

规律很清楚：当 AI 替代的是产品的核心价值，你必须重构为原生物种，否则就是下一个 Chegg；当 AI 增强的是产品的边缘环节，功能叠加就是最优解。 判断的关键，是下面这个判据。

判据：拿掉 LLM，产品还成立吗？

判断一个产品是不是 AI Native，不需要看发布会，只需要做一个思想实验：

把产品里的大模型拿掉，换成「没有 AI」，这个产品还成立吗？

成立 → 它是带 AI 功能的传统产品。不成立 → 它才是 AI Native。

AI Native 判据：把产品里的 LLM 拿掉做思想实验，还成立的是带 AI 功能的传统产品，不成立的才是 AI Native

这个判据之所以有效，是因为它直接检验了价值来源：AI Native 产品的价值是从模型能力里「长」出来的，模型是地基；而 AI 功能只是把模型当成一块贴在墙上的装饰板。

实操时可以拆成三个追问：

拿掉之后还剩什么？ 剩下的是一个完整可用的产品（功能），还是一堆没有灵魂的 UI 空壳（原生）？
核心价值由谁产生？ 用户在意的那个结果——答案、代码、图片、决策——是模型生成的，还是系统里本来就有、模型只是润色？
模型失效时退化为什么？ 优雅降级为传统流程（功能），还是直接停摆（原生）？这个答案还会顺带暴露你的容灾设计。

判据还可以反向使用，指导自己的产品决策：如果拿掉 AI 业务毫发无损，说明你做的只是功能叠加——这不丢人，很多场景功能叠加就是正确答案（「常见误区」一节会展开），但别拿「AI Native 产品」的估值逻辑和叙事来自我感动。

从界面驱动到意图驱动

AI Native 最深刻的变化不在后端，而在人和软件的协作方式。要讲清楚这件事，得先补一段 Nielsen 给出的六十年 UI 简史。

六十年 UI 史的三次范式转移

可用性领域的祖师爷 Jakob Nielsen 在 2023 年提出一个论断：AI 是六十年来第一个新的 UI 范式。他把整个人机交互史分成三段：

范式一：批处理（Batch，约 1945 年起）。 用户把打孔卡交给机房，计算机跑完一整批作业再统一返回结果。你和机器之间没有「交互」，只有「提交—等待—领取」。
范式二：命令式交互（Command-Based，约 1964 年起）。 从命令行到图形界面，形态天差地别，但底层逻辑没变：用户逐步发号施令，计算机逐步执行。你点每个按钮、敲每条命令，都是在告诉机器「下一步做什么」。这套范式统治了六十年，今天我们用的绝大多数软件仍在其中。
范式三：基于意图的结果指定（Intent-Based Outcome Specification，2023 年起）。 用户不再下达步骤，只说明想要什么结果；「怎么做」第一次由系统负责。Nielsen 特别强调，这意味着控制权的让渡：用户失去了对过程的控制，换来的是表达成本的骤降。

六十年 UI 史的三次范式转移：批处理、命令式交互、意图驱动，第三次起「怎么做」由系统负责

这个框架的洞察在于：GUI 之于命令行，只是同一个范式里的体验改良（命令还是你下，只是从键盘变成了鼠标）；而意图驱动是范式级别的断裂——软件的职责边界变了。同时它也指出了新范式的新代价：过去的系统「难学但可靠」，现在的系统「好学但结果不确定」。可靠性问题第一次从工程边缘走到了产品中心。

界面驱动：用户学说软件的语言

把范式二落到具体场景：过去四十年的图形界面，本质是同一套逻辑——软件把能力陈列成菜单、按钮和表单，用户负责把自己的意图翻译成一长串 UI 操作。

想订一张机票？你的意图只有一句话，但你得自己完成这串翻译：

界面驱动 vs 意图驱动：订同一张机票，界面驱动要用户把意图翻译成一长串 UI 操作，意图驱动只需说出目标、由系统自己规划执行

每一步都是你在迁就软件：你得知道功能藏在哪个菜单里，得理解筛选条件的语义，得记住流程走到哪一步。软件的复杂度，原封不动地转移到了用户的脑子里。 所谓「软件学习成本」，就是这笔翻译费。

意图驱动：用户表达意图，系统自己想办法

AI Native 的交互是：你把那句话直接说出来——「帮我订一张下周三去上海、价格最低的机票，不要红眼航班」——然后系统自己想办法：理解意图、拆解任务、查询航班、对比价格、向你确认、完成下单。

过去是用户迁就软件、学习界面；现在是软件迁就用户、理解意图。复杂度的转移方向反过来了。 这也是为什么「意图驱动」的产品必然长出一对孪生能力：澄清（听不懂时怎么问）和确认（动手前怎么对齐），后面工程部分会展开。

一个最小的代码对比

界面驱动的伪代码，本质是让用户当人肉状态机，逐步走完你写死的流程：

// 界面驱动：流程是开发者编排好的，用户逐步执行
function bookFlightUI() {
  const form = renderFlightSearchForm();      // 用户自己填
  const list = searchFlights(form);           // 用户自己翻
  const picked = waitUserPick(list);          // 用户自己比
  return checkout(picked);                    // 用户自己确认支付
}

意图驱动则是：用户给出目标，由模型规划步骤、调用工具完成：

// 意图驱动：用户给目标，系统自己规划步骤
async function bookFlight(intent: string) {
  // 模型理解意图，生成计划：查航班 → 筛选 → 比价 → 待确认
  const plan = await llm.plan(intent, tools);

  for (const step of plan) {
    if (step.needsConfirm) {
      await askUserConfirm(step);   // 关键操作必须人来拍板
    }
    step.result = await tools[step.tool].call(step.args);
  }
  return summarize(plan);
}

await bookFlight("下周三去上海，最便宜，不要红眼航班");

两段代码的差别就是两种产品哲学的差别：前者的智能在流程编排里，后者的智能在模型对意图的理解和规划里。

工程实践：意图驱动怎么落地

度量：意图达成率

传统产品测「按钮跳转对不对、接口返回快不快」，AI Native 产品的核心指标是意图达成率（Intent Achievement Rate）——用户的目标最终被满足的比例。它比想象中难测，因为没有「正确答案表」可以比对，工程上通常这么搭：

建意图分类法。 先把产品的意图空间枚举成有限类目（如订机票场景下的「查询/比价/改签/退款/咨询」），每个类目定义「达成」的判定标准。没有分类法，指标就是一锅粥。
抽样人工标注。 定期抽会话日志，由人判断「这次会话用户的意图达成没有」。这是金标准，贵但不可省，用于校准一切自动指标。
LLM-as-Judge 放大规模。 用强模型按人工标注的同一套标准给全量会话打分，再用人工抽检计算 judge 与人类的 agreement，agreement 够高才敢信它的全量结论。
拆辅助指标定位问题。 意图达成率是结果指标，动作指标要看：澄清轮次（平均几轮才听懂，太高说明理解差，太低可能是瞎猜）、一次通过率（无澄清直接执行且成功的比例）、人工接管率、回退/撤销率（用户推翻系统结果的比例）。
按意图分层看板。 总体达成率会掩盖结构问题——可能「查询」类 95% 而「改签」类只有 40%。按类目分层看，才知道模型能力和工具覆盖的短板在哪。

澄清机制的对话设计模式

意图不是命令，天然有歧义。好的澄清不是「听不懂就问」，而是一套有层次的对话策略：

置信度反问：模型对意图的把握低于阈值时，主动问一个最关键的问题，而不是闷头执行。问什么比问不问更重要——问缺口最大的那个槽位。
默认假设 + 可纠正：把握较高但有分支时，给出默认方案并显式声明假设——「我按经济舱、直飞来找，想中转更便宜可以告诉我」。把一次打断变成一句确认。
选项式澄清：比起开放式提问（「你想要什么样的？」），给 2-4 个具体选项的澄清成本最低，也最不容易再产生新歧义。
渐进式确认：不可逆操作（支付、删除、发送）单独一道确认，可逆操作合并确认，查询类操作不确认。确认强度和操作代价成正比。

一个最小的澄清循环长这样：

type Intent = {
  action: string;                    // 用户想干什么
  slots: Record<string, string>;     // 已知的参数槽位
  confidence: number;                // 模型的把握程度
};

const CONFIDENCE_THRESHOLD = 0.8;

async function clarify(intent: Intent): Promise<Intent> {
  let cur = intent;
  while (cur.confidence < CONFIDENCE_THRESHOLD || hasEmptyRequiredSlots(cur)) {
    // 让模型找出缺口最大的槽位，生成一个澄清问题（优先选项式）
    const question = await llm.draftQuestion(cur);
    const answer = await askUser(question);
    cur = await llm.merge(cur, answer);  // 合并新信息，更新槽位与置信度
  }
  return cur;
}

注意这个循环里没有任何写死的业务问题——「该问什么」本身也是模型根据当前槽位状态生成的，这正是意图驱动和「表单换个皮肤」的区别。

其余几条硬原则

确定性的事，别交给模型。 支付、删除、发消息这类不可逆操作，必须由确定性代码和人工确认兜底。模型负责「想办法」，工程负责「不闯祸」——这正好和上一章讲的 Harness、权限控制接上。
给系统「想办法」的空间。 意图驱动意味着流程不能写死，要给模型提供一组粒度合适的工具和充分的上下文，让它自己规划。工具设计（Action 空间）直接决定了意图能被满足的范围边界。
界面没有消失，但角色变了。 GUI 从「操作入口」变成「意图确认 + 过程可见 + 结果呈现」。由此还长出一个新形态——生成式 UI：系统根据当前任务动态生成最合身的界面（比价时就该是一张对比表，而不是一段文字），界面从预制件变成生成物。用户不再逐步操作，但他必须看得见系统打算干什么、干得对不对——可解释的中间步骤是信任的来源。
可观测性要按「规划链」建。 意图理解失败可能发生在理解、规划、工具调用任何一环，日志必须能完整回放一条意图从输入到执行的全过程，否则线上问题根本没法定位。

争议：AI Native 是新瓶装旧酒吗？

这个概念并非没有反对者，把两边都摆出来：

质疑方的理由。 其一，「Native」叙事每波技术浪潮都有——Web Native、Cloud Native、Mobile Native——多数时候是融资话术，热词退潮后一地鸡毛。其二，今天大量自称 AI Native 的产品就是「GPT 套壳」：一个 prompt 包一层 UI，没有工具、没有数据、没有评估闭环，模型一升级就被官方功能碾死。其三，「说人话办事情」并不新：搜索框是意图输入，Siri、Alexa 十几年前就在讲意图驱动的故事，最后还不是退化成定闹钟的工具。凭什么这次不一样？

回应方的理由。 其一，移动浪潮早期同样有「App 只是网站的壳」的论调——而且当时多数 App 确实就是壳——但这并不妨碍原生物种后来完成分化。一个概念被滥用，不等于概念本身为空。其二，套壳和原生的差别是可以检验的：剥掉叙事，看有没有自有工具链、上下文管理、领域数据和评估闭环，有系统深度的产品不会因为模型升级而贬值，反而水涨船高。其三，语音助手的失败恰恰证明了范式论述的正确性：意图驱动作为交互理念早就存在，卡住它的是理解能力；Siri 死于「听不懂」，而大模型第一次让「听懂开放意图」跨过了可用线。范式在等待技术成熟度——命令行到 GUI 等了二十年鼠标和图形硬件，意图驱动等到今天才等到它的「鼠标」。

我的判断是折中的：作为一个热词，「AI Native」注定会被滥用和稀释，几年后大概率过时；但作为一个判据，「拿掉 LLM 产品还成立吗」不会过时。遇到任何 AI 产品叙事，别站队，做实验——把模型在脑子里拔掉，看剩下的是什么。这个动作五秒钟就能做完，比争论概念有效得多。

常见误区

把聊天框当 AI Native。 在产品角落塞一个 chatbot，是最典型的「AI 功能的皮肤」。判断方法还是那条判据：把这个聊天框删了，产品是不是毫发无损？
以为 AI Native 就是「全交给模型」。 恰恰相反，原生产品对工程的要求更高：权限、事务、幂等、熔断，一样都不能少。模型是引擎，工程是底盘和刹车。
低估意图理解失败的排查成本。 界面驱动时代，「用户点错了按钮」很好排查；意图驱动时代，「系统理解错了意图」可能发生在规划链的任何一环。没有可观测的中间步骤，线上问题根本没法定位。
为了原生而原生。 很多场景 AI 功能就是最优解——给一个成熟稳定的产品硬套「意图驱动」，往往是把简单事情复杂化。判据是双向的：拿掉 LLM 还成立的产品，老老实实用 AI 功能增强它，收益可能更实在。Adobe 们活得很好，就是证据。

术语表

名词	定义	一句话直觉	常见混淆
AI Native（AI 原生）	核心价值由大模型能力直接生成、拿掉 LLM 就不成立的产品形态	模型是地基，不是装饰	与「AI 功能」混用：加了 AI 特性 ≠ 原生
AI 功能（AI Feature）	在传统产品上叠加的 AI 增强项，拿掉后产品照常运转	锦上添花的那朵花	误以为 AI 功能低级——地基未被替代时它就是最优解
移动原生（Mobile Native）	围绕触屏、GPS、摄像头等手机能力重新设计的产品形态	Instagram 是，m 站不是	误以为「能在手机上跑」就是移动原生
界面驱动（命令式交互）	用户把意图翻译成一步步 UI 操作，系统逐步执行的交互范式	人迁就软件，学说软件的话	GUI 不是它的对立面——GUI 只是命令式交互的体验改良
意图驱动	用户表达目标，系统自行规划步骤并完成执行的交互范式	软件迁就人，听懂人话	意图 ≠ 指令：指令规定步骤，意图只说结果
基于意图的结果指定	Nielsen 对第三次 UI 范式的命名：只指定要什么，不指定怎么做	六十年来第一次「怎么做」归系统管	与「自然语言交互」混淆——语音助手早就能聊天，但理解能力不过关就不算范式成立
Software 2.0	Karpathy 提出的概念：用神经网络权重替代手写代码的软件新形态	代码从「写逻辑」变成「喂数据炼权重」	与 AI Native 不是同义词：2.0 讲软件的生产方式，Native 讲产品的存在形态
意图达成率	用户目标被最终满足的比例，AI Native 产品的核心结果指标	别测按钮，测「事办成没有」	与单轮准确率混淆：达成率按整次会话算，允许澄清多轮
澄清机制	系统对意图把握不足时主动追问、消除歧义的对话设计	听不懂时问一个最关键的问题	与「确认」混淆：澄清是消除歧义，确认是对齐授权
LLM-as-Judge	用强模型按人工标准给会话质量打分的评估方法	用模型批卷子，人只抽查	以为可以脱离人工标注——judge 必须先与人工标注对齐才有可信度
生成式 UI（Generative UI）	由系统根据当前任务动态生成界面，而非使用预制界面	比价就该生成对比表，而不是一段文字	与「聊天界面」混淆：聊天是生成式 UI 的退化形态，不是全部
GPT 套壳（GPT Wrapper）	只有一层 prompt 加 UI、缺乏自有系统深度的所谓 AI 产品	模型升级之日，产品死亡之时	与 AI Native 的边界看系统深度：工具链、上下文、数据、评估闭环

参考材料

AI: First New UI Paradigm in 60 Years — Jakob Nielsen 的著名文章，三次范式转移与「基于意图的结果指定」的出处
Software 2.0 — Andrej Karpathy 2017 年的预言：神经网络正在吃掉传统软件，理解「原生」的必读本
The Rise of the AI Engineer — swyx 的经典文章，讲清楚围绕模型能力做产品的人在干什么
Building Effective Agents — Anthropic 的工程实践，意图驱动系统里「模型想办法」的具体形态
Generative User Interfaces — Vercel AI SDK 文档，生成式 UI 的落地形态参考

小结

记住一句话：把网站塞进手机不是移动原生，把 AI 塞进产品不是 AI Native。

这一章的完整逻辑链是：移动互联网的历史证明，移植思维必败、原生物种晚成但通吃；AI 正在重演同一剧本，分界判据是「拿掉 LLM 产品还成立吗」；交互层面，Nielsen 的三次范式转移告诉我们，意图驱动是六十年来第一次「怎么做」从用户手里移交给系统，由此带来澄清、确认、意图达成率度量这一整套新工程问题；而面对「新瓶装旧酒」的质疑，最好的回应不是站队，而是做那个五秒钟的思想实验。

真原生的标志有三个：价值围绕模型能力重新设计、交互从界面驱动转向意图驱动、以及那条最狠的判据——拿掉 LLM，产品就不成立。后面的章节会接着聊：一个 AI Native 应用从想法到落地，完整的工程链路长什么样。

保持联系