阿里云蒋林泉谈企业AI Native落地难题

AI Native 已是企业讨论 AI 变革使用的热词。

围绕 AI Native 的，还有一长串概念——AI 生码率、Token Maxxing、编程智能体、通用智能体、一人公司、10 倍效率、全自动编程、数字员工、Agentic Workflow。

一个词用多了，似乎就容易“腐败”：含义被稀释，都在说，却谁也说不清。这是蒋林泉对概念泛化的提醒。

他的追问是：Token 用得越多，就越 AI Native 吗？用上了 Vibe Coding，就算 AI Native 的产研组织吗？用上了通用智能体，就是 AI Native 的业务团队吗？

这些指向同一个问题：工具的使用量，并不能直接证明组织形态发生了变化。AI Native 其实是组织层面的问题——什么样的组织，才算得上 AI Native ？

他把对 AI Native 的定义与过去三年的实践放在一起讨论：从 CIO 线自身的产研组织变革，到支撑业务团队，再到把内部能力变成对外交付的产品。

过程中，AI Native 必须同时发生在系统与组织两侧，CIO 与 CPO 的联动也由此成为关键。工具定义能力边界，组织决定这些能力能否进入真实工作、形成有效协作，并最终创造业务价值。

当下，他的回答方式，是复盘自己团队三年来真实走过的路。

AI 生码率飙升，换不来 E2E 交付效能

从 2024 年底，蒋林泉的团队已经全员用上 AI 编码工具，那时生码率就很快上到 30% 多。

但是，当时有个现象让他警觉：端到端交付一个需求所消耗的人力，没有变化。后来与业界很多产研团队交流，大家都发现了同样的问题——AI 生码率和代码量持续增长，真实业务项目的 E2E 耗时几乎没有缩短。

团队把一个需求从提出到上线的全过程拆开来看：需求设计、评审和修改约占 20%；交互视觉设计、评审和修改约 10%；技术方案设计和评审约 15%；编码开发约 20%；前后端联调和集成约 15%；测试和 Bugfix 约 20%。

真正写代码的时间，只占 20% 左右。

再把这 20% 拆开，其结构更说明问题。那些要在存量核心系统里修改、要和老系统融合、要保证上线后稳定安全运行的核心代码和关键非功能性代码，代码量不大，却吃掉了 65% 以上的编码时间——而这恰恰是 AI 帮助最有限的部分。反过来，增删改查、前端 UI、测试代码、胶水代码这类常规代码，占据了大部分代码量，却只消耗了不到 35% 的编码时间。

蒋林泉算了一笔账：20% 乘以 35%，约等于 7%。也就是说，即便 AI 把这部分代码的耗时压缩到零、其他环节都不变，端到端能节省的时间上限也只有 7% 左右——这还只是理论的上限。 业界交流中，有团队说端到端提效 3%，有的说 5%，做得不错的大约在 5% 左右，与这个推算大致吻合。

结论很清楚：AI 最容易生成的代码，原本就没花多少时间；真正花时间的地方，AI 帮的没那么多。

用了 AI，整体效率可能「不升反降」

如果只是提效不明显，问题还不算严重。蒋林泉观察到的另一个现象更值得警惕——有些团队的效率在下降。

很多 CIO 和产研负责人向他描述过同一种状况：用了 AI 之后，骨干反而成了更大的瓶颈，"像被 DDoS 了一样"。

可以理解为，一个同学用 AI 很快写出一大堆代码，要上线，就得有人 Review、有人为线上结果负责，而真正能负责的往往只是少数几位"老司机"。这些人被“打爆”，自己的事情干不了，全链路就卡在他们那里。可如果绕过 Review 直接上线，这些代码大概率会变成技术负债。

他把这一轮 生成式 AI 的悖论，概括为一句话：唯一可以确定的是，每个人都可以驾驶 AI，快速、规模化地生产无价值的“负债”。而且这些结果还很像模像样，导致比过去更难识别。

这种现象并不只存在于代码。开会时，一批人拿着 AI 生成的材料，另一批人用 AI 去总结、消化这些材料，彼此之间"用大模型 DDoS"。但风险最终总要有人扛，真正有效信息的上限，也只有骨干才能顶上去。

蒋林泉把它归结为两类风险：

• 价值风险：加速上线低价值的应用和功能，消耗组织和客户稀缺的注意力；

• 质量风险：加速产出低质量代码，增加系统复杂度和返工风险，影响稳定性，抬高长期维护成本。

背后的原理在于：一个组织里，注意力是稀缺的，真正能把控有效性、有品味的人是稀缺的。产出越多，这些稀缺的人就越被逼到极限。如果组织本身不做改变，测试、Review、线上检验这些本来就是瓶颈的环节，只会变得更堵。

回到《人月神话》：AI 改变了哪些协作前提

蒋林泉做了二十多年软件工程，也有 IBM 从业经历。他重新回到 Brooks 基于 IBM System/360 和 OS/360 项目经验写下的《人月神话》：在已经延期的项目中继续加人，往往只会增加沟通和磨合成本，让项目更慢。

在他看来，AI 提供了改变协作前提的机会，体现在两个维度：

第一，提升单节点的效率，而不增加人际协作链路。

在项目里加入 Agent，能够增强原有节点的执行能力，并沿用人的任务上下文，不必再通过带新人来增加节点。在任务与上下文清晰的条件下，这为局部提效创造了机会；但正如前面的数据所示，E2E 收益仍受其他环节的瓶颈限制。

第二，也是更有意思的：降低跨技能门槛，减少协作节点。

AI 让一个人跨岗位获取新技能的门槛，似乎下降到原来的十分之一甚至百分之一。移动互联网时代形成的前端、后端、设计、测试的精细分工，是那个时代的生产力决定的——专业供给稀缺，一个人的带宽处理不了那么多技术复杂度，只能以岗位为中心组织、把专业能力池化。今天，无论是做设计、写前端，还是上手一门新技术、新语言，门槛都在剧烈下降。

这意味着，原来必须凑齐多种技能的人才能完成的事，现在有机会由一个人带着 Agent 跨技能完成，从而减少那些"因为技能必须分岗位而被迫产生"的交接与等待。协作节点减少，沟通链路就会呈几何级下降，上下文密度也更高。

从"提升一个人的效率"，到"减少人与人之间的交接"——这是蒋林泉团队在 2024 年底确认的方向。《人月神话》讲了几十年"加人会更延期"，而现在，组织有机会不加人，甚至把多岗位协同变成少岗位协同。

两个「左移」，能有效控制复杂度

《No Silver Bullet》曾提出，软件开发的困难很大程度上源于复杂性，其中包括 偶然复杂性 与 本质复杂性。偶然复杂性来自编程语言、技术框架和工程工具等实现环节，可以通过自动化测试、CI/CD 等工程体系持续降低；本质复杂性则根植于业务问题本身，难以仅靠工具化解。

沿着这一思路，蒋林泉从两个层面的复杂度，推进变革。

第一：测试和观测左移，减少偶然复杂性。

核心的复杂代码，AI 未必擅长；但写测试、做日志和 Tracing，恰是它的强项。就分析覆盖度、补全缺失 Case 这类具体任务而言，效率可提升十倍甚至百倍。过去一轮轮“提升测试覆盖度”的运动，最后都不了了之，不是研发懒惰，是反馈链路太长：写的测试拦住了 Bug，往往是别人跑出来的，写的人拿不到反馈。于是测试扔给测试团队，Tracing 扔给运维，可处在右侧兜底的测试，并不是最懂业务的人。

有了 AI，这笔账变了。

研发自己做测试和观测，成本很低，最懂业务的人带着最精准的上下文去做，又准又快。2024 年底，蒋林泉把测试团队整体拆进各研发团队，运维职责也并入研发，上线出了问题由研发自己扛。验证更早、成本更低、返工更少。

第二：用 Live Demo 确认需求，应对本质复杂性。

本质复杂性有两个来源，一是业务原生的复杂度，二是对这种复杂度的误解导致的复杂度——需求准不准、有没有价值。

Vibe Coding 做出来的东西常被批评“Demo 可以，一上线就废”，但拿到最左侧去确认需求，远比 PRD 有效。人天然不喜欢读文档，PRD 这类 Paper Work 很难传递完备、准确的信息，才经常有上线后业务方说“这不是我要的”。《人月神话》里讲，软件有一个根本的困难：它是不可见的、不具象的，直到写出来才能被感知。Live Demo 让各方在最左侧就进入真实体验，基于可操作原型得到的反馈，精准度远高于文档。

由此，团队立下两条规矩：所有需求评审都用 Live Demo 进行；所有测试和可观测都由研发在左侧完成。“左移”减少的是需求误解和验证滞后造成的返工，并非消除所有返工；业务取舍和概念治理，仍需要人来承担。

岗位不是设计出来的，是“长”出来的：PDFE 与 ABE

两个左移推行之后，组织结构开始自发变化。测试和运维职责由蒋林泉直接推动并入研发；设计、前端和产品的融合，则是在实践中先做起来的。

AI 写设计和前端代码的能力越来越强。到 Codex、Qoder 这一代工具出现，一份 Design MD 就能完成功能设计，团队的功能设计环节已不再保留独立的设计岗位。前端早先就被要求接体验工单，转型为“体验与前端团队”。于是有产品经理疑惑：“怎么前端也在拿着 Demo 跑客户、与客户确认需求，设计也在这么干，这合适吗？”但在蒋林泉看来，三个岗位本质上都在理解客户需求，技能相互渗透，组织便慢慢融合。

最终，产品、设计与前端工程师三个岗位逐步融合为 PDFE，面向客户对清需求并交付 Live Demo。

Demo 要落地，仍必须连接和改造存量系统。

这里有个问题：产品与研发之间总有分歧，这往往来自对系统约束和历史逻辑的掌握不同。团队因此把隐性约束显性化：后端将 API 和数据结构梳理成 Repo，PDFE 用匹配的 Mock API 和 Mock Data 制作 Demo；客户演示前先与 Mock API“握手”，迭代中对齐约束，落地前再做真实联调，由此形成一个契约。

复杂系统，需要统一的「概念字典」

岗位收敛之后，蒋林泉没有把它当作终点。回到《No Silver Bullet》：没有任何一种单一技术能让软件工程效率提升十倍，尤其是对存量的复杂系统，因为本质复杂性无法避免。

业务规则、数据结构、各国法规、各式各样的 Corner Case，是软件存在就必须处理的复杂度。Demo 和编码的成本越下降，业务落地存量系统中的语义冲突反而越快暴露。

同一个原生复杂的东西，在不同组织、不同组件中，很容易被建模成不同的概念。

对此，他举了一个几乎所有企业都有的例子——"客户"。在销售系统里，客户是联系人；在财务系统里，客户是付款主体；在服务系统里，客户是使用者；在数据仓库里，客户是一个统计口径。系统割裂，概念不一，各自为真。老系统的复杂性大多来自这种腐化：概念不同、接口不同、分支定制不同，每个需求进来都要牵动多个组件、多个岗位，大家说的却不是同一种语言。

蒋林泉的判断是，业务本来已经足够复杂，却没有用一套自上向下的语言和结构去描述，也没有在跨团队之间建立一套结构化、确定性的“字典”——这是绝大部分效率折损的根源。

《人月神话》给出类似“外科手术团队”的办法：对于涉及大结构和核心概念的修改，需要由“主刀医生”式的核心架构师负责，其他角色协助。放到大型软件里，关键不是让所有人共同定义，是由能统筹全局的人建立统一边界，避免协作越多、概念分叉越多。

蒋林泉认为，如果没有一套自上而下的共同语言，跨团队协作只会放大分歧。架构治理的核心因此是 “概念完整性”：定义领域边界、统一业务语义、裁决跨域取舍。

这些共同概念，还要通过 API 契约和数据结构表达出来。用他的话说，先做到“书同文、车同轨”，才谈得上让人和 AI 依据同一套“概念字典”工作。

从 概念字典 到 SDD：让 Spec 支撑跨组件协作

有了统一的概念字典，才谈得上 Spec-Driven Development（SDD，规范驱动开发）。

蒋林泉团队从 2024 年底就在做这件事，当时称为 Blueprint，还专门做了 Blueprint Studio，要求写码、生码之前先用 Blueprint 对焦，确保概念完备、一致。后来 AI 能力增强，自造的轮子不再需要，用 Qoder、Codex 加几份 MD 就够了，但核心没变：跨 Repo、跨组件，概念必须一致。

很多人以为“AI 来了，写个 Spec 就行”。可如果每个组件、每个岗位各写各的 Spec，概念彼此不通，Spec 在组件内部有效，一跨组件就失效——而跨组件联调恰恰是最大的开销。 定义如果不能贯穿整个业务，Spec 最终仍会退化成各组件各自开发、再靠人联调的老路。这一部分 AI 解决不了：看到同一概念有两种说法，它会乱猜；两个都不完备时，它还可能编出第三个。

《人月神话》提倡由顶层架构师理清概念，现实中却很难做到：微服务和分布式开发不断派生出不同的东西，架构师不可能审阅每一行代码、每一次变更，结果，同一个概念在局部演化中分叉成不同的定义。

AI 带来了过去没有的治理机会。

以前还原大型软件中的概念与冲突，只能靠人读代码，成本极高；现在可以用 AI 从代码仓库、数据模型、对客文档、界面交互这些“产品事实”中逆向抽取概念，形成经人工确认、持续维护、可校验的共享 Spec，再正向用于产品设计、API 设计、研发测试和文档生成，并与实现同步校验。治理之后，还能通过跨 Repo、跨组件统一的 MD 做概念守护，探测新的分叉并设置门禁。

当然，AI 能帮架构师看清全局的概念复杂度，能提升效率，但不解决根本复杂度。 概念完整性涉及跨域治理和关键取舍，仍只能由具备关键能力和影响力的人类架构师主导。只要想跨岗位、跨组件联合生码，这件事就必须解决。

吞吐提升之后，瓶颈转向了价值本身

按蒋林泉对 CIO 线 AI 实践的回顾，从 2024 年 12 月到 2026 年 3 月，团队有效代码吞吐和端到端交付效率，大致达到原来的 2 到 3 倍。他的另一种表述是：同样一个需求，需要的“人月”降到原来的 二分之一到三分之一。

吞吐上来之后，新的瓶颈随即出现： 需求准不准、质量如何、交付出的软件最终有没有端到端的价值。

2025 年下半年，他就注意到这个问题——需求上得太快，端到端都能交付、都能落地，但做下去可能会出现一堆 DAU 很低的功能，客户痛点不明确，提升的吞吐最终被浪费。

他的应对，是在 PDFE 一侧增加产品评审机制：需求准入时，先在一页纸的 MD 上，按 PR/FAQ 的方式评审需求价值。

PR/FAQ 源自亚马逊的 Working Backwards 机制。产品进入开发前，团队先用一篇面向目标客户的新闻稿，写清要解决谁的什么问题、提供什么价值；再通过 FAQ 厘清关键场景、能力边界和落地条件。在蒋林泉看来，如果目标客户和痛点足够明确，PR 能把产品价值讲清，FAQ 也能回答客户落地时的关键问题，产品才大概率能“闭环到客户的真实使用”。

上线前，用 PR/FAQ 定义客户价值： 目标客户是谁，真实问题是什么，预期结果是什么。找不到真正的目标客户和痛点、说不清如何验证的，就不上。那段时间，大的需求蒋林泉都亲自带着 PDFE 团队逐个 Review，反复追问一句："你这个最后的客户是谁？"

上线后，验证价值落地： 一看使用渗透率——目标客户中实际使用核心能力的比例，如果宣称为某个角色解决痛点，上线后的 DAU 就应该来自这些人，如果没人用，这份 PR/FAQ 就是失败的；二做价值回访——渗透足够好，再抽样访谈客户，确认问题是否真被解决。

只有这样，才能解决"吞吐提升了，价值却没有提升"的问题。他的落点是：一个知识型组织，最终要对外交付价值，而非交付一堆只是能跑起来的软件。

这一阶段，蒋林泉提出了一个判断：技能通胀，品味通缩。

随着 AI 降低开发门槛，把软件做出来的能力不再稀缺——这是技能通胀。历史上因技能稀缺而形成的组织结构受到巨大冲击，组织不再以技能为中心。与之相对，判断做什么有价值、做成什么样客户最喜欢、什么是好与坏，越来越稀缺——这是品味通缩。

价值将越来越集中在三件事上：识别真问题——谁的什么问题值得解决，这要求理解目标客户的真实处境、识别高价值需求；做出好取舍——先做什么、哪些不做，按客户价值确定优先级，控制低价值功能的膨胀；把体验做好——让客户顺畅地获得结果，打通完整的使用路径，把功能变成可感知的价值。

为此，他在团队文化上鼓励每个角色的 Leader"左移"：面向真实的客户和场景，面向业界同领域的先进实践。不懂真实客户、不懂业务，就不可能有价值判断，也不可能有反馈闭环让人“长出品味”。这也是他三年前就要求前端岗位接体验工单，也是为了让写代码的人亲眼看到，客户怎样使用他们写出来的东西。

这里说的品味，能不能像技能一样被训练出来？ 蒋林泉给了一个观点：AI 会迅速降低技能门槛，但不会自动生成对客户、价值和取舍的判断。品味的上限很难通过统一方法训练出来，个体差异仍然存在；组织更现实的目标，是在每个人现有的基础上，“提高下限”。

提高下限的关键，是让大家更靠近客户，获得更完整的信息，并看到自己采取行动后的真实反馈。能够快速 A/B 测试、及时看到转化结果的业务，更容易像强化学习那样积累判断；如果一个决策三年后才显现结果，反馈就很难准确归因，只能更依赖少数人的经验和直觉。他判断，瓶颈最终一定会落在这里。

所以，当执行越来越便宜，判断什么值得执行，越来越昂贵。 只有补上这一层，增长的吞吐才能真正转化为客户价值。

如果说产研变革回应的是 AI 编程能力的冲击，那第二段实践回应的，是 2026 年以"龙虾"为代表的通用智能体浪潮。

蒋林泉回忆，这一波来得太迅猛。一开始，处理文档、生成图片、生成报表、写周报、写 OKR，都变得非常简单。但定睛发现，整体业务效能并没有显著提升。这与产研侧的经历指向同一个问题：个人产出提速，并不能自动形成端到端的价值闭环。

原因在于，本地办公和业务系统是割裂的，个人产出没有接入业务作业的闭环。智能体要真正产生业务价值，必须进入业务闭环：读取业务系统里的数据，处理完再写回去，并与他人协同。

从生码到办公，规律相同：局部产出更快了，端到端却没有同步提效。

对蒋林泉而言，很大压力来自另一件事：员工开始让通用智能体通过 Browser Use、Computer Use，自己去操作业务系统。

于是，问题来了。这些系统原本是为人设计的。智能体打开浏览器、开着机器，以类似爬虫的方式抓页面、填表单，失败就重试，重试又带来更多请求。

他总结了四个现象：

• 成功率低：智能体依赖抓取页面拿数据、做操作很难，任务反复失败，业务侧也抱怨其成功率和准确率特别低；

• Token 消耗大：智能体在任务失败后不断推理和重试，大量 Token 被烧掉；

• DDoS 式负载：多个智能体并发操作、反复重试，产生的请求量远高于人工点击，导致多个业务系统被打爆；

• 安全风险：外围数据被抓取并落到本地后，数据流向难以追踪，日志留存、授权边界和操作审计也难以统一治理。

由此，CIO 线选择通过 Headless MCP，让业务系统面向通用智能体开放。这项准备从 2025 年底开始：业务同学既可以自己使用系统，也可以让自己的通用智能体通过 Harness 来调用业务系统。

先统一业务概念，再规模化开放 MCP

很多企业在讨论"把系统开放给 Agent"时，关注的是接口。蒋林泉的第一原则却回到了产研部分反复强调的 概念一致性：如果系统之间的概念不一致，开放出去让智能体编排，只会制造更大的混乱。

这里，还是用“客户”的例子。

销售、财务、服务、数仓各有各的定义，是"多个局部真相"。直接通过 MCP 开放，跨系统调用是方便了，但 Agent 的组合调用也放大了影响——表述流畅，口径却不一。后果有三重：错误规模化，一次错误被并行复制；信任被透支，高质量的形式掩盖了错误；反馈回路被污染，错误输出回写后又生成新的错数据。

他举了一个真实问题：公司内部曾反馈某个产品的商业化配置速度太慢，要两个月才能配好。但是，如果真的直接交给 Agent，可能永远也配不好，因为它会把混乱加剧。

正确的治理顺序，是从根上减少语义混乱，自下而上分四层： 主数据层，明确标识与关系；业务语义层，明确定义与口径；MCP 接口层，只暴露受治理的语义；Agent 层，依据语义去推理。前两层是治理基础，第三层是受控连接，第四层才是可信应用。

他的概括是：接口解决的是连接，治理解决的是业务语义。

完成左侧的归一和概念梳理之后，在前述原本需要两个月进行商业化配置的场景中，蒋林泉表示，做一个 Skill 大致半天到一天就能搞定。他据此判断，在这类事情上，60 倍提效也有可能。但这并不是组织整体的提效倍数，也不能脱离治理工作单独归因于 AI：有了提效目标，组织倒过来把基础治理做扎实，才是关键。

对于业务系统开放的原则，在上述概念治理之外，权限边界同样关键：员工直接操作系统界面，与员工委托智能体通过 MCP 访问系统，必须是同一套业务权限——可访问的数据范围一样，可执行的操作一样，必须履行的审批流程也一样。用他的话说，100% 能力开放，不等于突破员工自身的权限边界。

原因很现实：智能体比人可怕，它有能力把一个业务系统的数据全部“拖走”，这只是一瞬间的事。

所以，必须清楚调用者是谁、有没有授权、权限机制是否健全、能否审计。蒋林泉称之为 “开放平台的 4A”：账号（Account）、认证（Authentication）、授权（Authorization）、审计（Audit）。这意味着，智能体一定是被某个具体的人驾驭着访问系统的，它所做的事和犯的错，需要由这个员工来相应负责。

要做到这一点，老业务系统需要大量补课。团队做了大量改造，才让底座跨岗位、跨职能的权限和审计日志真正健全。

"不是有人说的直接把 MCP 开出来就可以了，现实世界里做不到。"在他看来，概念完备性和权限梳理都是脏活累活，需要花巨大的精力。

从阿里云组织视角，希望每个业务团队都 AI Native 化，每个人都用通用智能体办公，包括用它来使用业务系统。于是，IT 部门接到的需求铺天盖地，若一上来要求全部开放，是做不成的。

CIO 线的节奏分三步： 先覆盖 80% 的高频场景，让业务尽快用起来；对事业部的高优先级专项，深入支持关键场景，补齐领域能力缺口；持续迈向 100% 业务系统能力开放。蒋林泉当时提出，希望在该财年前实现 100% 开放。

2026 年 5 月，阿里云的业务系统，正式向所有业务同学的通用智能体开放。

蒋林泉展示了云业务系统 API 调用量的三条趋势线：从 2026 年 5 月开放到当年 9 月的约 4 个月内，通用智能体调用量增长了 1000 倍，并超过人类通过 GUI 交互与一方 Agent 调用量的总和。 一方 Agent，是 CIO 为业务建设并已落地的智能体，这些通用智能体调用依然属于业务同学的 Copilot。当然，这一增长衡量的是调用量，不能等同于业务效能也增长 1000 倍。

他的解读是：过去业务有需求，都要找 CIO 团队实现；现在，财务、风控、销售、运营这些不懂研发的同学，用自然语言就能编排 Agent 调用系统。积压已久的痛点和需求，在他们手上得到了集中释放。

他半开玩笑地套用了一句话：这是业务团队对美好生活的向往，与以往 CIO 落后的生产力之间的矛盾，在通用智能体这里得到了充分释放。

当需求释放，大量业务同学来找 CIO 线要 MCP："我想要一个智能体功能，给我开放某某 MCP。"但与业务一起排查下来，蒋林泉的结论是：之前欠了那么多债。

他认为通用智能体有一个被低估的价值——它调动了业务团队自己去思考能用 AI 做些什么。业务同学自己动手时，想到的痛点往往比较准，与真实痛点是"握手"的。但有意思的是，痛点的解法最终未必是通用智能体。进入真实作业链路后，智能体接入受阻，暴露出的是几类历史的课要补：

• 流程缺口：关键作业仍在线下流转，业务系统无法形成连续的执行链路。过去，许多线下流程长期依赖人工完成，业务团队也已经习惯这种工作方式，很少将其作为系统需求提交给 CIO 线。AI 出现之后，业务团队开始意识到，这些环节或许可以通过 AI 解决；但要把局部尝试转化为可以正式上线、持续运行的业务能力，仍然需要接入现有系统。于是，那些过去没有被提出的系统需求，开始集中显现。

• 数据缺口：业务所需的数据虽然已有一部分实现线上化，却分散在不同系统和环节中，标识与口径也不一致，难以建立完整关联。完成一项业务任务往往需要将多处数据拼接起来，但数据彼此分散、标识无法对应，最终仍然无法串联成一条完整的信息链路。

• 规则缺口：许多审查和判断仍然依赖个人经验，缺少明确、可复用的标准。这些做法长期存在于少数人的线下操作和经验判断中，既没有沉淀到线上系统，也没有转化为可以被持续调用和复用的组织规则，因此还未成为真正的公司资产。

此外，还有 跨域协同的缺口。这些缺口并不是 AI 带来的，但 AI 让业务团队清楚地看到了效率的堵点，并把需求带到了 CIO 面前。CIO 线的做法是分类补课：先补齐阻碍业务闭环的流程、数据与规则，再让智能体持续执行。

随着系统开放，蒋林泉的前置判断是：随着通用智能体的探索，未被满足的长尾需求会集中爆发——把历史上积压已久的需求“炸”出来。

通过分析日志——业务用通用智能体调用 API 的 Pattern、调用最多的需求——他发现，有不少原本应由 CIO 线建设的智能体没有做，或供给不足；而各个领域、各个小部门各自搭建通用智能体，本身是重复建设。于是，要做的事：一旦发现某个需求是跨大部门、甚至全公司的，就把这个 Pattern 抓出来 "一方化"，由 CIO 做成稳定的 Auto-Pilot，以更低的成本、更稳定、更持续地提供服务。

这就形成了一条循环路径：通用智能体负责探索，承接长尾的自动化需求；CIO 线的开发者运营负责识别高频调用，验证哪些是真实有效的需求；再由一方 Agent 产品化，回归工程建设，做成稳定复用的 Auto-Pilot。 剩余和新增的合理长尾，继续留在业务团队，由通用智能体承接；主体调用和公司级工作流，则在统一的上下文中稳定执行。

基于这条路径，他认为：通用智能体调用量的激增，很大程度上是压抑多年的痛点集中爆发；当高频痛点被收割一轮、“一方化”之后，这条曲线有可能回落。原因在于，真正维护一个智能体，要规模化服务、稳定运行、持续改进，仍然是复杂的软件工程，他不认为这应由业务团队承担。

开放之后，CIO 线与业务团队的分工发生了一场变化。

蒋林泉用了一个比喻：通用智能体相当于业务人员的新"坐骑"。过去是业务人员自己与系统交互，现在是业务人员委派智能体调用 MCP。业务目标和责任并没有消失，变化的是人与系统之间的执行方式。

过去，业务需求集中交给 CIO，排期、交接和执行带宽制约着一线创新。现在分成两块：简单的、垂直领域的需求——取个数、处理一件域内的事、大量非结构化的需求——由业务团队用通用智能体调用 MCP 自主开发，并对业务结果负责；同时，那些困难的、复杂的、跨域的需求——线下转线上、跨域协同、更深度的 Copilot——仍由 CIO 团队承担。

就此，CIO 团队同时新增了两项职能，构成共同底座：

一是 系统开放平台：守护业务系统底座的数据一致性、概念完整性和整体架构，把能力和权限开放出来，并维护开放平台的有效性与治理规则。

二是 “开发者”运营：新时代的开发者，是拿着自然语言、通过智能体编程的业务同学，但有效编排智能体需要大量 Know-how。CIO 线为每个业务团队配备一名开发者运营，收集堵点、支持接入、发现执行障碍、推动能力补齐，并在需要时做培训赋能，让业务团队成为新的、广义的开发团队；同时把一线接入中的问题带回平台和流程建设。其处理的堵点，也不只限于开放 MCP 的需求。

这里有个插曲。开放之初，CIO 线团队内部曾担心：业务都能自己开发了，自己还能做什么？这导致团队本能上是有些排斥心理的。但蒋林泉判断，业务团队还是很难独立做出复杂且能可靠运行的系统，他坚持推动开放。

果然，开放之后，像打开了潘多拉的魔盒，新的工作反而接连出现。系统开放并没有让 CIO 团队消失，反而是把它从集中承接所有需求，推向平台能力建设、复杂问题解决和开发者运营：更多精力放在概念完整性、架构守护、MCP 开发、身份权限审计和平台稳定性上。生产力流动起来，组织职能也会跟着流动。

从这段实践中可以看到，开放不只是增加接口，也是重新划分协作责任：合理的长尾需求由业务自主闭环，困难、复杂和跨域需求由 CIO 深入支持，开放平台与开发者运营提供共同底座。

第三段实践，源自业务落地和方法沉淀。

从 2023 年到 2025 年上半年，阿里云落地了 28 类数字员工，分布在网站、CRM 和业务支撑等领域：售前售后客服，网站 SEO 运营，电销的话前准备、话中辅助、话后总结与质检，合同的信控、法务、税务、财务风险审核，文档翻译，面试辅助等。按完成的真实任务反算，合计折合拓展出 2000 多个 HC，并在真实业务岗位上工作、汇报到业务团队。 这里的 HC 是任务能力的折算，并非被替代的人数。

蒋林泉对"数字员工"的定义非常严格，也曾在内部与公司 CPO 深度讨论过：数字员工必须执行与人类员工一样的真实任务，并且效果更好、效率更高，能根据完成的任务反算出增加了多少 HC。以电销为例，如果一个电销员工一天打 20 个电话，数字员工也要能打 20 个电话，而且转化率不低于人，这才能算一个 HC。这与市场上对"数字员工"的泛泛之谈截然不同。

28 类数字员工的落地投入大、难度高。在这个过程中，蒋林泉总结出一套在大型组织中落地有效智能体的基础方法：RIDE，即 Reorganize、Identify、Define、Execute。

R，Reorganize：调整组织和生产关系。 他把生产关系放在首位，如果不对其调整，新生产力就会处处遇到阻力。阿里云的数字员工在 HR 系统里汇报给业务，是归属业务部门的人；IT 部门的角色是“供应商”，为业务补充 HC，而非替代业务团队的人员。否则，从一开始就会四面受阻，这种阻力往往不在顶层，在执行层。

I，Identify：识别业务痛点与 AI 机会点。 合适的切入点是重复执行的、语言类的知识性任务，业务压力大，能清晰度量、拿到反馈。从 offload 重复工作开始，最终走向拓展 HC，借助 AI 能力外溢，去解决新的问题。没有真实执行过的任务，拿不到反馈，就无法闭环。"现实中没有的任务，想直接用 AI 去做，我并不建议——因为人类的创新和 0 到 1 的能力是最强的。"

D，Define：定义 AI 产品与运营指标。 智能体的产品与运营必须一体：业务价值是成本节省还是效率提升；产品需求包括准确率、响应时效、安全合规；运营指标包括 DAU 与调用数、渗透率、留存率。他的一贯观点是，做出来的东西如果没有应有的渗透率和 DAU，会是一种负债，智能体做的也不例外。

E，Execute：AI 产品工程落地。 以产品和业务目标牵引执行。工程上，中间层是应用与算法，最底座是数据与评测。他的经验是：做数字员工的产研团队，如果没有一半以上的人在做该领域任务的数据和评测，最终很难落下去。换句话说，没有目标，不可启动智能体；数据和评测投入不足，一切皆是空谈。

将内部实践沉淀为方法论的同时，蒋林泉也开始向外寻找参照。

最初，他想了解其他企业是怎么做的。毕竟媒体的 PR 稿里，企业似乎都能轻松做出很多智能体，他一度怀疑是不是自己做得不够好；但交流下来才发现，真正落到真实岗位上的并不多。原本的取经，似乎变成了分享。

从 2025 年 6 月到 2026 年 6 月，他与 CIO、CTO、CEO 们进行了百场深度交流，覆盖十大行业，有的企业交流了两三次，围绕的都是同一个话题。

2026 年初回访时，企业普遍反馈，落地案例和 RIDE 方法都很有启发，场景也合理，但如果没有阿里云这样规模和强度的研发投入，落地仍然很难。最后发现，少数企业已经落地，多数仍未突破。

蒋林泉认为，原因可能不只在研发投入和人才结构，还在于对 AI 的洞察，以及发挥 AI Native 生产力所需的大量经验。无论原因如何，企业的共同诉求很明确：有没有产品？

CIO 这个角色对外做产品，以常规思维来看，似乎有些“不务正业”。

对此，蒋林泉后来想通了两点。第一，业界有需要。企业照着方法做，大多难以落地；每次他只带着方法论去和企业交流，自己觉得还不够。第二，自己团队的吞吐量已经提升到原来的两三倍，产能富余，应该可以对外释放。

由此，他提出一个明确的观点：如果一个组织，有价值的事情已经饱和，再提效就失去意义；AI 提效最不能做的，就是为了减人而提效。如果好不容易建成一个生产力很高的组织，却因为战斗力提升而减员，这本身就是悖论。他想把释放出的产能投向新的价值，去做对外交付的产品。

从真实岗位到「睿系列」：一次真交付产品的突破

做的产品，就是睿系列。

睿系列并不是从一张产品规划图开始的，是从自阿里云端到端真实业务实践中沉淀来的。

其中的睿译宝（Real Translation Buddy），在 2026 年云栖大会主论坛及多个分论坛承担同传字幕输出；这一应用也说明，相关能力确实先在自身真实场景中验证过，再被产品化对外。

睿系列于 2026 年 6 月正式发布，定位为 RaaS（Result as a Service），强调“拟真人效果，交付真结果”。

拟真人效果是起点。 它对应是人机交互门槛：在电销、客服、同传等场景，用户是否愿意继续交流，往往取决于表达是否自然、响应是否符合岗位习惯。但自然并不等于可靠；越过交互门槛之后，还要继续回答，知识是否准确、流程是否合规、异常是否可处理。

交付真结果是标准。 它对应的是业务验证标准：也就是说，必须能完成复杂的长程任务、现实世界的任务，并取得效果。比如，评价电销数字员工，不看通话时长，而是直接与金牌员工比较转化率。

这些在严苛环境中规模化沉淀的技术，被打磨成对外产品，形成睿系列家族。截至目前，睿系列涵盖了翻译场景的睿译宝、外呼电销的睿呼宝、企业知识顾问睿知宝、面试官睿招宝，还有面向服务场景的睿服宝。

从这一路径看，产品化要解决的不是“能不能再生成一个智能体”，是企业客户能否获得稳定的业务结果。 睿系列以内部真实岗位上的任务、效果和规模实践为起点，对外回应企业“方法懂了，但还是难以落地”的需求。这里的价值，仍然要回到实际任务能否完成、结果是否可靠来检验。

从方法到产品，蒋林泉的团队替企业把最难落地的那一程做好。

回看阿里云 CIO 线这三年的实践，几条变革路径并行，又彼此交叠。2023 年 3 月，团队从数字员工开始，经过两年多的端到端规模化落地，28 类数字员工正式上岗，沉淀了 RIDE 方法。其间，2024 年 10 月，AI 编程能力的提升又将变革推向产研组织，团队以 Half-Stack 重组岗位与流程。到 2025 年末，通用智能体进一步推动业务系统开放，CIO 线通过 MCP 与 Headless 向智能体开放业务系统，持续运营平台能力，与业务形成更动态的分工。同时，睿系列产品于 2026 年初启动研发，并在 6 月首发，将内部积累的场景、方法与工程能力转化为对外交付业务结果的产品。

三年间，AI 进入业务、研发与系统，CIO 线也从内部变革走向外部产品化。

最后，回到 AI Native 组织本身，蒋林泉给出的回答是：能充分发挥 AI 生产力的组织，才可能成为 AI Native 组织。他特别强调了“可能”二字。

这个定义包含环环相扣的三个环节：

AI 生产力： 持续追踪、理解 AI 不断进化的能力边界，且善用 AI ；

组织变革： 持续识别制约 AI 生产力发挥的组织瓶颈，并通过变革加以突破。这些瓶颈往往来自既有的工作习惯、流程和岗位设置，就像是移动互联网十来年刻在脑子里的“思想钢印”；

企业内外部价值： 让 AI 生产力与组织充分结合，更高效地产出更大的业务价值。突破带来的效能，要以企业内外部价值的增加来度量；相反，如果开发了大量软件却无人使用，提效本身便失去了意义。

蒋林泉用 “价值流冲刷岗位和边界” 来解释这条链路：AI 能力进入真实任务并产生价值后，价值流会反过来重塑原有的岗位和边界；经过真实任务检验后保留下来的组织结构，才能更充分地发挥新的生产力，继续创造企业的内外部价值。

他将其归结为：生产力决定生产关系，生产关系也会反过来影响生产力的发挥；只有适应生产力发展的生产关系，才能生存下来。

如果拿蒋林泉自己对 AI Native 的定义来衡量，他不认为自己的团队已经是 AI Native 组织，但期望朝这个方向持续迈进。

在他看来，AI Native 更像一种“状态”—— AI 的能力每个月都在进化，组织也要不停地革自己的命。 三年里，团队搭过很多脚手架，但模型一升级就作废，再一升级又作废；他们继续往前，抛掉不再适应新生产力的东西。

CIO 线的使命，至此有了两个方向：向内， 持续变革自身，力求成为能充分发挥 AI 生产力的产研组织，助力阿里云业务组织的 AI Native 变革；向外， 将三年规模化实践中形成的经验、RIDE 方法和工程能力沉淀为睿系列 RaaS 产品，用经过规模验证的产品，帮助企业客户变革自身的业务与组织。

其中，不变的是持续创造更大的内部与外部价值；变化的是随着 AI 能力变化，调整实现价值的工作流和组织方式。

最终，我们会发现，企业走向 AI Native，并没有宏大的答案，只是要看 AI 能否持续创造业务价值，无论对内与对外。