为什么重构最容易翻车

AI 编程代理对"结构目标"理解得很好——把三层嵌套拆成中间层、把重复代码抽成公共函数，这类指令它执行得很稳；但对"隐式行为契约"的理解很差：边界条件、执行顺序、副作用、异常路径，这些代码里没写明的行为，它猜错一个就破坏一个功能。

而重构的定义恰恰是"行为不变、结构变好"。于是问题来了：AI 擅长改结构，目标却是保持行为——行为恰恰是最难描述、也最难检查的部分。更糟的是，重构失败的症状往往延迟出现：模块内部结构变了，调用方在完全不同的地方开始报错，等到人发现时，AI 已经基于坏结构继续改了好几轮。所以重构翻车不是 AI 能力问题，是方法问题：缺了"行为检验"的手段，速度和风险就成正比。

四步法

• 第一步，建护栏。重构前先把测试补齐：现有测试要全部跑绿；没有测试的区域，先写特征测试把当前行为固化——哪怕是看起来不合理的"历史行为"也要固化，因为线上系统已经依赖它。这一步没做完，不要让 Codex 动任何结构。
• 第二步，画依赖地图。让 Codex 先只读梳理：模块的入口出口、调用关系、外部依赖、已知风险点，输出一份改动方案（范围、顺序、风险）给你确认，确认后再动写。地图画不清的区域，就是重构要避开的雷区。
• 第三步，分阶段小步改。把重构拆成逻辑单元：先抽公共函数、再换数据源、再删死代码，每个单元完成就跑测试、提交一次（配合分支纪律，见本站 Git 协作一文）。任何一步测试变红，立即停下查原因，而不是带着红灯继续。
• 第四步，行为比对收尾。重构完成不是"测试通过"就完了：做一次前后行为比对——关键路径输出抽样比对、性能基线对比、日志与错误路径检查，确认"结果相同、结构更好"才真正结束。

一个典型场景

假设要重构一个年久失修的结算模块：先让 Codex 只读梳理，发现它同时承担费率计算、税务字段拼接和日志输出三件事，且被十几个调用点直接依赖。方案定为三步：先抽费率计算为独立函数（不动调用点）、再把税务字段拼接迁到新工具类、最后统一日志格式。每一步都有对应测试盯着，第三步做完后发现日志时间格式变了——这在测试里没覆盖，被行为比对抓出来，回退后先补测试再继续。整个过程没有一次大 diff，每步都能解释、都能回滚。

边界与注意

• 重构不是重写。让 Codex"顺便把需求也改一下"是重写事故的起点：需求变更和结构变更混在一起，出了问题分不清是谁引入的。重构期间冻结行为，需求另开任务。
• 测试覆盖不到的地方减速。护栏不完整的区域，重构步子必须更小，必要时先停下来补测试。测试不是重构的负担，是重构的许可证。
• 禁止大爆炸式重构。一次提交几千行 diff 的重构，出了 bug 既无法定位也无法回滚，等于把项目押在 AI 一次猜对上面。diff 越大，重构失败的概率越高。

结论

重构是 AI 编程代理最擅长、也最危险的场景：它改结构快，而重构要求行为不变。把"行为不变"变成可验证的检验——测试护栏、依赖地图、小步提交、行为比对——AI 的速度才有意义。四步法真正费时间的只有第一步和第四步，中间两步 AI 做得又快又稳；这正好是人和 AI 的分工：人管行为契约，AI 管结构改造。

来源：本文为常青实战技巧整理，基于长期使用 Codex 的实操经验，不依赖外部链接；Git 基础概念以 Git 官方文档 为准。最后更新：2026-08-19。