两个 AI 聊天窗口，不一定对应两份代码。如果它们都在同一个目录中工作，修改的仍是同一批文件：一个刚改完，另一个可能就把它覆盖了。
Git worktree 可以让同一个仓库拥有多个工作目录，每个目录检出自己的分支。把任务分别放进去，能隔开日常文件修改；最后如何合并，仍由 Git 和代码审查处理。
分支与目录，解决的是两件事
分支记录一条提交路线，工作目录存放当前正在编辑的文件。在同一目录里切换分支，并没有同时得到两份可编辑文件；两个进程仍可能互相影响。
| 工作方式 | 文件在哪里 | 同时修改会怎样 |
|---|---|---|
| 两个聊天共用一个目录 | 同一份文件 | 可能直接覆盖，未提交改动也会互相可见 |
| 同一目录来回切分支 | 同一个工作目录 | 需要切换状态，不适合两个任务同时写 |
| 两个 worktree，各用一个分支 | 两个独立目录 | 文件修改分开，提交后再决定如何合并 |
worktree 共用仓库的对象库和引用，并不是完整复制两个独立仓库。常规情况下，Git 也不会让同一个分支同时检出到两个 worktree；为不同任务创建不同分支即可，不必用强制选项绕过这个检查。
用一个小仓库看清隔离效果
下面是 Windows PowerShell 示例，在没有同名文件夹的空目录运行。先建立演示仓库，提交一个文件，再创建两个工作目录：
mkdir worktree-demo cd worktree-demo git init -b main Set-Content README.md "base" -Encoding utf8 git add README.md git -c user.name=Demo -c user.email=demo@example.invalid commit -m "base" git worktree add -b task/docs ../wt-docs git worktree add -b task/ui ../wt-ui git worktree listgit worktree list应列出三个目录及其分支：主目录对应main，wt-docs对应task/docs，wt-ui对应task/ui。
为了看出区别，故意让两个任务把同一个文件改成不同内容：
Set-Content ../wt-docs/README.md "docs change" -Encoding utf8 Set-Content ../wt-ui/README.md "ui change" -Encoding utf8 Get-Content README.md Get-Content ../wt-docs/README.md Get-Content ../wt-ui/README.md三次读取应分别得到base、docs change、ui change。一个任务修改文件，没有覆盖另一个工作目录；主目录也没有因此跟着变化。
给 AI 指定目录，比只说分支名更直接
实际分工时，在第一个任务中明确要求“只在 wt-docs 的绝对路径下改文档”，在第二个任务中指定 wt-ui 的绝对路径。开始修改前，让它报告当前目录和git branch --show-current的结果。
仅在提示词里写“你负责 docs 分支”，但两个任务仍从同一目录启动，不足以证明文件已经隔开。也不要让任务越过自己的目录，顺手修改另一份 worktree。
如果任务依赖当前尚未提交的修改，需要先明确怎样带入这些改动。新 worktree 从指定提交创建，不会自动复制另一个目录里的未提交文件。
隔开修改，不等于合并时没有冲突
演示中两个分支改了 README 的同一行。如果分别提交，再把两个分支合回 main，后合入的一方可能产生冲突；worktree 解决的是“编辑时互相覆盖”，不是替你决定该保留哪个版本。
合并前，先在各自目录检查git status --short，把需要交付的改动提交，再用git diff main...task/docs等命令审查已提交差异。三点比较查看的是提交之间的差异，不能拿它代替检查未提交文件。
两个 worktree 的开发服务也可能抢同一个端口，测试可能写入同一个数据库或共享缓存。文件目录分开之后，端口、测试数据与外部服务仍要按任务安排。
任务结束后怎样收拾目录
确认需要的改动已经提交或另行保存，再从主目录执行：
git worktree remove ../wt-docs git worktree remove ../wt-ui git worktree list如果 Git 提示目录还有修改，先回去检查，不要直接加--force。移除 worktree 不会自动删除对应分支；分支是否继续保留，等合并和审查完成后再决定。
