4个AI同时改一个项目，代码改没了？这个被冷落10年的Git功能，成了AI并行编程的标配

源自130位全网作者

18:25

前两天刷到一个帖子：一位开发者同时开两个AI会话改同一个项目，改到一半发现，刚写好的东西突然不见了。小红书不是灵异事件。两个AI进程在同一个目录里改文件，后保存的把先保存的覆盖了。

还有一个更典型的翻车现场：有人一次开了4个Claude Code并行跑，熬夜修好的BUG，第二天构建时又"复活"了——让Claude自己排查才发现，修复的commit躺在4个并行worktree里的某一个，昨晚没合回master，从master构建当然不存在。用他的话说：你以为你是4个Claude的老板，实际上他们在同一个文件夹里互相打架。小红书

如果你已经在用AI编程工具"多开"，或者正心动想试，这两个案例值得停下来看30秒。解法不是新工具，而是一个存在了10年、几乎没人碰的Git自带功能：git worktree。

工具生态为什么突然集体押注并行

先说时效背景。这波热度不是偶然，整个AI编程工具链都在往"多会话协作"方向推：

8月8日，Claude Code上线了一个重大更新：不同的Claude Code会话，现在可以互相聊天了，这个更新18个小时被近500万人看过。知乎
背后是两个新工具：ListAgents负责找到能联系上的会话，SendMessage负责发消息。在此之前，Claude Code已经以实验形式上线了Agent Teams（多会话组队），OpenAI的Codex CLI也在7月正式推出了Multi-agent v2，agent之间可以点对点互发消息。
Cursor走得更直接：Parallel Agents模式会自动帮你创建和管理工作树，多个AI同时开工，完成后一键合并回主分支。知乎

信号很明确：AI编程正在从"一个会话干一件事"走向"多个会话并行协作"。但工具只解决了"会话之间怎么说话"，没解决更底层的问题——多个会话同时写同一个目录，物理上就会打架。

worktree解决的不是分支问题，是目录问题

很多人的第一反应：给每个AI分一个分支不就行了？

不够。分支解决的是版本隔离，不是工作目录的并行。Git的默认规则是：一个仓库只有一个工作目录，git checkout切到哪个分支，整个目录的内容就变成哪个分支。两个Agent同时跑，一个要改A分支的代码，一个要改B分支的代码——一个目录根本摆不下。用git stash来回暂存恢复？两个AI进程同时改东西，stash只会乱成一锅粥。

worktree的思路很直白：让一个仓库同时展开多个工作目录，每个目录各自检出一个分支。

这真不是什么新特性。Git worktree自2015年随Git 2.5正式发布以来一直是Git的内置命令，冷坐了10年——毕竟人一次只能写一份代码，切分支足够用了。知乎直到AI Agent不需要睡觉、还能一次开好几个，这个老功能才终于等来了自己的杀手级场景：

所有worktree共享同一份.git对象库，就像同一棵树上长出的枝干共享根系，不用像多次clone那样重复存几份完整历史，大仓库能省下可观磁盘；
提交互相可见：一个worktree里commit了，另一个立刻能merge或检出，不用像多个clone那样来回push/pull同步；
Git还带一层强制保护：同一个分支不允许同时被两个worktree检出，直接杜绝"两个进程改同一个分支"的混乱。

三种并行方案怎么选

把主流做法摊开对比一下：

方案	能否并行	磁盘开销	主要代价	适合场景
单目录+stash切分支	只能串行	零额外	AI互相覆盖，stash混乱	单人单任务，不适合Agent并行
多次clone仓库	可以	完整历史×N份	大仓库磁盘翻倍，副本间同步麻烦	小仓库，图简单直接
git worktree	可以	只增加工作区文件	依赖、.env要重新装	中大仓库，单机多Agent并行

小红书评论区有条很实在的留言，说代码库小的、一两百M这种，clone最方便省事，直接物理隔离。小红书小仓库真没必要上花活；但如果你的.git目录就有好几个G，worktree的优势会非常明显。

最小用法，就四条命令

假设你的项目在my-app目录，想让两个AI同时开工：

```

创建工作树，顺便各建一个新分支

git worktree add -b feature-login …/my-app-login
git worktree add -b feature-search …/my-app-search

看当前所有工作树

git worktree list

干完合并后，删掉工作树

git worktree remove …/my-app-login

如果手动删过目录，清理残留元数据

git worktree prune
```

之后my-app、my-app-login、my-app-search三个目录并排存在，每个目录开一个AI会话，各自独立运行、独立编译，互不干扰。

高赞帖《让4个Claude给我打工》里有个可以直接抄的落地方式：作者在CLAUDE.md里写了一条铁律——AI进会话先用pwd自检，在主仓库就自动建worktree再开工，干完活给出选项菜单。用他的话说：自己习惯一点不改，AI自觉走完。小红书

爆款文章不告诉你的四个坑

泼冷水时间。吹worktree的文章很多，把这四个坑说全的不多。worktree解决的只是工作目录隔离，运行环境和任务边界它管不了。小红书

1）被Git忽略的文件不会自动出现。 node_modules、.env、本地生成的文件都不在Git追踪里，新worktree里全是空的。常见结果是代码检出成功，项目因为缺环境变量跑不起来。建议用pnpm这类能复用全局存储的包管理器，建worktree时顺手复制.env模板。

2）开发服务会抢端口。 两个worktree同时跑dev，都会去占默认端口。成熟做法是用post-checkout钩子自动分配端口，或者干脆写个脚本把"建worktree+装依赖+配环境+分端口"一条命令搞定。

3）目录隔离不等于没有合并冲突。 这是最容易误解的一点：两个AI各自安静干活，不代表不打架——如果它们改了同一个模块，冲突只是从"开发时"推迟到了"合并时"，合并时还是得人工决定保留谁的代码，所以拆任务有个原则：尽量让不同的AI改不同的文件，按文件归属拆。知乎今天知乎上还有人问Git什么时候能出个智能合并，看了一圈回答，合并冲突这道坎目前还是得人来迈。知乎

4）多仓库submodule架构先缓一缓。 Git官方文档明确指出：多worktree场景下的Submodule支持仍不完整，并不推荐对superproject进行多重检出。知乎

百度团队就在生产环境里趟过一遍：他们给多仓库平台加worktree时，只能自己写脚本把建worktree、初始化子模块、分配端口固化成确定性流程；还遇到过两个Agent同时生成相同需求编号的并发冲突，最后靠"git创建同名分支会失败"这个特性做互斥才解决。知乎他们总结的三条经验值得抄：Agent负责理解需求和编排，脚本负责确定性操作；用Git自带的失败保护比自造锁更稳；本地Git引用只能管住单机并发。

决策树在这里

刚入门、仓库很小（几百M以内）：多clone几份，简单粗暴有效；
中大仓库、单机跑多个Agent：git worktree是标准答案；
不想记命令：Cursor这类工具的Parallel Agents模式已经自动管理worktree，直接用；
多仓库submodule、团队协作：先脚本化流程再上，否则别急着碰；
最后提个醒：社区也有开发者在跑过几百个worktree后公开复盘，宣布放弃这套玩法。小红书也有人吐槽codex+worktree每改个功能就新建一个worktree，但桌面端切工作区又切不了，一个项目搞着搞着成了三个。小红书翻一下细节，问题大多不在工具，而在任务没拆对、工作流没配好。别神化，也别因噎废食。