Claude Code 很适合处理真实项目里的跨文件任务，但当你同时想做两个方向时，问题也会变明显：一个任务在改样式，另一个任务在改接口；一个会话还没验收，另一个会话又把同一批文件动了。最后不是 AI 不会写代码，而是工作区被搅在一起，人工也很难判断哪一步出了问题。
Git Worktree 正好可以解决这类问题。它允许你基于同一个仓库，创建多个独立目录，每个目录对应不同分支。你可以让 Claude Code 在不同 worktree 里分别处理任务，互不覆盖，最后再回到主分支逐个合并和验收。
如果你已经看过 AI编程工具专题 里的任务拆解、测试和代码审查文章，这篇可以看作更进一步的“并行执行”流程。相关的 Claude Code 用法，也可以放到 Claude专题 里一起看。
什么时候需要 Git Worktree
不是每个 AI 编程任务都需要 worktree。小改动、单文件修复、一次性脚本优化，直接在当前分支做就够了。真正适合 Git Worktree 的，是这些情况：
- 你想同时尝试两个方案，比如改首页布局和改发布脚本。
- 一个任务还在等人工验收，另一个任务又必须马上开始。
- 你想让 Claude Code 和另一个 AI 编程工具分别处理不同分支。
- 你要做风险较高的改动，希望失败后整个目录可以直接丢掉。
- 你不想在一个工作区里堆太多未提交修改。
简单说，worktree 适合“并行、隔离、可回滚”的任务。它不是为了炫技，而是为了让 AI 改代码时边界更清楚。
Worktree 和普通分支有什么区别
普通分支通常共用同一个工作目录。你切到 A 分支做一半，再切 B 分支，很容易遇到未提交修改、依赖状态、生成文件冲突等问题。Worktree 则是给每个分支单独开一个目录。
例如你可以这样安排：
project/
project-worktrees/
seo-check/
mobile-layout/
publisher-refactor/
每个目录里都是同一个仓库的不同分支。Claude Code 进入哪个目录，就只看到那个任务的文件状态。这个边界对 AI 很重要，因为它能减少“顺手改了旁边未完成任务”的概率。
基础创建流程
假设主项目目录是 laodad.com，你想单独做一个发布后检查脚本优化，可以这样创建 worktree：
git status
git worktree add ../laodad-check-post -b feat/check-post-hardening
cd ../laodad-check-post
第一步先看 git status，确认当前主目录没有混乱的未提交修改。第二步创建一个新目录和新分支。第三步进入这个目录，让 Claude Code 在这里执行任务。
给 Claude Code 的任务说明可以这样写：
你现在位于独立 Git Worktree。请只处理发布后检查脚本的稳定性问题，不修改文章草稿和主题样式。开始前先读取项目规则和相关脚本，完成后列出修改文件、验证命令、残余风险和回滚方式。
这类提示词和 AI编程任务说明怎么写 是配套的：任务边界越清楚，worktree 的隔离价值越大。
一台电脑上跑多个 Claude Code 会话
有了多个 worktree，你可以打开多个终端窗口，每个窗口进入不同目录：
cd ../laodad-check-post
claude
cd ../laodad-mobile-layout
claude
每个会话都只负责一个目标。不要让一个会话跨目录去改另一个任务，也不要把两个任务的需求混在一个长提示词里。AI 编程最怕“顺便”，worktree 的价值就是把“顺便”挡在目录之外。
如果任务之间可能改到同一文件，要提前决定优先级。例如一个任务改文章页模板，另一个任务也改文章页 SEO 输出，就不适合完全并行。可以先做 SEO 输出，再在另一个 worktree 里基于最新主分支创建布局任务。
合并前先验收，不要急着进主分支
Worktree 只是隔离了过程，不代表结果一定能合并。每个任务完成后，先在对应目录里做验收：
- 看
git diff，确认只改了预期文件。 - 运行项目里最窄的相关检查，比如测试、构建、脚本 dry-run。
- 打开关键页面或执行关键流程，确认用户结果真的出现。
- 让 Claude Code 写清楚修改文件、验证结果和未验证风险。
- 必要时先提交，再回主分支合并。
这一步可以参考 AI编程测试自动化怎么做 和 Claude Code代码审查怎么做。Worktree 让任务分开，测试和审查负责判断能不能进入主线。
一个适合 AI 编程的目录命名规则
Worktree 多了以后，命名会影响维护。建议用“项目名 + 任务关键词”的方式：
../laodad-seo-meta-check
../laodad-topic-page-layout
../laodad-publisher-media-alt
分支名也保持一致：
feat/seo-meta-check
fix/topic-page-layout
chore/publisher-media-alt
不要用 test1、new-try、claude-fix 这种名字。过两天你就会忘记它们分别在做什么，AI 交接记录也很难看懂。
常见风险：依赖和配置不同步
Worktree 是独立目录，但不是完全独立环境。它们通常共用同一台电脑、同一套全局工具和同一个远程仓库。常见风险有三个。
第一，依赖安装状态不一致。 一个 worktree 里更新了依赖，另一个没有安装，测试结果可能不同。涉及依赖变更时，要特别说明。
第二，本地配置和密钥不要复制乱放。 如果项目依赖 .env，不要为了方便把真实密钥随手复制到多个临时目录后忘记清理。项目规则里也要写清楚密钥不能提交。
第三，生成文件容易造成噪音。 构建产物、截图、缓存文件如果没有被忽略，会让 diff 变脏。让 Claude Code 改代码前，先确认 .gitignore 和项目规则是否清楚。
回滚和清理方式
如果某个 worktree 方案失败，不要在主项目里手工到处撤。先确认这个目录里的有用内容已经提交或丢弃，然后回主目录执行：
git worktree list
git worktree remove ../laodad-check-post
git branch -D feat/check-post-hardening
如果分支里有值得保留的提交，就不要删除分支；如果只是一次失败实验，清理 worktree 和分支即可。相比在一个目录里反复撤销，worktree 的好处就是失败成本低。
老达建议：先从两个并行任务开始
第一次用 Git Worktree 配合 Claude Code，不建议一下开五六个目录。先从两个任务开始：一个低风险修复，一个中等复杂度功能。每个任务都要求 Claude Code 输出影响范围、验证结果和回滚方式。
当你能稳定做到“一个目录一个目标、一个分支一个结果、合并前先验收”，再考虑把 Cursor、Codex、Claude Code 分别放进不同 worktree 里协作。更多 AI Agent 和自动化流程，可以继续看 AI智能体与自动化专题。
AI 编程真正提效的关键，不只是模型更强，而是流程能承受更快的修改速度。Git Worktree 给 Claude Code 加上的，正是这种可隔离、可并行、可回滚的工程边界。
