代码是一份负债？AI 时代下，我们为何重拾“工程左移”的古老智慧
品味，是对业务价值的判断；AI 只能做到 Average，但有品味的人能定义什么是“好”。
前言：当“AI 生码率”成为 KPI 的迷思
在过去的一年里，如果你问一个技术团队最火的指标是什么，答案大概率不是 QPS（每秒查询率）或 RT（响应时间），而是 “AI 生码率” 。
从硅谷到国内，大家都热衷于炫耀 AI 生成的代码占比从 20% 攀升到 50% 甚至更高。似乎 AI 渗透率越高，团队的效能就越强，技术 Leader 们的汇报 PPT 也就越厚重。然而，在喧嚣之下，一个更加冷峻的现实正在浮现：
代码行数增加了，业务价值真的提升了吗？
最近，阿里云 CIO 蒋林泉在一场深度的实践复盘中的观点发人深省。他提出，在 AI 时代，我们首先要建立一种认知：“代码一旦生产出来，首先是负债。”
这个观点无疑是反直觉的，甚至有些“泼冷水”。但当我们撕开“AI 生码率”这块华丽的遮羞布，深入软件工程的本质时，你会发现，这或许才是组织效能得以规模化提升的真正起点。
01 代码即负债：重新定义“资产”
为什么说代码是负债？
这是一个非常经典的财务视角。任何一段代码被合并进入生产环境后，它可能是资产（因为它带来了业务价值），但它一定是负债（因为从此以后，它将产生维护成本、增加系统复杂度、引入潜在 Bug，并成为新人的认知负担）。
在过去，我们通过严格的 Code Review、架构设计和文档来对抗这种负债。而在 AI 时代，由于大模型极低的代码生成成本，这种“负债”被以前所未有的速度规模化放大。
“Vibe Coding”的陷阱：
Vibe Coding 让我们非常兴奋，用自然语言描述就能快速搭建一个 Demo。这在做新产品原型或个人项目时非常好用。但在企业的存量核心系统中，Vibe Coding 生成的代码往往无法直接上生产。因为企业系统需要处理的是边缘场景、极端并发和历史遗留的数据结构，而非仅仅“看起来很美的”核心路径。
AI 像一个极其勤奋但缺乏经验的实习生，他可以极快地写出“胶水代码”，却也极快地制造出难以维护的“屎山”。
02 破解“人月神话”：AI 改变了什么？
既然代码是负债，难道我们就不写代码了吗？当然不是。我们的目标是让产生的负债能换来足够多的资产（业务价值）。
这就需要我们重新审视软件工程中两个无法绕开的经典难题——“人月神话”与“工程左移”。
- “人月神话”的终结与新生
《人月神话》告诉我们：在一个延迟的项目中增加人力，只会让它更延迟。因为人与人之间的沟通成本呈几何级数增长。
但在 AI 时代，这个逻辑被改写了。
如果你增加的“人手”是 AI Agent 呢？Agent 之间传递上下文没有损耗，Agent 接管了大部分低效的沟通与信息同步工作。以前一个需求需要产品、开发、测试三方拉会对齐，现在可以通过 AI 将存量代码、PRD（产品需求文档）转化为结构化的 Spec（规格说明），让信息在流转中不失真。
- “左移”的 ROI 终于为正了
“左移”是一个老生常谈的概念，即把质量保证、安全测试等工作从“右边”（发布后/测试时）移到“左边”（开发时/编码前）。
道理大家都懂，为什么以前做不好？因为成本太高。
让开发者在写代码前去写详尽的测试用例，去梳理复杂的业务链路覆盖度？这虽然正确，但极其反人性，ROI（投资回报率）极低。
AI 让这一切发生了质变。
03 最佳实践：AI 重塑“工程左移”的实战路径
依托于通义灵码等 AI 助手，阿里云内部团队进行了一场关于“左移”的静默革命。以下是值得借鉴的具体策略：
- 质量左移：从 20% 到 100% 的覆盖度飞跃
在传统的开发模式下，单元测试覆盖率往往随缘，通常仅覆盖核心逻辑（可能不足 20%）。因为在开发完业务逻辑后，开发者的精力已耗尽。
AI 实践方案：
在编码阶段，开发者不再需要手动编写琐碎的测试用例。IDE 插件可以根据上下文代码自动生成覆盖边界条件和异常路径的测试代码。
效果：
阿里云内部团队反馈，在 AI 的辅助下，部分模块的测试覆盖率从原本的 20% 提升到了接近 100%。更重要的是，这种质量的“左移”强迫开发者在编码前就想清楚“我的代码如何被验证”，从而反向优化了代码结构。
- 知识左移：为存量系统“解冻”
企业最大的痛苦不是写新代码，而是理解旧代码。新接手一个项目，可能需要两周时间熟悉上下文。
AI 实践方案：
利用 RAG（检索增强生成）技术，将存量系统的代码库、历史文档、需求文档向量化。AI 可以瞬间“通读”整个老旧系统。
新需求落地： 开发人员在提出一个新需求时，AI 能自动检索现有系统，指出“这个功能在 xxx 模块已有类似实现，建议复用”或“修改此处可能影响到隔壁的订单系统”。
核心转变：
知识传递不再依赖于人与人之间的口口相传，而是变成了“人 + AI + 代码库”的高效互动。
- Spec 驱动：让 AI 遵循“契约”
不要简单地让 AI 写代码，而是让 AI 遵循 Spec。
AI 实践方案：
研发流程可以调整为：
写 Spec（契约/规格）：开发者（或 AI）先定义好函数输入输出的预期、业务规则的边界。这一步是定义“什么是好”。
AI 生成实现：AI 根据 Spec 生成满足条件的代码。
AI 校验：利用 AI 检查生成的代码是否违背了原始的 Spec。
在这套流程下，开发者的角色从“代码打字员”转变为了“架构师与验收官”。稀缺的不再是堆砌代码的能力，而是定义业务价值、判断代码好坏的 “品味”。
04 结语：不做 AI 的奴隶，做 AI 的主人
回到文章的开头，为什么我们不应盲目追求 AI 生码率？
因为低价值的代码是负债，而高价值的业务洞察才是资产。
阿里云开发者社区一直倡导“天然无套路，有料必精品”。在这个 AI 汹涌的时代，技术人最容易被替代的恰恰是那些机械化的编码技能。而其中最不会被替代的，是界定问题、拆解复杂度和守卫代码质量的判断力。
从现在开始，也许我们该换个玩法：不再炫耀 AI 写了多少行代码，而是关注“在 AI 的辅助下，我们的无效代码减少了多少行，系统熵增降低了多少”。
