ARTICLE · 1147764

一个产品加了 AI,为什么还不算 AI 原生?

发布时间：2026-10-09 23:19:52 最近访问：2026-10-09 23:19:53

这几个月写 WorkBuddy、知识库、Skill 和 Dots，我反复碰到一个小问题：它们都可以被称作 AI 产品，可 AI 在里面做的事，并不一样。

有的产品帮人写一段话、总结一场会议；有的已经能读取资料、调用工具，把一件事往前推几步。都在用大模型，产品发生的变化却不在一个层次。

过去看这类产品，我也容易先看模型、参数和 Agent 数量。后来我常用一个简单办法：暂时不看 AI 标签，跟着一项具体工作走一遍。

比起数模型和 Agent，我现在更关心一件事：用户原来要做的那段工作，有没有真的改变。

一张发票

报销很适合说明这个差别。

给原来的系统加一个“识别发票”功能，可以少录很多字段。这类改进本身很实在，跟“原生”与否是两回事。

只是，报销的其他步骤并没有消失。用户还得整理票据、选类别、找制度、填行程，再处理超标和缺材料。AI 省掉了一次录入，整件事还是由人一步步组织。

换一种产品思路，入口可能是：“把这次出差的票据报销了。”

系统去对照票据、行程和当前制度，生成报销单。金额超标、用途不明或材料不齐时，它带着原始依据回来问人；没有争议的部分继续处理，提交后再把审批状态带回来。

两种做法都用了 AI。差别不在“智能”多少，而在于产品有没有开始接手原来由人串起来的那段工作。

看哪里	多一个 AI 功能	AI 进入主流程
入口	打开识票功能	直接说“报销这次出差”
资料	人自己找票据、行程和制度	AI 按任务取用当前资料
过程	AI 返回字段，人继续串步骤	AI 推进常规步骤，例外交给人
结果	得到一次识别结果	报销单和审批状态回到业务

同样用了 AI，接手的工作不同

AI 如果只生成一个结果，它仍是一项功能。当它开始理解目标、找到当前材料、执行获准的动作，并把状态和异常交回来，产品的主流程才开始改变。

原生不看出身

IBM 把两种做法分得很清楚：AI enhanced 是给现有系统补上 AI，AI native 则从产品核心重新考虑架构、交互、数据和运行方式。

这里有个很容易误会的词：“原生”。

它听起来像一种出身，仿佛只有新公司、新代码库才有资格。但 IBM 在文中也明确提到，老企业如果围绕数据和 AI 重新组织业务，同样可以走向 AI 原生。

所以，它更像在描述改造深度，而不是给产品分新旧。

一套上线多年的客服系统，可以在旁边加一个回复生成器，也可以继续向里改：识别问题类型，按权限查订单和知识库，附上来源生成草稿，遇到退款、承诺或低置信度问题就转人，最后把处理结果和修改原因留下来。

原来的业务数据、权限和工作流没有变成包袱，反而是改造的起点。

工作连起来了

把今年写过的几篇文章放在一起看，这条变化会清楚一些。

WorkBuddy 可以从一句需求生成微信小程序。如果页面能打开就结束，它完成的主要是生成。当数据可以保存，身份和权限经过检查，体验版能试，发布后还有人知道怎样维护，这件事才从“生成一个页面”走向一次完整交付。

知识库的情况也很像。上传文件和收藏链接并不难，难的是使用时拿到对的版本，知道一条结论来自哪里，遇到冲突时不装作没看见。人修正过的结果还要回到工作区，不然下次仍从同一个错误开始。知识不再只是一批可搜索的文件，它开始跟着任务流动。

BrowserSkill 又补上了另一块。网页是做给人点的，Agent 要在里面做事，不能只“看懂页面”。它还要知道当前登录了谁，哪些元素可以操作，什么时候应该停，点完以后页面是否真的变了。

Dots 则把时间拉长了。一次对话结束后，任务可能还在等资料、等回复、等一个新状态。产品如果要继续跟进，就得保留目标和当前进度，在需要决定或授权的地方再回来找人。

这几个产品看起来分得很开：一个生成小程序，一个整理知识，一个操作网页，一个跟进长任务。但它们指向同一个变化：AI 从生成内容，逐渐走进任务进行的地方。

AI 进入主流程后，一项工作怎样走完

变化不只是多生成一次内容，而是目标、依据、动作和结果开始连成一段工作。

软件的新用户

Simon Willison 对 Agent 有个很简洁的定义：大模型围绕一个目标，循环调用工具。

这个定义很朴素，也让产品问题变得具体。人使用软件，可以看页面、读说明、猜一个红色按钮会发生什么。Agent 要重复、稳定地完成动作，更需要可调用的能力、明确的参数、可理解的错误和可检查的结果。

Aaron Levie 今年在 X 上提到一个变化：过去的软件先把页面做好，API 往往排在后面；Agent 开始使用软件后，API 会被放到更靠前的位置。人的界面仍会保留，因为结果还要核对、协作和继续处理。

我觉得这比“未来都不需要界面”更接近现在的产品。

在实际产品里，两种使用方式往往会同时存在：Agent 能找到和调用能力，人能看到依据、处理例外、修改结果。API、CLI、Tool 和 Skill 会变得重要，页面和操作记录也不会因此消失。

同一套软件，怎样同时服务人和 Agent

所以，Agent 数量在我这里不再是重要判断。一个 Agent 配上几个边界清楚的工具，可能已经够用。任务没理顺、资料相互冲突、权限说不清时，多几个 Agent 也只是多几段需要对齐的对话。

人还在流程里

AI 原生常被说成“从头到尾自动完成”。这种说法很有吸引力，落到产品里却不太够用。

Karpathy 在《Software 3.0》演讲里借自动驾驶谈到“部分自主”：不同任务适合的自动程度不同，产品需要把自主权做成可调整的设计，而不是在手动和全自动之间二选一。

报销里，票据分类和表单填写可以自动做，制度有歧义时要问人。客服里，常见问题可以准备草稿，退款和对外承诺要交回负责的人。代码可以由 Agent 修改并跑测试，是否合并和发布仍然有工程边界。

一项任务里的不同步骤，可以有不同的自动程度

OpenAI 收集的几个案例，刚好能看到这种分工：

案例	AI 接住了哪段工作	人留在哪里
Basis	把稳定的入职流程做成可复用 Skill	处理例外，确认结果
Clay	为客户持续更新工作空间和一手证据	校正判断，补充上下文
Exa	从机会发现推进到代码修改和测试	复核变更，决定是否合并

做法各不相同，共同点是 AI 没有单独待在对话框里，而是进入了一段有材料、有动作、也有验收的工作。

人不必再亲手点完每个步骤，但目标、例外、承诺和责任还在。这不是一个把人“移出流程”的故事，更像是人和软件重新分工。

回到 AI 原生

如果一定要给一句工作中能用的定义，我会先这样说：

AI 原生，是产品让 AI 作为受约束的任务参与者，重新组织一项工作怎样进入、怎样获取依据、怎样执行、又怎样确认完成。

这只是一个便于继续讨论的理解，不是认证标准。一个只做 AI 识别或内容生成的产品，只要真能解决问题，完全可以是好产品。我也不太愿意为了一个标签，硬把每个工具都做成 Agent。

反过来，界面里有聊天框、背后有多个 Agent，也不代表工作已经重新设计。如果资料还要人到处搬，权限靠猜，做完只留下一句“已完成”，用户承担的主要工作并没有变。

所以，我现在再看一个 AI 产品，会少问一点“它有哪些 AI 功能”，多跟一件事走一遍：从用户开口，到资料被找到，动作被执行，例外被交回，最后结果真的回到业务里。

能看到这些变化时，“AI 原生”这个词才有了具体内容。

产品是这样，团队也会遇到同样的问题。每个人都开始用 AI，个人动作变快了，不代表需求、信息、协作和验收已经跟着变。

下一篇，我们继续聊：每个人都用了 AI，为什么团队效率还是没变？

参考资料

IBM：What Is AI Native?（https://www.ibm.com/think/topics/ai-native）
OpenAI：How AI-native companies turn workflows into operating capability（https://openai.com/index/ai-native-company-workflows/）
OpenAI：Dots（https://learn.chatgpt.com/docs/dots）
Simon Willison：I think “agent” may finally have a widely enough agreed upon definition to be useful jargon now（https://simonwillison.net/2025/Sep/18/agents/）
Aaron Levie：Software becomes API-first（https://x.com/levie/status/2023635013963559352）
Y Combinator：Andrej Karpathy — Software Is Changing (Again)（https://www.youtube.com/watch?v=LCEmiRjPEtQ）
AIAGI：WorkBuddy 实用教程：从一句话需求到上线一个微信小程序
AIAGI：用 WorkBuddy 建立知识库：把收藏夹变成真正能用的工作记忆
AIAGI：我给 WorkBuddy 加了一个浏览器 Skill，让 Agent 真正替你“上网干活”
AIAGI：OpenAI Dot 详解：一个会持续跟进工作的 AI 助手
AIAGI：Agent Skill 是什么？和 Prompt 有什么区别