用 AI 重构遗留代码，正确顺序是先补测试网再动手，不是让模型直接改——没有可回退的基线，你得到的只是「看起来更干净」的错误代码。 AI 在这个场景真正的价值是把读代码的成本压到接近零：它能在几十分钟内给出模块依赖、风险分级和业务规则摘要，而人只需要守住「每次改动都能验证」这条底线。
为什么老项目重构总在半途死掉
Anthropic 在《 Code Modernization Playbook 》里把遗留系统改造分成几个成熟度阶段，最底层那一档的共同特征是：代码行数、年龄、重要性的清单有，但没有 ROI 分析，也没有可自动验证的手段。于是团队只能靠人肉核对每一次翻译结果，进度必然卡住。
常见失败原因其实就三条：
- 没人知道这段代码到底干什么：原作者已离职，注释与实现早已脱节。
- 没有测试，改完不敢发：改动的正确性只能靠”看起来对不对”。
- 重构和功能改动混在一次提交里：出问题时无法二分定位。
三步法：画像 → 基线 → 小步
第一步：先让 AI 产出模块画像，不要让它改代码
把仓库路径交给 AI，只要求它输出三样东西：模块依赖图、风险分级（改动影响面）、以及每个模块的业务规则摘要。这个阶段禁止任何写操作。用 Claude Code 时可以直接开只读会话；用 Cline 这类插件则把 Plan 模式当作默认，确认后再进 Act 模式。
阅读 src/order 目录，输出：
1. 模块间依赖列表（谁调用谁）
2. 按"改动影响面"给模块分高/中/低三档
3. 用中文写出每个模块的业务规则，不超过 5 条
不要修改任何文件。有了这份画像，你才知道该从哪儿下刀。我们的经验是先动低风险、高重复的模块，把 AI 的产出与人工判断做一次校准，再往核心业务推进。
第二步：建立可回退基线（characterization test）
这是最容易被跳过、也最要命的一步。对要重构的模块，先写一批”描述当前行为”的测试——注意，是记录它现在怎么跑，而不是它应该怎么写。哪怕当前行为本身就是 bug，也先固化下来，等重构完成、行为保持一致的证据拿到手之后，再单独修 bug 。
这层测试正是 Michael Feathers 在《修改代码的艺术》里讲的”接缝”：没有它，后面每一步都是在赌。 AI 在这里效率很高，把模块喂给它让它生成覆盖测试即可，但生成完必须自己抽查断言是否真的检查了行为，而不是只验证了”没抛异常”。
第三步：小步重构，一次提交一个动作
每次只做一种重构手法：提取函数、消除重复、以卫语句替换嵌套条件、拆分大模块。每一步都要满足三个条件——能编译、测试全绿、提交信息写清用了哪种手法。 Anthropic 团队在内部实践里反复强调的一点很实用：把工具设计成让模型不容易犯错，比如文件操作工具强制要求绝对路径，模型就不再会在切换目录后写错相对路径。
四类优先动刀的点
| 类型 | 判断标准 | AI 提效程度 | 风险 |
|---|---|---|---|
| 死代码清理 | 从入口追踪调用图后不可达 | 高（自动追踪调用链） | 低 |
| 重复逻辑提取 | 相同代码块出现 3 次以上 | 高 | 低 |
| 嵌套条件化简 | 缩进超过 3 层、函数超过 30 行 | 中高 | 中（易改行为） |
| 大模块拆分 | 单文件超过 800 行且职责混杂 | 中 | 高（依赖方向易乱） |
拆模块这一步建议留到最后，并且先让 AI 画出目标依赖方向，人工确认没有循环依赖了再动手。
三条不能碰的红线
- 禁止重构与功能改动混提交：一次 PR 只做一件事，否则无法二分定位回归。
- 禁止在无测试覆盖的核心计费 / 权限路径上让 AI 自由发挥：这类模块必须人工逐行 review 。
- 禁止把”AI 说它完成了”当作验收标准：验收只看测试是否变绿、覆盖率是否下降、静态分析告警数是否变少。
成本与产出的现实预期
别指望”一键现代化”。真正能压缩的是理解成本——以前两个人周才能摸清的模块，现在一个下午能出画像；真正压不动的是业务决策——哪些行为是历史包袱、哪些是刻意设计，AI 不知道，只有人和业务方能判断。所以合理的分工是：AI 负责读、负责改、负责跑测试；人负责定义”什么才算改对了”。
相关阅读
- Claude Code Hooks 用法详解：把「改完必须跑测试」写成强制钩子。
- Cursor Rules 配置实战：把团队的目录约定与重构规则固化下来。
- Cline 开源 AI 编程插件实测：Plan/Act 双模式更适合老项目。
评论 (0)