老项目重构，是很多技术团队最想做、也最不敢做的事。代码跑了几年，业务一直加，最初写的人可能早走了。你打开一个文件，里面三千行，既有订单逻辑，又有会员逻辑，还顺手发短信。老板说“这个模块能不能优化一下”，开发心里想的是：能不能别动它。

Claude Code 和 Codex 在老项目里很有用，但用法要克制。它们不应该一上来就“大规模重构”，更不应该把一个能跑的系统改成看起来漂亮但没人敢上线的新系统。正确用法是：先理解、再加保护、再小步迁移。AI 负责帮你读、拆、写、验证，人负责定边界、看风险、拍板上线。

第一件事：让 AI 先当“读代码的人”

老项目的最大问题是信息不透明。你不知道哪些函数被谁调用，不知道某个字段为什么存在，也不知道一个 if 分支是不是历史兼容。这个时候让 AI 直接重构，等于让一个新同事第一天就改核心账本。更稳的做法是让 Claude Code 先阅读项目，输出模块地图。

提示词可以这样写：“请只读代码，不要修改。帮我梳理订单模块的入口、核心服务、数据库表、外部依赖和关键业务规则。对不确定的地方请标注不确定，不要猜。”这里“不要猜”非常重要。老项目里最危险的不是不知道，而是假装知道。

输出结果不一定百分百准确，但它会给你一个起点。你可以拿着这份结构说明去问老员工、对照日志、看数据库，再逐步补全。以前这一过程可能要两三天，现在可以先在一小时内形成草图。

第二件事：先补测试，再谈重构

很多团队重构失败，是因为没有测试。没有测试，所谓重构就是“改完点一点页面”。点页面能发现明显错误，却发现不了边界条件。比如老用户优惠、部分退款、跨月结算、异常重试，这些逻辑如果没被锁住，重构后很容易悄悄变味。

你可以让 Codex 根据现有代码和历史样例补“行为保护测试”。这类测试的目标不是追求覆盖率好看，而是锁住老逻辑。哪怕老逻辑写得不优雅，只要业务依赖它，就先用测试记录下来。等测试稳定，再拆函数、拆类、拆模块。

这里有个大白话原则：先给房子拍照，再装修。测试就是照片。没有照片，你装修完说“应该没变”，别人很难相信。

第三件事：重构要像搬家，不要像爆破

老项目迁移最稳的方式，是一箱一箱搬。先把一个纯函数抽出来，再把一个服务拆出来，再迁一个接口。每一步都能回滚，每一步都有测试，每一步的 PR 都能看懂。AI 很擅长做这种机械但细致的工作，比如把重复的校验逻辑抽成公共函数，把老的回调写法改成统一的异步流程，把散落的配置整理到一个地方。

但你要明确告诉它：不要顺手改风格，不要顺手改命名，不要顺手优化无关逻辑。重构的目标是降低风险，不是炫技。尤其是业务高峰前，不要做大范围改造。AI 不累，人会累；AI 看得快，人评审不过来，风险就来了。

第四件事：让 AI 做迁移文档

很多重构项目上线后没人知道改了什么，过两个月又回到混乱状态。每次迁移结束，应该让 Claude Code 同步写一份简单文档：改动范围、保留逻辑、删除逻辑、测试命令、回滚方式、后续待办。文档不需要长，关键是让后面接手的人看得懂。

这类文档也是 SEO 内容里很容易被用户搜索到的真实痛点：老项目怎么重构、如何避免重构引入 bug、Claude Code 重构怎么用、Codex 代码重构靠谱吗。真正能吸引用户的不是“模型多强”，而是“我这个烂摊子能不能稳一点”。

接入建议：先在非核心模块跑通

如果团队准备把 Claude Code / Codex 放进老项目改造流程，建议先统一入口，再统一规范。想把工具接到智脑API，可以按这份教程文档配置：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg。第一次不要挑支付、余额、权限这种高风险模块，可以从导出、通知、后台查询、报表脚本这类边界清楚的地方开始。

一旦跑通，就把提示词、测试命令、评审标准沉淀下来。后面每个重构任务都复用这套流程，而不是每个人临时发挥。

适合谁用

这篇更适合技术负责人、维护老系统的后端开发、接手历史项目的外包团队，以及准备做系统升级的创业公司。你们的共同痛点是：代码能跑，但不敢改；需求还在加，但地基越来越重。AI 编程工具不是一键翻新老楼，而是帮你把拆墙、加固、验收这些步骤做得更清楚。

最后记住一句话：老项目重构，最重要的不是让代码变漂亮，而是让团队重新敢改它。只要这件事做到，工具的价值就已经出来了。

落地小结：先让一个小场景跑起来

真正开始用 AI 编程工具时，不要一上来就喊口号，也不要让它一次接管整个项目。选一个能看见结果的小场景：一个高频 Bug、一个后台小功能、一个报表脚本、一次 PR 自查，或者一组关键测试。把输入材料准备好，把期望输出说清楚，把验证方式写在提示词里，跑完以后再复盘哪里省了时间、哪里还需要人把关。

只要第一条流程跑通，后面就容易复制。团队可以把有效提示词、检查清单、测试命令和注意事项沉淀成模板，新人照着模板也能上手。AI 的价值不是让大家都去研究参数，而是把那些重复、容易漏、又必须做的步骤固定下来。等这些步骤稳定了，再扩大到更复杂的业务，成功率会高很多。

还有一点很重要：每次试点都要留下结果记录。比如这次节省了多少沟通时间，发现了几个以前容易漏的问题，哪些地方仍然需要人工确认。记录不是为了做汇报好看，而是为了下一次少踩坑。工具本身会变化，但“先定场景、再跑流程、最后验证”的方法不会过时。

所以别纠结第一版是否完美。先让一个真实任务从开始到结束跑完整，再把中间的坑补进模板。能复制的流程，才是团队真正买到的效率。