乐于分享
好东西不私藏

AI 原生到底是什么?钉钉悟空、飞书 Aily:用 AI 重做一遍!

AI 原生到底是什么?钉钉悟空、飞书 Aily:用 AI 重做一遍!

AI训练营9期5月7日开班,欢迎咨询

这两年有个词被用得非常泛,他就是 AI 原生,AI Native,但你如果非要较真去问人家什么是 AI 原生,你会发现完蛋了,真的是全部在自说自话,整理一下会混淆在三个层面做展开:

  1. AI 原生思维;
  2. AI 原生系统/架构;
  3. AI 原生应用/AI 原生团队;

如果这三个东西很容易混在一起,理不开的话就容易囫囵吞枣,用很大的一句话去描述:只要把 AI 当底座,一切都是 AI 原生

结果就是:还是挺空的,依旧搞不明白标准是什么,但这很正常,因为:

发展期没有标准

比如移动互联网,其实是微博奠定了移动端的交互结构(tab,图文流),然后微信做了收敛,最后是抖音告诉大家其实原生得这么做,但小红书也给了不同解。

这里我认为都对,毕竟又不是考试哪有什么标准解,有人用,用得爽就是硬道理。

AI 原生应用

然后回归到 AI 原生应用,我觉得昨天前同事一句话非常贴切:

所谓 AI 原生,就是 AI 生出来的嘛

大家先不要笑,由 AI 而生,为 AI 而生,这就是 AI 原生一个比较好的标准了,这里有两个极为典型的案例:GEO 与 CLI 改造

GEO

首先,整个 GEO 这个产品形态,完全是因 AI 而生,他天然会适应模型的习惯,创造对模型跟亲和的内容与服务。

更准确地说,没有大模型,就不会有 GEO,正如没有浏览器/搜索引擎就没有 SEO 是一个道理

SEO 时代优化的是搜索引擎,目标是让用户在搜索结果里先看到你;

GEO 时代优化的是模型的知识选择机制,目标是让 AI 在回答问题、执行任务时,优先采用你。

两者最大的区别在于:

  1. SEO 争的是展示位;
  2. GEO 争的是引用权、解释权,甚至调用权。

目标不同,载体不同,那么行为就会不同。所以,GEO 从第一天开始,就不是写给人看的,而是写给模型读的内容工程。

因此,GEO 关心的就不再只是关键词、标题、外链,而是:

  1. 模型能不能找到你;
  2. 模型能不能读懂你;
  3. 模型愿不愿意信你;
  4. 模型会不会在关键任务里采用你;

所以 FAQ、结构化问答、案例库、白皮书、权威信源,这些东西在 GEO 时代都会变得异常重要,因为它们 更适合被模型消费

这里小结一下,类似于 GEO 这种因 AI 而生、为 AI 而生的产品,自然就是 AI 原生应用了。

其次,与他类似的 AI 浏览器、NoteBookLM、Manus 等也是 AI 时代的产物。

CLI

如果说 GEO 是 AI 时代的信息分发重构,那么 CLI 改造就是 AI 时代的软件能力重构

他同样很典型,因为:

没有 Agent,就绝不会有这一轮 CLI 回潮

这里又可以对比 GUI 了,他是人类认知/视觉系统而生的产物,GUI 这套东西,本质上是为人类设计的:

  1. 信息密度高;
  2. 强视觉引导;
  3. 靠按钮、菜单、弹窗组织能力;

这对人很友好,但对 Agent 很不友好。因为 Agent 做事不需要看这么多界面元素,他需要的其实是:

  1. 一个明确动作;
  2. 一组明确参数;
  3. 一个明确结果;

比如在人类眼里,升级钉钉文档空间可能是后台里某个很深的按钮;但对 Agent 来说,他要的不是按钮,而是这种东西:

dingtalk doc-space usagedingtalk doc-space plans listdingtalk doc-space upgrade --plan pro_100g --dry-run

所以,CLI 改造的本质,不是把 GUI 换成命令行,而是:

把原本埋在 GUI 背后的能力,重新暴露成一组更适合 Agent 调用的标准动作

这就是 CLI 为什么也是 AI 原生应用,因为它满足同样的两个条件:

第一,它是因 AI 而生的。不是因为人类突然不爱 GUI 了,而是因为 Agent 开始大量进入工作流,软件必须提供一种更适合机器理解和执行的动作层。

第二,它是为 AI 而生的。它关心的不是页面好不好看,而是动作能不能拆清楚、参数能不能说明白、输出能不能结构化、流程能不能被 Skills 顺手组织起来。

站在这个角度大家再去看钉钉整个这次基于 CLI 重构形成的悟空系统,其实就是他们在升级上一代的 GUI 系统,形成新一代 基于 CLI 的 AI 原生系统:

去掉 AI 会如何?

至此,我们再回归为 AI 而生这个点上,就会发现这个标准有些苛刻了,Notion AI、GitHub Copilot 也都是旧容器装新酒,可谁会说它们不是 AI 原生?

所以,在由 AI 而生,为 AI 而生之外,还需要加上一条更宽的检验标准:把 AI 抽掉,这个产品的核心价值还成立吗?

这个时候我们对很多产品的判断就会更清晰了:

GEO:抽掉大模型,GEO 这个概念立刻消失,他当然是真·AI 原生;

NotebookLM:抽掉模型的理解与生成能力,它就是一个普通的笔记本;

最后就是 CLI 改造后的钉钉:抽掉 Agent,它的 CLI 接口对人类几乎无用,但钉钉作为协作软件依然存在(只是退回 GUI)。

但如果这套 CLI 之上还生长出 Agent 自动编排任务、动态调用能力的新逻辑,那么那个编排层才是真正的 AI 原生,而非 CLI 本身。

以此类推,我是一个做传统 ERP 的公司,接下来需要做全面的 AI 改造,如果我们将原来所有的系统做 Tools 化,丢给 AI 做调用,在上层做个 OpenClaw 包装,接下来这个算不算 AI 原生应用?

他当然算啊,移动互联网与 PC 互联网也是继承关系,而不是颠覆关系啊...

因 AI 而重新组织

综上,单说 AI 应用原生,我认为不是有没有 AI,而是系统是不是围绕 AI 重新组织过

因为 AI 真正带来的变化,不是多了一个能力点,而是它会反过来要求产品去改自己的基本结构。这种结构变化,至少会发生在三个层面:

  1. 交互方式变了
  2. 能力组织方式变了
  3. 系统运行方式变了

从这里就可以回答问题了:AI 原生,到底原生在哪里?

AI 原生,就是产品把 AI 当成主引擎,而不是外挂插件,这个主引擎有两个判断标准:

一、AI 是否进入了主流程

很多产品也接了大模型,但 AI 只是用来做:

  1. 润色;
  2. 总结;
  3. 问答;
  4. 推荐;

这种当然有价值,但它更像是 AI 增强,而不是 AI 原生。因为产品主体没变,主流程也没变,AI 只是加分项。

而 AI 原生不一样,AI 原生的产品,AI 需要进入了主流程本身,甚至控制主导流程,比如:

  1. 用户先表达目标,而不是先点按钮;
  2. 系统先理解意图,再决定调用什么能力;
  3. 执行过程不再是固定流程,而是动态编排;
  4. 最终交付的也不只是一个页面,而是一个任务结果;

这里关键区别就出来了:

  1. AI 增强:AI 帮你把原来的流程做得更快;
  2. AI 原生:AI 直接参与定义这个流程应该怎么走;

二、AI 是否改变了系统的组织方式

对于 AI 原生,系统会开始围绕 AI 的特性重新组织:

1. 交互从功能入口变成目标入口

以前软件更像工具箱,你自己找锤子、找螺丝刀。

AI 原生软件更像一个会干活的助手,你先说目标,它再决定调用什么工具。

2. 能力从页面能力变成动作能力

以前能力藏在页面里,得靠人自己点。现在能力要被拆成可调用、可组合的动作单元。

GEO 是这样,CLI 改造也是这样,本质都在做一件事:把原本服务于人的表达,改造成更适合 AI 消费的结构。

3. 泛化能力增强

接下来也是重点判断了,以往系统往往是基于 Workflow 结构进行设计,如果有用户/需求超出边界那么就人为进行扩展(程序员写代码补全边界);

现在来说的话,是不希望我们做这一切了,而是我们只提供20% 的 Workflow,去稳定解决 80% 的核心问题,而剩下的 20% 就由 AI 的泛化能力自己搞定。

连锁反应

综上,AI 原生不是一个单点能力,而是一种新的产品范式,再说直白一点:

  1. 以前的软件,核心是 功能集合
  2. AI 原生的软件,核心是 任务完成

这个变化非常大。

因为功能集合的逻辑是:

我把能力摆在这里,你自己学会怎么用

而任务完成的逻辑是:

你告诉我你要什么,并且提供能力清单,我来想办法帮你做完

整个这个东西下来很多变化就产生了:

  1. 权限系统会变;
  2. 能力封装方式会变;
  3. 数据组织方式会变;
  4. 工具接入方式会变;
  5. 评估标准也会变;
  6. ...

到这里大家就可以看出来了,如果一个团队的目标是一个 AI 原生应用,那么他们的开发方式就与传统团队差距很大了。

在这个基础上,我们再来讨论 AI 原生团队:

AI 原生团队

其实 AI 原生团队反而更好讨论些,因为人是不可能被 AI 生出来的,如果要说 AI 原生团队,觉得比较好的描述就是:对 AI 适应得比较好的团队

而关于 AI 原生团队的回答,我觉得由我来做不合适,以下是我与某CEO 关于 AI 原生团队的讨论:

所谓 AI 原生团队,其实判断条件简单而苛刻:

他是一号位工程,所以最核心的判断标准是公司实际做事的一号位,到底用不用 AI?

这里的核心是他对各种 AI 能力的边界是什么,是不是清楚,有没有评价能力

在一号位清晰 AI 边界的情况下,才是 能用 AI,就不用人的大策略,这里的点是:至少这个团队的人在脑子上要先 AI

在基础认知没问题的前提下就应该上强度了,也就是:

如何组织团队的工作流程/方式,让他更适应于 AI 的习惯

这里举个例子:

基于 Spec-Kit 的改造

比如我们自己在做 AI Coding 落地时,就做过一次比较典型的团队改造: 《我们如何摸索出一套 AI 协作研发范式》

一开始,我们想解决的问题很直接:怎么让 AI 在人的监管下,尽可能完整地承担代码实现。

但真正做进去后很快发现,瓶颈根本不在模型会不会写代码,而在于团队前面的东西稳不稳定,比如:

  1. 需求边界清不清楚;
  2. 规则口径统不统一;
  3. 接口约束明不明确;
  4. 验收标准能不能落地;

这些东西如果没立住,人来写会返工,AI 来写只会返工得更快。

所以我们后来调整的重点,不是先换更强的模型,也不是先堆更多 AI 工具,而是先改团队自己的工作方式:把需求、设计、实现、验证这些原本比较松散的环节,尽量收进一条更稳定的规范链路里。

最开始我们用飞书文档承接需求和规则,后面又把文档和代码仓打通,再进一步转向基于 Spec-Kit 的 SDD。最后真正得到的,不是一套工具用法,而是一种新的协作方式:

让规范、实现、验证、修复和反馈回写逐步形成闭环,让 AI 不再只是辅助写代码,而是在约束下参与真实研发。

这件事的意义很大,因为它说明 AI 原生团队 不是大家都会用几个 AI 工具,而是团队已经开始为了 AI 去重写自己的协作流程。

过去很多事情靠人盯,比如:

  1. 需求有没有说清楚;
  2. 代码是不是偏离规范;
  3. 实现完之后和 spec 到底有没有对齐;

现在则开始变成:

  1. 规范前置;
  2. AI 按规范实现;
  3. 实现后再校验;
  4. 发现问题继续修复和回写;

说白了,团队不是单纯用了 AI,而是开始围绕 AI 的工作方式重新组织自己了。

这就是我理解里比较典型的 AI 原生团队:

不是 AI 替团队干活,而是团队先把自己改造成更适合 AI 干活的形状

上述只是我们在产研体系的实践,接下来我们举个国外完整链路的案例:

Code Banana

如果说我们基于 Spec-Kit 的那次探索,更多还是站在研发链路里,去摸索如何让 AI 在规范约束下参与真实交付;

那么 Code Banana 这类方案,则更进一步,它已经不只是改研发流程,而是在尝试把整个团队的动作方式,按 AI 的习惯重新编排。

AI 原生团队的重点,不是多用几个 AI 工具,而是:

团队有没有主动把自己的工作拆成更适合 AI 理解、执行、检查和反馈的形状

传统团队的很多工作方式,其实都不太适合 AI。

比如大量依赖口头同步、临场判断、隐性经验、跨角色来回确认,这些东西人能消化,但 AI 很难稳定承接,AI 更喜欢的是另一套东西:

  1. 明确的动作边界;
  2. 清晰的输入输出;
  3. 稳定的任务顺序;
  4. ...

而 Code Banana 这类方案,本质上就是在做这件事:把团队原本比较混沌的工作过程,切成一段段更适合 AI 接手的标准动作。

这里说人话就是:老子知道你不会好好做或者不会做,所以直接照着我的规则做就行了,于是这里关于 AI 原生判断标准就出来了:

有没有一套切实可行的基于 AI 的团队管理方案

如果有,那么 AI 就不再只是某个成员手边的提效工具,而开始进入团队真正的运行链路:

  1. 哪一步该分析;
  2. 哪一步该生成;
  3. 哪一步该验证;
  4. 哪一步该回写;
  5. 哪一步必须人确认;

这些都不再靠线下交流,而是基于线上 AI 的协作开始有更稳定的组织方式。

只不过,Code Banana 这个案例到底有多少成功案例,每个案例到底做到什么程度了现在是不知道的,但是它很好地说明了一点:

AI 原生团队的本质,不是团队里有 AI,而是团队本身开始按 AI 能工作的方式重组

这和前面的 GEO、CLI 改造其实是一回事: GEO 是让内容更适合模型消费,CLI 是让能力更适合 Agent 调用,而 Code Banana 这种团队组织方式,则是让团队本身更适合 AI 参与协作。

结语

最后结合文章讨论,给 AI 原生 下一个相对清楚的定义:

AI 原生,不是给旧系统加一个 AI 功能,而是把 AI 当成新的基础设施,围绕它重新设计产品、流程、架构和团队。

反过来说,所谓非 AI 原生,很多时候就是在旧软件系统上叠加了一些 AI 能力,比如这里的结构图:

AI 在里面很多节点上当然做了足够降本增效的作用,但他并没有改掉事件/产品的核心流程和业务逻辑。

这里举个例子:团队每个个人都在使用 AI(Coding) 做提效,有的100%、有的甚至500%,但是整个团队最终加到一起发现整体提效就 20%,这就是很多团队正在发生的情况:

AI 确实对每个个人有很大的帮助,但整体事件的收益并不太大,甚至一些关键人反而更累了...

AI 不是一次普通的功能升级,而是一次生产力变革,生产力一旦变了,生产关系、产品形态、组织方式就迟早都要跟着变。

这就像移动互联网时代,如果你还想拿 PC 时代那套思路,简单把网站压成一个手机版,那大概率是要吃亏的;

也像更早些年的云原生,真正的变化从来不是把服务器搬上云,而是承认云已经成了新的基础设施,于是运维体系、组织分工、岗位能力、交付方式都要一起改。

AI 原生也是一样,它要求我们重新去想几个问题:

  1. AI 时代的用户是谁?已经不只是人了,而是 人类 + AI;
  2. 新的用户习惯是什么?不再只是点按钮、走菜单,而是表达目标、调用能力、完成任务;
  3. 新的产品形态应该是什么?不再只是功能集合,而是围绕任务完成来组织系统;

对企业、团队、个人来说,就需要思考一个问题了:

你到底是在旧系统里给自己打补丁,还是已经开始在新世界的规则下重建自己

这,可能才是 AI 原生最核心的意义。

点击上方卡片关注叶小钗公众号,查看下方二维码,添加我个人微信:

往期推荐

《系统性:如何进入AI行业?》

《万字:Agent概述》

《万字:做一个Agent-上》

《万字:做一个Agent-下》

《万字:理解LangChain》

《实践:用LangChain开发一个Agent》


《万字:AI Coding 的真实情况》

《万字:普通人学 AI Coding》

《AI Coding 实战:10年祖传系统,54万行代码,2周重构结束》

《AI Coding 实战:2周重构54万行代码,细节详解》


《重要:AI学习路线图》

《万字:个人IP,包教包会》

《万字:AI客服实战方法论》

《万字:生产级别的RAG系统》

《万字:RAG实战技巧,包教包会》


《2025年终总结》

《OpenClaw 会不会淘汰 Coze、Dify 这类平台?》

《别被 OpenClaw 带偏了,AI 公司到底该如何组织人才?》