多开AI编码助手，你的代码还在吗？

当你同时启动三个Claude Code处理不同任务时，有没有想过——它们其实在同一个目录里互相踩脚？

这不是假设。原文作者发现，当实例A有未提交改动、实例B执行git pull --rebase时，A的工作会被直接覆盖丢失。更隐蔽的是实例C的git stash：A和B的改动会被卷进C的暂存堆栈，彻底脱离原始上下文。

传统上我们靠人工协调避免冲突，但这对自主运行的AI代理行不通。Git工作树（git worktree）提供了一种隔离方案：每个实例拥有独立的工作目录和专属分支，从物理层面消除干扰。

隔离方案的技术实现

作者提供的脚本setup-instance-worktree.sh完成了三件事：定位仓库根目录、创建命名工作目录、绑定独立WIP分支。以实例"ps1"为例，执行后生成.claude/worktrees/instance-ps1/目录，并自动关联claude/ps1-wip分支。

关键配置是将.claude/worktrees/写入.git/info/exclude而非.gitignore——前者是本地隔离，避免污染团队共享的忽略规则。通过git worktree list可随时查看所有活跃实例的状态。

正方：直接推主干的简洁主义

方案的核心设计是每个实例直接向origin/main推送。作者认为这比维护长期功能分支更简单：

在工作目录内执行git push origin HEAD:main，无需记忆分支名称。当冲突发生时，恢复流程也极度精简：git pull --rebase origin main && git push origin HEAD:main。

选择rebase而非merge，是为了保持线性历史——这对AI生成的提交序列尤为重要，能减少人工介入时的认知负担。

反方：直接推主干的风险边界

但"直接推主干"在团队协作中历来争议极大。质疑者会指出：如果实例A和B的改动存在逻辑冲突，rebase后的强制推送可能掩盖问题，而非暴露问题。

原文作者并未回避这一点，只是将场景限定在"个人使用多实例"而非"多人协作"。换句话说，这个方案假设所有实例的决策者本质上是同一个用户——你。

当这个前提不成立时，WIP分支的隔离优势可能转化为集成噩梦。每个实例的提交历史独立演化，最终汇入主干时，冲突解决的责任完全落在用户身上。

我的判断：场景适配比方案完美更重要

这个方案的真正价值不在于技术新颖性——git worktree存在多年——而在于它精准匹配了AI编码助手的新使用模式。

传统开发中，多工作树常用于同时维护多个发布版本。而这里的需求是"同一时刻、同一仓库、多个自主代理"。冲突从"人与人之间的协调失败"变成了"代理与代理之间的资源争抢"，性质完全不同。

作者的设计选择体现了对AI工作流的深刻理解：放弃分支合并的复杂性，换取即时集成的确定性。当实例被拒绝推送时，它不会陷入等待，而是立即执行标准化的恢复序列——这对没有人类判断能力的代理至关重要。

如果你正在用Claude Code处理多个并行任务，这套脚本值得直接套用。但请严格遵守作者的前提假设：单人使用、即时审查、快速集成。一旦涉及多人协作或需要代码审查流程，WIP分支的设计就需要重新评估。

技术方案没有绝对优劣，只有与使用场景的匹配程度。git worktree在这里不是最优解，而是足够好的解——而"足够好"往往是工程实践中最难达成的平衡。