AI 重构是典型的”看着美好、偶尔静默崩”工作流。模型欢快地改名、重构函数、“优化”代码路径——四小时后你发现一个被裁掉的 null check 让生产 checkout 挂了。解法不是不用 AI 重构，而是限制爆炸半径。这套流程给你”AI 重构能用”的四个前提、先 plan 后改的模式、以及周一早上不接到 incident 电话的回滚纪律。
这篇讲什么
什么时候 AI 重构是对的工具：受影响区域有测试、scope 小（单模块或单关注点）、把 AI 当一个必须替自己 diff 辩护的初级工程师。什么时候不是：没测试、跨模块重构、“让这里更干净”这种没有验收准则的请求。
这篇适合谁看
维护真实代码库的开发者（不是 greenfield 原型）、在 deadline 压力下还技术债的工程师、把清理工作交给 AI 助手的 tech lead、没时间撤回烂重构的独立开发者。
什么时候适合用
跨模块改一个概念（变量、函数、类名）。把重复逻辑抽到 helper。收紧类型签名。替换 deprecated API。语法现代化（callback 转 async/await、class 组件转 hooks）。任何”before / after 清晰且测试全绿”的重构。
什么时候不建议用
全项目架构重写。没测试的代码。性能优化（AI 不会测量）。“正确答案”依赖代码库外上下文（合规、运维约束、未来产品方向）的事。
开始前准备
- 确认受影响代码有测试覆盖。让 AI 介入前先跑绿。没测试就先写——重构变成 TDD 练习。
- 干净 commit 快照当前 working tree。AI 重构永远从干净状态开始，
git diff才能精确显示 AI 改了什么。 - 一句话写下重构目标：“把
userService.js里的 callback 风格 fetch 换成 async/await，保留所有公开方法签名”。模糊目标”清理一下”会引发扩散。 - 设时间预算。超过预估 2-3 倍就是 scope 错了——回滚拆分。
具体步骤
- 确认重构区域有测试覆盖。跑绿。记下基线测试命令和输出。
- scope 限制到单模块 / 单文件 / 单关注点。避免”既然在做”的扩张——这是重构回归的最大单一来源。
- 让 AI 先出 plan，先别写代码：“这是文件，这是目标。列出你会做的改动，按顺序，带文件路径。先别写代码。” 这一步以最低成本捕获 scope 漂移。
- 用一句话目标去审 plan。不在路径上的改动直接砍。常见拒绝：“我顺便发现一个无关 bug，要不要修？” — 推迟。
- 增量应用——一次一个逻辑步骤，不要一把推完整个重构。每步跑测试。绿 = commit。红 = 检查。
- 每步
git diff细看。专门看：被删的错误处理、被去的 null / undefined check、“被优化掉”的 guard 子句、改的默认参数、改名的 export。 - 整套重构后不只跑单测，还跑你有的集成 / e2e。重构能过单测但在边界处崩。
第一次实操怎么跑
- 选一个小的、测试齐全的、一直想清理的模块。别选关键路径；别选”既然在做”的乱麻。
- 完整跑一次 plan-then-execute。plan、diff、测试运行都存档当参考。
- 全程计时。数据点是：含 review 开销，这次比手工快了多少？
- 第二次只改一件事：更严的 plan 模板、更小的 scope、或换模型。测差异。
完成后检查
- 所有基线测试通过——和 AI 介入前同一命令。
git diff只有一句话目标隐含的改动。意外改动一律 revert。- 没有未在 diff 里明确说明的”删错误处理 / 删 null check / 删 guard 子句”。
- 公开 API 签名未变（除非这就是目标）。内部调用方没被静默重接。
- 第二双眼睛（人或新开 AI 会话）审 diff。AI 不能稳定发现自己的回归。
怎么复用这套流程
- 把 plan 请求 prompt 存模板：“这是文件、这是目标。列出有序改动、带文件路径。先不写代码。” 丢进 Claude / Cursor / Copilot Chat。
- 建”AI 重构后必查”清单：被删 null guard、被去 try/catch、改默认参数、改名 export。每个 diff 走一遍。
- 留小日志记下”以微妙方式弄崩了”的重构。规律会浮现——你的 AI 在特定区域倾向于过度删。
- 每次模型更新重评估。上季度不安全的可能现在安全（反之亦然）。
建议的操作流程
测试绿 + scope 化目标 → AI plan → 审 plan → 增量执行 → 每步测试 → 集成测试 → git diff 审计 → commit。单模块现代化（callback 转 async/await）含 review 通常 30-60 分钟。
容易踩的坑
- 重构无测试代码——你没有”坏了”的信号。先写测试；重构变安全。
- scope 失控——“既然在做”把 30 分钟重构变 4 小时漂移。岔路推迟。
- 跳 plan 直接写代码——失去在花钱前捕获 scope 漂移的机会。
- 接受 AI”我顺便改了”的礼物——这就是静默回归上线的方式。diff 严格限定到一句话目标。
- 整套重构一个大 commit——拆步骤，bisect 失败成本才低。
- 只信测试——AI 重构能过测试同时在集成边界改变行为。
FAQ
- 没测试的代码库怎么办？: 先给重构区域写测试。重构变成 TDD 练习。在无测试代码上 AI 重构是微妙回归 bug 的最大单一原因。
- AI 能做架构级重构吗？: 现在还不能稳定做。它能提议；你决定。按同样 plan-execute 纪律一块一块来。
- scope 能多大？: 单模块 / 文件 / 关注点。跨模块重构错误会复合；拆开做。
- AI 不理我 plan 改更多怎么办？: 拒绝这次改动、用更严 scope 重 prompt 或换工具。有的助手比别的更守纪律。
- 能让自主 agent 跑重构吗？: 仅当 scope 有限、步骤间有中间 commit、人在每个 diff 上 review。长 agent run 无 checkpoint 是最高风险模式。