AI 编程工具越来越强以后，很多人会把旧项目一口气交给 Cursor、Claude Code 或 Codex：帮我整理结构、优化代码、顺便修几个历史问题。这个方向没错，但代码重构最怕的不是 AI 不会改，而是它改得太积极，把还能跑的老逻辑改成了“看起来更优雅、实际上更脆弱”的新逻辑。
所以 AI编程代码重构要有一套更稳的流程：先理解旧项目，再拆小步，再让测试和回滚兜底。你可以把这篇和 AI编程工具专题、老达AI实践专题 一起看，适合个人项目、独立站、小团队后台和长期没人维护的工具库。
先判断：这次到底是不是重构
很多“重构”其实混了三件事：修 bug、改功能、整理代码。对 AI 来说，这三类任务的验收标准完全不同。修 bug 要看问题是否消失，改功能要看新需求是否满足，重构则要看外部行为是否保持不变。
如果你把三件事混在一个提示词里，AI 很容易边整理边顺手改业务逻辑。更稳的做法是先让它回答：
- 哪些文件只是结构整理，不应该改变输出；
- 哪些文件确实存在已知 bug，需要单独修复；
- 哪些需求属于新功能，应该另开任务；
- 这次重构结束后，用什么证据证明“行为没变”。
如果项目结构本来就很乱，可以先参考 AI编程项目结构怎么整理。目录、入口和命名先说清楚，后面的重构计划才不会跑偏。
第一步：让 AI 建一张项目地图
不要一上来就说“帮我重构”。我更建议先让 AI 只读代码，输出项目地图，不允许改文件。项目地图至少包含四块：
- 入口：用户请求、命令行、定时任务、页面路由从哪里进来；
- 核心流程：数据从输入到输出经过哪些模块；
- 高风险依赖：数据库、文件系统、第三方 API、支付、登录权限；
- 现有保护：测试、日志、类型检查、回滚方式和人工验收步骤。
这一步看起来慢，其实是在省后面的返工时间。尤其是旧项目里常有“没人敢删但也没人解释”的代码，AI 如果没有先画地图，很容易把历史兼容逻辑当成废代码。
第二步：把重构目标压到足够小
安全的 AI 重构，不是一次性把项目改漂亮，而是每次只处理一个明确问题。例如：
- 把重复的表单校验提成一个函数；
- 把过长的发布流程拆成读取、校验、上传、发布、检查五步；
- 把散落的配置项集中到一个配置文件；
- 把同步流程改成更清楚的错误返回，但不改变对外接口。
这里的关键词是“小步”。如果一次重构跨了十几个文件，还同时改命名、改目录、改逻辑、改依赖，最后测试失败时你很难判断是哪一步出了问题。对 Cursor 这类编辑器内工具，可以让它局部改；对 Claude Code 和 Codex，可以让它先列计划，再按步骤执行。
第三步：先补测试，再动核心逻辑
旧项目最缺的往往不是“更优雅的代码”，而是“能证明没坏的测试”。在重构前，先让 AI 找出最少但关键的回归用例。比如文章发布流程，至少要覆盖标题、摘要、SEO 字段、特色图、正文结构、内链数量和发布后页面检查；比如订单流程，至少要覆盖价格、库存、重复提交和失败重试。
具体的测试方法可以看 AI编程测试怎么做。如果项目还没有自动化测试，也不要直接放弃，可以先让 AI 写人工验收清单和最小命令检查。重构不是必须一步到位，但每一步都要留下可验证证据。
第四步：让 AI 输出“变更契约”
每次重构前，让 AI 写一段变更契约，明确它承诺什么不变。比如：
本次只整理发布脚本的参数解析和校验逻辑，不改变 WordPress REST API 请求字段，不改变默认分类、标签、文章状态、特色图上传逻辑和错误输出格式。
这个契约很有用。它会迫使 AI 在修改时围绕边界工作，也方便你审稿。重构完成后，再让它逐条对照：哪些承诺满足了，哪些地方确实改变了行为，是否需要单独说明。
第五步：保留回滚点，不要相信一次改对
AI 重构旧项目时，版本管理是底线。每次开始前先确认工作区干净，或者至少知道哪些文件是你自己的未提交改动。重构完成后，不要急着混入新需求，先跑测试、看 diff、记录结果。
如果你还没有形成这个习惯，建议先读 AI编程版本管理怎么做。对个人项目来说，回滚点不一定复杂，可以是一次清晰的 Git 提交，也可以是备份分支；关键是出问题时能退回去，而不是靠记忆手工还原。
Cursor、Claude Code、Codex 怎么分工
三类工具可以各做擅长的事，不要让一个工具从头包到尾：
- Cursor：适合在编辑器里做局部提取、命名调整、类型补全和小范围函数整理。
- Claude Code：适合读较长上下文，梳理项目地图、重构边界和风险清单。
- Codex CLI：适合执行命令、跑测试、修失败、整理 diff 和发布后检查。
如果项目很大，可以先用 AI编程上下文管理 的方法控制输入范围。让 AI 只读相关目录、相关测试和接口说明，比把整个项目扔进去更可靠。
一个可复用提示词
请先只读项目，不要修改文件。为这次代码重构建立项目地图：入口、核心流程、依赖、测试和回滚方式。然后把重构目标拆成 3-5 个小步骤，说明每一步不应改变的外部行为。开始修改前先补最小回归测试或人工验收清单。每完成一步后运行已有检查命令，输出修改文件、测试结果、行为是否变化和可回滚点。
这个提示词的重点不是让 AI “显得专业”，而是把它限制在可控流程里。AI 编程真正适合重构旧项目的地方，是它能快速阅读、提炼重复、补测试和整理记录；不适合的地方，是在没有边界时替你做大量隐性决策。
最后的检查清单
- 这次重构是否和新功能、修 bug 分开了？
- AI 是否先输出项目地图，而不是直接改文件？
- 每一步是否足够小，失败时能定位？
- 是否有测试、命令检查或人工验收清单？
- 是否保留了回滚点和变更说明？
- 是否让另一个工具或人工做过代码审查？
最后一项可以结合 AI代码审查工作流 来做。写代码的 AI 和审查代码的 AI 最好分开角色，避免它只验证自己刚刚相信的路径。对旧项目来说，重构的目标不是炫技，而是让系统更容易维护、更容易验证，也更容易继续交给 AI 协作。
