代码一旦生产出来，首先是负债 —— 一个CIO 的AI效能实践复盘

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 办公效率, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/TrgoIq3rWn6bpYT8Lvdwyw

摘要

阿里妹导读当下，企业 AI 产研提效，「规模化」是真正的难点。文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。前言：技能通胀，品味通缩 2026 财年对比 2025 财年，阿里云 CIO 线的产研效能呈现出一组清晰的跃升：前端人均有效代码量提升至 3 倍，后端提升至 2 倍；千行代码缺陷率，前端下降 30%，后端下降 55%。数字背后，是在承接更多核心业务与 AI 创新、没有增加人力、最终落实到了业务价值的多重前提下实现的。在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。 2026 年，「AI 提效」已经成为产研圈最急迫的词...

核心内容

阿里妹导读

当下，企业 AI 产研提效，「规模化」是真正的难点。文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
前言：技能通胀，品味通缩

2026 财年对比 2025 财年，阿里云 CIO 线的产研效能呈现出一组清晰的跃升：前端人均有效代码量提升至 3 倍，后端提升至 2 倍；千行代码缺陷率，前端下降 30%，后端下降 55%。

数字背后，是在承接更多核心业务与 AI 创新、没有增加人力、最终落实到了业务价值的多重前提下实现的。

在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。

2026 年，「AI 提效」已经成为产研圈最急迫的词汇。它几乎被贴在所有季度汇报的第一页，却很少出现在真实的业务结果里。这背后有个结构性问题：大多数企业对 AI 的使用，停留在工具替换层面，而非流程重构层面。工具替换能产生局部加速，却无法带来系统性效能跃升。更隐蔽的危险是：当 AI 让代码生产的边际成本趋近于零，它同时也在加速放大流程中每一个错误决策的代价。

阿里云 CIO 蒋林泉及其团队这一年的实践结果，凸显在AI变革中的热情与理性。早在2025 年 8 月，一次关于企业大模型落地的主题分享[1]中，他就提出了一个判断：「技能通胀，品味通缩」。

八个字，浓缩了 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 终究是个手段，它放大了工程能力，但无法替代工程本身。

他的分析从《人月神话》开始

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充