代理越用越多，企业为何仍不够AI Native？

AI 生码率飙升，端到端交付却没有变快；通用 Agent 提效办公生产力，整体业务效能却未同步提升。当企业把 AI 工具推向业务流程，“局部更快、整体不快”的现象值得审视。阿里云智能集团副总裁、CIO 蒋林泉复盘了三年 AI 实践，从问题中找到了答案，也对 AI Native 有了清晰的认识。 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，恰是它的强项。就分析覆盖度、补全