5.4 多工具协同（双开 / 多开）
预计耗时：12 分钟
本关任务简报
前面三关都在讲"从别的工具换到 Claude Code"。但现实里，很多高手不止用一个工具——Claude Code 干一类活，Cursor 干另一类，甚至让两个 AI 互相审查对方的代码。
为什么？因为每个工具有自己的主场（前面也反复提到：Claude Code 擅长 agentic 重活，IDE 助手擅长行内补全）。与其纠结"该用哪个"，不如让它们各干各擅长的，再互相配合。
这一关讲清楚：有哪些值得用的协同模式，怎么操作，以及双开会带来哪些坑（文件冲突、git 变脏、成本翻倍）该怎么躲。
先说清楚：这是进阶玩法，慎用
多工具协同属于"锦上添花"，不是用好 Claude Code 的前提。本关讲的模式更多是提供思路和借鉴——是否值得尝试，取决于你的项目复杂度、预算和熟练度，需要你结合自己的真实需求来权衡。如果你还在打基础阶段，完全可以先跳过，把单个工具用顺了再回来看。
通关奖励：解锁以下技能
- 🤝 掌握 4 种实用的多工具协同模式
- 🔀 用 Git Worktree 让多个实例并行又不打架
- 🔁 用 cc switch 切模型，让 Claude Code 自己给自己当"第二意见"
- ⚠️ 认清双开/多开的三大问题并知道怎么规避
开始前先检查装备
| 前置知识 | 说明 |
|---|---|
| 3.3 Git Worktree 并行实例 → | 多实例并行的隔离基础，本关的分工模式要用到 |
| 3.8 cc switch → | 切换不同平台模型的工具，"第二意见"模式要用到 |
机制解析
为什么要多工具协同
两个核心动机：
- 能力互补：让每个工具干它最擅长的，整体效率比单工具高。
- 交叉审查：一个工具写、另一个审。换一个"大脑"看代码，更容易发现第一个工具的盲区——比你自己从头审查省时。
模式一：交叉审查（一个写，一个审）
最有价值、也最容易上手的模式。两种方向：
- Claude Code 写 → 别的工具审：Claude Code 完成功能后，把改动交给 Codex / Cursor 审一遍。
- 别的工具写 → Claude Code 审：用
/review或直接让 Claude Code 审查另一个工具产出的代码。
操作上不需要工具直接对话——它们通过代码本身交接。审查方读的是已经写进文件的改动：
@刚改动的文件 这是另一个 AI 写的实现，帮我审查：
有没有逻辑漏洞、边界没处理、安全问题？给出具体行号和修改建议。模式二：分工并行 + Worktree 隔离
想让两个实例同时干不同的活（比如一个重构旧模块、一个写新功能），直接在同一个目录开两个会很容易互相覆盖文件。
正确做法是用 Git Worktree 给每个实例一个独立工作目录、各自一个分支，物理隔离、互不干扰：
git worktree add ../proj-feature -b feature-branch
git worktree add ../proj-refactor -b refactor-branch然后在两个目录里各开一个实例——可以都开 Claude Code，也可以一个开 Claude Code、另一个开别的工具。完整用法见 3.3 Git Worktree 并行实例 →。
模式三：能力互补（重活 / 轻活分开）
不需要复杂配置，纯粹是使用习惯：
- 行内补全、改一两行：用 IDE 助手（Cursor Tab、Copilot）——修改更精准、随手就能改。
- 跨多文件的成块任务、要跑命令验证的：交给 Claude Code。
最顺的姿势是把 Claude Code 开在编辑器的终端里（VS Code / Cursor 都行，见 2.11 IDE 集成 →）：左边编辑器补全照用，终端里 Claude Code 做 agentic 任务，改动还能在编辑器里看内联 diff。
模式四：cc switch 切模型当"第二意见"
不想真的开两个工具？在 Claude Code 内部也能制造"第二意见"——用 cc switch 切到另一个平台的模型，让它重审一遍同一段代码：
- 用模型 A 写完 / 审完
- 用 cc switch 切到模型 B（见 3.8 →）
- 让模型 B 重新审一遍
不同模型的盲区不一样，换一个重看常能挖出第一个漏掉的问题。这是单工具就能做到的"轻量交叉审查"。
双开/多开的三大问题
多工具不是免费的，下面这些坑要心里有数：
| 问题 | 会发生什么 | 如何避免 |
|---|---|---|
| 文件冲突 | 两个工具同时改同一批文件，互相覆盖 | 分目录 / 分支 / 用 Worktree 物理隔离 |
| git 变脏 | 多来源改动混在一起，难追溯谁改了啥 | 分支隔离，每个工具的改动单独 commit，commit message 标注来源 |
| 成本翻倍 | 两个工具都烧订阅 / token | 想清楚每个工具的分工，别让它们做重复的活 |
还有一点：工具之间不共享对话上下文。模型 A 的思路模型 B 不知道，交接全靠代码、commit message 和 CLAUDE.md。所以交接点要把信息写进文件，而不是指望它们"心有灵犀"。
开始闯关
目标：跑通一次"一个写、一个审"的协同。
第 1 步：选一个小功能，让 Claude Code 实现
帮我实现 [一个小功能]，改动写进对应文件第 2 步：换一个"大脑"审查
两选一：
- 用 cc switch 切到另一个模型，让它审（模式四）
- 或把改动交给你手边的另一个工具（Codex / Cursor）审
@刚才改动的文件 帮我审查这段实现的逻辑漏洞和边界问题第 3 步（进阶）：用 Worktree 开两个实例分工
按 3.3 → 建两个 worktree，一个实例写新功能、一个实例修 bug，体会物理隔离下的并行。
第 4 步：留意摩擦
过程中注意有没有文件冲突、git 记录乱不乱，对照上面的"如何避免"调整。
通关检定
- [ ] 跑通了一次"一个写、一个审"的交叉审查
- [ ] 知道并行改动要用 Worktree 隔离，避免文件冲突
- [ ] 会用 cc switch 切模型制造"第二意见"
- [ ] 理解工具间不共享上下文，交接要靠代码 / commit / CLAUDE.md
- [ ] 清楚双开的三大问题及规避方法
全部点亮就算通关 ✓
卡关了？翻车指南在这
两个工具改完，代码乱成一团 / 互相覆盖了
大概率是没隔离。同时改动一定要分支或 Worktree 隔离，别在同一个目录、同一个分支上让两个工具乱来。
交叉审查时，审查方"看不懂"另一个工具的思路
正常——它们不共享对话。审查方只能基于代码本身判断。如果上下文不够，把相关的设计意图、约束写进提示或 CLAUDE.md 再让它审。
感觉双开反而更慢、更费了
可能是分工没分清，两个工具在做重复的活。回到"能力互补"原则：明确谁干重活、谁干轻活，别让它们抢同一件事。
到底要不要双开？
再强调一次：多工具协同是进阶选项，不是必修。它带来的提效要能盖过上面那些问题摩擦才划算。先掂量自己的真实情况——项目够不够复杂、预算够不够、是否已经把单个工具用熟——再决定要不要上，别为了双开而双开。还在打基础阶段的话，先把 Claude Code 一个工具用顺，比急着多开更值。
🎉 全站通关
这一章到此结束。你已经能把原工具的经验平移到 Claude Code，也知道了怎么让多个工具配合。
如果还没系统过一遍 Claude Code，建议回到 🚀 快速上手 → 或 ⚙️ 基础使用 → 打好基础；想随手查命令和快捷键，去 🧰 工具箱 →。