做后端的，几乎都啃过祖传 Java 项目：变量命名乱、上千行的大方法、SQL 硬编码、SpringBoot2.x 老版本、javax 包，依赖混乱，不敢动，一改就崩。 很多 AI 工具只能改单文件，跨依赖、多文件联动重构直接翻车。我实测用 Codex 做遗留 Java 工程重构，它可以读取整个仓库、梳理依赖链路、批量修改多个关联文件，并且可以在沙箱里执行 Maven 编译、跑单元测试，适合存量 SpringBoot 项目改造。下面全部是落地步骤、提示词、风险卡点，没有虚话。
一、重构前准备（这一步偷懒，后面必翻车）单独拉重构分支，原分支冻结，所有改动只在 feature/refactor 分支，随时可以回滚。先把基线用力补齐。遗留项目大概率单测缺失，优先让 Codex 生成核心业务的单元测试，保证重构前后行为一致。没有测试用例，不要做业务逻辑重构，只能做格式、包名、依赖迁移。仓库精简上传：不要把完整大仓库一股脑丢进去。删掉本地日志、target、.git、配置密钥、敏感 yml。只上传 src、pom.xml。MCP 前置配置（关键） 想要 Codex 读代码、执行 mvn compile、mvn test，需要接入 MCP 服务。我用的组合：代码索引 MCP + Maven MCP，给 Codex 开放只读仓库、编译、运行测试权限，禁止开放生产数据库权限。提醒：Codex 沙箱自带网络限制，本地 MCP 走内网，不要把生产服务暴露给 Agent。
明确重构范围，不要一次性全量重构 优先拆分 4 类低风险任务，按顺序来： ① 清理魔法值、规范变量命名、抽取常量 ② 拆分超长方法，单一职责改造 ③ javax → jakarta、SpringBoot 版本升级、依赖版本迁移 ④ 按领域拆包，把单体逐步拆成模块（这个是最高风险）二、标准重构流程（固定 5 步，我每次都这么跑）第 1 步：让 Codex 先做全局分析，输出评估报告不要上来直接改代码。先让它看懂整个项目结构。 直接复制这段提示词：
你现在是 Java 后端架构师，读取当前 SpringBoot 遗留项目。先不要修改任何代码。
梳理项目模块、包结构、依赖关系； 标记所有超长方法（>100 行）、硬编码 SQL、魔法值、重复代码； 列出所有过时依赖、废弃 API、javax 相关导入； 评估重构风险，区分：低风险（命名、常量抽取）、中风险（方法拆分）、高风险（业务逻辑、数据库相关）； 输出 markdown 评估报告，附带文件路径。
输出报告之后，你先人工审核一遍，确认哪些模块可以动手，哪些模块业务复杂，暂时不动。
第 2 步：低风险批量重构（优先做，见效最快）适用：变量命名、常量抽取、删除死代码、统一日志、消除重复代码。 提示词模板：
只做低风险重构，不修改原有业务逻辑、接口出入参、SQL 执行逻辑。 规则：
所有变量、方法名按照 Java 驼峰规范重命名； 所有魔法数字、固定字符串抽取到常量类； 抽取重复代码为公共工具方法； 日志统一用 SLF4J，替换 System.out； 修改完成后，执行 mvn compile，编译报错就自动修复，编译通过再给我 diff。
这一步 Codex 准确率很高，适合一次性批量处理几十个文件。
第 3 步：中风险：拆分超大方法、抽取 Service遗留项目最常见：一个 Controller 里面几百行，包含参数校验、业务计算、数据库操作。 提示词：
重构文件【填写文件路径】，这个方法太长。 要求：
保持对外接口入参、返回值完全不变； 参数校验抽单独方法，业务逻辑抽 Service； 不要改动原有 SQL、查询条件； 拆分后，为每个新方法生成 JUnit 单元测试； 重构完成自动编译，保证编译通过。
重点约束：对外接口签名不变，这是防止线上出问题的核心。
第 4 步：版本迁移（SpringBoot2→3，javax 转 jakarta）这个是很多人头疼的，包名批量替换，很多注解、包路径连锁改动，人工改很容易漏。 提示词：
本项目从 SpringBoot2 升级到 SpringBoot3，完成 javax 到 jakarta 迁移。 规则：
全局替换 import javax.* → jakarta.*，包括 validation、persistence、servlet； 同步修正 pom.xml 里面 starter 依赖版本； 修正废弃注解、废弃方法； 所有修改完成后执行 mvn compile，出现编译错误自动修复； 输出改动清单，标记所有改动文件。
⚠️ 坑点：很多第三方老 SDK 不支持 jakarta，Codex 会自动改包，但不会识别第三方兼容性，编译过了也要人工核对依赖。
第 5 步：高风险：单体拆包、领域重构（谨慎）不建议直接让 Codex 一次性拆分整个单体。按模块分批：比如先拆用户模块，再拆订单模块。 提示词约束一定要写死：
只重构【用户模块】，其他模块禁止改动。 按照 DDD 分层：controller、dto、service、repository、entity； 原有数据库表结构不变，Mapper、SQL 逻辑不动； 接口保持兼容，不改动返回字段； 重构完成后，生成该模块的单元测试，跑测试。
三、Codex 重构必加的强制约束（不加必踩坑）我踩过很多坑，现在每一条 prompt 底部固定带上：
所有重构，优先保证原有业务行为不变，不是为了写漂亮代码；禁止擅自优化 SQL、修改查询条件、调整事务注解；改动完成必须执行编译，编译失败自动修复，编译不通过不要提交；所有改动输出 diff，标明文件路径；涉及金额、状态流转、订单结算的代码，只做整理，不做逻辑改动；不擅自新增注解、异步、缓存等逻辑。四、实测它搞不定的场景（不要神化）复杂状态机、多线程时序、资金结算逻辑，AI 很难理解隐性业务规则，只能辅助整理，不能交给它重构；大量自定义老框架、内部自研 SDK，没有文档，依赖关系黑盒，容易改错；分布式事务、消息队列回调逻辑，隐性耦合太多；数据库存储过程、复杂多表 SQL，尽量不动。五、落地验收标准（重构完怎么检查）mvn compile 编译无报错；原有单元测试全部跑通；接口入参、返回字段和之前一致；代码评审，重点看 Service、DAO 层改动；上线前做回归测试，核心链路走一遍。六、我的配套工作流我把这套重构流程、MCP 配置、全套提示词做成了 Codex 公开 Workspace，里面还有配套的 SonarQube 检查、自动生成单元测试的 Skill。大家可以直接拿去复刻，不用自己反复调试 prompt。
AI 重构遗留项目，本质是帮你处理海量重复、低价值的代码改动，减少人工查找替换的工作量，架构判断、业务风险把控，依然需要开发自己兜底。
后续我会持续分享 Codex 对接 Maven、SonarQube、数据库审计的实战案例，都是真实项目跑出来的方案。
#codex##ai##程序员#