两个 AI 编程助手同时在终端里跑一个负责写一个负责审听起来像是左右互搏的骚操作但实际用下来这套组合能把我日常改代码的效率拉高一大截。Claude Code 和 Codex 都是命令行里的 AI 编程工具前者擅长理解上下文、做重构和写测试后者在补全、快速生成片段和跨文件改动上有自己的节奏。问题在于它们默认各自为战你想让两个工具看到同一份代码状态、共享同一套改动就得手动来回切目录、复制粘贴烦得很。这篇内容就是讲我怎么用 git worktree 加一层轻量调度让一个对话窗口同时指挥这两个 CLI把双 AI 协作从概念变成每天能用的工作流。适合已经在用 Claude Code 或 Codex CLI、想进一步压榨效率的开发者也适合刚接触命令行 AI 工具、想少走弯路的新手。1. 为什么要把两个 CLI 塞进同一个对话里1.1 单工具的天花板在哪里我先说清楚一个前提Claude Code 和 Codex 不是互相替代的关系它们的强项有重叠但重心不同。Claude Code 在长上下文理解、多文件重构、按自然语言指令生成测试用例这些场景里表现稳定尤其是你给它一个明确的改哪里、改成什么样的指令它能顺着项目结构一路改下去。Codex 的优势则在于响应快、补全准适合在写代码的过程中随时插入做一些局部生成和快速修正。但单独用任何一个都会遇到瓶颈。比如我用 Claude Code 做一次跨五个文件的重构它改完之后我想让另一个视角检查一下有没有遗漏的边界情况这时候要么我自己读一遍要么再开一个 Claude Code 会话重新描述需求。前者费眼睛后者费 token 还容易漏掉上下文。Codex 这边也一样它快速生成了一段逻辑我想让 Claude Code 帮忙补测试就得把代码复制过去再描述一遍背景。这种来回切换的成本单次看不多一天下来累积起来很可观。更麻烦的是状态不一致两个工具看到的代码版本可能不同改着改着就冲突了。1.2 双工具协作的真实收益把两个工具放进同一个对话调度里之后最直接的变化是一个指令两个视角。我给一个任务描述Claude Code 负责主体实现Codex 负责快速验证和补充两边看到的是同一份工作区状态。举个我实际遇到的场景要给一个数据处理模块加缓存层。我让 Claude Code 先出实现方案并落地代码然后同一个对话里让 Codex 针对新加的缓存逻辑生成边界测试最后再让 Claude Code 根据测试结果修一轮。整个过程不需要我手动同步任何文件。收益体现在三个地方。第一是上下文一致性两个工具操作的是同一个 git worktree不存在版本漂移。第二是角色分工明确一个主攻实现一个主攻验证比让同一个工具既写又审更客观。第三是对话连续性所有指令和结果都在一个会话里回溯起来方便不像以前要在多个终端标签页之间找记录。提示双工具协作不是让你同时开两个窗口各干各的那样反而更乱。核心是一个调度层两个执行体调度层负责分发任务和同步状态。1.3 适合引入这套工作流的场景不是所有任务都值得上双工具。我总结下来这几类场景收益最明显跨多文件的系统性改动、需要实现加验证闭环的任务、涉及陌生代码库需要快速建立理解的探索性工作、以及需要反复迭代的算法调优。反过来如果只是改个变量名、调个格式单工具甚至手动改更快硬上双工具就是给自己找事。另外这套工作流对机器资源有一定要求。两个 CLI 同时跑加上 git worktree 的磁盘开销内存和磁盘都要留够余量。我一般建议至少 16GB 内存起步磁盘上每个 worktree 按项目大小预留大项目一个 worktree 几个 GB 是常事。2. git worktree 是整个方案的地基2.1 worktree 解决了什么根本问题很多人第一反应是我直接开两个终端cd 到同一个目录不就行了。不行因为两个 CLI 如果同时改同一份工作区文件会互相覆盖git 状态也会乱。你需要的是同一份仓库历史不同的工作目录这正是 git worktree 干的事。git worktree 允许你从同一个仓库检出多个工作树每个工作树有自己独立的工作目录和索引但共享同一个 .git 对象库。这意味着分支切换、提交历史这些是共享的但文件改动互不干扰。对双 AI 协作来说这简直是量身定做的Claude Code 在 worktree A 里改Codex 在 worktree B 里改两边基于同一个提交起点改完之后再合并。我试过不用 worktree、直接复制两份代码目录的做法结果是 git 历史对不上合并的时候冲突一堆还不如手动改。worktree 的好处是它天然带着 git 的版本管理能力合并、对比、回滚都有现成工具。2.2 创建和管理 worktree 的实操基础命令不复杂但有几个细节容易踩坑。先看创建# 在主仓库目录下执行 git worktree add ../project-claude -b feat/claude-work git worktree add ../project-codex -b feat/codex-work这两条命令分别在上级目录创建了两个工作树各自绑定一个新分支。注意分支名要区分开否则 git 会拒绝因为同一个分支不能同时被两个 worktree 检出。查看现有 worktreegit worktree list输出会列出主工作树和所有附加工作树及其对应分支。清理不再需要的 worktreegit worktree remove ../project-codex如果 worktree 里有未提交的改动remove 会失败需要先处理掉或者加--force。我一般不用 force因为那意味着有改动没保存强制删掉就丢了。注意worktree 的路径不要放在主仓库目录内部否则 git 会把它当成未跟踪文件各种工具扫描的时候也会重复处理。放在同级或上级目录最稳妥。2.3 worktree 与两个 CLI 的目录绑定策略关键决策是哪个工具用哪个 worktree。我的做法是让 Claude Code 用主攻实现的 worktreeCodex 用验证和补充的 worktree。这样分工清晰合并方向也明确——从 Codex 的 worktree 往 Claude Code 的 worktree 合或者反过来取决于谁的工作是最终版本。但这里有个坑两个 worktree 如果都从同一个分支切出来改完之后合并冲突可能很多。我的经验是让它们基于同一个提交点但各自只改自己负责的部分减少重叠。如果任务本身就需要两边改同一批文件那不如串行执行先让一个改完提交另一个再基于新提交开 worktree。还有一个细节是依赖安装。每个 worktree 是独立的工作目录node_modules、虚拟环境这些不会自动共享。如果项目依赖重两个 worktree 各装一份很占磁盘。我的处理方式是能共享的依赖用软链接指过去不能共享的比如有平台相关编译产物的就各装各的。这个取舍要看具体项目没有一刀切的答案。3. 调度层怎么设计才能让一个对话指挥两个 CLI3.1 调度层的核心职责拆解调度层不是要你写一个复杂的框架它的职责就三件事任务分发、状态同步、结果汇总。任务分发是把我的自然语言指令翻译成两个 CLI 各自能理解的调用状态同步是确保两个 worktree 的 git 状态在关键节点对齐结果汇总则是把两边的输出整理成我能读的形式。我用的是一个轻量的 shell 脚本加一个约定好的目录结构。脚本负责接收指令、决定分发给谁、收集输出。目录结构里放两个 worktree 的路径配置和一个共享的任务日志。这样我不需要记复杂的命令一个入口就能操作两边。为什么不直接用某个现成的多 agent 框架因为那些框架往往有自己的抽象层配置成本高而且对 CLI 工具的调用方式有假设。我的需求很具体自己搭一层反而更可控出问题也好排查。3.2 指令分发的实现思路分发逻辑的核心是判断这个任务该给谁。我用的规则比较简单涉及多文件重构、需要理解项目结构的给 Claude Code涉及局部生成、快速验证、写测试片段的给 Codex不确定的先给 Claude Code 出方案再让 Codex 验证。实现上我用一个函数封装对每个 CLI 的调用。Claude Code 的调用形式大致是传入指令和 worktree 路径Codex 类似。关键是每次调用前要 cd 到对应的 worktree调用完把输出重定向到日志文件。run_claude() { local task$1 cd $CLAUDE_WORKTREE || exit 1 claude-code --task $task $LOG_DIR/claude.log 21 } run_codex() { local task$1 cd $CODEX_WORKTREE || exit 1 codex --task $task $LOG_DIR/codex.log 21 }实际调用时我会先跑 Claude Code等它完成并提交再跑 Codex 基于新提交做验证。这个顺序很重要否则 Codex 验证的是旧代码结论没意义。3.3 状态同步的关键节点状态同步最容易出问题的地方是什么时候该合并、什么时候该重新拉取。我的做法是在三个节点做同步任务开始前、Claude Code 完成实现后、Codex 完成验证后。任务开始前确保两个 worktree 都基于最新的主分支提交。这步用git fetch加git rebase或者直接重新创建 worktree。我倾向于重新创建因为干净不会有残留改动干扰。Claude Code 完成后把它的改动提交然后让 Codex 的 worktree 拉取这个提交。这样 Codex 验证的就是最新实现。Codex 完成后如果它只是加了测试没改实现就把测试合并回 Claude Code 的 worktree如果它改了实现就要人工看一下改动是否合理再决定合并方向。提示每次同步前先git status确认没有未提交的改动否则 rebase 或 merge 会失败。这个习惯能省掉很多莫名其妙的报错。4. 实际跑起来会遇到的那些坑4.1 CLI 调用失败与路径问题最常见的报错是找不到 CLI 可执行文件。Claude Code 和 Codex 安装后可执行文件路径可能不在当前 shell 的 PATH 里尤其是用不同方式安装的比如通过包管理器 vs 直接下载二进制。我的处理是在调度脚本开头显式声明路径不依赖 PATH。另一个高频问题是 worktree 路径里有空格或特殊字符导致 cd 失败。项目路径尽量用纯英文加连字符别用中文和空格这是省事的做法。还有一种情况是 CLI 需要认证信息两个工具各自的认证状态是独立的。如果认证过期调用会静默失败或者报一个含糊的错误。我一般会在脚本里加一个前置检查跑一个最简单的命令确认认证有效再执行正式任务。4.2 两个工具改同一文件的冲突处理即使有 worktree 隔离如果两个工具都改了同一个文件的同一区域合并时还是会冲突。我的经验是尽量在任务分配阶段就避免这种情况明确告诉 Claude Code 改哪些文件告诉 Codex 只碰测试文件或只读不改。如果实在避不开冲突处理就按正常 git 流程走。但有个技巧让 Claude Code 来做冲突解决因为它对上下文理解更好。把冲突文件交给它描述清楚两边的意图它通常能给出合理的合并结果。Codex 在这方面容易只看局部合出来的结果可能破坏另一边的逻辑。4.3 资源占用与并发控制两个 CLI 同时跑CPU 和内存占用会明显上升。我实测下来如果两个都在做重活比如大范围重构加全量测试生成机器会卡。解决办法是错峰让 Claude Code 先跑跑完再让 Codex 跑。虽然总时间长了点但稳定性好很多。如果非要并发给每个 CLI 限制资源。Linux 下可以用nice和cpulimitmacOS 下用nice调优先级。另外注意磁盘 IO两个 worktree 同时大量读写会拖慢整体速度SSD 是基本要求。4.4 日志与可追溯性双工具协作如果不记日志出了问题根本不知道是谁改的、什么时候改的。我在调度脚本里强制每个 CLI 的输出都写到独立日志文件并且带上时间戳和任务标识。这样回溯的时候能清楚看到每个步骤。日志目录我单独放在仓库外面避免被 git 跟踪。日志文件按日期滚动太老的定期清理不然磁盘会被撑满。这个习惯看起来琐碎但真出问题的时候能救命。5. 一套可复用的双工具协作流程5.1 从任务描述到分工的拆解方法拿到一个任务我第一步不是直接跑工具而是先拆解。拆解的标准是哪些部分是实现哪些部分是验证哪些部分是探索。实现类给 Claude Code验证类给 Codex探索类看情况——如果需要深入理解代码库结构给 Claude Code如果只是快速试几个方案给 Codex。拆解完之后我会写一个简短的任务说明包含目标、涉及的文件范围、验收标准。这个说明同时给两个工具看确保它们对任务的理解一致。别小看这一步很多协作失败是因为两个工具对任务的理解有偏差各改各的。5.2 执行顺序与检查点设置执行顺序我固定为Claude Code 实现 → 提交 → Codex 验证 → 汇总。中间设两个检查点Claude Code 完成后检查改动是否符合预期Codex 完成后检查验证结论是否合理。检查点不是形式是真的要停下来看。我踩过的坑是让两个工具一路跑到底结果发现 Claude Code 理解错了需求Codex 基于错误实现做了一堆无用验证全白干。现在我宁愿多停两次也不让它们盲目往下跑。5.3 结果合并与最终验证合并的时候如果 Codex 只加了测试直接 merge 回主 worktree 就行。如果 Codex 改了实现我会先 diff 看改动确认合理再合。合并完跑一遍完整测试确保两边的工作叠加后没有破坏性影响。最终验证我一般会再让 Claude Code 做一次整体 review因为它对全局的把控更好。这一步相当于第三只眼能发现前两步遗漏的问题。虽然多花点时间但换来的是更高的代码质量。6. 几个提升效率的细节技巧6.1 用别名简化高频命令调度脚本里的命令我配了一堆 shell 别名比如cc-run触发 Claude Code 任务cx-run触发 Codex 任务sync-wt同步两个 worktree。这样日常操作就是几个短命令不用记长串参数。别名写在 shell 配置文件里换机器的时候一起带过去。6.2 任务模板化减少重复描述有些任务是反复出现的比如给这个模块加测试重构这个函数。我把这些常见任务的描述做成模板用的时候填几个变量就行。模板里包含固定的上下文说明和验收标准减少每次重新描述的成本也保证两个工具收到的指令质量稳定。6.3 定期清理 worktree 和日志worktree 和日志不清理会越积越多。我设了一个每周的清理任务把已经合并完的 worktree 删掉日志按保留策略清理。清理前确认对应分支已经合并或者不再需要避免误删还在用的工作树。6.4 根据任务类型动态调整分工不是所有任务都按Claude Code 实现、Codex 验证这个固定分工。有时候任务很简单Codex 直接实现更快那就让它主攻Claude Code 只做最后 review。有时候任务需要深度理解Claude Code 全程主导Codex 只做局部补充。分工是手段不是目的怎么高效怎么来。我在实际使用中最大的体会是这套工作流的价值不在于用了两个工具而在于它强迫我把任务拆解清楚、把验收标准写明白。很多时候工具没出问题是我自己的任务描述太模糊导致两个工具都跑偏。把任务想清楚比选什么工具重要得多。另外worktree 的隔离机制是这套方案的命脉一旦绕过它直接在同一目录操作各种诡异问题就会冒出来别图省事。