夜雨聆风一、每个团队都有那段"禁区"代码
项目组里往往有几个文件，打开之后谁都沉默。
注释是 2014 年写的，变量名用的是 temp2、flag_xxx，逻辑绕来绕去，没人敢改。上一个改它的同事早已离职，留下一句话："能跑就别动。"
这类代码在行业里有个正式名称：遗留系统（Legacy System）。特征很统一：原始开发者离职了，业务逻辑全藏在代码里没有文档；测试覆盖率个位数，改一行可能爆另一处；新需求只能绕道加代码，越绕越乱。没人愿意接手，只要"能跑"就没人动。
2025 年，这个格局开始松动。不是工程师变得更勇敢，而是 AI 工具让进去不那么危险了。
二、真实案例：2 周干完预估 5 周的活
掘金上有一篇文章值得细看：作者接手了一个 Vue 2.x 订单管理系统，1 万行核心业务逻辑，经手 5 人，3 年没人敢大改。
代码的具体状况：
单文件最长 1800 行， OrderService.js一个文件塞了 47 个方法测试覆盖率不足 10%，关键业务路径基本裸奔 订单状态判断逻辑在代码里复制粘贴了 23 处 状态管理用了四种方案混用：Vuex、LocalStorage、SessionStorage、全局事件总线 订单列表加载 3~4 秒，用户投诉不断
Tech Leader 给了 2 周时间，传统方式预估要 35~40 天。
作者选择了 Claude Code 作为主力工具，原因很具体：GitHub Copilot 只能逐行补全，面对大型遗留代码力不从心；Cursor 处理复杂依赖时偶尔"理解偏"；Claude 的 200K token 上下文窗口可以一次性读进整个核心模块，并主动给出架构层面的建议。
14 天后的结果：
三、更大的规模：20 万行代码怎么搞
腾讯云开发者社区有一篇实战记录更重，作者团队重构的是一个推荐系统，代码总量超过 20 万行，触发点是 Code Review 时反复出现"绕道实现"——明知代码写在错误位置，但原文件几千行、几十层 if-else 嵌套，理解成本太高，大家选择妥协。
这种妥协是有传染性的：每绕一次，下一个人的理解成本就更高，下次更可能继续绕。十几次绕道之后，多个需求因代码太复杂根本无法上线。
团队用 AI 辅助的七步流程啃下这个任务：
- 建立战略框架
：确定影响范围、目标架构、重构标准 - AI 分析现状
：用 AI 扫描问题，输出优先级表格，重点是"哪些地方最危险" - 暴力拆解大函数
：把 2000 行的巨型函数拆到每个函数不超过 100 行 - 引入策略模式 + 依赖注入
：替换散落各处的 if-else 分支 - Pipeline 替代 DAG 配置
：让流程可读、IDE 可追踪 - 性能优化
：火焰图定位热点，平均耗时降低 20ms - 补测试、生成文档
：AI 系统化覆盖边界条件
最终数据：
巨型函数平均行数：2000 行 → 100 行以内 代码重复率：35% → 10% 新功能开发周期：3 天 → 1.5 天 Code Review 时间：2 小时 → 30 分钟 测试覆盖率：不足 30% → 100%
四、AI 在重构里到底做了什么
很多人以为 AI 重构就是"把老代码贴进去，让它改一遍"。实际不是这回事。
诊断是第一件事。把核心文件喂进去，让 AI 列问题清单。1 万行代码，几分钟能出一份 20 页的报告，指出重复逻辑、性能瓶颈、潜在 bug 分别在哪。这份清单省去了人工通读的时间，也比较客观，不会因为是自己写的就手下留情。
拆函数是第二件事。一个 800 行的 processOrder，AI 能帮你识别出 6 个独立职责，给出拆分点，生成代码框架。这类工作重复性高、模式明确，AI 做起来比较稳。
最实在的收益可能是补测试。遗留代码最大的风险不是看不懂，是改完不知道哪里断了。让 AI 先把核心路径的测试用例补上，覆盖率从 10% 拉到 45%，传统方式要一周，AI 辅助 1~2 天能搞定。
然后是模式替换：把散落各处的 if-else 改成策略模式，把紧耦合的依赖改成注入。这类有明确范式的改动，AI 生成的代码质量相对稳定。
但 AI 做不到的事同样要说清楚。它不知道这段代码背后的业务决策，它无法替你判断这个模块值不值得重构，它生成的代码需要人工逐行审核。
腾讯的案例踩了一个教训：AI 把函数形参悄悄替换成同名成员变量，声称"完全等价"，实际行为完全不同。没有人工复审，这个 bug 就直接上线了。
五、一套可复用的重构流程
结合两个案例，整理出一个通用步骤。
第一步是搭安全网，1~2 天。先不动代码，先补测试。覆盖率低于 30% 的遗留代码，把核心路径的测试用例先写出来，这是后面所有操作的底线，不能省。
第二步是 AI 诊断，半天。把核心模块代码喂给 AI，让它出问题清单：重复逻辑在哪、哪几个函数行数异常、依赖关系有没有明显耦合。这份清单直接当重构路线图用。
第三步是逐模块拆解。从最让人崩溃的地方下手，一次只动一个模块。AI 识别拆分点，你判断业务边界。改完一个模块立即跑测试，通过再往下走。
第四步是引入现代模式。重复的 if-else 分支改策略模式，紧耦合的依赖改注入，大文件拆成小模块。AI 对这类有明确范式的改动生成质量比较稳定。
第五步是三层验证：单元测试看每个函数的逻辑，集成测试看模块间的接口，端到端测试跑核心业务流程。三层都过才算这一轮改完。
第六步是灰度上线。先放 5% 流量，观察 30 分钟，没问题扩到 10%，再到 30%，最后全量。每一步都备好回滚，不要赌。
六、动手之前先问自己几个问题
不是所有遗留代码都值得现在重构。
这段代码还有人在改吗？如果一个模块 3 年没有新需求，改它的收益有限。真正值得动的，是每个月都要改、每次改都让人想摔键盘的那种。
业务逻辑有人能说清楚吗？AI 可以帮你理解代码结构，但没人知道业务的情况下盲目重构，风险很高。至少要找到一个能核实"这段逻辑是否正确"的人，哪怕是产品经理。
有测试兜底吗？覆盖率 0、没有回归测试，重构一次可能制造一次线上事故。先补测试，再谈重构。
团队现在有时间处理这件事吗？AI 提高了效率，但人工审核的工作量并不小。强行推进而后续没人跟进，往往烂尾。
七、AI 不是银弹，但已经够用
GitHub 做过一个有对照组的实验（2022 年，95 名专业开发者参与）：使用 Copilot 的开发者完成 HTTP 服务器任务的速度比不用的快 55%，p 值 0.0017，统计显著。
这个数字来自新任务，不是遗留代码重构，背景不同。遗留代码的麻烦主要在于"改了这里不知道会断哪里"，AI 能帮你读代码、生成代码，但它无法替你承担那个不确定性。
真正发生变化的是：一个工程师带着 AI 能干的活，比之前多，速度比之前快，质量不比之前差。
工程师没有消失。判断要不要改、改哪里、改对没有，这些只有人能做。而且现在这些判断变得更重要了，因为执行的速度快了一个数量级。
