先问一个问题：过去一年，你用过几次 `git worktree`？
不用不好意思。这条命令2015年7月随 Git 2.5 发布，之后在官方文档里躺了十年，分类是"高级功能"，偶尔出现在面试冷门题里，绝大多数人听到名字的第一反应是"这玩意有什么用"。知乎但最近几个月，它突然成了 AI 编程圈出场率最高的命令。
B站上，"先搞懂GitWorktree，再开始Vibecoding"播放1.6万、收藏1051。哔哩哔哩"GitWorktree是什么？为什么它能让AI编程效率直接翻倍"播放1.1万、收藏579，收藏数差不多是点赞的两倍，典型的"先存下来回头照着做"型需求。哔哩哔哩
小红书从4月开始持续出现 Claude Code 并行开发的帖子。小红书知乎甚至有人在"Git发布2.10"这种十年老问题下面，8月新增回答：“Worktree终于等来了他的黄金年代”。知乎
为什么？因为大家开始同时开好几个 AI 写代码了。
一、多个AI同时改代码，先崩的不是模型，是目录
最典型的场景：同一个项目目录里开两个 Claude Code 会话，一个改前端、一个改后端。理论上效率翻倍，实际是灾难现场——A 刚写好的文件，B 按自己的理解又重写了一遍，你的改动直接蒸发。小红书上有篇高收藏帖子叫《Git worktree保命》，作者同时开3个会话，第二天发现文件被覆盖、改动全没，排查一圈才意识到问题出在"大家都住在同一个目录里"。小红书这不是某个工具的bug，是 CLI Agent 工作方式的必然结果：它们直接读写文件系统，多个实例共用一个目录，等于几个人抢同一块键盘。
最近两个月，社区和工具层几乎同时收敛到了同一个答案：给每个 Agent 一个独立的 worktree。
证据是今年以来的动向：
其实早在2月，Claude Code 就在 v2.1.50 版本里把 worktree 直接做成了内置功能：命令行加 `–worktree` 参数进隔离模式，桌面端一键开启，子代理也能各自跑在独立 worktree 里，官方甚至说非 Git 的版本控制系统都能通过 hooks 获得隔离能力。小红书
桌面编排工具 Orca 8月冲到 8.6k star、日增400，核心机制就是"为每个任务创建独立 Git Worktree，绑定独立终端和 Agent 会话"，还做了 SSH 远程 worktree——Agent 跑在远程开发机上，本地和手机只负责看和管。知乎小红书
8月10日 Claude Code 更新会话互发消息（ListAgents + SendMessage 两个工具），18小时近500万人围观，它支持的并行场景里，用户实际的标准部署就是"一个会话一个 worktree"。小红书
8月底新出的开源工具 lyshell，卖点之一也是给 Claude 和 Codex 的终端会话指定独立 worktree。
上层工具花样再多，底下垫着的都是这条十年的老命令。
二、隔离方案有三条路，为什么赢的是 worktree
想让多个 Agent 并行不打架，其实有三条路。把账算清楚，就知道为什么是 worktree 赢。
第一条：同目录多开。成本为零，但改动必然互相覆盖，直接出局。
第二条：再 `git clone` 一份。隔离是彻底了，但大仓库动辄几个GB要重新拉一遍，磁盘翻倍；更麻烦的是两份克隆的历史、远程状态互相独立，跑着跑着就分不清哪个是"本体"。知乎
第三条：`git checkout` + `git stash` 切分支。这本质是串行不是并行——工作目录只有一个，想干B就得先把A的半成品塞进 stash。stash 这东西名声有多差，B站有个视频标题就是"别再stash了"。哔哩哔哩
第四条才是 worktree：
```
git worktree add …/proj-feature-a -b feature/a
```
关键在机制：新目录有自己独立的工作区和分支，但和主仓库共享同一份 .git 对象库。知乎历史提交、远程缓存全部即取即用，磁盘几乎零增量，创建秒级完成，每个 worktree 还有自己独立的暂存区索引——A 没提交的改动，B 连看都看不见。
一句话：clone 是整库复印，切分支是单线程排队，worktree 是共享内存、只开新栈的"平行宇宙"。AI Agent 带来的"多个不完全可信的写作者并行"场景，简直像为这个机制量身定做的。
三、社区已经跑通的一套工作流
命令只有一行，并行要跑得稳，靠的是流程。最近小红书和B站几篇高收藏帖子，做法高度趋同，大致五步：
先分边界再并行。把任务先喂给 AI，让它列清楚每个任务会碰哪些文件。任务之间有文件重叠的，不并行，排队串行。大部分翻车现场，根子都在这一步省掉了。
跨界任务先立契约。前后端要对接的，先写一份 API_CONTRACT.md，字段名、类型、必填项全部固定，所有会话开工前先读它，不许自行脑补。小红书
一个任务一个 worktree + 一个独立分支。`git worktree add …/proj-task-a -b feature/task-a`，Agent 在新目录里启动。
启动时写明文件权限边界。哪些文件能改、哪些是禁区，禁区碰了必须停下来问人。
合并按风险排序。测试通过的低风险改动先合，高风险的放最后。
这套东西说白了，是把版本控制世界的老智慧——先划边界、后谈合并——给 Agent 重新讲了一遍。十年没火的工作流，现在成了新刚需。
四、手写命令还是上工具，看你处在哪一档
偶尔并行两三个任务：手写两条命令就够了。`git worktree add` 开工、`git worktree list` 查看、`git worktree remove` 收尾。用的是 Claude Code 的话，也可以直接开内置的 worktree 模式，命令行加个 `–worktree` 参数就行，连目录都不用手动建。
每天常驻三五个 Agent 的重度用户：可以看看编排工具。以 Orca 为例，它比手写多出来的东西是：把任务、分支、终端、Diff 绑进同一个视图，哪个 Agent 在跑、哪个在等你确认，一眼看清。知乎需要的话还能把 Agent 放到远程机器上跑。判断标准很简单——看它是不是把"任务"和"worktree"绑定管理，只是帮你多开几个终端窗口的，是伪并行。
团队要落地的：在上面之外再加一条审计线，哪个 Agent、在哪个 worktree、产生了哪次提交，得能追溯。
五、几句清醒话
worktree 不是沙箱。它隔离的是文件，不隔离命令执行——Agent 在 worktree 里照样能跑任意命令、碰系统文件。它解决的是"互不覆盖"，解决不了"闯祸"，删库这种事故还是得靠备份兜底，别把隔离当保险。
依赖不共享。node_modules、build 产物这些不进 Git 的东西，每个 worktree 都要单独装一遍。知乎大前端项目这是实打实的磁盘和时间成本，并行前先算账。
收尾别用 rm。删 worktree 目录要用 `git worktree remove`，直接 rm 会在仓库里留下悬空记录，得靠 `git worktree prune` 清理。分支也会越攒越多，合并完及时删分支，别让分支列表变成垃圾场——小红书上有位开发者的帖子标题很直白：《895个Worktree之后，我放弃了Worktree》。小红书并行能力是免费的，管理纪律不是。
最后
对关注版本控制的人来说，这件事还有点浪漫色彩：Git 当年的设计——廉价分支、内容寻址存储、对象库与工作区分离——是为了让几千个内核开发者协作不打架；二十年后，它恰好接住了"多个 AI 同时写代码"这个新物种。worktree 躺了十年没人理，被 AI 一朝翻出来变成必修课。
下次再有人问"想同时开几个 AI 写代码怎么办"，别只回"多开几个窗口"。告诉他：`git worktree add`。
