获课：shanxueit.com/12558/

开发者经验分享：Codex 重构老旧项目的效率提升技巧

接手一个五年前的老项目是什么感觉？我的比喻是：像推开一扇很久没开过的门，灰尘扑面而来，里面堆满了不知用途的零件，线路缠绕得像一窝蛇。半年前我就在这样一个 PHP 项目中挣扎，直到我让 Codex 加入战场。不是把它当神供着，而是当个得力助手，这篇文章聊聊我摸索出来的实用技巧。

第一次碰撞：从“这写的什么”到“原来如此”

坦白说，刚开始我对 AI 重构老项目是存疑的。老代码最让人头疼的不是语法旧，而是那些只有原作者才懂的隐晦逻辑——为什么这里要加一？为什么这个函数有两百行且没有注释？我试着把一段最令人费解的函数扔给 Codex，描述了一下上下文，它给出的解读居然八九不离十。那一刻我意识到，AI 读代码的耐心远胜于我，它不会因为看到烂代码就血压升高。

我的第一个技巧就来自这次经历：用 Codex 做代码解读和文档生成。拿到一个陌生模块，先让 Codex 总结它的职责、依赖关系、潜在的副作用，相当于白得了一份即时生成的维护文档。看懂之后，重构才有了底。

三个让我效率倍增的使用习惯

习惯一：先写测试，再用 Codex 落地。 重构最怕改出 bug 而不知。我会先把期望的行为用测试用例描述清楚，然后让 Codex 在保持测试通过的前提下优化实现。Codex 生成的代码未必一次过，但有了测试兜底，迭代修改的成本极低。这比我以前“手改到手软，然后提心吊胆上线”的流程快了不知道多少倍。

习惯二：把“迁移计划”喂给 Codex。 老项目重构通常有大致的步骤，比如“先升级框架版本，再替换数据库层，最后拆分控制器”。我把这个计划写成一个粗粒度的清单，让 Codex 帮忙拆解成具体可执行的改动点。它甚至会提醒我哪些改动有依赖顺序，哪些文件需要同步修改。这就相当于一个熟悉整个代码库的副驾驶在帮你做项目规划。

习惯三：善用“对比模式”。 遇到一段逻辑可疑的旧代码，我会让 Codex 生成两个版本的重构方案——一个激进（完全重写），一个保守（局部修缮）。然后对比阅读，结合业务风险选择合适的那一个。这个过程中，我学到的比单纯接受一个方案要多得多，因为差异本身就是教材。

那些 AI 帮不了我的事

我必须说一个真实体会：Codex 在处理老项目的框架级耦合时，表现并不稳定。比如一个类同时承担了 MVC 三层的职责，AI 倾向于给出“正确但理想化”的解耦方案，却忽略了我们暂时不能动其他模块的现实约束。后来我学会了分阶段引导——第一轮只做接口层面的兼容重构，第二轮再深入内部优化，把大问题拆成小步骤，Codex 的表现立刻稳定了许多。

还有一个盲区是业务语义。老代码里充斥着只有业务才懂的缩写和魔法数字，Codex 会基于上下文猜测，但猜错的时候不少。我会在 prompt 里显式标注这些业务名词的含义，甚至用一两句话描述这个模块在真实业务中扮演的角色。给 AI 足够的业务语境，它的输出质量会上一个台阶。

人和工具的关系

半年前我花了整整三周才完成一个模块的重构，现在同样的工作量大约一周可以收工。这省下来的时间不是用来摸鱼的，而是用来做更重要的代码审查和架构思考。

我越来越觉得，Codex 这类工具真正提升的不是我的打字速度，而是我的思考效率。我不再需要把精力耗在“这个老函数到底在干什么”的考古工作里，而是可以把注意力集中在“这个模块应该长成什么样”的设计问题上。重构的本质不是把旧代码换成新代码，而是把隐藏在代码里的业务逻辑梳理清楚、表达干净。Codex 帮我扫除了表达路上的障碍，但梳理的方向和质量，最终还是我的责任。

如果你也正准备用 AI 工具重构老项目，我的建议是：大胆用，但别全信。把它当成一个读过全部源码但不懂业务的实习生，你负责指挥、校对和兜底。这样的人机配合，效率才会有真正的提升。