用 Claude Code 做大型重构不翻车：分批+Git 兜底+验证闭环的实战流程（2026）

让 AI 改一个函数，谁都会。让它重构一个上千行、跑着线上业务的老模块还不出事------这才是真本事。

这是《Claude Code 从入门到精通》专栏的硬核实战篇。很多人栽在这里：兴冲冲让 Claude Code "把这个模块重构一下"，结果它一口气改了十几个文件，测试全红，自己都不知道哪步改坏的，只能 git reset 全部丢掉重来。我用这套流程做过好几次几千行级别的重构，没翻过车。核心就三件事：分批、Git 兜底、验证闭环。下面拆开讲，每步给具体命令和话术。

一、先认清：大型重构为什么会翻车

不是模型不行，是人把它当神用。大型重构翻车的三个真实原因：

一次让它改太多------上下文一长，它会"忘记"前面的约束，越改越飘。
没有兜底------改坏了没法干净回退，只能整体推倒。
不验证就往下走------前一步其实已经改错了，它却接着在错的基础上改，错误滚雪球。

对症下药，就是下面这套 SOP。

二、重构前的三个准备动作（缺一不可）

1. 必须在干净的 Git 状态下开始

这是铁律中的铁律。没有 Git 的项目，别让 AI 做大重构。

bash 复制代码

# 确认工作区干净
git status
# 如果有未提交的改动，先提交或暂存
git add . && git commit -m "chore: checkpoint before refactor"
# 开一个专门的重构分支，别在主分支上搞
git checkout -b refactor/order-module

有了这个，无论它怎么改，你一条命令就能回到原点：

bash 复制代码

git checkout .        # 丢弃所有未提交改动，回到上次 commit

2. 先让它"读懂"再动手

直接让它改是大忌。先让它把现状讲给你听，确认它真的理解了：

复制代码

先别改代码。读一下 src/order/ 这个模块，告诉我：
1）它现在的核心职责和数据流是什么；
2）你觉得有哪些问题；
3）如果要重构，你打算分几步、每步做什么。
等我确认方案后再动手。

它给的方案你过一遍------这一步能提前发现它理解错了，比改完才发现强一百倍。

3. 把重构目标和约束写进 CLAUDE.md（或对话置顶）

markdown 复制代码

## 本次重构约束
- 只重构 src/order/，不碰其它模块
- 保持对外接口签名不变（别人还在调）
- 每改完一个文件就停下来，等我确认再继续
- 改完每一步都要能通过 pnpm test

上一篇专栏讲的 CLAUDE.md 写法，在这里就是救命的。约束写清楚，它才不会越界。

三、核心流程：分批改 + 每批验证（带话术）

重构的精髓是把大象切成块，一块一块吃，每吃一块称一次体重。

第 1 步：让它制定分批计划

复制代码

按你刚才的方案，把重构拆成 4-6 个独立的小步骤，
每步只动尽量少的文件，每步做完都应该能跑通测试。
先把步骤列出来，我们一步一步来，我说"下一步"你才做下一步。

让它列出来，比如：

步骤 1：抽出数据校验逻辑到 validators.ts
步骤 2：把 3 个重复的查询合并成一个 service 方法
步骤 3：拆分超长的 handleOrder 函数
......

第 2 步：一次只做一步，做完立刻验证

复制代码

执行步骤 1，只改这一步涉及的文件，改完告诉我动了哪些文件。

它改完后，你立刻做验证闭环（下一节详细讲）。验证通过了，才提交这一步：

bash 复制代码

pnpm test                              # 绿了再往下
git add . && git commit -m "refactor: extract order validators (step 1/5)"

每一步一个 commit 。这样万一第 3 步改坏了，你 git reset --hard HEAD~1 只丢第 3 步，前两步的成果还在。

第 3 步：重复，直到改完

每步都"改 → 验证 → 提交"，稳扎稳打。一步出问题，损失最多就是一步，永远不会满盘皆输。

四、验证闭环：怎么确认它真的没改坏

光看测试绿还不够。一套完整的验证闭环：

1. 跑测试（第一道闸）

bash 复制代码

pnpm test

让 Claude Code 自己跑也行：帮我跑测试，红了把原因和修复方案告诉我，先别改。注意是"先别改"------先看它怎么解释，确认它没在乱修。

2. 看 diff（第二道闸，最重要）

bash 复制代码

git diff

亲眼过一遍它改了什么 。重点看：有没有动你没让它动的文件？有没有偷偷删掉某段逻辑？接口签名变了没？这一步是 AI 重构里最不能省的------测试覆盖不到的地方，只有你的眼睛能抓。

3. 类型检查 / lint（第三道闸）

bash 复制代码

pnpm typecheck && pnpm lint

4. 关键路径手动冒烟

对核心功能（比如下单流程）手动点一遍或跑一个端到端用例，确认行为没变。

四道闸全过，这一步才算真的稳。

五、翻车时的急救（怎么干净回退）

即便再小心也可能出问题。按损失从小到大：

bash 复制代码

# 1）只是当前这步改乱了，还没 commit ------ 丢弃未提交改动
git checkout .

# 2）当前步已 commit 但发现是错的 ------ 退回上一步
git reset --hard HEAD~1

# 3）想看看是哪一步引入的 bug ------ 逐步回退对比
git log --oneline          # 看每步的 commit
git checkout <commit-hash>  # 跳到某一步的状态验证

# 4）整个重构分支都不要了 ------ 回主分支，分支一删了事
git checkout main
git branch -D refactor/order-module

因为我们每步一个 commit、在独立分支上搞，所以无论哪步出事，回退都是干净的、可控的。这就是"Git 兜底"的全部意义。

六、踩坑总结（真实报错与根因）

坑 1：它在重构中途"擅自扩大范围"。

现象：你让它拆函数，它顺手把整个文件的命名风格也改了。根因：约束没写死。解法：CLAUDE.md 里明确"一次只做被要求的事"；发现跑偏立刻 git checkout . 回退，重新更窄地下指令。

坑 2：测试绿了但行为变了。

现象：测试通过，上线却出 bug。根因：测试覆盖不全，而你跳过了 git diff 人工审查。解法：diff 这一步永远不能省，尤其是涉及边界条件和错误处理的改动。

坑 3：上下文太长，它"忘了"前面的约束。

现象：改到第 4 步，它又开始用你早就禁止的写法。根因：会话太长，约束被稀释。解法：每完成一个大阶段 /clear 清一次上下文，重新喂一句当前约束再继续；或干脆开新会话接着干。

坑 4：token 烧得快。

现象：一次大重构账单肉疼。根因：把整个大模块反复塞进上下文。解法：分批本身就省 token（每步只给相关文件）；让它读文件时指明具体路径，别让它全项目扫。成本控制我单独有一篇，专栏里能找到。

七、小结：一张流程图记住全部

复制代码

干净 Git 状态 + 开重构分支
        ↓
让它先读懂 + 给方案（你确认）
        ↓
拆成 4-6 个小步骤
        ↓
┌─→ 执行一步（只动必要文件）
│        ↓
│   验证闭环：测试 → git diff → typecheck → 冒烟
│        ↓
│   过了 → git commit（一步一个）
│        ↓
└─── 还有步骤？回到上面
        ↓
全部完成 → 合并回主分支

记住核心三件套：分批（切小）、Git 兜底（一步一 commit、独立分支）、验证闭环（测试+diff 缺一不可）。做到这三点，几千行的重构你也能让 AI 干、还睡得着觉。

建议收藏本篇 ，下次接手老代码重构直接照这套流程走。本专栏《Claude Code 从入门到精通》会持续更新进阶实战------下一篇讲Claude Code 的 token 成本控制，把账单压到最低的 7 个实操。重构中遇到过什么坑，欢迎评论区分享，我会把典型问题补进文章。