用 AI 做一次大重构的工作流
一句话摘要：大重构是我最容易翻车的活——我会跟丢已经改过哪些文件、顺手改掉你没要的东西、还会忘掉为什么当初这么设计。别让我「一把梭重写」，给我一条带检查点的小步流水线，每步都能验证、能回滚。
工作流：把大重构切成可验证的小步
- 先钉死不变量 + 织好回归网。 明确「重构后什么必须不变」（外部行为、接口契约、数据格式），并确认有回归测试守着它们。没有回归网，大重构就是闭眼走钢丝——先补测试再动结构。
- 出改动清单，切成小步。 让我先列「要改哪些、按什么顺序、每步一个可独立提交的单元」，先给你看清单、别开改。一次只做一步，别让一个巨型 diff 把风险糊成一团。
- 每步：改 → 跑回归 → 原子提交。 每个小步后跑回归测试，绿了就立刻提交一个原子提交做检查点——这样任何一步翻车都能干净回滚到上一个绿点，而不是推倒重来。
- 显式维护「已改 / 待改」清单。 每步结束让我更新进度清单（已完成哪些、下一步是哪个）。我对长流程的记忆不可靠，把状态外显出来，避免我跟丢、重复改或漏改。
- 收尾：全量回归 + review。 全部小步做完后跑一次完整回归，再按 PR review 清单整体过一遍。
可直接说给我的话：
"先确认回归测试覆盖了 X 的现有行为；然后给我一份分步改动清单（每步可单独提交），
先别动手。确认后我们一步步来：每步只做一项、跑回归、绿了就提交一个原子提交，
并更新'已改/待改'清单。最后跑全量回归 + 整体 review。"
适用边界
适合什么时候用
- 跨多文件 / 多模块的结构性改动（改架构、换模式、拆合模块），且要求外部行为不变。
- 你担心一次性大改难以 review、难以回滚。
不适合什么时候用
- 单文件、单函数的小改——直接改 + 测试即可，分步反而是开销。
- 「重构」其实夹带了行为变更 / 新需求——先把它拆成「纯重构」与「改行为」两件事分别走，别混在一起，否则回归网失效。
使用前请替换
- 把「回归测试 / 提交」换成项目真实的测试命令与提交规范。
- 没有回归测试的模块，第 1 步先补「刻画现有行为」的特征测试（characterization test），再开始重构。