Codex 重构代码时，如何避免越改越大

“帮我重构这段代码”是一个危险提示词。因为重构的空间几乎无限：可以改函数名、目录、依赖、抽象层、错误处理，最后一个 100 行的小修改可能变成几十个文件的变化。

如果你只是想改善局部代码，必须给 Codex 加边界。

例如：

只重构 payment/service.go 中的支付结果处理逻辑。
目标是降低重复代码和圈复杂度。
不要修改对外接口、数据库结构和包名。
不要引入新依赖。
修改范围尽量控制在 3 个文件以内。
现有测试必须全部通过。

如果是大型重构，最好拆成多个可验证阶段：先补测试，再抽函数，再调整目录，最后清理旧代码。一次完成全部重构，出了问题后很难判断是哪一步导致的。

还可以要求 Codex 先给“最小改动方案”和“彻底重构方案”，然后你选择前者：

先给两个方案：
A. 最小风险重构；
B. 架构级重构。
默认不要修改代码。

对于生产项目，通常 A 更适合日常迭代。

重构的本质是“行为不变，结构更好”。因此验收时不要只看代码是不是更漂亮，还要让 Codex 运行原有测试，必要时补充针对旧行为的回归测试。