CIO正在抛弃AI生码率：一场关于什么才算产研提效的实践复盘
核心要点
- AI生码率是"过程指标"：阿里云CIO蒋林泉从一开始就将此指标排除在考量体系之外，理由明确：AI生码率是"过程指标"，团队一旦观测量化这种过程指标，AI就特别容易产生"毒害"
- 代码最终要转化为真正的业务价值：这是最开初强调的产研效能数据提升的前提
- 两个流行误区正在让大量团队越跑越偏"AI生码率"一路攀升：真实项目的E2E产研时间却没有缩短
- Vibe Coding快速搭建新应用 VS 企业存量主力老系统中无法落地：企业核心应用都是存量系统，在这类系统中Vibe Coding生成的代码无法直接大规模投入生产并承担质量责任
详细内容
一、为什么CIO们开始放弃"AI生码率"
蒋林泉的核心观点：
代码一旦生成出来，首先是负债。
技术圈盛行的"AI生码率"指标，恰好在最容易被优化的地方——整个软件交付链路里，价值密度最低、最容易被AI替代的一段。如用最容易替代的环节，来衡量整体效能，是第一个误区。
更根本的问题在于：即使把那些容易的代码做到了70%~80%的AI生码率，整体的端到端效能提升，依然可能非常有限。
二、两个典型误区
误区1：AI生码率指标
从硅谷大厂到国内独角兽，大家普遍炫耀生码率从20%攀升到50%。蒋林泉从一开始就排除这个指标，他的理由极其明确：
- AI生码率是"过程指标"，团队一旦观测量化这种过程指标，AI就特别容易产生"毒害"
- 代码行数如果"不加权"是没有意义的，这让团队很容易陷入"灌水"的陷阱——AI生码率看起来很高，但对业务效能毫无帮助
误区2：Vibe Coding
Vibe Coding适合场景有两类：
- 做一个Demo、个人应用，和做一个客户大规模生产系统之间，有巨大的差别
- 做一个全新的应用，和在已有核心主力业务系统上叠加上新需求，也有巨大不同
大多数企业的核心应用都是存量系统。业务复杂度极高，历史积累了大量技术债务、不同人的编码风格；需要为生产稳定性负责，整体性能、可维护性都要关注。
三、阿里云CIO团队的实践
蒋林泉团队采取的路线是：
不用"Vibe Coding 直接上生产"，采用"AI辅助的软件工程"方式，将AI作为提效工具融入规范化的工程项目流程中
蒋林泉反复强调的一个逻辑：
代码一旦生成出来，首先是负债。
增加的大量代码"可能是"资产，但"一定是"负债。
他用经典逻辑总结：
增加的大量代码"可能"是资产，但"一定"是负债。
四、AI破解"人月神话"与"左移"难题
关于人月神话：在组织里加人会有低效的沟通问题，但加AI Agent就不一样了——Agent可以无损地拿到上下文，能规模化地从已有代码里解析上下文，并不需要人与人之间低效的几何级数增长的沟通消耗。
关于左移：AI时代里，原来那些上下文和知识资产，AI可以从存量代码里提取出来，再加上增量的PRD、Spec等上下文，业务复杂系统能够简化成一个大家可理解上下文框架——无论对新成员还是不同岗位之间，都能在一条业务链路里更低成本、更高效率地对齐。
五、四个显著性改变
- 左移"质量与测试"：测试覆盖从20%提升到加权接近100%。AI帮助定义覆盖范围、识别异常路径与边界条件，也能快速生成大量Test Case
- 左移"知识工程 + Spec"：存量系统的知识解冻还原。团队从既有代码、前后端代码、内部文档到客户使用文档中，挖掘系统API、数据结构和业务流程，再按照规约模板，引导AI生成结构化的Spec知识库
- 规约跨职能边界：API First 终局不良"代偿"。AI辅助团队规约排查系统中不合规的职责分布，并解读书籍API：哪些API职责重复、边界不清、语义混乱？哪些业务逻辑被错误地分散在不同系统中？
- Vibe Coding左移确认：需求澄清大幅度"前置"。用Live Demo与业务方对焦，"所见即所得"的需求确认，把本来上线后才发生的验货，前置到需求最左侧
六、结论
灵瑰 × 骨架构定义问题，就已解决90+%的问题。
"灵瑰"指向业务价值。如果做了一个软件，上线后有没有在端到端的业务闭环中产生业务价值，是关键。
真正耗时的，变成了人与人之间的战略判断、跨团队协作，以及对不可逆决策的审慎讨论——而这些，AI目前还无法完全替代。
文章原载于 InfoQ，作者王玮、籍云，经授权转载。