有人每个月在Claude Code上烧数万美元。不是因为他们用AI写了多少代码，而是因为他们同时跑着十几个Claude Code实例，7×24小时，每个实例各干各的，互不干扰。

一个让人头疼的问题

做开发的人都遇到过这种情况：

Claude Code正在帮你处理一个复杂的重构任务，跑到一半，来了一个紧急Bug，必须今天修。你不能直接切分支——git checkout会把整个工作区的文件状态都切过去，打断正在进行的任务，所有上下文全毁。

等重构跑完再处理Bug？紧急的事情不等人。

这个问题，Git在2015年就有了解法。只是大多数人不知道，或者说，直到Claude Code出现，才知道它为什么重要。

这个解法叫git worktree。

从"老式收音机"到"摆满收音机"

用一个比喻来解释。

传统的git checkout，就像一台老式收音机。你的项目目录在任何时候，只能锁定一个频道——一个分支。想换台，你得先停掉正在播的节目，重新调频，然后还要等一段时间缓冲（npm install，重新编译）。

git worktree不一样。

它让你从同一个.git仓库出发，在外面摆上一排收音机——每台收音机锁定一个不同的频道，各自播放，互不干扰。想听哪个就听哪个。关掉一台，对其他的没有任何影响。

技术原理只有一句话：git worktree让你能同时在文件系统里检出多个分支，把时间上串行的操作，变成了空间上并行的存在。

所有工作区共享同一份git历史，但文件互相独立，分支互相独立，跑在里面的Claude Code实例也互相独立。

三个命令，开启并行

假设你今天需要同时处理两个独立任务：issue-12是个Bug，issue-13是个新功能。

第一步：设置

echo "worktrees/" >> .gitignore
mkdir worktrees

把worktrees/这个容器目录加进.gitignore，防止它本身被git追踪。里面每个工作区的文件仍然完整受git管控，不受影响。

第二步：为每个任务开一个工作区

git worktree add worktrees/issue-12 main
git worktree add worktrees/issue-13 main

这两行执行完，你就有了两个独立的文件目录，都基于main分支，但完全隔离。

第三步：分别启动Claude Code

# 进入issue-12目录
cd worktrees/issue-12
git checkout -b fix/issue-12
claude
# 交代任务，让它跑

# 不等它跑完，打开新终端
cd worktrees/issue-13
git checkout -b feat/issue-13
claude
# 交代另一个任务

两个实例同时在跑。你可以随时cd进去看进展，也可以去干别的事情。

等issue-12的review意见回来，再进那个目录，所有文件状态都在，上下文没丢。改完提交，再回到issue-13继续。

整个过程没有等待，没有切换成本，没有"我刚才做到哪了"的迷失感。

一个人管理多个AI，是真实可行的

当你能同时跑三个Claude Code实例，你就不再是一个开发者，你是一个小团队的leader：

• 一个实例在修Bug
• 一个在写新功能
• 一个在做文档

你在几个工作区之间来回切换，做的事情是：看进展，拍决策，给方向，处理卡点。

这和管理一个三人团队，在结构上没有本质差别。

差别在于：你不需要开会，不需要等人，不需要担心沟通成本。

并行的前提

当然，这也意味着你对每个任务要足够清楚——说不清楚的任务，AI也做不好。

并行的前提是：

• 每个任务有独立的边界
• 清晰的目标
• 明确的交付物

模糊的需求交给并行工作流，会乘以三倍混乱。

Git本来就是为了协同设计的

有一个细节很有意思。

git worktree不是为AI设计的。它是2015年Git 2.5里加的功能，当时是为了解决人类团队的分布式协同问题——多人同时在不同分支上工作，避免互相干扰。

现在，AI来了，同样的问题出现了：多个AI实例同时在不同任务上工作，如何避免互相干扰？

答案还是一样的：worktree，隔离，并行，最后集成。

从人人协同，到人机协同，底层逻辑没有变过。

试一次就会上瘾

下次当你在等Claude Code跑一个耗时任务的时候，不要干坐着。

开一个新worktree，启动第二个实例，把另一个任务也交出去。

串行变并行，一倍时间，两倍产出。

---

这件事给我一个启发：现有的工具和概念，很多都可以直接迁移到AI工作流里，不需要发明新轮子。提高效率的很多机会，藏在"换个方式用旧工具"这件事里。