遗留代码不是死的——它承载着多年的业务决策、历史教训和隐性知识。AI 不是魔法棒，但用对方法，它能成为你最得力的现代化武器。日本电商巨头 Rakuten 的工程师 Kenta Naruse 做过一个实验：给 Claude Code 丢了一个 1250 万行代码的开源项目 vLLM，让它实现一种复杂的激活向量提取方法。然后他离开了电脑。"那 7 个小时里我没有写一行代码，只是偶尔给出方向性指导。"这不是科幻片。这是 2026 年 4 月 Anthropic 发布的真实案例研究。但如果你以为把自家那个跑了十年、注释停在 2018 年、变量名叫 x 和 tmp 的老系统丢给 AI 也能得到类似结果——那我得给你泼一盆冷水。存量代码的现代化，从来不是一键生成的事。它是一套需要技术负责人精心设计和把控的系统工程。这篇文章讲的是这套工程怎么做。从理解代码、分层介入、执行落地到质量守住，四个步骤，外加 2026 年最新的业界案例和踩坑经验。2025 年一项行业调查显示，65% 的企业应用运行在过时的框架上（AngularJS、jQuery、Python 2、Java 8），40% 的核心业务逻辑写在 COBOL、Perl、Visual Basic 这些开发者正在急剧萎缩的语言里。企业 50%–70% 的开发预算花在维护已有系统上。而传统遗留现代化项目的失败率高达 70%——要么超预算 200%，要么彻底失败。（来源：综合 Gartner 2025 遗留系统报告、Industry Surveys 2025）信息不对称。 新项目的代码是你写的，你知道它要干什么。存量代码的作者可能已经离职三年了，注释停在 2018 年，变量名叫 x、tmp、data2——没有任何人能一眼看懂它在做什么。
隐性知识。 那段看起来很奇怪的支付模块逻辑？是因为 2017 年某个监管要求临时加的。那个永远不能被删除的表字段？因为有一个跑了十年的批处理任务依赖它。这些知识不在代码里，在人的脑子里——而人已经不在了。
耦合复杂。 单体架构里改一个函数，可能影响十几个看似不相关的模块。分布式系统里加一个字段，可能需要改五六个服务。AI 不了解你公司的风险容忍度、客户 SLA，或者为什么凌晨 3 点的告警电话不能出现。
测试困难。 存量系统往往缺乏完善的测试覆盖。没有测试的保护，任何重构都是在黑暗中走路。
AI 做不了业务判断和架构决策——那是技术负责人的活儿。但一旦你做了决策，AI 就是你执行层面的超级武器。
Coder.com 在 2025 年的一篇指南里把这个问题讲得很实在：AI 不是魔法，但在四个场景里效果是实打实的。还记得你花了三周时间追踪一个客户 ID，穿过十七个系统，才搞明白为什么某位客户的账户显示负余额吗？AI 可以在几小时内完成这种依赖追踪。它能跨数百万行代码映射调用链、数据流、业务逻辑。用 Copilot 的 @workspace 命令、Cursor 的代码库级搜索、或者 Claude Code 的 repo-map，直接问："这个函数被谁调用？这条数据从哪里来？"你的遗留系统里，同一个日期验证逻辑可能有十二种不同的实现方式，其中至少一半认为二月有 30 天。AI 能瞬间识别这些不一致模式，并给出标准化建议。这是人类开发者做得到但极度耗时的事情——而 AI 从不厌倦。废弃 API 调用的批量替换、语法升级（Python 2 → Python 3、Java 8 → Java 17）、公共功能提取到共享库、注释风格统一——这类任务 AI 能带来 2–3 倍的效率提升。你得到了一个永远不会抱怨重复工作的助手。没人喜欢写文档，但 AI "喜欢"。它能在一小时内为一个 15 年的模块生成比原作者半年写出来还好的文档。新团队成员入职时，AI 可以充当"导师"——解释架构决策、梳理代码逻辑、回答"这段代码为什么要这么写"。一个值得注意的陷阱： 上面这四个场景都有一个共同前提——AI 需要先理解代码。如果你什么都没喂给它，它就是在盲猜。
所以下面进入正题：怎么系统性地让 AI 帮你改造存量代码。
原则很简单：永远不要让 AI 在你不理解代码的情况下修改代码。
1. 全景扫描。 用 AI 对代码库做一次全局分析，生成架构概览、模块清单、依赖关系图。不需要人工逐行看，让 AI 先跑一遍，你再看摘要。
2. 关键路径追踪。 选 3–5 个核心业务流程，用 AI 追踪完整的代码路径——从入口到数据库。比如"用户下单"这个流程，经过了哪些服务、哪些表、哪些中间件。
3. 风险标注。 让 AI 识别高风险区域：缺乏测试覆盖的核心模块、复杂的条件分支、硬编码的配置、已知的技术债务。
4. 知识沉淀。 把 AI 分析的结果写成文档，存入团队知识库。这份文档本身就是现代化的起点。
> 实操示例：用 CLAUDE.md 建立知识基线
>
在项目根目录放一个 CLAUDE.md 文件，告诉 AI 项目的关键信息：> # 项目概述
> - 技术栈：Java 17 + Spring Boot 2.7 + MySQL 8.0
> - 模块：user-service, order-service, payment-service
>
> # 编码规范
> - 使用 Lombok，但禁止 @Data，只用 @Getter/@Setter
> - 所有异常必须继承 BusinessException
>
> # 红线模块
> - payment/core/SettlementEngine.java — 资金结算核心，禁止自动修改
> - config/SecurityConfig.java — 安全配置，需人工审查
>
> # 测试策略
> - 核心模块单元测试覆盖率不低于 80%
> - 集成测试使用 Testcontainers
>
这样一个文件，就能让 Claude Code / Cursor 等工具从一开始就知道项目的边界和约束。- 外围层——独立模块、工具函数、文档、配置文件。AI 全量参与，人工快速审查。
- 中间层——业务逻辑模块、服务接口、数据处理。AI 主导执行，人工深度审查。
- 核心层——核心算法、资金流转、关键路径。AI 辅助建议，人工主导修改。
为什么这样分层？因为风险和信任是递进的。团队需要先在外围层建立对 AI 的信心，积累"AI 改的代码靠谱"的经验，才能逐步扩大 AI 的权限。一上来就让 AI 改核心支付模块，出了事团队对 AI 的信任直接归零。
确定了层级和策略后，进入实际执行。核心模式是：人类做决策，AI 做执行。
- 增量修改。 不要一次性让 AI 重构整个文件。选一个函数，改完、测完、审完，再改下一个。
- 测试先行。 让 AI 修改代码之前，先让它为现有代码生成测试。有了测试保护，重构的安全性大幅提升。这就是 TDD 的理念——只是现在测试是 AI 生成的。
- 小步提交。 每次 AI 生成的改动都应该是一次独立的 git commit。粒度越小，回滚越容易。
- 并行执行。 Claude Code 等工具支持多会话并行。同时让 5 个 AI 会话处理 5 个不同模块，人工逐个审查。Rakuten 的实践就是一个工程师同时管理 4 个 AI 会话。
AI 生成的代码，必须经过和人类代码一样（甚至更严格）的审查。- 自动化测试。 CI/CD 流水线中的所有测试必须通过。AI 生成的代码不应该降低现有测试覆盖率。
- 代码审查。 至少一名资深开发者审查 AI 的改动。审查重点不是"代码能不能跑"，而是"代码是否符合业务意图"。
- 灰度发布。 关键模块的改动，先让小部分用户验证，确认无误再全量上线。
- 回滚预案。 每次 AI 驱动的改动都要有明确的回滚方案。
2026 年主流的 AI 编程工具，各有各的主场：- GitHub Copilot。 日常编码辅助最顺手。IDE 内对话、slash 命令丰富，企业版支持私有部署。适合"边写边问"的场景。
- Claude Code。 大规模代码库操作和自主重构的强者。多会话并行、MCP 协议集成，适合"给它一个目标，让它自己跑"的场景。
- Cursor。 代码理解和上下文感知编辑做得好。代码库级索引、@workspace 搜索，适合存量代码的理解阶段。
- Continue / Aider。 开源方案，支持多种开源模型，适合需要深度定制工作流的团队。
建议不是选一个，而是组合使用。 日常编码用 Copilot，大规模重构用 Claude Code，代码理解用 Cursor。工具是手段，不是目的。
- commit message 标注 AI 辅助改动，方便追溯。
Rakuten：7 小时重构 1250 万行代码——但有前提2026 年 4 月，Rakuten 和 Anthropic 联合发布了一份案例研究，数据很漂亮：- Claude Code 在 7 小时内完成了 vLLM 项目中的复杂功能实现，准确率 99.9%
- 新功能交付时间从 24 天缩短到 5 天，降幅 79%
- Claude Managed Agents 在一周内部署到产品、销售、市场、财务全公司
第一，vLLM 是一个规范良好的开源项目，代码质量远高于大多数企业的内部代码库。Rakuten 的 99.9% 准确率在这个前提下成立，换到一个充满 hack 和临时方案的企业代码库里，这个数字大概率会掉下来。第二，Rakuten 在引入 Claude Code 之前，已经自建了 AI 基础设施——包括内部 LLM 和大模型平台（他们的 "AI-nization" 战略）。这意味着他们不是在"裸用"一个工具，而是有完整的评估、测试、安全体系在兜底。第三，交付时间从 24 天降到 5 天，靠的不是 Claude Code 单打独斗，而是整个工作流的重构——并行开发、AI 辅助代码审查、测试流程优化。启示： AI 编程的真正价值不是"写代码更快"，而是"交付价值更快"。但要达到这个效果，前提是团队有足够的工程化基础。裸上一个 AI 工具，效果有限。
GitHub Copilot：公共部门、金融、零售的 COBOL 现代化GitHub 在 2025 年 1 月发布了一篇官方博客，记录了用 Copilot 将 COBOL 系统迁移到 Node.js 的实战过程。作者日常帮助公共部门、金融和零售企业部署 Copilot，被问到最多的问题是："我们怎么用 Copilot 现代化遗留系统？"- 用 /explain 命令理解 COBOL 代码的业务逻辑
但同样有局限： COBOL → Node.js 的迁移场景比较特殊，语言范式差异大，AI 在这种"翻译"任务上的表现反而比"重构"任务好。如果是在同一种语言内做架构重构（比如单体拆微服务），AI 的理解难度会更高。
C3 AI 在 2025 年 10 月展示了企业级方案：用生成式 AI + 多 Agent 工作流自动化文档生成和代码翻译。以一个 Fortran 神经网络库为例，流程是：解析代码生成 AST → AI Agent 生成架构文档 → 多 Agent 协作按模块翻译 → Agent 交叉检查一致性 → 最终人工审查。这个案例的关键启示是： 对于超大规模代码库，"一个 AI 搞定全部"不现实。需要结构化的多 Agent 工作流，每个 Agent 负责特定任务，互相校验。这和 Coder.com 在 2025 年提出的"私有模型部署 + 微调 + RAG + 隔离环境"的技术基础设施建议是一致的。
Essa Mamdani 在 2026 年 4 月的一篇文章中写道："2026 年最大的突破是高自主性 AI 编码 Agent——它们本地运行，通过 MCP 协议索引整个仓库，能在数小时内编排大规模重构操作。"这意味着 AI 编程正在从"短提示→短回复"的交互模式，进化到"给一个目标→Agent 自主执行数小时"的新模式。对技术负责人来说，要准备的问题不是"怎么选 AI 工具"，而是"怎么管理自主 AI Agent"——如何给目标、设边界、验结果。
一、别一上来就让 AI 碰核心代码。 从外围模块开始，建立信任，再逐步深入。信任不是一天建立的，但可以一天摧毁。
二、培养团队的 AI 素养比选工具更重要。 工具会变，能力不会。让团队学会"怎么问 AI"比"用什么 AI"更重要。
三、AI 做不了你的业务判断。 哪个模块先改？兼容旧接口还是直接破？灰度多久？这些决策只能由了解业务的人来做。AI 是执行者，不是决策者。
四、测试是安全的底线。 没有测试覆盖的 AI 重构就是赌博。先补测试，再谈重构。
五、小步快跑，频繁验证。 不要让 AI 一次改一千行。改十行、测十行、审十行，再改下一个。
六、度量真实价值，不是代码行数。 别统计"AI 写了多少行代码"。统计"交付时间缩短了多少"、"Bug 率降低了多少"、"团队满意度提升了多少"。
七、存量改造是一场马拉松。 遗留代码现代化不是一两个 sprint 能完成的。制定计划、设定里程碑、保持节奏。快不是目的，稳才是。
2026 年，AI 编程已经不再是"尝鲜"——它是技术负责人手里最务实的效率杠杆。存量代码库的现代化，本质上不是技术问题，是知识问题——理解已有的，决定要改的，安全地执行变更。AI 在"理解"和"执行"上越来越强，但"决定"这件事，还得靠人。用好 AI，不是让 AI 替你做技术负责人该做的事。而是让 AI 帮你把该做的事，做得更快、更好、更安全。
夜雨聆风
