榨干 AI 效率，优雅的 AI 并行开发技巧

AI 不是不够快，是你的工作流只允许它一次干一件事。Git Worktree 让你的项目从单行道变成多车道，每个 AI 各走各的，互不干扰。

上周，AI 正在帮我重构一个组件。进度条缓慢推进，预计还要 3 分钟。

我盯着屏幕，脑子里想的全是：另一个需求的接口层也可以同时改啊。于是我开了第二个 AI 会话窗口，让它去改接口层。两边同时跑，效率翻倍，完美。

直到我准备合并代码的那一刻。

两个 AI 都动了同一个配置文件。满屏红色冲突标记，解冲突花了半小时。比让 AI 排队干还慢。

问题出在哪？

想明白之后，答案很简单：两个 AI 会话共用了同一个工作目录。

它们改的文件确实大部分不重叠，但只要有一个公共文件被双方碰过，就会打架。这就像两个厨师共用一个灶台，各做各的菜没问题，但只要同时伸手拿调料瓶，就撞上了。

而且这个问题不只出现在个人开发中。

团队开发时更明显。需求单都是独立的，大家本来就习惯用 git branch 各自开分支。但如果你想让 AI 帮你在不同分支上同时开发不同的需求，就会非常别扭。AI 没法在同一个工作目录里同时 checkout 两个分支，你要么频繁切分支，要么 clone 多份仓库。

前者打断工作流，后者浪费空间和时间。

我一度觉得，这大概就是 AI 并行开发的天花板了。

直到我发现 Git Worktree

Git 里有一个存在很久、但大多数人没用过的功能：Worktree（工作树）。

一句话解释：它可以让你为同一个仓库创建多个独立的工作目录，每个目录对应一个不同的分支。

my-project/              ← 主目录，在 main 分支
my-project-feat-a/       ← Worktree 1，在 feature/a 分支
my-project-feat-b/       ← Worktree 2，在 feature/b 分支

这三个目录是完全独立的文件系统，互不干扰。但它们共享同一个 .git 对象数据库。提交历史、远程仓库配置、钩子全部共享，不会出现"两份代码配置慢慢漂移"的问题。

和 git clone 多份仓库相比，Worktree 的优势很明显：

• 创建速度快：几乎瞬间完成，不需要重新下载整个仓库
• 几乎不占额外空间：共享对象数据库，只多了工作区的文件副本
• 配置不漂移：远程仓库、钩子、Git 配置全部共享

说白了，Worktree 就是让你在一个仓库里同时"打开"多个分支，每个分支有自己的目录，互相看不见。

发现它的那一刻，我就意识到：这不就是给 AI 并行开发量身定做的吗？

实操：两分钟上手

基础命令速查

# 查看当前所有工作目录
git worktree list

# 为已有分支创建新工作目录
git worktree add ../feat-login feature/login

# 创建新分支 + 新工作目录，一步到位
git worktree add ../feat-payment -b feature/payment

# 在某个特定 commit 上创建工作目录（只读排查场景常用）
git worktree add --detach ../investigate abc1234

就这么几条命令。没有复杂的配置，没有需要记的参数。

场景一：个人 AI 并行开发

你手上有三个需求要同时推进。打开终端：

git worktree add ../my-project-feat-a -b feature/a
git worktree add ../my-project-feat-b -b feature/b
git worktree add ../my-project-fix-bug -b fix/bug-123

现在你有四个完全独立的项目目录。打开多个 AI 编程窗口，每个窗口指向一个目录，让它们各干各的。

改同一个文件？没关系，它们在不同的目录里，根本碰不到彼此。

各自改完之后，回到主目录正常合并：

git merge feature/a
git merge feature/b
git merge fix/bug-123

如果合并时有冲突，那是正常的代码逻辑冲突，你可以从容处理。而不是两个 AI 在同一份文件上乱改造成的混乱。

场景二：团队多分支开发

团队里每个人各自开了分支做不同需求，你负责修一个线上 bug。

传统方式：git checkout 切来切去，AI 的上下文全丢了。

Worktree 方式：

# 为 hotfix 单独开一个工作目录
git worktree add ../hotfix-2174 -b hotfix/2174 origin/release/1.2

# 在 hotfix 目录里让 AI 修 bug，主目录继续开发新功能
cd ../hotfix-2174
git commit -am "Fix null check in payment total"
git push -u origin hotfix/2174

# 修完了，回主目录继续手头的活
cd ../my-project

不用切分支，不丢上下文，每个需求都有自己的"房间"。

AI 编程工具已经在用这个方案了

这不是我一个人折腾出来的野路子。

Cursor 最近发布的 Parallel Agents 功能，底层就是用 Git Worktree 实现的。每个并行 Agent 自动运行在独立的 Worktree 和分支上，提供三个关键保障：

• 文件隔离：每个 Agent 的文件编辑和暂存区完全独立，不会互相覆盖
• 高效创建：Worktree 比 clone 快得多，几乎没有额外空间开销
• 历史可追溯：每个 Agent 的分支清晰记录了它做了什么改动

这意味着行业已经在朝这个方向走了。即使你现在用的工具还不支持自动并行，手动用 Worktree 一样能达到同样的效果。

用完记得收拾

Worktree 用完后别忘了清理，否则目录会越攒越多：

# 删除不再需要的工作目录
git worktree remove ../feat-login

# 如果目录已经被手动删了，清理残留的元数据
git worktree prune

# 可选：删除已合并的远程分支
git push origin --delete feature/login

养成习惯：需求合并后，顺手 remove 对应的 Worktree。

什么时候该用，什么时候不用？

简单记：需要长时间并行、不想频繁切换上下文的场景，用 Worktree。

Worktree 之于 Git，就像多车道之于单行道。车还是那些车，路宽了就不堵了。

AI 编程工具越来越快，但如果你的工作流一次只允许它干一件事，再快的 AI 也帮不了你太多。把路拓宽，让每个 AI 都有自己的车道，这可能是当前 AI 开发效率中最容易被忽略的优化点。