AI 辅助代码重构实战

一、重构:每个开发者心里那块不敢动的石头

每个老项目里都躺着几段"祖传代码":没人能完整说清它为什么这么写,但谁也不敢动。改好一个边界条件,可能在三个月后的某个深夜线上告警里炸出来。于是大家默契地绕着走,技术债越垒越高。

重构是技术债的解药,这件事所有工程师都懂。它挡在面前的不是认知问题,而是成本和风险问题:你得先读懂上下文、理清所有调用方、确认没有遗漏的副作用,然后小心翼翼地改、跑测试、再改。一个工作日能重构完的函数,前置调研可能就要两天。所以重构永远排在"下个迭代"。

AI 真正改变的不是"重构好不好",而是重构的启动成本。让它先帮你读完 2000 行的旧模块、列出所有调用点、生成一份"如果改成这样会影响什么"的影响面分析——这件原本没人愿意干的苦活,现在几分钟就有初稿。门槛降下来,很多"本来该做"的重构就真的会做了。

但门槛降低不等于风险消失。AI 改代码又快又自信,而自信和正确是两回事。它会在你眼皮底下把 >= 写成 >,顺手"优化"掉一个看起来多余、实则兜底 null 的分支。用对了是加速器,用错了就是隐蔽 bug 的批量制造机。 这篇文章讲的,就是怎么只拿加速、不接 bug。

二、AI 擅长的重构场景:放手让它干

有一类重构的共同特征是:目标明确、行为可验证、上下文局部。这类活交给 AI 又快又稳。

1. 纯函数抽取。 一个方法里混着计算、IO、格式化,把它拆成纯函数,是最适合 AI 的活——因为纯函数行为可单测、可枚举。

// 重构前:计算、副作用、格式化全揉在一起
async function checkout(order: Order) {
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.qty;
    if (item.sku.startsWith('VIP-')) total -= item.price * 0.1;
  }
  total = Math.round(total * 100) / 100;
  await db.save({ ...order, total });
  sendEmail(order.userId, `订单金额 ${total}`);
}

给 AI 的指令是:"把金额计算抽成纯函数 calcTotal(items),不改任何对外行为,补一组单测。"它产出的 calcTotal 可以独立测试——而原本埋在 checkout 里的折扣逻辑,以前根本测不到。

2. API 替换 / 迁移。 废弃的 moment 换 dayjs、旧 SDK 方法名更新、fetch 加统一错误处理层。这类机械但易漏的重构,AI 比人靠谱得多,人眼扫 50 个调用点一定会漏。

3. 类型补全。 把 any 拍成具体类型、给函数参数补 interface。AI 结合调用方推断类型,再让 tsc 把关,准确率很高。

4. 命名统一 / 死代码删除 / 模式统一。 同一个"用户"叫 user / account / profile 的,让它统一;同一个校验逻辑在五个文件里各写一遍的,抽成一个 util。这类零散活,人懒得做,AI 做得开心。

三、AI 不该碰的地雷区:人主导,AI 最多打下手

另一类重构,上下文全局、行为难验证、错了代价大。这些地方 AI 只能当助手,决策必须是人。

• 大架构调整:单体拆微服务、改状态管理方案、重排模块边界。这类决策依赖业务演进判断,AI 看不到半年后的产品规划,硬给它一个"重构建议",往往是教科书式正确、工程上不可行。
• 性能敏感区:热路径、序列化、缓存层。AI 喜欢把"啰嗦但快"的代码改"优雅但慢"——比如把 for 循环换成链式 filter().map(),多走两遍数组;或者把对象缓存改成闭包变量,顺手引入内存泄漏。
• 并发 / 竞态逻辑:锁的粒度、事务边界、消息顺序。这类 bug 复现都难,更别说靠 AI 凭直觉改。一个看似多余的 await,可能是为了等前一个写操作落盘。

我的原则是:凡是"跑通测试"不足以证明正确的地方,AI 只能提方案,不能直接落代码。 它可以帮你列出"这处重构可能的 3 种风险",但拍板的得是你。

四、安全重构的方法论:小步、测试护栏、行为等价

不管谁来改——人或 AI——安全重构的底层逻辑是同一套,Martin Fowler 二十年前讲过,现在依然成立,AI 只是放大了它。

小步:一次只动一个维度。 别让 AI 在一次改动里"既抽函数又改命名又换 API"。一次一个 diff,每个 diff 都能独立通过测试。这样真出了问题,git bisect 一下就定位到。AI 的倾向是"既然在改了我一起改了吧",你必须用指令把它按住:"本次只做 X,不要动其他任何东西。"

测试护栏:先补测试,再重构。 这是铁律。没有测试覆盖的代码不要让 AI 重构——你拿什么证明它没改坏?正确顺序是:先让 AI 帮你补测试(characterization test,把当前行为锁住),跑绿了,再开始重构。重构后测试还是绿的,才有底气说"行为没变"。

行为等价:重构不是优化。 重构的定义就是"在不改变对外行为的前提下改善内部结构"。如果你想顺手优化性能、改返回值、加新参数——停下来,那是另一个 PR。混在一起,review 没法做,出了问题也没法回滚。

五、喂给 AI 的上下文,决定产出的下限

AI 重构的质量,70% 取决于你喂了什么上下文。只贴一个函数让它重构,它一定瞎改调用方。

一次合格的重构提示,上下文至少包括四块:

1. 被重构的代码(完整,带 import)
2. 所有调用方(让它知道改了签名会影响谁)
3. 现有测试(让它知道行为契约长什么样)
4. 明确约束(保持 API 不变 / 不改对外行为 / 不引入新依赖)

一个可复用的提示骨架:

我要重构 <函数/模块>,目标是 <抽纯函数 / 换 API / 补类型>。
约束:
- 保持对外 API 和返回值完全不变
- 不改变可观察行为
- 不引入新依赖
- 只做这一件事,不要顺手改别的

被重构代码:<贴>
调用方:<贴>
现有测试:<贴>

先告诉我你打算怎么改、影响哪些调用方,确认后再动手。

最后那句"先告诉我方案"很关键——它强制 AI 在动手前做一次影响面分析,你能拦下不靠谱的方向,比改完再 review 省一个来回。

六、Review 重点:盯着 diff,别盯着代码漂不漂亮

AI 生成的代码有个迷惑性:它读起来特别顺。但漂亮的 diff 不等于正确的 diff。Review 时盯四件事:

1. diff 是不是最小。理想的 diff 只动该动的。如果 AI 连带改了 import 顺序、重排了无关函数、统一了无关的引号风格——打回去。越大的 diff 越藏 bug。
2. 行为有没有变。重点看边界:null / undefined / 空数组 / 0 / 负数。AI 最爱"清理"它看不懂的防御性分支——而那往往是前人踩过坑后补的。
3. 有没有顺手改无关的。AI 会偷偷把 >= 改成 >,把 || 改成 ??,把命名"优化"成它觉得更好的。逐行看,这种语义微调才是最危险的。
4. 测试有没有真的覆盖。AI 喜欢写"看起来在测、其实只测 happy path"的测试。检查:边界值测了吗?异常分支测了吗?如果重构前有 bug,这个测试能抓住吗?

一个实用习惯:让 AI 在重构的同时输出"行为可能变化的风险点"清单。它自己列出来的风险你会重点看,它没列出来的你就靠 diff 逐行兜底。

七、完整工作流:从坏味道到安全落地

把上面几节串起来,就是一个可以直接照搬的工作流:

1. 识别坏味道——这段代码长函数、重复逻辑、any 满天飞、调用了废弃 API?先判断它是不是"适合 AI"的那类(第二节),不适合的别硬上。
2. 补测试(护栏)——让 AI 先补 characterization test,把当前行为锁住。跑绿了再往下。没测试就别重构,这是底线。
3. 让 AI 重构——喂足四块上下文(第五节),要求它"先出方案再动手",一次只改一个维度。
4. 跑测试——绿了进下一步,红了让它修,修不好就 git restore,别陪它原地打转。
5. Review diff——盯最小化、行为等价、语义微调、测试真覆盖(第六节)。

从 2 到 5,每一步都是一个"安全阀"。漏掉任何一个,AI 的速度优势都会被后期排查 bug 的成本吃掉。

小结

• AI 降低的是重构的启动成本,不是风险——读代码、找调用方、列影响面这些苦活它接了,但改对改错的判断还得你来。
• 选对场景是第一步:纯函数抽取、API 替换、类型补全、命名/模式统一适合放手交给 AI;大架构、性能敏感、并发逻辑必须人主导。
• 小步 + 测试护栏 + 行为等价是安全重构的三角,缺一个都会翻车。先补测试再重构,是铁律。
• 上下文决定下限:被重构代码 + 调用方 + 测试 + 明确约束,四块喂全,质量才稳。
• Review 盯 diff 不盯漂亮度:最小化、边界、语义微调、测试真覆盖——AI 写得越顺,你越要逐行看。

祖传代码不是不能动,是以前动不起。AI 让"动得起"变成了默认选项——但"动得起"和"动得对"之间,隔着一个有测试、有护栏、有你逐行 review 的工程纪律。