到底什么才算 AI-native？

最近一次面试里，我被问到一个现在很常见的词：

AI-native

这个词我以前也经常看到。我的理解大致是：它不是简单地在原有产品里接入一个大模型、增加几个 AI 功能，而是 AI 更深入地影响产品本身的设计。

但这个定义还是很宽。

现在一个 SaaS 加了 AI summary，可以说自己 AI-native；一个公司大量使用 Copilot，也可以说自己正在成为 AI-native organization。招聘 JD、产品官网、融资稿里都很常见。

所以我后来重新整理了一下这个概念。

我觉得判断一个产品是不是 AI-native，重点不在于“有没有用 AI”，也不一定在于“是不是从 Day 1 就用了 AI”，而在于：

AI 到底改变了这个产品的什么？

最基本的区别：AI 是一个功能，还是已经进入产品的核心结构？

IBM 对 AI-native 的定义大意是：

AI 从一开始就是核心组成部分，而不是后来外挂进去的功能；它会进一步影响产品架构、决策、用户体验和整个系统生命周期。

这里的“从一开始”其实不用理解得太字面。

一家已经存在十年的软件公司，同样可能因为 AI 重新设计自己的核心产品。

比如一个传统客服系统，本来有工单、搜索和模板回复，后来增加一个 AI summary。

这是一个很好用的 AI feature。

但如果 AI 开始参与理解客户历史、查询相关系统、判断下一步、生成处理方案，而人的角色逐渐变成审核和纠偏，变化就明显更深了。

这时候 AI 改变的已经不只是一个功能，而是整个 workflow，以及人与系统之间的分工。

所以比“它是不是从 Day 1 就用了 AI”更值得看的，是：

AI 有没有改变产品的核心价值、workflow、系统结构，甚至 economics？

我现在大概会从四个地方判断。

1. 核心价值有没有变化？

以前很多软件要求用户自己知道：

去哪个页面、填什么字段、点什么按钮、按什么顺序操作。

AI 产品开始出现另一种可能：

用户先表达自己想完成什么，系统再帮助判断应该怎么做。

变化不只是多了一个聊天框。

产品和用户之间的分工开始变化。

过去的软件更多是在帮助用户完成一系列操作；现在一些 AI 产品开始承担其中一部分判断和执行。

比如用户不再需要明确告诉系统：

先查这个数据，再打开那个页面，再执行下一步。

他可能只需要给出一个目标，系统自己理解 context、调用工具、处理中间结果，在需要的时候再让人审核或纠偏。

OpenAI 在谈 Agent 时经常使用一个词：delegation。

我觉得这个词很准确。

AI-native 的一个重要变化，就是软件开始从“帮助用户操作”，逐渐走向“接受一部分任务委托”。

当然，并不是所有产品最后都会变成全自主 Agent。

真正重要的是：AI 是否开始承担过去必须由用户明确决定的一部分工作。

2. Workflow 有没有真的重做？

很多所谓 AI 产品，其实仍然是：

原来的 workflow + 一个 AI button。

原来写报告需要填十个字段，现在旁边多了一个：

Generate with AI

功能可能很好用，但流程本身并没有发生太大变化。

更深入的 AI 产品设计，会重新考虑整个 workflow：

• 用户到底还需要输入多少？
• 哪些步骤可以由系统自己决定？
• 什么时候应该问人？
• 什么时候可以继续调用工具？
• 做错以后怎么恢复？
• 人是在操作每一步，还是逐渐变成设定目标、审核和纠偏？

于是流程不再完全是固定的：

step 1 → step 2 → step 3

中间会出现更多由 context、模型判断和运行结果决定的动态路径。

这也是为什么 Agent、tool use、context engineering 这些概念会一起变得重要。

当系统可以自己判断下一步，产品设计自然也不能只考虑页面和按钮了。

3. 模型外围会多出一整套新的产品能力

这一层是我以前比较容易忽略的。

如果只是做一个很简单的 AI 功能，看起来可能就是：

prompt → response

接入模型 API，拿到结果。

但一旦 AI 真正进入核心 workflow，很快会遇到很多额外问题：

• 模型现在知道什么？
• 可以访问哪些数据？
• 能够调用哪些工具？
• 有没有权限执行这个动作？
• 出错以后怎么办？
• 怎么知道新模型到底让产品变好了，还是变差了？

于是产品外围会慢慢长出：

context、memory、tools、permissions、guardrails、evals、observability、fallback……

这些东西以前当然也不是完全不存在，但 AI 产品会明显放大它们的重要性。

这也是我现在觉得 AI-native 很容易被误解的地方。

大家很容易把注意力全部放在模型本身：

• 用了哪个模型？
• 是不是最新的？
• benchmark 高不高？

但真正到了生产环境，模型只是系统的一部分。

大家可以买到类似的模型能力，真正决定产品能不能稳定工作、敢不敢交给真实用户的，经常是模型外围这一整套系统。

所以我现在反而觉得：

AI-native 的“native”，很多时候体现在模型外围。

4. 连 economics 都可能跟着变化

AI 产品还有一个很现实的区别：

使用本身会持续产生计算成本。

一个复杂任务可能包含模型调用、检索、工具执行、长 context、多轮 reasoning，失败以后还可能重新运行。

于是产品很早就需要考虑：

• 什么任务值得用更强、更贵的模型？
• 什么时候可以 routing 到更便宜的模型？
• 一个 Agent 可以运行多久？
• 给用户多少额度？
• 按 seat、usage、task，还是最终结果收费？

这些已经不只是技术问题。

它们会直接影响产品体验、margin 和商业模式。

传统 SaaS 里，很多功能开发完成以后，用户多点一次按钮带来的边际成本很低。

AI 产品不一定如此。

所以如果 AI 真正进入产品核心，它有时候会一路从 UI、workflow、system architecture，影响到 economics。

AI-native 更像一个程度，而不是一道分界线

所以我现在不太想把所有产品简单分成：

AI-native / 非 AI-native。

更接近一个逐渐深入的过程。

AI feature

在原来的产品里增加生成、总结、搜索等 AI 能力。

AI-enabled

AI 已经明显改变一些重要 workflow，但大部分产品结构仍然沿用过去的方式。

AI-native

AI 开始影响产品提供什么价值、用户怎么完成任务、系统怎样运行，以及产品怎样被评价和收费。

这个边界当然不会非常精确。

而且 AI-native 本身已经被 marketing 用得很泛。

未来如果 AI 真像互联网一样逐渐成为默认基础设施，这个词可能也会慢慢失去区分度。

今天我们已经不会特别说：

“这是一个 internet-enabled product。”

因为默认就是。

AI-native 以后也有可能走到类似的位置。

所以我现在怎么判断一个产品是不是 AI-native？

我不会因为一个产品用了最新模型、有聊天框、有 Agent，或者官网写着 AI-native，就直接接受这个标签。

我会看几个更具体的地方：

• AI 改变了产品的核心价值吗？
• 它改变了用户完成任务的 workflow 吗？
• 它是否要求系统重新处理 context、tools、permissions、eval 和 failure？
• 它有没有进一步改变成本结构和商业模式？

如果这些基本都没有，只是原来的软件增加几个 AI feature，那么 AI-native 更多还是一个包装。

如果 AI 的存在已经让产品需要重新设计核心逻辑，这个词才真正开始有信息量。

这也是我现在面对很多 AI buzzwords 时越来越常用的判断方式：

先不看它叫什么。

先看：

它到底让什么东西和以前不一样了？