AI 原生重构钉钉飞书悟空 Aily：围绕 AI 重塑产品、流程与团队

这两年有个词被反复滥用，那就是 AI 原生，AI Native。可一旦认真追问“到底什么才算 AI 原生”，立刻就会发现各家各派全在自话自说，梳理下来通常会在以下三个层面混为一谈：

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

Image

一旦这三个维度缠在一起，很容易就囫囵吞枣般地抛出一句大而化之的论断：只要把 AI 当成底座，一切就都是 AI 原生。

Image

结果呢？仍旧很虚，依然搞不懂评判标准是什么。但这其实很正常，因为：

在高速发展期，标准本来就是缺失的。

就像移动互联网早期，真正奠定移动端交互范式（Tab、图文流）的是微博，随后微信做了收敛，后来抖音用视频给出了另一种“原生”答案，而小红书又拿出一套截然不同的解法。

这件事本来就没有考试一般的标准答案，有人愿意用，用得舒服，就是硬道理。

什么是真正的 AI 原生应用？

回到 AI 原生应用这个主题，我觉得昨天一位前同事的话格外传神：

所谓 AI 原生，不就是 AI 自己生出来的嘛。

先别笑，由 AI 而生，为 AI 而生，恰好就是一个判断 AI 原生挺不错的标尺。以下就有两个极其典型的例子：GEO 和 CLI 改造。

GEO：为模型而生的内容工程

第一，GEO 这个产品形态，完完全全是因 AI 而诞生的。它天生就适应模型的习惯，专门去创造对模型亲和的内容与服务。

更准确地说，如果大模型不存在，就根本不会有 GEO，正如没有浏览器/搜索引擎就不会有 SEO 一样。

Image

SEO 时代优化的是搜索引擎，目标是让用户在搜索结果前排看见你；
GEO 时代优化的则是模型的知识选择机制，目标是让 AI 在回答问题、执行任务时，优先采纳你。

两者的本质差别在于：

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

目标不同，载体不同，行为也就彻底不同。 因此，GEO 从一开始就不是写给人类阅读的，而是一套写给模型消费的内容工程。

于是，GEO 所关注的便不再只是关键词、标题和外链，而是：

  1. 模型能不能找到你；
  2. 模型能不能读懂你；
  3. 模型愿不愿意信任你；
  4. 模型会不会在关键任务中实际采用你。

正因为如此，FAQ、结构化问答、案例库、白皮书、权威信源这些东西在 GEO 时代变得分外重要，因为它们的结构更适合被模型消化。

小结一下：像 GEO 这种因 AI 而生、为 AI 而生的产品，自然就是标准的 AI 原生应用。与之类似的，还有 AI 浏览器、NoteBookLM、Manus 等，它们同样是 AI 时代的产物。

CLI 改造：为 Agent 调用而重构能力

如果说 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 调用的标准动作。

Image

这便是 CLI 同样被称为 AI 原生应用的原因，因为它满足同样的两个条件：

第一，因 AI 而生。 不是因为人类忽然厌弃了 GUI，而是因为 Agent 正大量进入工作流，软件必须提供一种更便于机器理解和执行的动作层。

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

站在这个角度来看，钉钉围绕 CLI 重构构建出的悟空系统，本质上就是在上一代 GUI 系统的基础上升级，形成新一代基于 CLI 的 AI 原生系统：

Image

检验标准：去掉 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 互联网也是继承关系，而非彻底的颠覆关系……

Image

围绕 AI 重新组织产品

总的来说，判断一个应用是否 AI 原生，我认为关键不在于有没有 AI，而在于系统是否围绕 AI 被重新组织过。

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

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

由此，就可以回答那个问题：AI 原生，究竟原生在哪里？

AI 原生，指的是产品把 AI 当成主引擎，而不是外挂插件。这个主引擎有两个判断标准：

一、AI 是否进入了主流程

很多产品也接入了大模型，但 AI 只是被用来做：

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

这当然有价值，但充其量叫 AI 增强，而不是 AI 原生。因为产品的主体和主流程没变，AI 只是锦上添花。

AI 原生产品却不同，AI 需要进入主流程本身，甚至成为主导流程的角色，例如：

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

这里的关键区别就非常明显了：

  1. AI 增强： AI 帮你把原有流程做得更快；
  2. AI 原生： AI 直接参与定义这个流程应该怎么走。

Image

二、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 适应得足够好的团队。

而关于 AI 原生团队 的回答，我认为由我空谈不太合适，以下是我与某位 CEO 关于 AI 原生团队的讨论：

Image

AI 原生团队，判断条件其实简单又苛刻：

它是一号位工程，因此最核心的评判标准是：公司实际做事的一号位，到底用不用 AI？
这里的核心在于：他对各种 AI 能力的边界是否清晰，有没有评价能力。

在一号位对 AI 边界有清醒认知的前提下，才会施行能用 AI，就不用人的大策略。这里的关键点是：至少这个团队的人在脑子层面要先 AI 起来。

Image

认知基础没有问题之后，就该上强度了，也就是：

如何组织团队的工作流程和协作方式，使之更适应 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

Image

如果说我们基于 Spec-Kit 的探索更多还站在研发链路里，去尝试如何让 AI 在规范约束下参与真实交付，那么 Code Banana 这类方案则更进一步，它已经不只是改研发流程，而是在尝试把整个团队的动作方式，按照 AI 的习惯重新编排。

Image

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 能力，正如下图所示：

Image

AI 在很多节点上确实起到了降本增效的作用，但它并没有改变事件或产品的核心流程和业务逻辑。

举个典型例子：团队里每个人都在用 AI（比如 Coding）来提效，有人效率提升 100%，有人甚至达到 500%，但整个团队加起来一看，整体效率仅仅提升了 20%。这正是在很多团队正在上演的真实情况：

AI 确实对每个个体帮助巨大，但整件事情的总体收益并不显著，甚至某些关键角色反而更累了……

AI 不是一次普普通通的功能升级，而是一次生产力变革。生产力一旦变了，生产关系、产品形态、组织方式势必早晚跟着改变。
就像移动互联网时代，如果还想沿用 PC 时代那套思路，简单把网站压缩成手机版，那大概率是要吃亏的；也像更早的云原生一样，真正的变化从来不是把服务器搬上云就结束了，而是承认云已经成为新的基础设施，于是运维体系、组织分工、岗位能力、交付方式都得一起改。

Image

AI 原生也是如此，它要求我们重新去思考几个根本问题：

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

对企业、对团队、对个人而言，都需要认真想清楚一个问题：

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

这，很可能才是 AI 原生最核心的意义所在。