CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘

研发效能，规模化已成 2026 财年对比 2025 财年，阿里云 CIO 线的产研效能呈现出一组清晰的跃升：前端人均有效代码量提升至 3 倍，后端提升至 2 倍；千行代码缺陷率，前端下降 30%，后端下降 55%。 数字背后，是在承接更多核心业务与 AI 创新、没有增加人力、最终落实到了业务价值 的多重前提下实现的。 在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。 2026 年，「AI 提效」已经成为产研圈最急迫的词汇。它几乎被贴在所有季度汇报的第一页，却很少出现在真实的业务结果里。在笔者看来，背后有个结构性问题：大多数企业对 AI 的使用，停留在工具替换层面，而非流程重构层面。工具替换能产生局部加速，却无法带来系统性效能跃升。更隐蔽的危险是：当 AI 让代码生产的边际成本趋近于零，它同时也在加速放大流程中每一个错误决策的代价。 阿里云 CIO 蒋林泉及其团队这一年的实践结果，凸显在 AI 变革中的热情与理性。早在 2025 年 8 月，一次关于企业大模型落地的 主题分享 "中，他就提出了一个判断：「技能通胀，品味通缩」。 八个字，浓缩了 AI 时代对组织和人才的价值迁移方向。 蒋林泉对「品味」有他独特的理解 —— 品味，是对业务价值的判断，对一件事情好与不好的最终验收；AI 只能做到 average，但有品味的人，能定义什么是「好」。 AI 时代，对「好」的判断力是稀缺的，相反，随着工具的普及，技能正在迅速失去稀缺性。Anthropic 的 Claude Code 的创建者 Boris Cherny 曾表示，软件工程师这一职位将在今年消失。企业正在从为传统的技能付费，转向为判断和结果付费。 肉眼可见，一年之后，蒋林泉的这一判断不再只是趋势预判，它在具体实践中逐渐被验证、被放大。围绕产研组织的能力结构与运作方式，其 CIO 团队完成了一轮系统性的重构。也因此，才有了这次他对 「AI 时代产研组织效能规模化提升实践」 主题的深度复盘 。 他把一年的成果与沉淀的方法称为“汇报”，成果的关键定焦在「规模化」， 毕竟个人的 AI 提效满天飞，组织效能的规模化提升，才是真难点。 两个流行误区，正在让大量团队越跑越偏 「AI 生码率」一路攀升，真实项目的 E2E 产研时间却没缩短 变革都需要数据的侧面支撑，选择对标什么数据，本身是一种战略判断。 在阿里云 CIO 的统计维度中，看到的是人均有效代码量和千行代码缺陷率，并没有看到一个行业极其流行的指标：AI 生码率。 从硅谷大厂到国内独角兽，大家普遍炫耀生码率从 20% 攀升到 50%。蒋林泉从一开始就将这个指标排除在考核体系之外，他的理由非常明确：AI 生码率是「过程指标」，组织一旦观测这种过程指标，AI 就特别容易产生毒害。 他的意思是，代码行数如果「不加权」是没有意义的，这让团队很容易陷入「灌水」的陷阱 —— AI 生码率看起来很高，但实际上对业务效能毫无帮助。相反，他坚持，代码最终要转化为真实的业务价值。 这也是最开始强调的产研效能数据提升的前提。 「AI 生码率」确实是个充满诱惑的陷阱。当我们重新审视这个指标时，发觉 AI 生码率的流行，折射的不是技术问题，是组织管理的认知困境：当一种新技术出现，最强烈的冲动是找一个可量化的指标来证明它有用。这种冲动本身无可厚非，但它产生了危险效应：用力「证明 AI 有用」，忽视了「业务效能提升」。 蒋林泉习惯用「业务价值 E2E 标准」，来看研发的实际效能，所以需要先正确度量项目 E2E 各环节耗时与代码复杂度加权耗时。 图 1: 正确度量 ：项目 E2E 各环节耗时 与 代码复杂度加权耗时 从图中不难发现，在完整的软件工程生命周期中，开发人员实际编写代码的时间仅占 20%，大量时间消耗在需求对焦、PRD 编写与评审、跨团队沟通对齐、上下游联调及返工等环节。 即使在 AI 编码那 20% 的部分里，代码与代码之间的价值密度差异极大。 自动生成单元测试、补充注释、编写胶水代码——这些本身耗时有限。真正消耗精力的是核心概念、核心算法、核心逻辑及上下游联调的整体解决方案。那些代码量虽少，但精力投入度极高。 两个漏斗叠加：时间大部分不在编码上，即使把那些容易的代码做到了 70%、80% 的 AI 生码率，整体的端到端效能提升，依然可能非常有限。 这是蒋林泉想直观分享给大家的事实。 问题是什么？AI 生码率指标，它恰好在最容易被优化的地方，是整个软件交付链路里，价值密度最低、最易被 AI 替代的一段。如此，用最容易被替代的环节，来衡量整体效能，是第一个误区。 Vibe Coding 快速搭建新应用 VS 企业存量主力老系统中无法落地 与「AI 生码率」类似的另一个误区，是 Vibe Coding。 大家都非常兴奋于「用 Vibe Coding 搭个应用很快」，但放在企业系统，事情没这么简单。 蒋林泉认为，有两个区分至关重要： 做一个 Demo、个人应用，和做一个客户大规模生产系统之间，有巨大的差别；做一个全新的应用，和在已有核心主力业务系统上叠加新需求，也有巨大不同。 “大部分公司不是一个创业公司，也并非在做公司的第一个应用。企业的核心应用都是存量系统，包括隔壁团队的系统也是存量系统。”这是实际。 他抛出这个直击本质的问题，让企业可以开始正视 Vibe Coding 的适用边界。 对于大多数企业来说，核心应用都是存量系统。业务复杂度极高，历史上积累了各种技术债务、不同人的编码风格；需要为生产稳定性负责，整个性能、可维护性都要关注。 但在这样的存量系统中，Vibe Coding 生成的代码无法直接大规模投入生产并承担质量责任。 对于需要为生产质量负责的场景，仍需投入大量工程精力。 图 2 : 正视 VibeCoding：适合与不适合的场景 因此，阿里云 CIO 团队的果断选择：不用「Vibe Coding 直接上生产」，采用「AI 辅助的软件工程」方式， 将 AI 作为提效工具融入规范化的工程流程中。 更深一层的思考，是蒋林泉在团队反复强调的一个逻辑：代码一旦生产出来，首先是负债。 这大概是技术圈细思甚恐的问题，被一语道破。如果生成的代码无法对业务客户产生正向价值，规模化地生产代码，本质上就是规模化地生产负债。毕竟，任何代码进入生产环境后，要即刻引入维护成本、增加系统复杂度，其与现有代码的依赖关系需要持续管理。代码能否转化为资产，即对业务客户产生正向价值，是不确定的。 他的经典逻辑是：增加的大量代码「可能」是资产，但「一定」是负债。 理解这一点，是后续全部 AI 工程实践的逻辑基础。 ? 同行之问：如果你也在被 AI 生码率困扰—— 我们设计了一份 「AI 同行人」交流意向 "，对于那些「看起来对、用起来不灵」的困惑，可以尝试对号入座、解决问题。 AI 破解「人月神话」与「左移」难题 很显然，流行的指标和工具，在企业的复杂系统里不灵，那效能的瓶颈该怎么解决？ 从问题矛盾要走到解决方案，蒋林泉用实战经验给出的结论是：要回到最本质的产品规划和软件工程里，才能解决价值问题、可靠性问题和可用性问题。AI 终究是个手段，它放大了工程能力，但无法替代工程本身。 他的分析从《人月神话》开始。 书中那个