开场 — 这次分享从哪里来

自我介绍

各位好，非常荣幸今天能和大家做这个分享，也先感谢腾讯学堂的介绍和邀请。

我先简单自我介绍一下。我叫任川，之前在 Google 和 LinkedIn 工作了八年，一直是工程和技术背景。后来我和朋友一起共创了 Palona AI，在里面做 Head of Engineering，把系统和工程团队从 0 到 1 搭起来。

今年几个月前，我从 Palona AI 出来，开始做一家新公司 Clockless。现在也会给一些 AI startup 做 advisor，同时自己也在做一些更激进的 AI Native 实践。

所以今天讲的很多东西，可能听起来有点激进。但如果放到硅谷现在的 AI startup 里面看，其实已经不是特别罕见了。大家可以把它当成一组一线经验和实验样本，不是标准答案。

我也先说明一下，我不是从一个传统管理专家的角度来讲组织转型。我的管理经验其实相对有限，最多管过二十多个人的团队。在座很多朋友的管理经验，应该都比我丰富。

但这件事也有一个好处，就是我在做组织设计的时候，包袱会少一些，很多尝试会更激进一点。这也是为什么我今天会先从一个 AI-only 团队实验讲起。

为什么现在讲组织

今天我想聊的主题，是组织形态重构：从 Human Native 到 AI Native。这个题目听起来好像偏组织，但我自己其实一直是工程背景，所以一开始也是从技术和产品的角度去理解 AI。

去年我帮朋友录过一期 42章经的播客，聊 AI Native 公司应该怎么组织工作流、人才和团队。当时很多观点听起来还比较激进。坦率地说，我自己那时候也还没有完全意识到，组织形式会变得这么重要。

但这半年再看，我越来越觉得，AI 带来的变化不是单个工具的提效，而是会把公司内部的执行层、协作方式和责任边界都重新改一遍。

为什么这么说？因为在很多任务和场景里，AI 本身的能力已经不再是最主要的瓶颈了。甚至在不少问题上，AI 的能力已经超过了解决问题所需要的能力。

但 AI 落地还是会遇到很多问题。很多问题不是 AI 不够强，而是新的 AI 技术落到传统组织形态里以后，组织本身不适应，导致 AI 的能力发挥不出来。

所以今天我想重点讲的，不是某个具体模型，也不是某个工具，而是组织形态本身。接下来一段时间，组织形态很可能会成为 AI 能力释放的瓶颈。

今天的核心问题其实很简单：如果 AI 不再只是工具，而是组织里的主要执行层，公司应该怎么从 Human Native，重构成 AI Native？

今天怎么讲

这不是简单把每个人都接上 AI 工具，而是重新定义三个东西：工作流怎么运转，人还负责什么，以及组织如何分工。

今天我会分四部分来讲。先讲一个 AI-only 团队的背景；后面三部分还是沿用去年播客里的框架，从比较具体的工作流讲起，再讲 AI Native 时代需要什么样的人才，最后讲更 high level 的组织形式。

Human Native 组织默认人是执行节点；AI Native 组织默认 AI 是执行系统，人负责目标、边界、context 和判断。

背景 — 一支 AI-only 团队

先讲一下背景。我现在的一个核心实验，是一支 AI-only 团队。

Clockless Engine 如何运转

大家如果看这个组织架构图，会发现最上面只有一个人类，就是 Kelvin，也就是我。Elon 是我的 AI CEO。日常所有沟通和协作，我基本都只和 Elon 完成，也就是只跟这一个 agent 对话。

Elon 下面是各个干活的 worker agents：Jobs 负责产品和设计，Linus 负责工程和部署，Turing 负责验证，Bezos 负责客户反馈和客户成功。后来我还继续加了一些新的 agent，比如负责 go-to-market 的角色。

这些 agent 靠什么协作？靠中间的 Clockless Engine。Elon 会从我和它的日常 IM 对话里抽取意图，把意图翻译成结构化文档，包括目标、验证方式、核心 metrics，再写入 Clockless Engine。

其他 worker agents 会定期扫描系统，看看有没有当前需要自己处理的任务。比如 Jobs 做完产品方案以后，Linus 接着实现，Turing 再去验证。Bezos 每小时扫描一次客户对话和产品 log，如果发现问题，就自己提交一个新的 issue，后续再交给其他 worker agents 处理。

这里最关键的，不是我给这些 agent 起了名字，而是所有任务、日志、产物、review 和反馈，都写回同一个共享状态里。Agent 不需要互相聊天，也不需要我逐个安排；它们只需要看当前状态，领取任务，完成以后再把结果写回去。

换句话说，worker agent 是可以替换的，真正的公司级 memory 不是某个 agent 的私人记忆，而是这个共享的 task state。这也是我后来越来越确定的一点：Agent collaboration is not chat，Agent collaboration is shared state。

这套系统大概是今年二三月份开始做起来的。随着基础设施越来越成熟，现在已经越来越容易跑起来。它本质上就是一支 7×24 小时不断电的 AI-only 团队。

我讲这个例子，不是为了说所有公司都应该长这样，而是用它来帮助我们讨论：AI Native 时代的工作流、人才和组织，到底会变成什么样。

Part 1 — AI Native 工作流的三个标准

接下来讲第一部分：AI Native 的工作流应该是什么样。

在我看来，当下 AI Native 工作流最重要的发展方向，是从 AI 提效走向 AI 自循环。也就是说，不只是让每个人用 AI 更快地完成原来的工作，而是让 AI 系统可以自己拿信息、自己执行、自己验证、自己继续推进。

这里面我会用三个标准来判断一个工作流是不是足够 AI Native。

标准 1：100% AI-only

过去我们讲 AI Native 团队，通常会说“凡事先让 AI 做”，AI 做不了的地方再让人补上。这个方向没有问题。但今天我会把目标再往前推一步：直接以 100% AI-only 研发系统为目标来设计工作流。

第一，模型进步加基础设施进步，使 100% AI-only 系统变得可行。 一方面是模型能力继续进步，另一方面是底层 infra 明显成熟。尤其是 Claude Code 和 OpenClaw 这类系统，把 coding agent 的能力带到了更多 use case 里面。它不再只是程序员在 IDE 里用的一个工具。

OpenClaw 对我的启发是，它把一层窗户纸点破了：先别管 security、token usage、UX 这些工程化问题，直接把整台电脑交给 Agent，看它到底能不能跑起来。结果是很多事情真的能 work，而且门槛没有我们想象得那么高。

第二，90% 和 100% 的差距不是 10%，可能是 100 倍。 在达到 100% 之前，不管 AI 承担了 30% 还是 90%，我们本质上还在讲“提效”：旧流程仍然存在，只是每个环节更快一点。一旦以 100% AI-only 为目标，我们就会重新审视整个研发工作流：哪些环节是为人设计的？哪些环节在 AI-only 的情况下还需要？这时很多流程不是被加速，而是会被取消或重构。

可以用 code review 的例子来理解。在 Google，一次 code review 可能要一到两天；在 Palona AI，我们用 AI review 把它压到十分钟；现在在 Clockless，我直接取消了 code review 这个环节，让 AI 自己发现问题、自己修改、自己继续跑。

这个例子的重点不是 code review 这个动作本身，而是提醒我们：很多研发流程不是自然存在的，它们是为了人类协作、责任交接和风险控制设计出来的。一旦 AI 系统可以自己观察、修复、验证，这些流程就不一定还应该保留。

图：OpenClaw / AI tipping point / 100% AI-only 研发拐点（待替换）

标准 2：自我进化

标准二讲的是 AI 工作系统的自我进化。这里的“进化”，我觉得有两层意思。

第一，不设 SOP，设定好目标和验收标准，让系统自我进化。 去年我们讲“只要有 SOP，就没有 Claude Code 干不成的事”。但在今年的 Agent 系统里，我们要再往前走一步：不要直接给系统写死一个确定性的 SOP，而是把目标、要解决的问题、验收标准讲清楚，剩下让 Agent 自己朝着目标运行。

在运行过程中，系统要把经验和教训沉淀下来，变成长期知识、skill，甚至变成一个特殊的 CLI 或工具。这样 AI 工作系统不是每次从零开始，而是可以在工作中持续进化。过去这件事实现起来很难，但 OpenClaw 之后，基于这类系统做二次开发，或者使用现有 agent framework，已经变得更容易。未来还会出现新的框架，但它们要解决的问题是一致的：让 Agent 在工作过程中持续变强。

这里有一个很重要的观念：artifact 是副产品，系统改进才是主产品。一次任务最后当然会产出代码、文档、网页或者报告，但更重要的是这次协作有没有让系统下次更会做这类事。好的 AI 工作系统，每做一次任务，都应该把稳定的方法沉淀成 skill、policy、heuristic 或 evaluation criteria。

第二，不直接使用工具，而是把工具交给 Agent 操作。 不要让 Agent 靠自己做所有事情，而是要把合适的工具配给它。大家应该都听过一个说法：未来的软件是为 Agent build 的，不是为人 build 的。Claude Code 就是一个很好的例子。过去是人打开 Claude Code，给它 prompt，等它回来，再继续循环；在 AI-only 的工作系统里，应该是我们定义的 Agent 去使用 Claude Code 来 coding。

这和持续进化直接相关。因为这些工具本身也在不断 improve，所以你不需要把 Agent 设计成万能的。很多时候，你只需要给它配好合适的 tool；当 tool 进化时，整个 AI 工作系统的能力也会随之进化。

图：Clockless Engine / Agent 共享任务状态

标准 3：7×24 小时工作

第一，AI 长时间工作循环已成为现实。 我们要把系统设计成可以自己从环境中拿 signal，自己做决策，自己推进，不断朝着设定好的目标运行。最近 Claude Code、ChatGPT、Codex 都加入了类似 Go mode 的能力。你给一个 high-level 的目标，它就可以持续运行下去。这已经是在往更长程的 AI 工作循环前进了一大步。

但更重要的不是某一个 agent 能跑十几个小时，而是整个系统能不能长期运行。单个 session 会结束，worker agent 会换，模型也可能会换；但 task board、状态机、日志、artifact 和 review 记录不能断。持续运行的核心，不是 session，而是共享状态。

第二，人和 Agent 的沟通要被视为对系统的打断。 去年我们讲，人与人的沟通会是工作流里吞吐量最低、信息损失最大的环节，这个观点现在很多人已经接受了。下一步，在 AI Native 工作流里，人与 Agent 的沟通也应该被视为对系统的打断，而不是工作本身。每一次被动沟通，都必须对系统有明确提升，否则就应该尽量被系统自动吸收掉。

这也是为什么我越来越强调“人只面对一个主 Agent”。人不应该变成多个 Agent 之间的路由器，否则只是把 Slack 里的组织混乱复制到 Agent 世界里。更合理的方式是：人表达 intent，主 Agent 把 intent 翻译成任务，系统异步执行，只有真正需要判断的时候再把人叫回来。

从 Human Native 到 AI Native，工作流的核心变化是：人不再是默认执行节点，而是系统设计者。

Part 1 小结：现在就要开始做

所以 Part 1 讲的这三个标准，就是我判断 AI Native 工作流的标准。但也要说清楚：按照现在模型和工作流的能力，它肯定还不能解决所有研发问题。

如果把研发任务从简单到复杂排开，我自己的判断是，现在大概可以解决前 40% 相对容易的问题。从一个简单 landing page，到一个 CRM 系统，再到一个 monitoring 系统，这一段已经有机会用 AI-only 的方式跑起来。

但这件事一定要现在开始做。因为模型和 infra 的增长速度非常快。两个月前我做这套系统的时候，很多问题还需要自己补；但短短两个月，agent infra 和模型能力已经往前走了很大一步。

所以现在硅谷很多团队内部会把这件事当成 Q2 级别的重要目标：每个团队都要有一个 AI-only 工作系统跑起来。它做的任务可以很简单，结果也不一定马上复杂，但它必须是一个真正 AI Native、AI-only 的工作系统。

Part 2 — AI Native 人才的三种能力

讲完工作流以后，我们再讲人。

如果工作流里 AI 承担越来越多执行，人当然不会没有价值。但人的价值会发生变化，而且对人的要求会更高。

去年在 42章经的播客里，我讲过三个能力：Context provider、Fast learner、Hands-on builder。今年再看，这三条主线没有变，但每一条都要升级。原因也很简单：AI 的能力在快速提高，AI 能做的事情越多，人就越不能只停留在“会用 AI”的层面。

所以这一部分我会一条一条讲：先讲去年对这个能力的要求，再讲今年这个能力应该升级到什么状态。

能力 1：Context provider → System designer

我们先讲第一个能力。去年我把它叫做 Context provider，今年我会更倾向于把它叫做 System designer。

  • 第一，核心能力是持续解决限制 AI 效率的最大 bottleneck。 AI 还远没有到完美状态，所以一定会有一个地方卡住它的效率。最早 bottleneck 是 prompt，所以大家讲 prompt engineer；后来是 context，所以讲 context engineer；现在更多是 harness。名字会变，但人的价值是持续找到并解决这个 bottleneck。按照我现在的体感，模型能力对很多 Agent 任务已经有六七十分，但 harness 可能只有二十分，记忆、权限、状态、工具路由和验证都还很早。
  • 第二，Context provider 是把真实世界持续接进 AI 工作流。 它不是写更漂亮的 prompt，而是把客户现场、行业惯例、团队判断、产品品味、历史决策这些 context 接进来。以前很多 AI 工作流不 work，不一定是模型不够聪明，而是 context 的信噪比不够。
  • 第三，System designer 是为 Agent 设计稳定工作的环境。 它不是给 Agent 写一套死流程，而是设计工具、状态、权限、日志、反馈和验证机制，让 Agent 能在开放空间里尝试、比较、回滚和继续迭代。

能力 2：Fast learner → Targeted learner

第二个能力，去年叫 Fast learner。今年我觉得更准确的说法是 Targeted learner。

  • 第一，核心能力是判断 AI 当前边界，并预判边界如何移动。 这个边界判断非常重要，因为它会直接影响你怎么设计产品、怎么设计系统、怎么设计组织。如果你低估 AI，会保留太多人类流程；如果你高估 AI，系统又会不稳定。
  • 第二，Fast learner 是快速掌握最小必要知识，激发 AI 对应能力。 它不是说人要学得比 AI 更强，这件事已经不可能了。它的意思是快速补齐必要知识，把问题定义清楚，然后引导 AI 解决具体问题。
  • 第三，Targeted learner 是围绕明确问题学习，而不是追逐所有新东西。 AI 发展太快，连“快速学习”本身都可能跟不上。现在不是每个新工具、新论文、新 demo 都要追。更重要的是先问清楚：我到底要解决什么问题？每多学一点，都应该让你离解决那个问题更近一步。

能力 3：Hands-on builder → Problem solver

第三个能力，去年叫 Hands-on builder。今年我会把它再往前推一步，叫 Problem solver。

  • 第一，核心能力是端到端负责最终结果。 AI 擅长中间执行过程，但它最欠缺的是为最终结果负责的能力。人要在 AI 的帮助下，从问题定义、方案选择、执行调度到结果验收一路负责到底。
  • 第二，Hands-on builder 是不只交中间产物，而是 build 出最终产品。 过去很多岗位是按流程分工的，所以大家交付的是 PRD、设计稿、技术方案、研究报告这些中间产物。但 AI 不按传统流程工作，它更适合围绕最终目标自己探索过程。
  • 第三，Problem solver 是不只 build 产品，而是真正解决用户问题。 能 build 出产品还不够，真正重要的是这个产品是不是真的解决了客户或用户的问题。未来最有价值的人，不是只会把东西做出来的人，而是能判断“这个东西到底有没有解决问题”的人。这也是为什么很多非传统科技背景的人，反而可能做出很好的 AI 产品：他们未必最懂技术，但他们最懂具体业务和真实问题。

AI Native 时代，人的核心能力不是亲自执行，而是定义问题、提供 context、判断结果，并持续训练系统。

Part 2 小结：High agency 比岗位名称更重要

所以这三种能力其实是一套闭环：System designer 解决 AI 效率瓶颈，Targeted learner 判断 AI 能力边界，Problem solver 对最终结果负责。

现在大家评价人才时，经常会提到一个词，叫 high agency。我觉得在 AI Native 时代，这个词会变得更重要。千万不要被自己的岗位和岗位名称限制住。PM、工程师、设计师、运营这些边界都会变得越来越松，甚至在很多场景里没有那么重要。

更重要的是，对照这三种能力看自己：我能不能找到 AI 系统当前最大的 bottleneck？我能不能判断 AI 能力边界，并围绕目标学习？我能不能对最终问题负责，而不是只交付一个中间产物？这才是 AI Native 时代人才真正应该发展的方向。

Part 3 — AI Native 组织的三个原则

前面我们先讲了比较具体的工作流，然后讲了人。最后我们进入一个更宏观的话题：组织。

组织这个词听起来很虚，但它非常重要。去年讲这件事的时候，我自己的感受还没有这么强，因为 AI 还在快速发展。但到了今年，我觉得可以比较自信地说：在很多场景里，AI 目前的能力已经不再是 AI 落地的主要瓶颈了。

现在 AI 在组织里落地，最大的矛盾不是 AI 不够强，而是现有组织形式没有办法让 AI 的能力充分发挥出来。单个人用了 AI 以后效率提高十倍，不等于公司效率提高十倍。如果下一个环节仍然要等人 review、等人排期、等人开会对齐，组织效率不会真正提升。

所以回到今天的标题，从 Human Native 到 AI Native。AI Native 组织的目的，就是最大化发挥 AI 的能力。那要往 AI Native 转型，首先要看清楚我们今天的组织是什么。

OPC 不是重点，做事方式才是重点

国内最近会把这类公司叫做 OPC，也就是一人公司。这个概念我觉得很好，但这个词未必特别准确。因为 AI Native 团队真正重要的不是人数，它不一定是一个人，也可以是几个人，甚至是更大的组织。

比如 Anthropic 在很多意义上就是一个相当 AI Native 的团队，但它已经是几千人的公司。所以人数本身不是重点，真正重要的是做事方式。

从 Human Native 到 AI Native

那什么叫 native？我自己的理解很简单，就是看一个组织的核心生产力以什么为中心。Human Native 组织的核心生产力是人，所以组织架构、激励机制、协作方式、奖惩体系，都是围绕人来设计的。今天绝大多数互联网公司都是这样：人是最重要的资产，也是默认的执行节点。

从 Human Native 到 AI Native，本质上是把核心生产力从人转移到 AI。不是说人不重要，而是人从默认执行层上移到目标、context、评估、调度和系统设计。

原则 1：AI 是生产系统本身

第一个原则，是先重新定义 AI 在组织里的位置。我前两天写过一篇小文章，里面用了一个比喻：AI 不是工具，更不是同事，AI 更像一座水电站。

当然，水电站只是比喻。更准确地说，AI 是一整套新的认知生产系统。

  • 第一，AI 不是工具，它会自己规划和执行。 如果你还觉得 AI 是工具，建议一定去试一下 Claude Code 或 Codex。你给它一个目标，它自己读上下文、规划步骤、调用工具、运行测试、观察报错、继续修复，甚至跑十几个小时把事情做成。这个体验已经不是“我在使用一个工具”，而是一个系统在自己工作。
  • 第二，AI 不是同事，它的生产力和人不在一个数量级。 把 AI 当同事是现在很流行的说法，因为它能对话、能接任务、能进 Slack、Linear、GitHub，甚至有些公司会给 AI 做一套类似员工入职的流程。但同事关系的前提，是大家的生产力大致在一个数量级上。AI 的生产力未来可能是人的十倍、一百倍、一千倍，这时候它就不再适合被理解成同事。很多人现在已经感觉到了：和多个 AI 一起工作，生产力提高了，但人反而更累。
  • 第三，AI 是生产系统本身，人负责控制、调度和监控。 拿三峡大坝举例，大坝每年发出大量电，也有很多工作人员，但没有任何一度电是员工靠体力发出来的，电是大坝这个生产系统产生的。人的价值不是亲自发电，而是设计、调度、维护这个系统。AI 也是一样，未来智能生产会越来越多交给 AI，人要学会控制、调度、监控和设计 AI 系统，让它按照人的目标工作。

原则 2：人要接触问题现场

第二个原则，是人要直接接触问题现场。第一个原则讲的是 AI 在组织里做什么；第二个原则讲的是人应该站在哪里。

如果 AI 已经越来越像完整的生产系统本身，那人的位置就会越来越靠近组织的边缘：去接触生产线，接触客户，接触问题真正发生的现场。

  • 第一，FDE 是把人直接派到企业客户的真实场景中。 OpenAI 已经有 Forward Deployed Engineering 和 Deployment Company，Anthropic 也在招 Forward Deployed Engineer。这个岗位最早是 Palantir 带火的，意思就是把工程师部署到客户和问题现场。过去互联网公司不太喜欢这个模式，因为成本高；但 AI 时代最后一公里太重要，这个角色又变得非常关键。
  • 第二，Popup 是把用户、社区和问题一起带到公司现场。 硅谷最近很多团队会在咖啡馆、酒吧、活动现场临时出现，产品和工程负责人直接见用户，现场听反馈、现场改。Corgi Insurance 做得更极致，直接开了 Corgi Cafe，一个 24/7 的咖啡馆，让创始人、客户和 AI startup 社区自然聚在一起。它表面上是咖啡馆，本质上也是一种问题现场。

这背后的原因，是 AI 能力和 AI adoption 之间的 gap 正在变大。以前 SaaS 公司给客户一个软件，优化一下 onboarding，客户自己用就可以。但现在只提供软件往往不够，因为客户自己也要变成 AI Native，客户的组织也要一起改。

这个 gap 越大，越需要有人站到现场，把 AI 系统、客户流程和真实问题接起来。一手 context 会越来越值钱，也会直接决定 AI 系统能不能做对。

原则 3：人按结果分工和负责

第三个原则，是人要按结果分工，并且为结果负责。因为如果 AI 已经承担大量执行，很多过去围绕人设计的流程，其实会被 AI 系统内化掉。

  • 第一，组织内按结果分工，不按流程分工。 过去流程里每一步都需要一个人，所以我们会有 PM、设计、前端、后端、测试、运营这些细分角色。但在 AI Native 组织里，流程本身很大程度上会被 AI 系统吸收。人不应该只负责流程中的一段，而应该对一个最终结果负责。
  • 第二，雇佣制会弱化，合伙人和合同工会出现。 雇佣制本质上是双方互相购买确定性：公司买员工固定时间和稳定产出，员工买稳定薪水，但员工通常不直接承担公司的盈亏结果。AI 承担大量执行以后，真正高价值的人要么成为公司合伙人，把权责和公司结果绑定；要么把稀缺判断、context 和专业能力卖给多个公司，成为高价值合同工。
  • 第三，会出现大量小公司，但外部协作会变多。 公司变小不代表协作变少，而是协作从组织内部转向组织外部。我们已经能看到一种趋势：一些非常资深的人加入前沿 AI 公司，title 可能看起来只是 engineer，但他们不是传统雇佣制里的普通工程师。他们有极大的自由度，拿到最强模型和最聪明的同事，具体做什么自己决定，最终结果也和自己强绑定，本质上更像小型合伙人。

模型和工具会扩散，但把人、Agent、客户 context 和外部网络组织成一个系统的能力，不会自动扩散。

Part 3 小结：组织要从流程中心，转向结果中心

所以组织这一部分，其实是在回答三个问题：AI 在组织里是什么，人应该站在哪里，组织应该怎么分工。

我的判断是，AI 会越来越像生产系统本身；人要站到问题现场，拿到一手 context；组织内部和外部，都要从按流程协作转向按结果负责。

这和传统公司的差别非常大。传统组织是围绕人类执行能力设计的，所以需要流程、交接、审批和管理层级。AI Native 组织则要围绕 AI 的执行能力重新设计，让系统默认推进，让人只在目标、边界、现场 context 和关键判断上介入。

最后：AI Native 不是工具升级，而是组织重构

最后简单总结一下。

Human Native 到 AI Native 的变化，不是“每个人都用 AI 工具”这么简单，而是公司默认的生产力中心变了。

在工作流上，目标不是让人用 AI 提效，而是让 AI 系统形成自循环：自己拿 signal，自己执行，自己验证，自己沉淀经验。

在人才上，岗位名称会越来越不重要。真正重要的是三种能力：能解决 AI 系统 bottleneck 的 System designer，能围绕目标判断 AI 边界的 Targeted learner，以及能端到端解决问题的 Problem solver。

在组织上，最重要的是重新定义人和 AI 的关系。AI 不是一个更聪明的工具，也不是一个普通同事，而是新的认知生产系统。人要更靠近问题现场，并且围绕最终结果来分工和负责。

这也是为什么我越来越相信，组织能力会成为 AI 公司真正的壁垒。模型会扩散，工具会扩散，单点技巧也会扩散；但把模型、Agent、工作流、人才、客户 context 和外部网络组织成一个持续运转的系统，这件事不会自动发生。

所以 AI Native 转型不是等模型再强一点再开始。恰恰相反，越早开始重构工作流、训练人才、调整组织边界，等模型继续变强的时候，组织越能接住这部分能力。

AI Native 组织的核心，不是拥有更多 AI，而是更早学会围绕 AI 重新设计公司。