并行 ClaudeCode 开发实践

作者:Atom

字数统计:3.8k 字

阅读时长:15 分钟

iTerm2 + Git Worktrees 实践指南

2026 年 1 月，Claude Code 的创建者 Boris Cherny 在社交媒体上分享了他的日常开发工作流，引发了开发者社区的热议。令人意外的是，他的配置出奇地"朴素"——没有花哨的插件，没有复杂的自定义，核心就是 5 个 iTerm2 标签页 + 系统通知 + Git 隔离。但正是这套看似简单的方案，让一个人拥有了一个小型工程团队的产出能力。

"I run 5 Claudes in parallel in my terminal, numbering my tabs 1–5." — Boris Cherny

本文将从三个维度展开：

维度	内容
工具配置	iTerm2 的标签、快捷键、通知全套配置
隔离策略	Git Worktrees 并行开发的正确姿势
协作模式	有关联性的多迭代如何安全并行

一、iTerm2 并行环境配置

安装 iTerm2

Homebrew手动下载

bash

brew install --cask iterm2

bash

# 访问 https://iterm2.com 下载 .dmg 安装包

标签页命名

默认情况下，所有标签页的名称都是 -zsh，并行 5 个 Claude 时完全无法区分。

配置步骤：

按 ⌘T 创建 5 个标签页
双击标签上的 -zsh 文字
在弹出的 "Set Tab Title" 窗口中输入编号
使用 ⌘1 ~ ⌘5 快速切换

命名建议

不只是编号，可以用更语义化的名称来标识用途：

标签	名称示例	用途
⌘1	`backend`	后端 API 开发
⌘2	`node`	Node 中间层
⌘3	`frontend`	前端 UI 开发
⌘4	`test`	测试 & 验证
⌘5	`ops`	构建 / 部署 / Git 操作

修复键盘快捷键冲突

Claude Code 中 ⌘→ 用来跳到行尾，但 iTerm2 默认把它映射成了切换标签页，会导致编辑中突然跳走。

必须修复

不修复这个冲突，在 Claude Code 中编辑长命令时会非常痛苦。

修复方法：

⌘, 打开 iTerm2 偏好设置
进入 Keys → Key Bindings
找到 Next Tab 和 Previous Tab
将两者都设为 -（即禁用）

为什么不是重新绑定？

Boris 的方案是直接禁用，因为 ⌘1 ~ ⌘9 的数字跳转已经足够精确，不需要 Next/Previous 这种顺序切换。

通知配置（核心）

这是 Boris 工作流的灵魂所在——你不需要盯着每个标签页，Claude 需要输入时系统会主动通知你。

Step 1：iTerm2 设置

打开 ⌘, → Profiles → Terminal，勾选以下选项：

✅ Flash visual bell
✅ Show bell icon in tabs
✅ Notification Center Alerts

Step 2：macOS 系统设置

进入 系统设置 → 通知 → iTerm2：

✅ 允许通知
✅ 显示在通知中心
✅ 横幅样式（推荐，不打断工作流）

效果

当任何一个标签页中的 Claude 完成任务并等待输入时：

标签图标会闪烁
macOS 通知中心弹出提醒
你可以从当前标签页直接 ⌘N 跳过去

汇总：iTerm2 配置清单

配置项	操作
安装 iTerm2	`brew install --cask iterm2`
创建 5 个标签页	`⌘T` × 5
标签页命名	双击标签名编辑
禁用 Tab 切换快捷键	Keys → 禁用 Next/Previous Tab
开启通知	Profiles → Terminal → 勾选三项
macOS 通知权限	系统设置 → 通知 → iTerm2

二、Boris 的并行工作哲学

核心原则

Boris 对 Claude Code 的态度不是把它当成"魔法"，而是当成基础设施——围绕它建立系统：记忆文件、权限配置、验证循环、格式化钩子。

Boris 的原话

"There is no one correct way to use Claude Code: we intentionally build it in a way that you can use it, customize it, and hack it however you like."

工作方式详解

mermaid

graph LR
    A[Plan Mode] --> B{满意？}
    B -->|否| A
    B -->|是| C[Auto-accept 模式]
    C --> D[Claude 一次性执行]
    D --> E[Review & Commit]
    E --> F[Push & PR]

实践	做法	原因
模型选择	全部使用 Opus（最重模型）	追求质量，不追求速度
Plan Mode	`Shift+Tab` × 2 进入	先讨论方案，再执行
权限模式	沙箱内用 `--dangerously-skip-permissions`	避免被权限弹窗阻塞
Slash 命令	`/commit-push-pr` 等高频命令	存入 `.claude/commands/`，全团队共享
远程会话	`claude &` 启动 + `--teleport` 拉回本地	在本地和远程间无缝切换
并行数量	本地 5 个 + 远程 5~10 个	一个人 = 一个小团队

注意

--dangerously-skip-permissions 仅适用于沙箱环境或你完全信任的场景。生产代码库请使用标准权限模式或 --permission-mode=plan。

三、Git Worktrees——并行开发的正确隔离

为什么不是多分支？

在同一目录中切换分支有三个致命问题：

问题	后果
文件状态共享	一个 Claude 的修改会影响另一个的文件视图
node_modules 污染	分支间依赖不同时反复 install
Git 索引冲突	两个进程同时操作 staging area 会出错

Worktree vs Clone vs Branch

方案	磁盘占用	Git 历史共享	隔离度
Worktree	低（共享 `.git`）	完全共享	完全隔离
Clone	高（完整副本）	独立	完全隔离
Branch 切换	最低	共享	无隔离

Worktree 基础操作

创建 Worktree查看 & 管理清理 Worktree

bash

# 从当前分支派生新 worktree
git worktree add ../vf-backend -b feature/1.0.3-backend

# 基于指定分支创建
git worktree add ../vf-frontend -b feature/1.0.3-frontend origin/feature/1.0.3

bash

# 列出所有 worktree
git worktree list

# 输出示例：
# /Users/you/vibeFlow           feature/1.0.3        [主仓库]
# /Users/you/vf-backend         feature/1.0.3-backend
# /Users/you/vf-frontend        feature/1.0.3-frontend

bash

# 正确方式：使用 git 命令删除
git worktree remove ../vf-backend

# 清理残留元数据
git worktree prune

# 错误方式：直接删目录（会留下残留引用）
# rm -rf ../vf-backend  # 永远不要这样做！

关键规则

永远不要 rm -rf 删除 worktree 目录
一个分支只能存在于一个 worktree 中——Git 强制约束
使用 git worktree remove 确保元数据正确清理

四、关联性迭代的并行策略

这是实际项目中最棘手的问题——多个迭代内容有依赖关系时，如何并行而不翻车？

策略一：按架构层切分 Worktree

推荐策略

对于全栈项目（如 Backend + Node + Frontend），按架构层而非按功能切分是最安全的并行方式。

bash

# 错误：按功能拆（关联性高 → 冲突多）
git worktree add ../wt-chat -b feature/chat      # 前端+后端+node 全改
git worktree add ../wt-auth -b feature/auth      # 前端+后端+node 全改
# 两个 worktree 都会改 router.ts、App.vue...

# 正确：按层拆（文件天然不重叠）
git worktree add ../vf-backend  -b feature/1.0.3-backend   # 只改 backend/
git worktree add ../vf-node     -b feature/1.0.3-node      # 只改 node/
git worktree add ../vf-frontend -b feature/1.0.3-frontend   # 只改 frontend/

策略二：集成分支模式

用一个集成分支作为各 worktree 的汇合点：

mermaid

gitGraph
    commit id: "feature/1.0.3"
    branch feature/1.0.3-integration
    branch feature/1.0.3-backend
    checkout feature/1.0.3-backend
    commit id: "API: 用户接口"
    commit id: "API: 权限接口"
    checkout feature/1.0.3-integration
    merge feature/1.0.3-backend id: "合并后端"
    branch feature/1.0.3-node
    checkout feature/1.0.3-node
    commit id: "WS: 对接用户API"
    checkout feature/1.0.3-integration
    merge feature/1.0.3-node id: "合并Node"
    branch feature/1.0.3-frontend
    checkout feature/1.0.3-frontend
    commit id: "UI: 用户页面"
    commit id: "UI: 权限页面"
    checkout feature/1.0.3-integration
    merge feature/1.0.3-frontend id: "合并前端"

集成节奏：

时间线 ───────────────────────────────────────→

backend:   ████████ 完成 → merge 到 integration
node:      ██████████████ 完成 → merge 到 integration
                  ↑ 中途 rebase integration 获取后端 API
frontend:         等待... ██████████████ 完成 → merge
                          ↑ 拿到 backend + node 后启动

策略三：契约先行

在开始并行之前，先约定接口契约，写入项目共享目录：

openspec/changes/<feature>/context/
├── api-contract.md       # 后端 → 前端的 REST API 定义
├── ws-protocol.md        # Node → 前端的 WebSocket 消息协议
└── shared-types.md       # 各层共享的数据类型定义

api-contract.md 示例

markdown

## 用户信息接口

### GET /api/v1/users/me

**Response:**

| 字段 | 类型 | 说明 |
|------|------|------|
| id | number | 用户 ID |
| name | string | 用户名 |
| avatar | string | 头像 URL |
| role | enum | admin / member / guest |

### POST /api/v1/users/me

**Request Body:**

| 字段 | 类型 | 必填 | 说明 |
|------|------|------|------|
| name | string | 是 | 用户名 |
| avatar | string | 否 | 头像 URL |

每个 worktree 中的 Claude 都能读到同一份契约，保证各层开发方向一致。

五、冲突预防与检测

文件边界规则

最有效的冲突预防就是：明确每个 worktree 的文件所有权。

Worktree	允许修改	禁止触碰
`vf-backend`	`backend/**`	frontend, node
`vf-node`	`node/**`	frontend, backend
`vf-frontend`	`frontend/**`	backend, node
主仓库	`openspec/**`、配置文件	业务代码

在启动 Claude Code 时，在 prompt 中明确边界：

bash

# 进入 backend worktree 后
claude

# 首条消息
> 你只能修改 backend/ 目录下的文件。
> 禁止修改 frontend/、node/ 目录。
> 如需前端配合，写入 openspec/changes/<name>/context/api-contract.md。

使用 clash 实时检测冲突

clash 是一个专为 worktree 并行开发设计的冲突检测工具，它通过模拟三方合并提前发现问题。

安装常用命令

bash

# macOS
brew install clash

# Cargo
cargo install clash-sh

# 一键安装
curl -fsSL https://clash.sh/install.sh | sh

bash

# 查看所有 worktree 间的冲突矩阵
clash status

# 检查某个具体文件是否与其他 worktree 冲突
clash check src/views/VibeWorkspace.vue

# 实时监控模式（TUI 界面）
clash watch

# JSON 输出（可集成到 CI）
clash status --json

clash 的工作原理

发现所有 worktree（主仓库 + 关联的 worktree）
对每一对 worktree 计算 merge-base
模拟三方合并
报告冲突文件

整个过程完全只读，不会修改你的仓库。

热点文件处理策略

每个项目都有"人人都要碰"的文件——路由配置、全局状态、入口组件。对于这些热点文件：

策略	做法	适用场景
先到先得	只在一个 worktree 中修改该文件	修改量小
串行处理	backend/node 并行，frontend 最后串行	前端依赖后端
拆分文件	将大组件拆为子组件，各改各的	长期方案
约定顺序	每个 worktree 只追加，不修改已有行	路由表、配置文件

实际案例

在全栈项目中，以下文件是典型的冲突热点：

frontend/src/router/index.ts    ← 每个功能都要加路由
frontend/src/App.vue             ← 全局布局改动
frontend/src/stores/index.ts    ← 状态管理入口
backend/build.gradle             ← 依赖变更

建议：这些文件只在最后的集成阶段统一修改，并行阶段各 worktree 不碰。

六、完整实战流程

准备工作

bash

# 确保主分支最新
git checkout feature/1.0.3
git pull origin feature/1.0.3

# 创建集成分支
git checkout -b feature/1.0.3-integration
git push -u origin feature/1.0.3-integration

创建 Worktree

bash

# 在项目同级目录创建 worktree（推荐）
git worktree add ../vf-backend  -b feature/1.0.3-backend
git worktree add ../vf-node     -b feature/1.0.3-node
git worktree add ../vf-frontend -b feature/1.0.3-frontend

# 验证
git worktree list

输出示例：

/Users/you/vibeFlow       feature/1.0.3-integration
/Users/you/vf-backend     feature/1.0.3-backend
/Users/you/vf-node        feature/1.0.3-node
/Users/you/vf-frontend    feature/1.0.3-frontend

各 Worktree 安装依赖

backendnodefrontend

bash

cd ../vf-backend/backend
# Gradle 缓存是用户级的（~/.gradle），自动共享，无需额外操作
./gradlew build -x test

bash

cd ../vf-node/node
pnpm install  # pnpm store 全局共享，秒级完成

bash

cd ../vf-frontend/frontend/web-app
pnpm install

pnpm 的天然优势

pnpm 的全局 content-addressable store 意味着多个 worktree 的 pnpm install 几乎零额外磁盘开销，速度也远快于 npm/yarn。这也是 Boris 工作流中推荐 pnpm 的原因之一。

启动并行 Claude Code 会话

在 iTerm2 的各标签页中分别启动：

bash

# Tab 1 - backend
cd /Users/you/vf-backend && claude

# Tab 2 - node
cd /Users/you/vf-node && claude

# Tab 3 - frontend（可稍后启动，等后端 API 就绪）
cd /Users/you/vf-frontend && claude

# Tab 4 - 留给测试/验证
cd /Users/you/vibeFlow

# Tab 5 - Git 操作 & clash 监控
cd /Users/you/vibeFlow && clash watch

集成合并

bash

# 回到主仓库
cd /Users/you/vibeFlow

# 按依赖顺序合并
git merge feature/1.0.3-backend    # 先合并后端
git merge feature/1.0.3-node       # 再合并 Node
git merge feature/1.0.3-frontend   # 最后合并前端

# 验证构建
cd backend && ./gradlew build      # 后端构建
cd ../node && pnpm build           # Node 构建
cd ../frontend/web-app && pnpm build  # 前端构建

合并顺序很重要

按依赖链的方向合并：backend → node → frontend。如果反过来，前端代码可能引用了还不存在的 API。

清理 Worktree

bash

# 逐个移除
git worktree remove ../vf-backend
git worktree remove ../vf-node
git worktree remove ../vf-frontend

# 清理残留
git worktree prune

# 删除已合并的分支（可选）
git branch -d feature/1.0.3-backend
git branch -d feature/1.0.3-node
git branch -d feature/1.0.3-frontend

七、常见陷阱与解决方案

1. 端口冲突

两个 worktree 同时启动 dev server，第二个会因端口占用失败。

bash

# 两个前端 worktree 都跑 pnpm dev → 端口 5173 冲突

# 方案一：不同 worktree 用不同端口
cd ../vf-frontend && PORT=5174 pnpm dev

# 方案二：只在需要调试时启动 dev server
# 其他时间只跑 type-check 和 build 验证

2. IDE 配置

VSCode 用户

在主仓库的 .vscode/settings.json 中排除 worktree 目录：

json

{
  "files.watcherExclude": {
    "../vf-*/**": true
  }
}

或者更好的做法：每个 worktree 开一个独立的 VSCode 窗口。

3. Git Hooks 路径问题

Git hooks 存储在主仓库的 .git/hooks/ 中，所有 worktree 共享。但如果 hook 脚本使用了相对路径，可能在 worktree 中找不到文件。

bash

# hook 中的相对路径在 worktree 中会出错
./scripts/pre-commit-check.sh

# 使用 git rev-parse 获取仓库根目录
REPO_ROOT=$(git rev-parse --show-toplevel)
"$REPO_ROOT/scripts/pre-commit-check.sh"

4. 忘记清理 Worktree

长期不清理的后果

磁盘空间持续占用
git branch 列表越来越长
误操作风险增加（在过时的 worktree 中提交代码）

建议：完成一轮迭代后立即清理。

八、速查表

iTerm2 快捷键

快捷键	功能
`⌘T`	新建标签页
`⌘W`	关闭当前标签
`⌘1` ~ `⌘9`	跳转到第 N 个标签
`⌘D`	水平分屏
`⌘⇧D`	垂直分屏
`⌘,`	打开偏好设置

Git Worktree 命令

命令	功能
`git worktree add <path> -b <branch>`	创建新 worktree
`git worktree list`	列出所有 worktree
`git worktree remove <path>`	移除 worktree
`git worktree prune`	清理残留元数据
`git worktree lock <path>`	锁定 worktree 防误删

Claude Code 并行技巧

技巧	命令
Plan Mode	`Shift+Tab` × 2
跳过权限（仅沙箱）	`claude --dangerously-skip-permissions`
后台启动	`claude &`
拉回远程会话	`claude --teleport`
自定义命令	存放在 `.claude/commands/`

九、总结

Boris 的工作流之所以有效，不是因为工具多厉害，而是因为他把 Claude Code 当成可编排的基础设施：

通知让你不用盯着终端 → Worktree 让并行无冲突 → Plan Mode 让 AI 先想后做 → Slash 命令让重复操作自动化。

三条核心原则

隔离第一——每个 Claude 实例有独立的文件空间
契约先行——并行前先约定接口，边界清晰
按序集成——按依赖链方向合并，backend → node → frontend

如果你的项目也是多层架构，不妨从 2~3 个 worktree 开始尝试，体会一下一个人当一个团队用的感觉。

并行 ClaudeCode 开发实践 ​

一、iTerm2 并行环境配置 ​

安装 iTerm2 ​

标签页命名 ​

修复键盘快捷键冲突 ​

通知配置（核心） ​

汇总：iTerm2 配置清单 ​

二、Boris 的并行工作哲学 ​

核心原则 ​

工作方式详解 ​

三、Git Worktrees——并行开发的正确隔离 ​

为什么不是多分支？ ​

Worktree 基础操作 ​

四、关联性迭代的并行策略 ​

策略一：按架构层切分 Worktree ​

策略二：集成分支模式 ​

策略三：契约先行 ​

五、冲突预防与检测 ​

文件边界规则 ​

使用 clash 实时检测冲突 ​

热点文件处理策略 ​

六、完整实战流程 ​

准备工作 ​

创建 Worktree ​

各 Worktree 安装依赖 ​

启动并行 Claude Code 会话 ​

集成合并 ​

清理 Worktree ​

七、常见陷阱与解决方案 ​

1. 端口冲突 ​

2. IDE 配置 ​

3. Git Hooks 路径问题 ​

4. 忘记清理 Worktree ​

八、速查表 ​

iTerm2 快捷键 ​

Git Worktree 命令 ​

Claude Code 并行技巧 ​

九、总结 ​

参考资料 ​

并行 ClaudeCode 开发实践

一、iTerm2 并行环境配置

安装 iTerm2

标签页命名

修复键盘快捷键冲突

通知配置（核心）

汇总：iTerm2 配置清单

二、Boris 的并行工作哲学

核心原则

工作方式详解

三、Git Worktrees——并行开发的正确隔离

为什么不是多分支？

Worktree 基础操作

四、关联性迭代的并行策略

策略一：按架构层切分 Worktree

策略二：集成分支模式

策略三：契约先行

五、冲突预防与检测

文件边界规则

使用 clash 实时检测冲突

热点文件处理策略

六、完整实战流程

准备工作

创建 Worktree

各 Worktree 安装依赖

启动并行 Claude Code 会话

集成合并

清理 Worktree

七、常见陷阱与解决方案

1. 端口冲突

2. IDE 配置

3. Git Hooks 路径问题

4. 忘记清理 Worktree

八、速查表

iTerm2 快捷键

Git Worktree 命令

Claude Code 并行技巧

九、总结

参考资料