这个系列从今年 6 月份开始写到现在，已经快两个月了。

这两个月不只是码字，更多是在思考。

第一篇文章的出发点很简单，就是在想 AI 应该如何分工。那时候我还没有正确答案，只是有一个很朴素的感觉：AI 之间的分工，和人类组织里的分工会非常不同。

所有的 AI 都是六边形战士，而人是有短板的。人类基于短板分工，AI 会基于注意力分工。这是最早的一个种子。

随后我沿着这个种子往下走，写了注意力坐标，写了一个任务进入 AI 团队后如何流转，也写了 AI 从 Demo 到规模化会遇到的组织问题和技术问题。

兜兜转转两个月下来，问题开始从“AI 之间怎么分工”，变成了“企业到底应该怎么做 AI Native 转型”。说到AI Native转型，我们最常能听到的建议是，做一两个速胜项目，给团队和管理层信心，后面的工作就好做了。

通过我最近协助一些企业做AI转型的经验来看，一个项目可以解决眼前问题，但CEO 还要知道，这个项目将来接到企业的哪个位置。

我现在的阶段判断是：AI Native 转型最终改变的是企业运行方式。CEO 脑子里要装着整个企业，手上先抓一条链。

一、小项目会先跑起来，也会很快散掉

企业做 AI，通常不会一上来就谈“运行方式重构”。最先发生的，往往是几个看得见的小项目。

研发团队装上 AI Coding 工具，有些工程师的局部动作会变快。产品团队给现有系统加一个 AI 问答入口。销售或售前做一个数字员工，帮忙查资料、回答常见问题、生成方案初稿。公司办一次 AI 应用大赛，员工做出很多小工具。

这些事情都有价值。我自己也是从很小的工具和很小的流程开始试的。

问题在于，它们常常停在散点上。

研发快了，需求、接口、测试、上线和验收没有同步变化，团队只是从“写得慢”变成“生成得快、集成得累”。销售前场有了数字员工，产品资料、研发文档、价格边界、风险责任没有打通，它能答的仍然很有限。产品里多了 AI 问答，客户服务、知识更新和异常处理还按原来的方式走，最后只是多了一个入口。

AI 应用大赛也一样。它可以发现人、发现场景、发现方法，但比赛作品如果不能进入正式业务链路，就很难沉淀成企业能力。

某个部门用了工具，某个人效率提升，某个 Demo 很惊艳，站在 CEO 视角都只能算信号。更重要的是，这些信号能不能连成一条工作链。

任务能不能从市场端进来，被生产端接住，再带着结果回到市场端验证。知识能不能跟着任务走。权限和责任能不能跟着动作走。结果能不能回到下一轮规则。

散落在各部门里的 AI 工具，不会自然长成一家 AI Native 企业。

二、第一层：方向与结果

我现在更愿意把企业 AI Native 转型看成一张运行地图。

这张地图不需要一开始画得很复杂。我把它压成四层：

• 第一层，方向与结果；
• 第二层，组织怎样工作；
• 第三层，市场与生产之间的价值链；
• 第四层，支撑任务流动的协同底座。

这四层不是四个并列的部门。前两层是企业做 AI 转型的前提，第三层是企业创造价值的主链，第四层在下面托住整条链。

先看第一层，方向与结果。也就是过去说的战略与思想。

这件事不能只停在“我们要拥抱 AI”。企业真正要问的是：先解决什么经营问题，允许 AI 进入到哪里，最后用什么结果判断它有没有价值。

需要做 AI Native 转型的 CEO，重点要放在方向、授权和资源上。他要把讨论从态度问题拉回经营问题：先解决什么，允许 AI 进入到哪里，最后用什么结果判断。风险当然要讨论，但风险要落成权限、范围、验收和责任，不能一直停在情绪上。

三、第二层：组织怎样工作

第二层，是组织怎样工作。也就是个人与组织实践。

关键岗位的人要亲自用 AI。目的很朴素：在真实工作里摸到 AI 的边界，知道它到底能做到哪一步，哪里会胡说，哪里需要人确认，哪里一旦接入业务系统就会放大风险。

一个管理者如果没有亲自把 AI 放进自己的工作里，很难判断下属提的 AI 项目到底是真需求，还是一个看起来很热闹的工具包装。

所以，个人实践会直接影响组织的验收能力。

到这一层，我们会问两个问题：方向有没有讲清楚，组织里有没有足够多的人能判断 AI 的能力和权限边界。

四、第三层：市场与生产之间的价值链

方向和组织能力只是前提。企业真正运行起来，靠的是一条价值链。

这条价值链一端靠近市场，一端靠近生产。

市场端负责看见客户问题。销售、售前、客服、客户成功、运营都在这里。它们接触需求、异议、投诉、询价、竞争信息和交付反馈。

生产端负责形成可交付结果。产品、研发、测试、交付、知识运营都在这里。它们把需求变成方案、功能、文档、测试用例、交付口径和可运行系统。

AI Native 转型的关键在于：同一个任务能不能在市场端和生产端之间流动。

一个客户问题进来，先被整理成有边界的任务。这个任务带着可靠知识进入生产端，产品判断需求，研发判断实现，测试判断风险，必要时把不确定内容退回前场确认。生产端形成结果以后，再回到市场端接受客户和业务结果的检验。

这件事听起来很普通，但它和单点 AI 工具有很大差别。

单点工具只改变一个人的动作。价值链改变的是任务的走法。

如果销售数字员工回答了客户问题，但答案没有进入产品资料更新；如果研发 AI Coding 提升了编码速度，但测试和交付没有接住新增变化；如果客服 AI 总结了客户投诉，但这些投诉没有回到产品和规则更新，这些 AI 应用就会留在局部。

局部有用，企业没有变。

CEO 看这张地图时，可以把问题换成：客户问题有没有进入生产端，生产结果有没有回到客户侧，反馈有没有更新下一轮知识和规则。

五、第四层：支撑任务流动的协同底座

价值链要跑起来，底下需要一层协同底座。

这里说的底座，可以先理解成一组必须随任务一起存在的条件。

任务是什么。知识从哪里来。AI 代表谁执行。它能看什么，能建议什么，能改什么。关键判断由谁确认。异常出现后谁接管。过程如何留下记录。结果如何回到下一轮。

第09期写的是组织侧问题。AI 的行动能力下放以后，企业原有的决策权、责任和利益没有同步重排。到了真实业务里，这会变成很具体的问题：谁授权，谁验收，谁放行，谁按停。

第10期写的是技术侧问题。多智能体从 Demo 进入生产后，协作能不能按时收敛，任务状态能不能保持一致，工具动作能不能受控，长期结果能不能持续验证。到了企业地图里，这会变成另一组问题：任务版本能不能对上，工具权限有没有边界，过程记录能不能串起来，最终结果能不能复盘。

所以协同底座同时关乎知识、权限、责任、版本、记录和成本。

没有这一层，AI项目越多，企业会因为AI变得更加混乱。每个部门都有工具，每条链路都有例外，每个结果都需要人重新解释，很多提效就会被协调成本抵消。

有了这层底座，局部项目才有机会变成组织资产。一次售前问答沉淀出的产品资料，可以被下一次销售使用；一次研发测试发现的风险，可以被下一次需求评审引用；一次客户反馈触发的规则更新，可以回到知识库和流程里。

任务、知识、权限、责任和结果开始在企业里流动，AI Native 才从工具使用走向组织能力。

六、规划要看全，启动要做小

这里要分清两个尺度。

规划时看全，启动时做小。

看全，是为了知道一个小项目将来接到哪里。它接市场端，还是接生产端；它需要哪些知识，碰到哪些权限，结果由谁验收，失败后谁接管。没有这张图，小项目可能变成孤岛。

做小，是因为企业资源有限，组织对 AI 的理解也不一致。所有部门同时开工，往往会做出很多 Demo，却没有一条链真正跑完。

第一条链不需要轰轰烈烈。它最好来自反复发生的真实业务痛点，范围和权限能够控制，需要两三个角色共同完成，结果可以验收，出错能够交给人，跑完以后能留下知识、规则或流程。

这里我只说到这个程度。更具体的第一条链怎么选、怎么判断有没有跑通，留给下篇。

这篇上篇只想把地图先画出来。

AI Native 转型可以先落成一件更朴素的事：脑子里装着整个企业，手上先抓一条链。

CEO 不需要知道每个 Agent 怎么调度，但要知道企业最终会被哪些东西重构：方向与结果、组织实践、市场端、生产端，以及支撑任务流动的协同底座。

最后真正要问的问题会落回一个项目上。

一个项目用了 AI，就已经算 AI Native 吗？

它有没有带着知识、权限、责任和结果跑成一条链？