Git Worktrees 1: How we are shipping faster with Claude Code and Git Worktrees
四月前，Claude Code 刚发布时，我们还在苦求"研究预览版"的邀请码。
如今呢？我们已经从零起步，发展到能同时运行四五个 Claude 智能体（Agent），让它们并行处理不同的功能特性。这听起来可能有点乱，但实际上，随着我们对 AI 信任度的增加以及工具本身的飞速进化，这一切都是水到渠成的自然演进。
当我们的 CTO Pete 给团队下达任务，要求"尽可能多地把辛苦融来的风投资金花在 Claude 上"时，许多人将其视为一种个人挑战。我们在办公室甚至立了个排行榜，实时追踪全队的 Claude Code 用量。
最初的大规模试错，如今已转化为实实在在的工作流变革，正在大幅加速我们的开发节奏。
Claude Code：驻扎在终端里的 AI 开发
还没试过的朋友可能不知道，Claude Code 是 Anthropic 推出的命令行工具，它让你能直接在终端里把编程任务委派给 Claude。虽然市面上不乏 AI 编程工具（如 Cursor, GitHub Copilot 等），但 Claude Code 有个独特之处：它完全运行在终端里。这意味着它能代你执行任何 bash 指令，而且非常容易同时启动多个实例。
你只需在任意目录下运行 claude，就能唤醒一个对话式 AI。它能阅读代码库、修改代码、运行命令，甚至提交代码。对于习惯在终端里"安家"的开发者来说，这种感觉非常自然。而且不像某些基于 IDE 的工具，你想开多少个 Claude Code 会话都行。
我们把它的用途发挥到了极致——构建新 UI、优化工具链、编写测试，甚至起草产品规格文档。为了让你更有实感，这里有几个真实案例。
构建新 UI
我们产品中有一个相当高级的部分，允许用户编写 JavaScript 从警报事件的 JSON 载荷中提取字段。这是我们"表达式（Expressions）“功能的一部分，旨在让用户在产品各处运行各种逻辑片段。
简单的解析脚本可能是 $.metadata.team 这样提取嵌套字符串的代码。但也支持更复杂的函数用例，比如 return $.values.map(function(v) { return v*2; })。
在大多数情况下，用户不需要太复杂的 JavaScript，我们甚至在产品里内置了 AI 来帮用户生成这些代码。因此，我们之前没怎么在输入框的体验上下功夫——它只是个单行输入框，和产品里其他表单没什么两样。
然而，利用 Claude Code，仅用了 30 秒的提示词（Prompting）和约 10 分钟的处理时间，我们就得到在一个漂亮的、支持多行编辑、行号显示甚至代码补全的新 JavaScript 编辑器。
Claude 首先进入了"计划模式（Plan Mode）"（稍后细说），它自己去 grep/find/cat 一通，找到了相关文件，并制定了计划。
有趣的是，Claude 建议的计划预估需要约 2 小时的工时——这显然是基于人类速度估算的——但它实际上只用了 10 分钟就干完了。我批准计划后，它迅速开工。不到 10 分钟，我就得到了一个完成度 90% 的新编辑器。因为它能按需搜索代码，还能运行 TypeScript 编译器来验证更改，所以产出的代码与我们现有的代码库风格高度一致——完全可用，除了几个视觉上的小瑕疵外，甚至比我预想的还要好。
这类改动通常是我们想做却排不上优先级的，但有了 Claude Code，一切变得轻而易举。
优化工具链
另一个案例是我让 Claude Code 帮我解决工具链运行缓慢的问题。我们需要通过代码生成（codegen）来产出 API 规范和客户端，这一直是我们工具链里的"慢郎中”，让我颇为恼火。
在我忙于其他功能时，我让 Claude 去分析并优化 Makefile 中的 API 生成命令。
我只给了它极少的上下文。花掉了 8 美元的 token 额度后，它交出了一份完整的分析报告，指出了瓶颈所在，并提出了一堆修复建议。
随后，我让它逐一实施这些改进，先挑性价比最高的做。它修改了 Makefile，在生成前端客户端的后续步骤中引入了并行处理。算上我自己的工作，大概也就花了 5 分钟，但我们 API 生成的时间缩短了 18%（约 30 秒）。考虑到这是每个 Pull Request 都要跑的流程，而且大多数开发者几乎每天都要运行，这 8 美元花得简直超值。
Claude Code 固然强大，我们也用得很欢。但既然是我们要发布的代码，我们就得负责。通常我们不会依赖 Claude 做重大的架构决策，但在方向明确的时候，它绝对是一个巨大的实现加速器。
唯一的痛点？你可以同时运行多个 Claude Code 实例，但默认情况下，你一次通常只能检出一个 Git 仓库。这意味着所有的 AI 会话都在同一个工作目录下"打架"——直到我们发现了 Git Worktrees。
Git Worktrees：幕后英雄
Git Worktrees 是一个等待被发掘的宝藏功能。随着多个 Claude 智能体并行运行，Worktrees 终于迎来了它的高光时刻。
对于不熟悉的人来说，Git Worktrees 允许你同时检出同一个仓库的多个分支，每个分支都有独立的目录。它不像克隆（clone）仓库那样浪费空间（复用同一个 .git 目录），却能让你把 feature-a 放在一个文件夹，bugfix-b 放在另一个，两者都连接到同一个 Git 仓库。Git 也提供了内置命令来管理这些工作树。
典型的工作流需要手动创建：git worktree add ../feature-branch，然后切进那个目录。这也能用，但当你管理几条并行的开发线时，不断的目录切换和管理就变得很繁琐。
我之前就是这么干的：切到单体仓库（monorepo），运行 git worktree add，指定路径，切换上下文，最后启动 Claude 会话。当你同时耍着好几个 AI 对话时，这些摩擦成本累积起来非常可观。
所以我写了一个自定义的 Worktree 管理器。现在，只要打开终端，输入 w core some-feature claude，就能瞬间在一个完全隔离的分支上启动 Claude Code 窗口。
w —— 给 Claude 和 Worktrees 配个好用的 Bash 函数
这个简单却强大的 bash 函数是在 Claude 的帮助下编写的，极大地简化了我们管理多分支开发的流程：
# 创建并进入一个新的 worktree
w myproject new-feature
# 在该 worktree 中运行 Claude Code
w myproject new-feature claude
# 在不切换目录的情况下检查 git 状态
w myproject new-feature git status
# 直接从任何地方提交代码
w myproject new-feature git commit -m "fix: the thing"
在底层，它做了这些事：
- 自动补全现有的 worktree 和仓库名。
- 自动创建带有你用户名作为前缀的 worktree（实际上就是创建分支）。
- 将所有内容整洁地组织在
~/projects/worktrees/目录下。 - 在 worktree 上下文中运行命令，而无需改变你当前的目录。
- 跨会话记住现有的 worktrees。
最棒的是它的智能补全系统。开始输入 worktree 名称，它会建议现有的，或者让你创建新的。输入命令，它会建议常见的 git 操作、Claude 或任何你需要工具。
它消除了"有人提需求"和"Claude 正在处理"之间的所有摩擦。最妙的是？Claude 甚至可以按你的要求提交并推送代码，而在 Worktrees 的加持下，每个对话都保持完全隔离。
我们如何实际使用 Claude Code
搞定了分支管理和并行开发，那日常到底怎么用？我们总结了一些行之有效的模式。
我不想在这里深究提示词技巧（Prompting）——网上这类内容多的是。我的建议是：尽管去试。真正的价值不在于打磨完美的提示词，而在于分享经验，以及构建围绕 Claude 的工作流和工具。
计划模式 (Plan Mode)：信心的来源
Claude Code 的"计划模式"改变了我们的工作方式。你可以放心地让 Claude 在计划模式下运行，不用担心它擅自改动代码。在此之前，这感觉很冒险——要么是 Claude 改了代码傻等着你确认，要么是你开启自动编辑模式然后祈祷回来时代码没烂掉。
这种信心意味着我们可以很好地并行工作。我不只是同时开启六个任务然后关掉它们——我是同时进行七个持续的对话，每一个都在独立演进。这就像拥有了一支分布式的初级开发者团队，每个人都在我的指导下工作。
语音驱动开发 (Voice-driven development)
最近最有趣的进展是将语音引入我们的 Claude 工作流。我一直在用 SuperWhisper 进行听写，你经常会看到我躲进会议室，对着 Claude 讲上 10 分钟。
流程出奇地自然：
- 花 5 分钟通过语音"倾倒"上下文和需求。
- 标记相关文件供 Claude 检查。
- 让 Claude 生成产品规格，或者直接生成完整的实现代码。
这感觉就像在给初级程序员布置任务：“这是我的想法，这是你需要的文件，去干吧。” Claude 给出的方案往往比我费劲打字表达的还要好。
语音方法在处理复杂功能时大放异彩，因为把所有边缘情况和需求敲出来太费时间了。最近我在优化我们的"请求覆盖（cover requests）“功能——场景极其繁杂，打字时很难跟上思维的速度，而语音让我能自然地把想法说出来。
未来的方向
有了这个基础，我们开始对自动化和工作流改进有了更大的构想。
更好的开发环境 我们想解决资源管理的挑战。虽然 Git Worktrees 解决了代码隔离，但本地资源依然有限。同时运行多个 Claude 会话意味着要处理数据库、端口和本地服务的冲突——这很快就会变得笨重。
我们的愿景是能够同时开发多个功能，将它们推送到云端，稍后回来时发现一切都保持原样——数据库、后台服务、整个技术栈都在完全隔离的预览环境中准备就绪。
闭合反馈循环 有了更好的预览环境，我们可以大幅缩短"反馈-实现"的周期。想象一下 Slack 里的内部反馈频道自动触发的不仅是工单，而是可运行的原型。
流程可能如下：
- 有人在 Slack 的
#product-feedback频道发帖：“如果能…就太酷了”。 - 系统自动创建 Linear 工单，Claude 评估需求是否足够具体以制作原型。
- Claude 在后台创建 worktree 和分支。
- 它根据反馈实现一个可工作的原型。
- 更改推送到 CI，触发预览版部署。
- Claude 将预览链接直接贴回原来的 Slack 帖子。
技术拼图已经齐备。我们的 CI 运行只需不到 5 分钟，Claude 已经能创建和推送分支，配合 worktree 管理器，瞬间启动隔离的开发环境已非难事。
写在最后
我们不仅仅是在优化开发工作流，更是在为一个AI 辅助开发成为常态的世界做准备。当你管理多个 AI 对话，且每个对话可能持续数小时甚至数天时，快速、隔离的环境就变得至关重要。
Git Worktree 方法赋予了我们一种强大的能力：将 AI 编程会话视为长期运行的进程。我们可以围绕特定功能进行持续、专注的对话，所有的上下文都保存在分支和 worktree 中。
四个月前，甚至一个月前，我们几乎没怎么用 Claude Code。今天，我们并行运行多个 AI 智能体，每个都在拥有完整开发环境的隔离特性上工作。我们的构建速度更快了，功能开发加速了，我们把更多时间花在了产品开发的创造性工作上，而不是与工具作斗争。
未来的开发不是要取代工程师，而是赋予他们超能力。有时候，这种超能力只需要 8 美元，还得加上你做晚饭时它默默提升的 18% 性能。
此外，还有一种"套娃"的乐趣：我用 Claude 编写了能更高效使用 Claude 的工具。这真是彻头彻尾的 Claude 优化 Claude。