两个命令行 AI 编程助手同时开着一个窗口问架构、一个窗口改代码来回切换窗口切到手指发酸——这是我过去两个月最真实的日常。后来我干脆花了几个晚上把 Claude Code 和 Codex 这两个 CLI 工具塞进同一个终端会话里用一套统一的对话入口去调度它们。实测下来效率提升不是线性的而是少了一次上下文搬运带来的质变。这篇就把我踩过的坑、验证过的方案、以及那些文档里不会写的细节完整摊开讲一遍。先说清楚这套东西是什么、能干什么、适合谁。核心思路是用git worktree给两个工具各自准备一份独立的工作目录再用一个轻量的本地调度层我用的是一层 shell 包装加一个共享的会话记录文件把两边串起来让你在一个对话流里同时指挥 Claude Code 和 Codex。它解决的是多 AI 工具并行协作时的上下文割裂问题。适合已经能熟练使用至少一个 CLI 编程助手、想进一步做多模型协作的开发者如果你连单个工具都还没跑通建议先把基础打牢再来看这篇。1. 为什么要把两个 CLI 塞进同一个对话流1.1 单工具的天花板在哪里我用 Claude Code 处理重构类任务时体验很好它对大范围代码结构的理解比较稳改起来不容易漏。但遇到需要快速生成大量样板代码、或者做一些偏算法推导的场景Codex 的响应风格又更合我的胃口。问题在于这两个工具各自维护自己的会话上下文你在 A 里讨论的结论到 B 里得重新复述一遍。这种复述的成本被严重低估了。一次架构讨论可能涉及五六个文件的改动意图、两三个被否决的方案、以及若干边界条件。你把这些重新敲进另一个工具不只是打字时间更致命的是信息在转述中失真——你会不自觉地省略掉那些当时觉得不重要但后来发现关键的细节。我做过一个粗略统计一个中等复杂度的功能改造如果要在两个工具间来回搬运上下文光是复述和校对就要多花 20 到 30 分钟。一天做三四个这样的任务一两个小时就没了。1.2 同对话调度的真实收益把两个工具放进同一个对话流之后最直接的变化是上下文只维护一份。我在对话里说把 user 模块的鉴权逻辑抽成独立中间件Claude Code 负责分析现有结构并给出改动方案Codex 负责按方案生成具体代码两边共享同一份任务描述和同一份代码快照。这里的关键不是让两个 AI 互相聊天那种花哨玩法而是让它们共享同一个事实来源。事实来源包括当前代码状态靠 git worktree 保证一致、任务描述靠共享会话文件保证一致、以及约束条件比如不要引入新依赖这种硬性要求。提示不要指望两个工具能自动理解彼此的意图。共享上下文的前提是你把任务描述写得足够结构化让两边都能解析。我后面会讲具体怎么写。1.3 哪些场景不值得这么折腾不是所有任务都适合双工具协作。我总结下来单文件小改动、纯查询类问题、以及需要极强连续推理链的任务用单个工具反而更快。双工具的价值出现在任务可以自然拆分成分析阶段和执行阶段的时候。举个例子给一个老项目补单元测试。分析阶段需要理解现有代码的依赖关系和测试盲区这适合 Claude Code执行阶段需要批量生成测试用例这适合 Codex。两个阶段之间有清晰的交接点这种任务就是双工具协作的甜区。反过来如果你在调试一个诡异的并发 bug推理链一环扣一环中途换工具只会打断思路。这种就老老实实用一个工具跟到底。2. git worktree 是整个方案的地基2.1 为什么不用两个 clone很多人第一反应是我 clone 两份仓库不就行了。我一开始也这么干结果踩了个大坑两个 clone 的 git 历史是独立的你在 A 里提交的改动B 里看不到除非手动 push/pull。而 CLI 工具在分析代码时高度依赖 git 状态历史不一致会导致两边对当前代码是什么样的认知出现偏差。git worktree 解决的就是这个问题。它让同一个仓库可以同时检出多个工作目录共享同一份 git 对象库和引用。你在 worktree A 里的提交worktree B 立刻就能看到因为它们指向的是同一个.git目录。# 在主仓库目录下执行 git worktree add ../proj-claude -b claude-work git worktree add ../proj-codex -b codex-work这两条命令创建了两个独立的工作目录各自绑定一个分支但共享底层仓库。proj-claude给 Claude Code 用proj-codex给 Codex 用。2.2 分支策略别让两边改同一个文件worktree 虽然共享仓库但两个工作目录里的文件是独立的。如果你让两个工具同时改同一个文件合并时会痛不欲生。我的做法是按职责划分分支分支负责工具典型改动claude-workClaude Code结构重构、接口调整、依赖梳理codex-workCodex样板代码、测试用例、文档生成main人工合并与最终校验关键原则两个工作分支尽量不碰同一批文件。如果实在避不开就在任务描述里明确只改 X 文件Y 文件留给另一个工具。2.3 worktree 的清理与常见坑worktree 用久了会积累一堆废弃目录。清理命令是git worktree list # 查看所有 worktree git worktree remove ../proj-claude # 移除指定 worktree git worktree prune # 清理已删除目录的元数据我踩过的一个坑在 worktree 里删除了目录但没执行 prune导致 git 一直报worktree 已存在的错误。养成习惯删目录后立刻 prune。另一个坑是分支名冲突。如果你已经有一个叫claude-work的分支git worktree add -b会失败。这时候要么换个分支名要么先删掉旧分支。我现在的做法是用带时间戳的分支名比如claude-work-0412避免冲突。注意worktree 里的未提交改动不会自动同步到另一个 worktree。两个工具各自的工作区是隔离的只有提交之后才能互相看到。所以我在每个阶段结束时会强制提交一次哪怕只是 WIP 提交。3. 调度层怎么搭一个对话指挥两边的实现3.1 调度层的本质是一个路由所谓一个对话同时指挥两个拆开看就是你输入一句话系统判断这句话该发给谁然后把结果汇总回来。这个判断逻辑就是路由。我的路由规则很简单基于任务类型关键词包含分析梳理重构方案依赖关系→ 发给 Claude Code包含生成写测试补全批量→ 发给 Codex包含两个都看看对比一下→ 两边都发结果并排展示这套规则用 shell 脚本就能实现不需要什么复杂框架。核心是一个dispatch函数dispatch() { local task$1 if echo $task | grep -qE 分析|梳理|重构|依赖; then run_claude $task elif echo $task | grep -qE 生成|测试|补全|批量; then run_codex $task else run_claude $task run_codex $task wait fi }run_claude和run_codex分别封装了两个 CLI 的调用关键是它们都cd到各自的 worktree 目录再执行。3.2 共享会话文件的设计光有路由还不够两个工具需要共享同一份任务上下文。我用一个 Markdown 文件做这个载体叫session.md放在两个 worktree 都能访问的位置我放在主仓库根目录。文件结构大概是这样# 当前任务 把 user 模块的鉴权逻辑抽成独立中间件 # 约束 - 不引入新依赖 - 保持现有 API 签名不变 - 需要补充单元测试 # Claude Code 输出 分析结果写这里 # Codex 输出 生成代码写这里每次调度前脚本会把session.md的内容作为上下文注入到工具调用里。这样无论哪个工具接手都能看到完整的历史。3.3 处理cc switch local proxy failed这类报错热词里出现的cc switch local proxy failed while handling codex endpoint /responses这类报错本质是本地代理层在转发请求时端点不匹配。Codex 的/responses端点和 Claude Code 期望的端点格式不一样如果你的调度层直接做透明转发就会撞上这个错。我的处理方式是不做透明代理而是在调度层做协议适配。具体说就是让每个工具走自己的原生调用路径调度层只负责传参和收集结果不介入请求转发。这样虽然少了一层统一入口的优雅但稳定性高得多。如果你确实需要代理层那就要针对/responses端点单独写适配逻辑把 Codex 的请求格式转换成目标格式。这块我没有深入做因为原生调用已经够用了。4. 两个工具的安装与配置要点4.1 Claude Code 的安装路径选择Claude Code 的安装方式在不同系统上差异不小。macOS 和 Linux 下我推荐用官方脚本安装Windows 下建议走 WSL 或者用桌面版。# macOS / Linux curl -fsSL https://claude.ai/install.sh | bash # 验证安装 claude --version安装完第一件事是配置工作目录。Claude Code 默认在当前目录工作但我们的方案需要它固定在proj-claude这个 worktree 里。可以在启动时用参数指定或者在项目根目录放一个配置文件。我踩过的坑在错误的目录启动 Claude Code导致它分析的是主仓库而不是 worktree结果给出的方案和实际工作区对不上。现在的做法是在run_claude函数里硬编码cd到 worktree 目录杜绝手滑。4.2 Codex CLI 的安装与登录Codex CLI 的安装相对直接npm install -g openai/codex # 或者 brew install codex安装后需要登录。热词里提到的codex auth token is unavailable是常见问题通常是因为 token 过期或者环境变量没设置对。我的做法是把 token 存在环境变量里而不是依赖交互式登录export CODEX_API_KEYyour-key-here提示不要把 token 硬编码在脚本里然后提交到仓库。用.env文件加.gitignore或者用系统的密钥管理工具。如果遇到unable to locate the codex cli binary or required runtime components这个报错八成是 PATH 没配好。检查which codex能不能找到找不到就手动把安装路径加进 PATH。4.3 让两个工具用同一套模型配置这里有个容易被忽略的点两个工具默认可能用不同的模型。如果你希望它们在协作时风格一致需要显式配置。Claude Code 用 Anthropic 的模型Codex 默认用 OpenAI 的模型这个差异本身不是问题但你要清楚它们的输出风格会不同。我的经验是不要强行统一模型而是利用差异。Claude Code 的分析更稳Codex 的生成更快让它们各司其职比强行对齐更有价值。5. 实战一次完整的双工具协作流程5.1 任务准备与 worktree 初始化假设我要给一个 Express 项目加请求日志中间件。第一步是准备 worktreecd ~/projects/myapp git worktree add ../myapp-claude -b claude-log-0412 git worktree add ../myapp-codex -b codex-log-0412然后在主仓库根目录创建session.md写清楚任务# 任务 为 Express 应用添加请求日志中间件 # 要求 - 记录 method、path、status、耗时 - 日志格式用 JSON - 不引入新依赖用现有 logger - 需要单元测试 # 约束 - 中间件放在 src/middleware/ 目录 - 在 app.js 里注册5.2 分析阶段交给 Claude Code启动调度输入分析现有 logger 结构给出中间件接入方案。Claude Code 会读取proj-claude里的代码输出一份分析报告写进session.md的对应区块。这一步的产出通常包括现有 logger 的接口、中间件应该挂载的位置、以及需要注意的边界情况比如错误请求也要记录。5.3 生成阶段交给 Codex拿到分析报告后输入按方案生成中间件代码和测试。Codex 读取session.md里的分析结果在proj-codex里生成代码。这里有个细节Codex 看不到 Claude Code 工作区里的未提交改动。所以如果 Claude Code 在分析过程中改了代码通常不会分析阶段只读需要先提交。我的流程里分析阶段严格只读避免这个问题。5.4 合并与验证两个阶段完成后我在主仓库里合并两个分支cd ~/projects/myapp git merge claude-log-0412 git merge codex-log-0412因为两个分支改的文件不重叠合并通常很顺。然后跑测试验证npm test如果测试挂了看是哪个分支的问题回到对应的 worktree 里修再重新合并。6. 那些文档不会告诉你的坑6.1 上下文注入的长度陷阱把整个session.md注入到每次调用里听起来很美但上下文长度是有上限的。任务做久了session.md会膨胀到几千行注入成本飙升而且工具可能因为超长而截断关键信息。我的做法是分段归档当前任务只保留最近三轮的交互更早的内容移到session-archive.md。这样既控制了长度又保留了可追溯性。6.2 两个工具同时写文件的竞态如果你用让两个工具并行执行而它们恰好都要写同一个文件就会产生竞态。我遇到过 Codex 生成的代码被 Claude Code 的写入覆盖的情况。解决办法有两个一是串行执行牺牲速度换稳定二是在任务描述里明确文件归属让两个工具改不同的文件。我通常用后者因为并行带来的速度优势在复杂任务上很明显。6.3 分支合并时的冲突处理即使文件不重叠合并也可能冲突最常见的是同一个文件的 import 区块。两个工具都往app.js顶部加 import就会冲突。我的处理方式是把 import 集中到一个文件比如src/middleware/index.js两个工具都只改这个文件的导出不改app.js。这样冲突面就小多了。6.4 工具版本升级带来的行为变化CLI 工具更新很频繁有时候一个小版本升级就会改变输出格式或者参数行为。我有一次升级 Codex 之后发现它不再接受某个参数导致调度脚本报错。建议是锁定版本在项目里记录当前使用的版本号升级前先在测试任务上验证。别在生产流程里用latest。7. 进阶把调度层做得更聪明7.1 基于历史成功率的路由固定关键词路由有个问题有些任务边界模糊关键词匹配不准。我后来加了一层历史成功率统计记录每次任务由哪个工具完成、结果是否被采纳然后在新任务到来时优先选成功率高的工具。实现上就是一个简单的计数文件每次任务结束后更新。不需要机器学习纯统计就够用。7.2 让两个工具互相 review一个有意思的玩法是让 Claude Code 生成方案Codex 来 review反之亦然。这利用了不同模型的盲区差异——一个模型漏掉的问题另一个可能正好能发现。具体做法是在调度层加一个review模式把 A 的输出作为 B 的输入要求 B 指出问题。实测下来这种交叉 review 能抓到不少单工具会漏掉的边界情况。7.3 与编辑器集成如果你用 VS Code可以把调度脚本挂到一个 task 上用快捷键触发。热词里提到的vscode配置claude code和vscode安装claude code是基础配置我这里说的是更进一步把双工具调度做成一个 VS Code task选中代码后一键发送给指定工具。配置大概是这样{ version: 2.0.0, tasks: [ { label: dispatch-to-claude, type: shell, command: ./scripts/dispatch.sh claude ${selectedText} }, { label: dispatch-to-codex, type: shell, command: ./scripts/dispatch.sh codex ${selectedText} } ] }这样选中一段代码按快捷键就能发给指定工具省去复制粘贴。8. 稳定性与日常维护8.1 定期清理 worktree 和分支worktree 和分支会越积越多。我每周做一次清理列出所有 worktree删掉超过一周没用的prune 掉元数据然后删掉对应的已合并分支。git worktree list git branch --merged | grep -E claude-|codex- | xargs git branch -d git worktree prune8.2 会话记录的备份session.md和归档文件是这套方案的核心资产记录了所有协作历史。我把它纳入 git 管理但放在一个独立的分支上避免污染主分支。这样既能追溯又不会影响代码仓库的整洁。8.3 监控工具调用的失败率调度脚本里加一层日志记录每次调用的耗时和结果状态。如果某个工具的失败率突然升高通常是 token 过期或者服务端问题。我设了个简单的阈值告警连续三次失败就打印醒目提示。这套方案我用了两个多月最大的体会是双工具协作的价值不在于工具本身多强而在于你能否把任务拆成适合不同工具的阶段。工具是死的拆分逻辑是活的。我见过有人把两个工具硬凑在一起结果比单工具还慢问题就出在没想清楚任务该怎么分。另外一个小技巧刚开始别追求全自动。先用半自动的方式跑通流程——手动决定每个任务发给谁手动合并结果。跑顺了再逐步加自动化。我一开始就想搞全自动路由结果因为规则没调好把分析任务发给了 Codex生成了一堆没用的代码白白浪费了半天。