1. 为什么要把 Claude Code 和 Codex 放在一起用1.1 两个 CLI 各自的脾气先说结论Claude Code 和 Codex 这两个命令行工具单独拎出来都能打但它们的强项完全不在一个方向上。Claude Code 的长处是理解大段上下文、做重构、写文档、梳理复杂逻辑你给它一个几千行的模块让它分析它能给你讲得头头是道。Codex 的强项则是补全、局部改写、快速生成小片段响应快、token 消耗相对可控适合那种我就想让它把这段函数改一下的场景。问题就出在这——实际干活的时候你往往两个需求同时存在。比如我在重构一个老项目一边要让 Claude Code 通读整个目录结构给我出重构方案一边又想让 Codex 帮我把某个具体函数快速改掉。以前的做法是开两个终端窗口左边敲 Claude右边敲 Codex来回切换上下文还得手动复制粘贴。切一次两次还行一天切上百次人就麻了。所以一个对话同时指挥两个这个需求本质上不是炫技而是减少上下文搬运成本。你希望在一个输入框里说一句话背后自动决定这句话该交给谁处理或者两个都处理然后你挑结果。1.2 一个对话指挥两个到底指什么这里得先把概念说清楚不然容易跑偏。一个对话同时指挥两个有三层含义复杂度递增第一层是统一入口。你只面对一个 CLI 界面输入自然语言背后路由到 Claude Code 或 Codex。这一层解决的是我不想记两套命令。第二层是共享上下文。两个工具看到同一份项目状态、同一份对话历史。这一层解决的是我不想重复解释背景。第三层是协同编排。一句话触发两个工具按顺序或并行工作比如让 Claude 出方案Codex 按方案改代码。这一层解决的是我想让它们配合。大部分人的真实需求停在前两层第三层属于锦上添花。我下面会按这个顺序讲从最容易落地的方案开始。1.3 适合谁来参考这篇内容适合三类人一是已经在用 Claude Code 或 Codex 其中一个想试试两个一起用的二是被多终端切换折磨、想找个统一工作流的三是对 CLI 工具编排感兴趣、想自己搭一套的。如果你连其中一个都没装过建议先把单个跑通再来看这篇不然会有点懵。基础安装部分我会简单带过重点放在怎么让它们协同上。提示本文所有方案都基于本地 CLI 工具的常规用法不涉及任何网络代理配置。如果你在安装环节遇到网络问题请参考各工具官方文档的说明。2. 方案选型三种思路的取舍2.1 思路一Shell 别名 手动路由最土但最稳的办法就是写几个 shell 函数把两个工具包一层。比如你定义ask命令根据参数决定调哪个# 放到 ~/.zshrc 或 ~/.bashrc ask_claude() { claude $ } ask_codex() { codex $ } # 统一入口第一个参数选工具 ask() { local tool$1 shift case $tool in c|claude) ask_claude $ ;; x|codex) ask_codex $ ;; *) echo 用法: ask [c|x] 你的问题 ;; esac }这样你输入ask c 帮我看看这个模块就走 Claudeask x 改一下这个函数就走 Codex。优点是零依赖、绝对可控、出问题一眼能看出是哪层。缺点是它没解决共享上下文的问题你还是得自己管对话历史。我早期就是用这个方案过渡的大概用了两周。它的价值在于让你先建立起哪个任务交给谁的直觉等你摸清楚分工规律了再上更复杂的方案会顺很多。2.2 思路二git worktree 隔离 双工具并行这个方案是我个人最推荐的也是热词里git worktree出现频率很高的原因。核心思路是用 git worktree 给两个工具各自开一个独立工作目录共享同一个 git 仓库。为什么需要隔离因为 Claude Code 和 Codex 都可能直接改你的文件。如果两个工具同时改同一个工作区轻则互相覆盖重则 git 状态乱成一锅粥你想回滚都不知道回滚到哪一步。worktree 的好处是每个工作目录有独立的文件状态但共享.git对象库分支管理还是统一的。具体操作# 在主仓库目录下 git worktree add ../proj-claude -b feat/claude git worktree add ../proj-codex -b feat/codex这样你就有了两个目录proj-claude和proj-codex分别对应两个分支。Claude Code 在proj-claude里干活Codex 在proj-codex里干活互不干扰。等两边都改完了你再在主仓库里 merge 或者 cherry-pick。这个方案的精髓在于把并行变成分支合并用 git 本身的能力解决冲突而不是靠工具之间的实时同步。实测下来这比任何实时同步方案都稳因为 git 的合并逻辑是经过千锤百炼的。2.3 思路三中间层编排Orkas 类思路热词里出现了Orkas这类工具的思路是做一个中间层把多个 CLI 工具包装成统一的 agent 接口由中间层决定任务分发给谁。听起来很美但实际用起来有几个坑一是中间层本身要维护工具升级了它可能就挂了二是路由逻辑很难做准什么任务该给谁规则写死了不灵活用模型判断又增加延迟和不确定性三是调试困难出问题你分不清是中间层的问题还是底层工具的问题。我的建议是除非你有明确的、重复性极高的编排需求否则别上中间层。先用 worktree 方案把并行跑通等你真的觉得手动 merge 太累了再考虑自动化。2.4 三种方案对比方案落地难度上下文共享冲突处理适合场景Shell 别名极低无手动单人、任务切换不频繁git worktree低通过 git 间接共享git merge并行改代码、需要隔离中间层编排高完全共享依赖实现团队、高频重复编排选哪个取决于你的痛点在哪。如果你只是嫌切换麻烦方案一够了如果你要两个工具同时改代码方案二如果你要的是一句话自动分派那才需要方案三但要做好踩坑的准备。3. 核心实操用 git worktree 搭一套双工具工作流3.1 环境准备与工具安装确认先把两个工具都装好确认能单独跑起来。Claude Code 的安装方式各平台略有差异Mac 上一般是通过包管理器或者官方脚本Windows 上现在也有桌面版和 CLI 版。Codex 同理装完之后用codex --version之类的命令确认一下。这里有个常见坑两个工具可能依赖不同版本的运行时。比如一个要 Node 18一个要 Node 20。如果你用全局安装很容易打架。我的做法是用版本管理工具比如 nvm 或 fnm给不同项目切不同版本或者干脆用容器隔离。确认清单claude --version能正常输出版本号codex --version能正常输出版本号两个工具都能在目标项目目录下正常启动git 版本在 2.5 以上worktree 需要注意如果你在安装 Codex 时遇到 unable to locate the codex cli binary or required runtime components 这类报错八成是 PATH 没配好或者运行时缺失。先解决单个工具的安装问题再谈协同。3.2 用 worktree 建立隔离工作区假设你的项目在~/work/myproj先确认当前工作区是干净的cd ~/work/myproj git status如果有未提交的改动先 commit 或者 stash 掉。然后创建两个 worktreegit worktree add ../myproj-claude -b ai/claude-work git worktree add ../myproj-codex -b ai/codex-work执行完git worktree list应该能看到三个工作区主仓库、claude 工作区、codex 工作区。这里有个细节值得说分支命名建议带前缀比如ai/claude-work这样后面 merge 的时候一眼能看出这是 AI 工具产出的分支方便审查。我见过有人直接叫dev1、dev2过两天自己都忘了哪个是哪个。3.3 让两个工具各就各位现在开两个终端窗口或者用 tmux 分屏一个进myproj-claude一个进myproj-codex# 终端 1 cd ~/work/myproj-claude claude # 终端 2 cd ~/work/myproj-codex codex这时候两个工具就在各自的工作区里跑起来了。你在 Claude 那边让它重构某个模块在 Codex 那边让它改另一个函数两边改的文件物理上就是分开的不会互相踩。但这里有个关键问题两个工作区的代码基线是一样的吗是的因为它们都是从同一个 commit 切出来的。所以 Claude 看到的代码和 Codex 看到的代码起点完全一致。这就是 worktree 方案的精髓——隔离的是改动共享的是历史。3.4 合并两边成果的实操流程等两边都干完活回到主仓库合并。假设 Claude 改了src/core.jsCodex 改了src/utils.js两个文件不冲突cd ~/work/myproj git merge ai/claude-work git merge ai/codex-work如果改的是同一个文件git 会提示冲突这时候你手动解决就行。因为两个分支的基线相同冲突范围通常很小比两个工具实时抢文件要好处理得多。我一般会先 merge 一个跑一遍测试再 merge 另一个。这样出问题能快速定位是哪个分支引入的。如果两个一起 merge测试挂了你还得二分排查浪费时间。3.5 清理工作区活干完了worktree 要记得清理不然目录越堆越多git worktree remove ../myproj-claude git worktree remove ../myproj-codex git branch -d ai/claude-work git branch -d ai/codex-workgit worktree remove会检查有没有未提交的改动有的话会拒绝删除这是保护机制。如果你确定不要了加--force。4. 上下文共享的几种土办法4.1 用共享文件当公共黑板worktree 解决了文件隔离但没解决上下文共享。两个工具不知道对方在干什么。最简单的办法是搞一个共享的说明文件比如在项目根目录放一个AI_CONTEXT.md两个工具都读它。但 worktree 是独立目录这个文件怎么共享答案是放在主仓库里然后让两个 worktree 都软链接过去或者干脆每次手动同步。软链接的做法# 在主仓库创建 echo # 当前任务上下文 ~/work/myproj/AI_CONTEXT.md # 在两个 worktree 里链接 ln -s ~/work/myproj/AI_CONTEXT.md ~/work/myproj-claude/AI_CONTEXT.md ln -s ~/work/myproj/AI_CONTEXT.md ~/work/myproj-codex/AI_CONTEXT.md这样你在任何一个工作区更新这个文件另一个立刻能看到。我一般会在里面写当前在做什么任务、已经改了哪些文件、有哪些约定。两个工具启动时我都会让它们先读这个文件。4.2 对话历史的导出与注入CLI 工具的对话历史通常存在本地某个目录格式各家不同。想跨工具共享对话历史实操上比较麻烦因为格式不通用。我的做法是不共享原始历史而是共享摘要。具体来说每完成一个阶段我会让当前工具输出一段总结刚才做了什么、结论是什么、下一步建议。然后把这段总结贴到AI_CONTEXT.md里。另一个工具读这个文件就相当于拿到了压缩后的上下文。这个办法听起来笨但实测非常有效。因为原始对话历史里大量是过程性的废话真正有价值的就是结论。让工具自己总结一遍反而比直接喂原始历史更清晰。4.3 用 git commit message 传递意图还有一个被低估的上下文载体commit message。Claude 改完代码提交时让它写清楚为什么这么改。Codex 那边git log一看就知道另一个工具的思路。我习惯让 AI 工具提交时用固定格式[claude] 重构 core 模块拆分出 validator - 原因原函数超过 200 行难以测试 - 影响core.js 导出接口不变这样git log --oneline一眼就能看出哪个工具做了什么、为什么做。合并的时候审查起来也快。5. 常见问题与排查实录5.1 工具启动报错类问题问题Codex 报 auth token is unavailable这是认证状态丢了。Codex 的登录态一般存在本地配置目录可能是过期了或者被清理了。重新走一遍登录流程即可。如果你在多个环境切换注意配置目录别被覆盖。问题Claude Code 报 internetopenurl() failed这类报错通常是网络请求环节出的问题可能是本地网络环境、DNS 或者工具自身的请求逻辑。先确认基础网络能通再看工具是否需要特定配置。这类问题排查顺序是网络连通性 → 工具配置 → 工具版本。问题两个工具都装了但命令找不到PATH 问题。检查which claude和which codex是否有输出。没有的话把安装目录加到 PATH 里。Windows 上还要注意用户变量和系统变量的区别。5.2 worktree 使用中的坑坑一worktree 目录被工具当成新项目有些工具会根据目录名或者.git的存在判断项目根。worktree 目录里.git是个文件指向主仓库不是目录。大部分工具能正确处理但少数工具会懵。如果遇到可以在 worktree 里跑一下git rev-parse --show-toplevel确认 git 认得它。坑二忘记清理导致分支混乱worktree 用多了git branch里一堆ai/xxx分支。建议养成习惯任务结束就 remove 删分支。我一般会在每周五清理一次把没用的 worktree 和分支都干掉。坑三两个 worktree 同时跑测试抢资源如果两个工具都在跑测试可能抢端口、抢临时文件。解决办法是给它们分配不同的端口范围或者错开跑测试的时间。我一般让 Claude 那边跑单元测试Codex 那边只做静态检查避免资源冲突。5.3 排查速查表现象可能原因排查动作工具命令找不到PATH 未配置which确认检查安装目录认证失败登录态过期重新登录检查配置目录worktree 创建失败分支已存在git branch查看换分支名合并冲突多两边改了同一文件缩小任务范围错开文件工具读不到上下文共享文件未同步检查软链接确认路径测试互相干扰端口/临时文件冲突分配不同端口错开执行5.4 几个我踩过的坑第一个坑是过早追求自动化。我一开始就想搞个脚本自动路由结果规则越写越复杂最后自己都维护不动。后来退回到手动选工具反而效率更高。自动化的前提是你已经清楚知道什么任务给谁这个认知得靠手动阶段积累。第二个坑是让两个工具改同一个文件。哪怕有 worktree 隔离合并的时候冲突还是很难受。后来我定了个规矩同一个文件同一时间只让一个工具碰。要改就排队Claude 改完合并了Codex 再基于新基线改。第三个坑是忽略 token 成本。两个工具一起跑token 消耗是双份的。有些任务其实一个工具就够了硬要两个一起上是浪费。我的判断标准是任务能不能拆成理解和执行两部分能拆才值得上两个工具。6. 进阶什么任务该给谁6.1 任务分派的经验法则用久了会形成直觉我总结了几条需要通读大范围代码的→ Claude Code。它的上下文窗口大适合先理解再动手。局部、明确的改动→ Codex。给它一个函数、一段逻辑它改得又快又准。需要写文档、写注释、写 commit message→ Claude Code。它的语言组织能力更强。重复性的样板代码生成→ Codex。快省 token。跨文件的架构调整→ Claude Code 出方案Codex 执行局部改动。这个分工不是绝对的但大方向是这样。你可以根据自己的实际体验微调。6.2 一个真实的任务拆解例子上周我重构一个数据处理模块流程是这样的先在myproj-claude里让 Claude Code 通读整个data/目录输出一份重构方案包括要拆成哪几个文件、每个文件的职责、接口怎么定。它给了方案后我把方案写进AI_CONTEXT.md。然后在myproj-codex里让 Codex 读这个方案按方案逐个文件实现。因为方案已经把接口定死了Codex 只需要填实现不需要做架构决策这种任务它最擅长。两边都完成后主仓库 merge。Claude 那边其实没改代码只产出了方案文档Codex 那边改了代码。合并很干净没有冲突。这个流程的关键是让 Claude 做决策、Codex 做执行各用所长。如果反过来让 Codex 做架构决策它容易给出短视的方案让 Claude 做大量样板代码生成又浪费它的能力。6.3 什么时候不该用两个有两种情况我建议就用一个一是任务很小比如改个变量名、修个 typo。这种任务启动两个工具的开销比任务本身还大。二是任务高度耦合改 A 必须同时改 B两个文件强关联。这种任务拆开反而增加协调成本不如一个工具一口气做完。判断标准很简单如果拆开之后你需要花很多精力协调那就不该拆。工具是为你服务的不是让你伺候它的。7. 我个人的一些使用体会这套工作流我用了大概三个月最大的感受是协同的价值不在同时而在分工。一开始我以为一个对话指挥两个的爽点在于并行后来发现真正的爽点在于让每个工具干它最擅长的事然后通过 git 这个可靠的中间层把成果拼起来。worktree 这个方案之所以好用是因为它把复杂的并发问题转化成了 git 已经解决得很好的分支合并问题。你不需要自己实现锁、不需要处理实时同步git 帮你兜底。这也是我一直推荐它的原因——用成熟的工具解决新问题比造新轮子稳。另外一个小技巧如果你经常在同一个项目上切换可以写个脚本一键创建/清理 worktree省得每次敲一堆命令。但脚本别写太复杂够用就行我见过有人把脚本写成一个小型框架最后自己都不敢改。最后说个心态上的事。两个工具一起用初期效率可能反而下降因为你要花时间协调、合并、排查冲突。这是正常的任何新工作流都有学习成本。撑过前两周形成肌肉记忆之后效率才会真正体现出来。别因为一开始不顺就放弃也别因为追求高级而硬上找到适合自己的节奏最重要。
Claude Code 与 Codex 协同实战：用 git worktree 打造高效双工具工作流
1. 为什么要把 Claude Code 和 Codex 放在一起用1.1 两个 CLI 各自的脾气先说结论Claude Code 和 Codex 这两个命令行工具单独拎出来都能打但它们的强项完全不在一个方向上。Claude Code 的长处是理解大段上下文、做重构、写文档、梳理复杂逻辑你给它一个几千行的模块让它分析它能给你讲得头头是道。Codex 的强项则是补全、局部改写、快速生成小片段响应快、token 消耗相对可控适合那种我就想让它把这段函数改一下的场景。问题就出在这——实际干活的时候你往往两个需求同时存在。比如我在重构一个老项目一边要让 Claude Code 通读整个目录结构给我出重构方案一边又想让 Codex 帮我把某个具体函数快速改掉。以前的做法是开两个终端窗口左边敲 Claude右边敲 Codex来回切换上下文还得手动复制粘贴。切一次两次还行一天切上百次人就麻了。所以一个对话同时指挥两个这个需求本质上不是炫技而是减少上下文搬运成本。你希望在一个输入框里说一句话背后自动决定这句话该交给谁处理或者两个都处理然后你挑结果。1.2 一个对话指挥两个到底指什么这里得先把概念说清楚不然容易跑偏。一个对话同时指挥两个有三层含义复杂度递增第一层是统一入口。你只面对一个 CLI 界面输入自然语言背后路由到 Claude Code 或 Codex。这一层解决的是我不想记两套命令。第二层是共享上下文。两个工具看到同一份项目状态、同一份对话历史。这一层解决的是我不想重复解释背景。第三层是协同编排。一句话触发两个工具按顺序或并行工作比如让 Claude 出方案Codex 按方案改代码。这一层解决的是我想让它们配合。大部分人的真实需求停在前两层第三层属于锦上添花。我下面会按这个顺序讲从最容易落地的方案开始。1.3 适合谁来参考这篇内容适合三类人一是已经在用 Claude Code 或 Codex 其中一个想试试两个一起用的二是被多终端切换折磨、想找个统一工作流的三是对 CLI 工具编排感兴趣、想自己搭一套的。如果你连其中一个都没装过建议先把单个跑通再来看这篇不然会有点懵。基础安装部分我会简单带过重点放在怎么让它们协同上。提示本文所有方案都基于本地 CLI 工具的常规用法不涉及任何网络代理配置。如果你在安装环节遇到网络问题请参考各工具官方文档的说明。2. 方案选型三种思路的取舍2.1 思路一Shell 别名 手动路由最土但最稳的办法就是写几个 shell 函数把两个工具包一层。比如你定义ask命令根据参数决定调哪个# 放到 ~/.zshrc 或 ~/.bashrc ask_claude() { claude $ } ask_codex() { codex $ } # 统一入口第一个参数选工具 ask() { local tool$1 shift case $tool in c|claude) ask_claude $ ;; x|codex) ask_codex $ ;; *) echo 用法: ask [c|x] 你的问题 ;; esac }这样你输入ask c 帮我看看这个模块就走 Claudeask x 改一下这个函数就走 Codex。优点是零依赖、绝对可控、出问题一眼能看出是哪层。缺点是它没解决共享上下文的问题你还是得自己管对话历史。我早期就是用这个方案过渡的大概用了两周。它的价值在于让你先建立起哪个任务交给谁的直觉等你摸清楚分工规律了再上更复杂的方案会顺很多。2.2 思路二git worktree 隔离 双工具并行这个方案是我个人最推荐的也是热词里git worktree出现频率很高的原因。核心思路是用 git worktree 给两个工具各自开一个独立工作目录共享同一个 git 仓库。为什么需要隔离因为 Claude Code 和 Codex 都可能直接改你的文件。如果两个工具同时改同一个工作区轻则互相覆盖重则 git 状态乱成一锅粥你想回滚都不知道回滚到哪一步。worktree 的好处是每个工作目录有独立的文件状态但共享.git对象库分支管理还是统一的。具体操作# 在主仓库目录下 git worktree add ../proj-claude -b feat/claude git worktree add ../proj-codex -b feat/codex这样你就有了两个目录proj-claude和proj-codex分别对应两个分支。Claude Code 在proj-claude里干活Codex 在proj-codex里干活互不干扰。等两边都改完了你再在主仓库里 merge 或者 cherry-pick。这个方案的精髓在于把并行变成分支合并用 git 本身的能力解决冲突而不是靠工具之间的实时同步。实测下来这比任何实时同步方案都稳因为 git 的合并逻辑是经过千锤百炼的。2.3 思路三中间层编排Orkas 类思路热词里出现了Orkas这类工具的思路是做一个中间层把多个 CLI 工具包装成统一的 agent 接口由中间层决定任务分发给谁。听起来很美但实际用起来有几个坑一是中间层本身要维护工具升级了它可能就挂了二是路由逻辑很难做准什么任务该给谁规则写死了不灵活用模型判断又增加延迟和不确定性三是调试困难出问题你分不清是中间层的问题还是底层工具的问题。我的建议是除非你有明确的、重复性极高的编排需求否则别上中间层。先用 worktree 方案把并行跑通等你真的觉得手动 merge 太累了再考虑自动化。2.4 三种方案对比方案落地难度上下文共享冲突处理适合场景Shell 别名极低无手动单人、任务切换不频繁git worktree低通过 git 间接共享git merge并行改代码、需要隔离中间层编排高完全共享依赖实现团队、高频重复编排选哪个取决于你的痛点在哪。如果你只是嫌切换麻烦方案一够了如果你要两个工具同时改代码方案二如果你要的是一句话自动分派那才需要方案三但要做好踩坑的准备。3. 核心实操用 git worktree 搭一套双工具工作流3.1 环境准备与工具安装确认先把两个工具都装好确认能单独跑起来。Claude Code 的安装方式各平台略有差异Mac 上一般是通过包管理器或者官方脚本Windows 上现在也有桌面版和 CLI 版。Codex 同理装完之后用codex --version之类的命令确认一下。这里有个常见坑两个工具可能依赖不同版本的运行时。比如一个要 Node 18一个要 Node 20。如果你用全局安装很容易打架。我的做法是用版本管理工具比如 nvm 或 fnm给不同项目切不同版本或者干脆用容器隔离。确认清单claude --version能正常输出版本号codex --version能正常输出版本号两个工具都能在目标项目目录下正常启动git 版本在 2.5 以上worktree 需要注意如果你在安装 Codex 时遇到 unable to locate the codex cli binary or required runtime components 这类报错八成是 PATH 没配好或者运行时缺失。先解决单个工具的安装问题再谈协同。3.2 用 worktree 建立隔离工作区假设你的项目在~/work/myproj先确认当前工作区是干净的cd ~/work/myproj git status如果有未提交的改动先 commit 或者 stash 掉。然后创建两个 worktreegit worktree add ../myproj-claude -b ai/claude-work git worktree add ../myproj-codex -b ai/codex-work执行完git worktree list应该能看到三个工作区主仓库、claude 工作区、codex 工作区。这里有个细节值得说分支命名建议带前缀比如ai/claude-work这样后面 merge 的时候一眼能看出这是 AI 工具产出的分支方便审查。我见过有人直接叫dev1、dev2过两天自己都忘了哪个是哪个。3.3 让两个工具各就各位现在开两个终端窗口或者用 tmux 分屏一个进myproj-claude一个进myproj-codex# 终端 1 cd ~/work/myproj-claude claude # 终端 2 cd ~/work/myproj-codex codex这时候两个工具就在各自的工作区里跑起来了。你在 Claude 那边让它重构某个模块在 Codex 那边让它改另一个函数两边改的文件物理上就是分开的不会互相踩。但这里有个关键问题两个工作区的代码基线是一样的吗是的因为它们都是从同一个 commit 切出来的。所以 Claude 看到的代码和 Codex 看到的代码起点完全一致。这就是 worktree 方案的精髓——隔离的是改动共享的是历史。3.4 合并两边成果的实操流程等两边都干完活回到主仓库合并。假设 Claude 改了src/core.jsCodex 改了src/utils.js两个文件不冲突cd ~/work/myproj git merge ai/claude-work git merge ai/codex-work如果改的是同一个文件git 会提示冲突这时候你手动解决就行。因为两个分支的基线相同冲突范围通常很小比两个工具实时抢文件要好处理得多。我一般会先 merge 一个跑一遍测试再 merge 另一个。这样出问题能快速定位是哪个分支引入的。如果两个一起 merge测试挂了你还得二分排查浪费时间。3.5 清理工作区活干完了worktree 要记得清理不然目录越堆越多git worktree remove ../myproj-claude git worktree remove ../myproj-codex git branch -d ai/claude-work git branch -d ai/codex-workgit worktree remove会检查有没有未提交的改动有的话会拒绝删除这是保护机制。如果你确定不要了加--force。4. 上下文共享的几种土办法4.1 用共享文件当公共黑板worktree 解决了文件隔离但没解决上下文共享。两个工具不知道对方在干什么。最简单的办法是搞一个共享的说明文件比如在项目根目录放一个AI_CONTEXT.md两个工具都读它。但 worktree 是独立目录这个文件怎么共享答案是放在主仓库里然后让两个 worktree 都软链接过去或者干脆每次手动同步。软链接的做法# 在主仓库创建 echo # 当前任务上下文 ~/work/myproj/AI_CONTEXT.md # 在两个 worktree 里链接 ln -s ~/work/myproj/AI_CONTEXT.md ~/work/myproj-claude/AI_CONTEXT.md ln -s ~/work/myproj/AI_CONTEXT.md ~/work/myproj-codex/AI_CONTEXT.md这样你在任何一个工作区更新这个文件另一个立刻能看到。我一般会在里面写当前在做什么任务、已经改了哪些文件、有哪些约定。两个工具启动时我都会让它们先读这个文件。4.2 对话历史的导出与注入CLI 工具的对话历史通常存在本地某个目录格式各家不同。想跨工具共享对话历史实操上比较麻烦因为格式不通用。我的做法是不共享原始历史而是共享摘要。具体来说每完成一个阶段我会让当前工具输出一段总结刚才做了什么、结论是什么、下一步建议。然后把这段总结贴到AI_CONTEXT.md里。另一个工具读这个文件就相当于拿到了压缩后的上下文。这个办法听起来笨但实测非常有效。因为原始对话历史里大量是过程性的废话真正有价值的就是结论。让工具自己总结一遍反而比直接喂原始历史更清晰。4.3 用 git commit message 传递意图还有一个被低估的上下文载体commit message。Claude 改完代码提交时让它写清楚为什么这么改。Codex 那边git log一看就知道另一个工具的思路。我习惯让 AI 工具提交时用固定格式[claude] 重构 core 模块拆分出 validator - 原因原函数超过 200 行难以测试 - 影响core.js 导出接口不变这样git log --oneline一眼就能看出哪个工具做了什么、为什么做。合并的时候审查起来也快。5. 常见问题与排查实录5.1 工具启动报错类问题问题Codex 报 auth token is unavailable这是认证状态丢了。Codex 的登录态一般存在本地配置目录可能是过期了或者被清理了。重新走一遍登录流程即可。如果你在多个环境切换注意配置目录别被覆盖。问题Claude Code 报 internetopenurl() failed这类报错通常是网络请求环节出的问题可能是本地网络环境、DNS 或者工具自身的请求逻辑。先确认基础网络能通再看工具是否需要特定配置。这类问题排查顺序是网络连通性 → 工具配置 → 工具版本。问题两个工具都装了但命令找不到PATH 问题。检查which claude和which codex是否有输出。没有的话把安装目录加到 PATH 里。Windows 上还要注意用户变量和系统变量的区别。5.2 worktree 使用中的坑坑一worktree 目录被工具当成新项目有些工具会根据目录名或者.git的存在判断项目根。worktree 目录里.git是个文件指向主仓库不是目录。大部分工具能正确处理但少数工具会懵。如果遇到可以在 worktree 里跑一下git rev-parse --show-toplevel确认 git 认得它。坑二忘记清理导致分支混乱worktree 用多了git branch里一堆ai/xxx分支。建议养成习惯任务结束就 remove 删分支。我一般会在每周五清理一次把没用的 worktree 和分支都干掉。坑三两个 worktree 同时跑测试抢资源如果两个工具都在跑测试可能抢端口、抢临时文件。解决办法是给它们分配不同的端口范围或者错开跑测试的时间。我一般让 Claude 那边跑单元测试Codex 那边只做静态检查避免资源冲突。5.3 排查速查表现象可能原因排查动作工具命令找不到PATH 未配置which确认检查安装目录认证失败登录态过期重新登录检查配置目录worktree 创建失败分支已存在git branch查看换分支名合并冲突多两边改了同一文件缩小任务范围错开文件工具读不到上下文共享文件未同步检查软链接确认路径测试互相干扰端口/临时文件冲突分配不同端口错开执行5.4 几个我踩过的坑第一个坑是过早追求自动化。我一开始就想搞个脚本自动路由结果规则越写越复杂最后自己都维护不动。后来退回到手动选工具反而效率更高。自动化的前提是你已经清楚知道什么任务给谁这个认知得靠手动阶段积累。第二个坑是让两个工具改同一个文件。哪怕有 worktree 隔离合并的时候冲突还是很难受。后来我定了个规矩同一个文件同一时间只让一个工具碰。要改就排队Claude 改完合并了Codex 再基于新基线改。第三个坑是忽略 token 成本。两个工具一起跑token 消耗是双份的。有些任务其实一个工具就够了硬要两个一起上是浪费。我的判断标准是任务能不能拆成理解和执行两部分能拆才值得上两个工具。6. 进阶什么任务该给谁6.1 任务分派的经验法则用久了会形成直觉我总结了几条需要通读大范围代码的→ Claude Code。它的上下文窗口大适合先理解再动手。局部、明确的改动→ Codex。给它一个函数、一段逻辑它改得又快又准。需要写文档、写注释、写 commit message→ Claude Code。它的语言组织能力更强。重复性的样板代码生成→ Codex。快省 token。跨文件的架构调整→ Claude Code 出方案Codex 执行局部改动。这个分工不是绝对的但大方向是这样。你可以根据自己的实际体验微调。6.2 一个真实的任务拆解例子上周我重构一个数据处理模块流程是这样的先在myproj-claude里让 Claude Code 通读整个data/目录输出一份重构方案包括要拆成哪几个文件、每个文件的职责、接口怎么定。它给了方案后我把方案写进AI_CONTEXT.md。然后在myproj-codex里让 Codex 读这个方案按方案逐个文件实现。因为方案已经把接口定死了Codex 只需要填实现不需要做架构决策这种任务它最擅长。两边都完成后主仓库 merge。Claude 那边其实没改代码只产出了方案文档Codex 那边改了代码。合并很干净没有冲突。这个流程的关键是让 Claude 做决策、Codex 做执行各用所长。如果反过来让 Codex 做架构决策它容易给出短视的方案让 Claude 做大量样板代码生成又浪费它的能力。6.3 什么时候不该用两个有两种情况我建议就用一个一是任务很小比如改个变量名、修个 typo。这种任务启动两个工具的开销比任务本身还大。二是任务高度耦合改 A 必须同时改 B两个文件强关联。这种任务拆开反而增加协调成本不如一个工具一口气做完。判断标准很简单如果拆开之后你需要花很多精力协调那就不该拆。工具是为你服务的不是让你伺候它的。7. 我个人的一些使用体会这套工作流我用了大概三个月最大的感受是协同的价值不在同时而在分工。一开始我以为一个对话指挥两个的爽点在于并行后来发现真正的爽点在于让每个工具干它最擅长的事然后通过 git 这个可靠的中间层把成果拼起来。worktree 这个方案之所以好用是因为它把复杂的并发问题转化成了 git 已经解决得很好的分支合并问题。你不需要自己实现锁、不需要处理实时同步git 帮你兜底。这也是我一直推荐它的原因——用成熟的工具解决新问题比造新轮子稳。另外一个小技巧如果你经常在同一个项目上切换可以写个脚本一键创建/清理 worktree省得每次敲一堆命令。但脚本别写太复杂够用就行我见过有人把脚本写成一个小型框架最后自己都不敢改。最后说个心态上的事。两个工具一起用初期效率可能反而下降因为你要花时间协调、合并、排查冲突。这是正常的任何新工作流都有学习成本。撑过前两周形成肌肉记忆之后效率才会真正体现出来。别因为一开始不顺就放弃也别因为追求高级而硬上找到适合自己的节奏最重要。
