C's Notebook 十元的创作档案

FEATURED / HUMAN

存量代码才是 AI 编程的主战场

说明 AI 编程的主战场为何是存量代码，以及安全改造所需的工程纪律。

Legacy Code · 测试 · AI Coding

SOURCE / Cshiyuan/article / 成品/AI深度学习系列/19-存量代码才是AI编程的主战场.md

图片来源：ProgrammerHumor - Legacy Code

引言

打开社交媒体，AI 编程的演示视频几乎都是同一个剧本：”用自然语言描述需求 → AI 从零生成一个完整应用 → 五分钟搞定”。

很酷，但这和大多数开发者的日常毫无关系。

现实是：你每天打开的不是一张白纸，而是一个跑了三年、经历了十几个人接手的代码库。几百个文件，上万行代码，到处是”临时方案”和”历史原因”。你要在这堆东西里加功能、修 bug、做重构——这才是你真正的工作。

一个被反复引用的数据：开发者 58% 的时间花在理解代码上，只有不到 5% 的时间在写新代码。 Robert C. Martin 在《Clean Code》里说过：”阅读代码与编写代码的时间比至少是 10:1。”

图片来源：ProgrammerHumor - When you have to work on legacy code

这引出一个反直觉的判断：AI 编程在存量代码中的价值，可能远大于从零开始的新项目。 因为新项目的瓶颈是”写”，而存量项目的瓶颈是”读”——而 AI 恰恰擅长高速阅读和理解大量代码。接手一个不熟悉的模块，你要花半天甚至几天去梳理目录结构、调用链、数据流向。AI 可以在几分钟内读完所有相关文件，给你一个结构化的全景图。

二、为什么存量代码比新项目更需要 AI

新项目的”AI 甜区”很窄

从零开始的项目，AI 确实好用：没有历史包袱，没有风格冲突，想怎么写就怎么写。

但新项目在整个软件生命周期里占多大比例？

  1. 一个典型的企业级应用，开发阶段占生命周期的 **20%**，剩下 80% 是维护和演进
  2. 大多数开发者 70% 以上的时间在和已有代码打交道
  3. 全球 IT 预算中，用于维护现有系统的比例高达 60%-80%

AI 编程的演示总是挑最好看的场景——从零搭建。但占据开发者绝大部分时间的，是存量代码。

大量关键系统仍然运行在多年积累的存量代码上。它们承载真实业务、依赖关系复杂，也很难靠一次重写安全替代。对多数工程团队来说，读懂、测试并持续改造现有系统，比从零生成一个演示项目更接近日常工作。

这不是一个小众问题，而是整个软件行业最大的痛点之一。

存量代码的痛点恰好是 AI 的强项

存量代码任务与 AI 能力逐项匹配

大厂已经在这个方向上重注投入：

  1. AWS Transform（2025 年 5 月）：首个代理式 AI 服务，专门用于大规模现代化大型机工作负载，能将 COBOL、JCL 等大型机语言翻译为 Java
  2. Google Cloud Mainframe Rewrite：将 COBOL 遗留代码转换为 Java、C# 等现代语言，提供 IDE 环境支持迭代式现代化
  3. Anthropic Claude 的 COBOL 冲击（2026 年 2 月）：Anthropic 宣布 Claude 可以自动化分析和探索遗留 COBOL 代码，IBM 股价单日暴跌超过 13%

一组效果数据：

  1. **交付周期缩短 83%**：一家企业通过 AI 代理集成到遗留系统，将交付从 6 个月缩短到 10 周，完成了传统上需要 20 名工程师的工作
  2. **部署问题减少 70%**：有系统化测试协议的团队，使用 AI 辅助重构后部署问题减少 70%
  3. 节省数百万美元：某金融机构用 AI 重构 300 个 Java 微服务的过时安全库依赖，自动映射依赖关系、生成升级补丁，通常三周完成

三、血泪教训：127 个新 Bug

数据很漂亮，但现实没那么美好。

一位开发者写了篇文章，标题就很有冲击力：《I Let AI Refactor Our Legacy Codebase. It Created 127 New Bugs》。

他让 AI 对遗留代码库做了一次大规模重构，结果引入了 127 个新 bug。代码看起来”更干净了”，但跑起来到处是问题——因为 AI 改变了很多微妙的行为逻辑，而这些逻辑恰恰是多年踩坑后”故意这么写的”。

这不是个例。更大规模的数据也在指向同一个方向：

  1. **代码复杂度增加 40.7%**：研究发现 AI 辅助编码导致代码复杂度指标反而上升了 40.7%，静态分析警告增加 29.7%。AI 没有让代码更简洁，反而更复杂了
  2. 近 3/4 组织遭遇生产事故：来自 AI 生成代码的生产事故，已经不是罕见事件
  3. 越自信越危险：使用 AI 助手的开发者写出的代码显著更不安全，但他们更倾向于认为代码是安全的

图片来源：ProgrammerHumor - Never touch the legacy code!

问题出在哪？

AI 会”自信地犯错”。 它可能给你一个技术上完全合理的重构方案，但这个方案破坏了业务逻辑或领域特有的约束。它会自信地重组代码，然后悄悄地搞坏边界条件。

“最大的风险不是’代码变乱’，而是’行为静默改变’。”

存量代码里有大量”看起来奇怪但其实是故意的”逻辑。AI 不知道某个 if 是为了绕过一个上游系统的 bug，不知道某个看似冗余的检查是因为三年前出过一次生产事故。它只看到”这段代码可以简化”——然后就简化了。

Agent 还有一个更隐蔽的问题：倾向于”造轮子”。 在不充分了解已有代码的情况下，AI 更倾向于重新实现一个功能，而不是复用已有的模块。结果就是代码库里出现了两套功能相似但实现不同的东西，维护成本翻倍。

METR 研究：一个让人清醒的发现

2025 年，METR 组织做了一项严谨的研究：让 16 名经验丰富的开源开发者在他们自己长期贡献的大型仓库（平均 22k+ stars，100 万+ 行代码）上使用 AI 工具。

结果出人意料：使用 AI 后，完成任务实际上**慢了 19%**。

更有意思的是认知偏差——开发者事前预期 AI 能加速 24%，事后仍然”感觉”加速了 20%，但实际上变慢了。我们对 AI 编程效率的直觉是不可靠的。

这个研究说明什么？在熟悉的大型存量代码库中，AI 的价值不在于”帮你写得更快”——你本来就很快。它的价值在于帮你做那些你不擅长或不愿意做的事：阅读不熟悉的模块、补写测试、梳理依赖关系、识别死代码。

四、棕地优势：约束反而是好事

在展开改造纪律之前，有一个反直觉的观点值得讨论。

有分析提出：存量代码的约束，反而能让 AI 产出更好的代码。

“Without constraints, AI produces chaos; brownfield constraints guide AI toward coherence.”
（没有约束时 AI 产出混乱，棕地约束反而引导 AI 走向连贯。）

举个具体的对比。同样是”给订单模块加一个缓存层”：

在新项目里，AI 可能自行选择 Redis 客户端库、自创一套缓存 key 的命名规则、用它觉得”最优”的缓存失效策略。三个不同的 prompt 可能产出三套完全不同风格的代码。

但在一个已有 50 个模块的存量项目中，AI 会看到：项目已经用了统一的缓存工具类、key 命名遵循 {service}:{entity}:{id} 的规范、失效策略统一用事件驱动而非 TTL。它会模仿这些已有模式，产出和项目整体一致的代码——不需要你在 prompt 里写一堆约束条件。

已有的架构模式、代码风格、命名规范、目录结构——这些”约束”是 AI 的护栏。新项目里 AI 自由发挥的结果往往是风格混乱，而存量项目的既有规范天然地给 AI 划定了轨道。

存量代码不只是挑战，也是 AI 的”脚手架”。

五、存量代码的 AI 改造纪律

存量代码的 AI 改造不是”让 AI 重写一遍”，而是一套需要纪律的工程流程。

纪律一：先锁行为，再改结构

这是最重要的一条。在动任何代码之前，先用测试把当前行为”锁住”。

阅读、补测试、跑基线与小步重构组成的安全变更循环

AI 特别擅长这一步——给它一段没有测试的老代码，它能快速生成覆盖当前行为的测试用例，包括你可能遗漏的边界情况。

这可能是 AI 在存量代码中最有价值的应用：不是改代码，而是先给老代码补上测试安全网。

纪律二：极小粒度，逐步推进

绝对不要对 AI 说”重构这整个包”或”把所有 HTTP 端点都重写一遍”。

正确的粒度是：

  1. 一次只改一个函数或一个模块
  2. 改完立即跑测试
  3. 确认没问题再改下一个
  4. 每次改动都生成独立的 commit

大规模一次性重构是”127 个新 bug”的根本原因。AI 在小范围内的准确率远高于大范围改动。

纪律三：重构和修 Bug 永远分开

这条规则在传统开发中就重要，在 AI 辅助开发中更加关键。

重构的目标是”改变代码结构，不改变行为”。修 bug 的目标是”改变行为”。如果两件事混在一起，你根本无法判断测试失败是因为重构引入了问题，还是 bug 修复改变了预期行为。

给 AI 布置任务时，永远只给一个目标：要么重构，要么修 bug，不要在同一个 prompt 里同时做两件事。

纪律四：CI 回归门控 + 人工审查

AI 变更经过自动化检查与人工意图审查后合并

自动化测试负责”代码对不对”，人工审查负责”方向对不对”。

人工审查的重点不是检查语法和格式（AI 通常不会犯这种错），而是检查：

  1. 这个修改是不是我想要的？
  2. 有没有改变原有的业务语义？
  3. 有没有引入不该引入的依赖？

“No AI-generated code merges without human review.” 这条规则没有例外。

六、AI 在存量代码中的最佳应用场景

不是所有存量代码任务都适合 AI。以下是投入产出比最高的场景：

第一梯队：高价值 + 低风险

  1. 代码理解和导航：你刚接手一个 10 万行的支付模块，需要搞清楚一笔退款从发起到到账经过了哪些服务。手动梳理可能要两天，AI 几分钟就能读完所有相关文件，画出完整的调用链和数据流向。这是 AI 在存量代码中的”杀手级”场景
  2. 补充测试覆盖：一个跑了五年的订单模块，测试覆盖率只有 12%。没人敢碰它，因为改了不知道会不会炸。让 AI 基于现有行为生成测试用例——即使不完美，也比裸奔强得多，而且给后续重构铺了安全网
  3. 死代码识别：代码库里有多少函数其实从来没被调用过？手动排查极其痛苦，AI 可以全局扫描依赖图，几分钟找出所有”僵尸代码”

第二梯队：高价值 + 需谨慎

  1. 小范围重构：提取函数、消除重复、简化条件逻辑——在有充分测试覆盖的前提下
  2. API 迁移：框架升级、依赖版本更新等机械性但大范围的改动。比如把 300 个微服务的某个安全库从 v2 升到 v3——AI 可以自动映射 API 变更、批量生成升级补丁
  3. 文档补充：为缺乏注释的代码生成文档，让下一个人更容易理解

第三梯队：谨慎使用

  1. 大规模架构重构：跨模块的结构性调整，必须分解成极小步骤，每步都要人工审查
  2. 涉及业务逻辑的改动：AI 不理解业务上下文，需要人类提供充分的背景信息

七、上下文是胜负手

存量代码的 AI 改造，技术上最大的挑战是上下文。

一个跑了三年的项目，背后有大量不在代码里的知识：为什么用了这个框架而不是那个，某个接口为什么设计成这样，哪些模块是”能跑就别碰”的禁区……

AI 看不到这些。它只能看到代码本身。

让 AI 有效改造存量代码的关键，是把隐性知识显性化。

几个具体的做法，以及没有它们时 AI 会怎么”翻车”：

  1. 项目规范文件（CLAUDE.md）：把架构约定、命名规范、已知的坑、团队共识写进一个 AI 每次启动都会读取的文件。没有它时，AI 可能在你的 Go 项目里写出 Java 风格的错误处理，或者在已经有统一日志库的项目里引入一个新的日志框架。有了它，AI 每次动手前都会先”对齐”团队规范。三个月积累下来，AI 对项目的理解会超过大部分新入职的工程师

  2. 已知问题库（docs/solutions/）：每个踩过的坑、做过的非平凡决策，都沉淀成可检索的文档。没有它时，AI 会”重新发现”你三年前踩过的坑——比如把某个看似冗余的 retry 逻辑删掉，然后你的服务在上游超时时开始雪崩。有了它，AI 遇到类似场景时自动命中历史经验

  3. 架构决策记录（ADR）：为什么选了 PostgreSQL 而不是 MongoDB？为什么用了消息队列而不是直接调用？没有它时，AI 可能建议你”直接用 HTTP 调用就行了，不需要消息队列”——它不知道你当初引入消息队列是因为下游服务的 SLA 只有 95%。有了它，AI 在做方案建议时会考虑这些历史约束

存量系统改造的关键不是 AI 的能力，而是你能不能给 AI 足够好的上下文。

这也是为什么上下文工程正在成为 AI 编程领域的核心话题。Token 成本、信息密度、检索精度——这些看似技术性的问题，直接决定了 AI 能否在你的存量代码库里”干活”。上下文给得好，AI 是高级工程师；上下文给得差，AI 是会写代码的实习生。

总结

回到开头的判断：存量代码才是 AI 编程的主战场。

不是因为新项目不重要，而是因为：

  1. 开发者的时间分布决定了这一点——58% 的时间在理解代码，而 AI 恰好擅长这个
  2. 软件的生命周期决定了这一点——80% 的时间在维护和演进，而不是从零构建
  3. 实际效果的数据支撑了这一点——交付周期缩短 83%、部署问题减少 70%

但这个主战场有它的规则。127 个新 bug 的故事告诉我们：AI 不是”重写按钮”，而是”加速器”。加速器要发挥作用，需要轨道——测试先行、小步前进、行为锁定、人工把关。

从零搭一个 demo 很酷，但让一个跑了三年的系统变得更好、更容易维护、更容易演进——这才是 AI 编程真正的硬仗，也是真正有价值的仗。

参考资料：

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。