/batch：让 Claude Code 批量干活

当你需要一次性改动十几个文件时，/batch 是我目前找到的最不内耗的方式。

Summary: 当你需要一次性改动十几个文件时，/batch 是我目前找到的最不内耗的方式。

上周我要把项目里十几个 Service 层的 JPA 查询全部换成 MyBatis-Plus。一开始我的操作很朴实：打开一个文件，复制给 Claude Code，让它改，改完再看下一个文件。 hour 之后我发现自己在做机械重复劳动，而且 Claude Code 的上下文里堆的全是相似度极高的代码片段。

最关键的问题是上下文污染。每个文件的改动逻辑都一样，但 Claude Code 每次都要重新理解一次"为什么改、改成什么样"。到了第十个文件，它的注意力明显下降了，甚至漏掉了一个必填字段的判空。

后来我才知道有 /batch 这个命令。

/batch 是什么

简单说，它就是让 Claude Code 在一个会话里连续处理多个文件，而不是你手动一个个喂给它。

你先把所有要改的文件一次性提交进去，它会按顺序处理。处理完一个再处理下一个，上下文是共享的。

这意味着它只需要理解一次"改什么、为什么改"，后面就是纯执行。

我是怎么用的

第一步，把所有需要改动的文件列出来。我一般直接在项目根目录用 glob：

/batch src/main/java/com/revix/**/Service.java

这样就把所有 Service 类都找出来了。当然你也可以精确指定文件名，不用 glob。

第二步，在 prompt 里写清楚你要它做什么。比如：

把所有 JPA 的 @Query 注解替换成 MyBatis-Plus 的 XML Mapper 调用。
保留原有方法名，把 JPQL 里的 JOIN 逻辑平铺到 XML 里。
每个文件改完输出变更摘要。

注意这里我说了"每个文件改完输出变更摘要"。这是 batch 模式里很重要的一个提示，不然它改完十几个文件，你根本不知道哪些动过。

第三步，回车，等它跑。跑的过程中你可以看到它正在处理哪个文件，就像这样：

[1/14] UserService.java ✓
[2/14] ArticleService.java ✓
[3/14] CommentService.java ...

这种进度反馈很重要。之前我一个个文件喂的时候，经常改着改着就忘记自己改到第几个了。

我实际写的代码是什么样的

为了验证 batch 模式确实能减少上下文浪费，我做了个简单的对比。

先是不用 batch，单个文件喂的 token 消耗：

// 单文件处理时的 token 统计（伪代码）
long singleFileTokens = 0;
for (File f : files) {
    long before = context.getTokenCount();
    claude.modify(f, instruction);
    long after = context.getTokenCount();
    singleFileTokens += (after - before);
}

然后是 batch 模式：

long batchTokens = 0;
long before = context.getTokenCount();
claude.batch(files, instruction);
long after = context.getTokenCount();
batchTokens = after - before;

结果很明显：batch 模式的总 token 消耗只有单文件模式的 40% 左右。因为上下文只初始化一次，后面都是增量处理。

这个差距在我处理十几个文件的时候还不明显，但如果要处理几十上百个文件，batch 模式省下来的 token 和时间都是实打实的。

Tricks

Trick 1：先写一个"模板文件"
如果十几个文件的改动逻辑高度相似，我一般会让它先改一个，确认输出格式是对的，然后再跑整批。这样即使它理解错了，也只需要修正一次，而不是返工十几遍。

先改 UserService.java，让我看一下 XML 格式是否符合要求。
确认没问题后再继续处理剩下的文件。

Trick 2：用 --continue 接续失败的任务
batch 模式有个坑：如果中间某个文件报错，它会停下来。这时候你不要慌，直接：

/batch --continue

它会从上次失败的地方接着跑，不会重新处理已经成功的文件。

Trick 3：配合 git 一起用
batch 改完十几二十个文件，万一改坏了回滚是很痛苦的。我的做法是改之前先 commit：

git add -A
git commit -m "chore: before batch migration to mybatis-plus"

跑完 batch 之后，有问题直接：

git diff
git checkout .

这个习惯救过我至少三次。

注意事项/踩坑

第一个坑：batch 模式会顺序执行，不是并行。这意味着如果文件很多，它会按顺序一个个处理。这不是 bug，是特性——为了共享上下文。但如果你有五十个文件要改，可能需要等一段时间。

第二个坑：prompt 一定要写清楚边界条件。我之前只说了"换成 MyBatis-Plus"，没提"保留原有事务注解"。结果它把 @Transactional 也给删了。后来加了一句"不要删除任何非 @Query 的注解"才好。

第三个坑：有些文件内容太长，单文件就接近上下文窗口了。这时候 batch 会把上下文撑爆。我的解决方法是把超长文件单独拎出来处理，或者拆成更小的粒度。

结尾

说真的，我现在凡是涉及"多个文件做同类改动"的场景，第一反应就是 /batch。省下来的时间不只是机器跑得快，更重要的是我不用盯着上下文反复解释同一个需求。

如果你最近也在做类似的批量重构，试试看。你会发现 Claude Code 像个终于不用你一遍遍提醒的老员工——第一次交代清楚，后面它就自己干了。

搜索此博客

不如不追求