Agent 越用越多，企业为何仍不够 AI Native ？
InfoQ 中文 · 软件开发
原创 籍云 2026-11-06 14:00 北京 工具解决局部，瓶颈落在价值 作者 ｜ 籍云 AI 生码率飙升，端到端交付却没有变快；通用 Agent 提效办公生产力，整体业务效能却未同步提升。当企业把 AI 工具推向业务流程，“局部更快、整体不快”的现象值得审视。阿里云智能集团副总裁、CIO 蒋林泉复盘了三年 AI 实践，从问题中找到了答案，也对 AI Native 有了清晰的认识。 1 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 的联动也由此成为关键。工具定义能力边界，组织决定这些能力能否进入真实工作、形成有效协作，并最终创造业务价值。 当下，他的回答方式，是复盘自己团队三年来真实走过的路。 2 产研组织重塑：从「生码率」到「交付效率」 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"。但风险最终总要有人扛，真正有效信息的上限，也只有骨干才能顶上去。 蒋林泉把它归结为两类风险： 价值风险： 加速上线低价值的应用和功能，消耗组织和客户稀缺的注意力； 质量风险： 加速产出低质量代码，增加系统复杂度和返工风险，影响稳定