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

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

  1. AI 原生思维;
  2. AI 原生系统/架构;
  3. AI 原生应用/AI 原生团队;
AI 原生到底是什么?钉钉悟空、飞书 Aily:用 AI 重做一遍!

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

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

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

发展期没有标准

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

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

AI 原生应用

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

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

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

GEO

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

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

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

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 usage
dingtalk doc-space plans list
dingtalk doc-space upgrade --plan pro_100g --dry-run

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

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

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

这就是 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 原生到底是什么?钉钉悟空、飞书 Aily:用 AI 重做一遍!

因 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 原生到底是什么?钉钉悟空、飞书 Aily:用 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. 评估标准也会变;

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

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

AI 原生团队

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

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

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

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

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

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

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

AI 原生到底是什么?钉钉悟空、飞书 Aily:用 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

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

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

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

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

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

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

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

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

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

而 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 原生到底是什么?钉钉悟空、飞书 Aily:用 AI 重做一遍!

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

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

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

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

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

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

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

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

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

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

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

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

行业动态

无法被蒸馏的人

2026-4-15 8:31:11

行业动态

从聊天窗口到多 Agent 控制台:一次 AI 编程协作范式的转移

2026-4-16 8:31:40

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧