用 AI 做代码重构：安全改结构的实战法

重构不是重写，是在不改外部行为的前提下让内部结构更合理。它枯燥、易出事，却是还技术债最靠谱的手段。 AI 编程助手擅长读懂旧代码、提出改法、补测试，但它分不清「能跑」和「改对了」——人必须守住行为不变的底线。本文给出用 AI 做代码重构的实战流程：怎么拆、怎么验证、哪些事必须人来拍板。

先把「重构」和「重写」分开

重构的前提是行为不变：输入输出、副作用、性能预算都维持原样，只动内部结构。如果你其实想换语言、换框架、换架构，那是重写，风险等级完全不同。和 AI 辅助做 JS 到 TypeScript 迁移 一样，凡是涉及语义变更的，都要当成迁移项目单独立项，而不是夹在重构里顺手做。先给本次重构划一条清晰的边界：只做哪几件事，明确不做哪些。

让 AI 先画「地图」再动手

动手前让模型先把目标模块的调用关系、依赖、边界画出来。它读得快，能帮你定位「谁在用它、它又依赖谁」，这正是手动重构最容易踩坑的地方。把这份地图当成检查清单：每改一处，对照它确认影响面。不要一上来就让 AI 直接给改完的代码——没有地图的重构等于蒙眼拆房子。

小步提交，每步都可独立回滚

把一次大重构拆成一系列能独立通过测试的小改动：提取函数、改名、内联、拆类，每一步都单独提交。这样哪一步出问题，git 直接回退那一步即可，不用全盘推翻。 AI 很适合做这种机械、重复的「提取/改名/搬移」动作，但它每做一步你都要跑一遍测试。小步快跑，比一次大改然后 debug 三天省事得多。

用测试把「行为不变」钉死

没有测试罩着，重构就是赌运气。理想顺序是：先补 characterization test（刻画当前行为的测试），确认绿了，再开始改；改完测试仍绿，说明行为没变。 AI 可以帮你把读代码、写用例、跑通的循环大幅压缩，就像 AI 代码审查工具 能快速指出隐患一样，但它写的测试只覆盖它能看到的表面行为，边界和异常分支要靠你补。测试不绿，宁可停下，也别带着红测试继续改。

性能与副作用是隐藏雷区

结构变好，性能未必变好。把循环里的计算抽出成函数、把内联判断改成虚调用，可能悄悄引入几十毫秒的退化。重构前后要用 AI 做代码性能剖析 对比关键路径，确认没有退化。同样危险的是副作用：原本在函数内悄悄修改了全局状态，抽出来后顺序变了就可能出 bug 。凡是涉及 IO 、全局变量、定时器的改动，都要单列一条回归检查。

常见问题