先把最容易说混的事讲清楚：“在 Claude Code 里直接调用 Codex CLI”、“让 Claude Code 把 GPT-5.4 当主模型”、“Claude Code 和 Codex CLI 混合协作”，其实是三件不同的事。
不少讨论把这三条路混在一起，结果看起来热闹，真正上手时却一头雾水。要把 Claude Code 和 Codex 用顺，最重要的不是先记命令，而是先分清楚架构。
一、真正可行的路线，其实只有三条
路线 A：在 Claude Code 里把 Codex CLI 当成外部工具调用
这种方式最直观。Claude Code 本身有 Bash 工具，能执行本地命令。只要本机已经安装并登录了 Codex CLI，Claude Code 就可以通过 Bash 去调用它，比如把一个子任务交给 codex exec 处理。
这条路线的特点是：Claude 还是主控，Codex 是外援。适合拿 Codex 做专项审核&查验、第二意见、补充测试、独立生成补丁，或者在复杂任务里做一次“平行思考”。
路线 B：通过网关，把 Claude Code 的底层模型切到 GPT-5.4
这条路线才是真正意义上的“Claude Code 接入 Codex / OpenAI 模型”。
Claude Code 官方支持通过 LLM gateway 接到代理层，但它要求网关至少能暴露 Anthropic Messages、Bedrock 或 Vertex 这类 Claude Code 能识别的接口格式。OpenAI 的 Responses API 不是 Claude Code 直接识别的原生接口，所以不能简单把 OpenAI 地址往里一塞就完事。要走通这条路，必须有一个中间翻译层。
目前最成熟、资料也最完整的方案，是用 LiteLLM 作为代理：Claude Code 继续发送 Anthropic Messages 格式，LiteLLM 再把请求转到 OpenAI，并在 OpenAI 模型场景下走 Responses API。
这条路线的特点是：Claude Code 这个外壳、交互方式、权限系统和工作流保留不变，但主模型可以换成 GPT-5.4 或 GPT-5.4-mini。
路线 C：Claude Code 和 Codex CLI 双开，组成双代理工作流
这是实战里最耐用的一条路。
Claude Code 更适合承担“读项目、改代码、走权限、跑工作流、维护项目记忆”这一层；Codex 则更适合承担“专项生成、独立审核&查验、批量执行、非交互脚本化”这一层。两边不一定是谁替代谁，更像是两个风格不同的终端代理。
真正进入日常开发后，很多高效用法不是“二选一”，而是：Claude 做主线，Codex 做并行、复核和加速。
二、先讲结论：想让 Claude Code 用上 GPT-5.4，正确思路不是硬改，而是走代理
这一点非常关键。
Claude Code 官方文档已经把边界写得很清楚：它支持通过网关接第三方部署，但网关本身要能按 Claude Code 预期的接口说话。LiteLLM 官方又专门给出了“让 Claude Code 使用非 Anthropic 模型”的教程，思路就是把 Claude Code 发出的 Anthropic Messages 请求，翻译成 OpenAI、Gemini 等目标供应商的格式，然后再把响应翻回来。
也就是说，Claude Code 接 GPT-5.4 不是伪需求，也不是民间魔改，而是有清晰技术路径的。真正的问题只剩下两个：
- 网关怎么配
- 配好以后，工作流怎么用才顺手
三、从零开始的最稳妥配置方案
1. 先把 Codex CLI 单独跑通
先别急着折腾 Claude Code。第一步应该是确认 Codex 自己是好的。
npm i -g @openai/codex
codex
首次运行时，Codex CLI 会要求登录。官方支持用 ChatGPT 账号登录，也支持 API key。模型方面，Codex 官方目前推荐多数任务优先从 gpt-5.4 开始，轻量任务可以考虑 gpt-5.4-mini。
如果想先在终端里确认体验，最简单的试法是：
codex -m gpt-5.4
或者直接做一次非交互执行：
codex exec -m gpt-5.4 "review this repository and summarize the riskiest modules"
这一步的意义很简单：先确认 Codex 本身没问题，再去谈和 Claude Code 的联动。
2. 用 LiteLLM 做中间层，把 GPT-5.4 暴露给 Claude Code
Claude Code 想把 GPT-5.4 当主模型，最清晰的做法是让 LiteLLM 暴露一个 Anthropic-compatible 的 /v1/messages 入口。
先安装：
pip install 'litellm[proxy]'
然后写一个最小可用的 config.yaml：
model_list:
- model_name: gpt-5.4
litellm_params:
model: openai/gpt-5.4
api_key: os.environ/OPENAI_API_KEY
- model_name: gpt-5.4-mini
litellm_params:
model: openai/gpt-5.4-mini
api_key: os.environ/OPENAI_API_KEY
再准备环境变量：
export OPENAI_API_KEY="你的 OpenAI API Key"
export LITELLM_MASTER_KEY="自己生成一串安全的代理访问密钥"
启动代理：
litellm --config /path/to/config.yaml
如果一切正常，LiteLLM 默认会跑在本地 4000 端口。
3. 把 Claude Code 指到这个代理
接下来才轮到 Claude Code：
export ANTHROPIC_BASE_URL="http://0.0.0.0:4000"
export ANTHROPIC_AUTH_TOKEN="$LITELLM_MASTER_KEY"
然后直接启动：
claude --model gpt-5.4
如果想用更轻的模型：
claude --model gpt-5.4-mini
这时候，表面上看还是在用 Claude Code，但底层模型已经变成了 LiteLLM 后面的 OpenAI GPT-5.4。
4. 想让 /model 菜单里也好看一点，可以加一个自定义模型入口
Claude Code 支持往模型选择器里添加一个自定义模型选项。对于走网关的人来说，这很实用，尤其是在模型名字比较“工程化”的情况下。
export ANTHROPIC_CUSTOM_MODEL_OPTION="gpt-5.4"
export ANTHROPIC_CUSTOM_MODEL_OPTION_NAME="GPT-5.4 via LiteLLM"
export ANTHROPIC_CUSTOM_MODEL_OPTION_DESCRIPTION="OpenAI model routed through local gateway"
这样做的好处不是功能增强，而是管理成本更低：切模型时不容易忘掉自己到底连的是谁。
四、所谓“在 Claude Code 中直接调用 Codex CLI”，到底该怎么用
如果只是想在 Claude Code 的会话里顺手借用 Codex，最实用的不是开第二个交互式 Codex TUI，而是让 Claude 通过 Bash 触发 codex exec。
比如下面这类任务，就很适合丢给 Codex 做独立处理：
- 让 Codex 单独审一遍当前改动
- 让 Codex 站在“Reviewer”角度给出风险清单
- 让 Codex 根据现有代码补测试
- 让 Codex 为一个模块生成迁移方案
- 让 Codex 把一段补丁说明整理成提交信息
核心原因很简单：codex exec 更稳定，也更适合被另一个代理调用。直接在 Claude Code 的 Bash 里开交互式 codex，通常只会把 TUI 套 TUI，控制感并不好。
更顺手的做法是让 Claude 触发类似这样的命令：
codex exec -m gpt-5.4 "Review the current git diff and list correctness risks, missing tests, and security concerns."
然后把返回结果当成另一份独立意见，再决定要不要采纳。
这类工作流的价值，不在于“谁更强”，而在于把单模型的思路偏差拉开。很多复杂问题不是缺生成能力，而是缺第二种视角。
五、cc-switch 到底值不值得上
值得，但不应该作为第一步。
cc-switch 这类工具的价值，并不在于替代官方 CLI，而在于统一管理多套配置、多家供应商、多种 CLI。尤其是同时使用 Claude Code、Codex、Gemini CLI、OpenCode 之类工具时，手动改 JSON、TOML、环境变量会很快失控。
这类工具最大的现实意义有三个：
- 多账号切换更省事
- 多供应商配置更集中
- MCP、Skills、代理地址这类设置不用来回手改
但对于新手来说，最容易犯的错恰恰是：还没理解底层变量在做什么，就把所有事情都交给切换器。这样一旦出问题，基本只能靠猜。
更稳妥的顺序应该是：
- 先手工跑通一遍 Claude Code → LiteLLM → GPT-5.4
- 再手工跑通一遍 Codex CLI
- 确认自己知道哪些变量在控制 base URL、auth token、model name
- 最后再上 cc-switch，把这些配置统一收口
这样用起来才不会“会切不会修”。
六、Claude Code 新手最值得尽快养成的习惯
1. 先用 Plan Mode，不要一上来就全自动
Claude Code 和 Cursor 最大的差别之一，是它更像一个会动手的终端代理，而不是侧边栏聊天框。
刚开始用时，最稳的方式不是直接把权限开很大，而是先从 Plan Mode 进入：
claude --permission-mode plan
Plan Mode 的价值在于，它先读项目、查代码、出方案，不会急着改文件。很多第一次用 Claude Code 的人，并不是败在模型不够强，而是败在没有先建立“先看计划，再放执行”的节奏。
2. 第一时间写好 CLAUDE.md
Claude Code 真正好用的地方，不是提示词魔法，而是项目记忆。
用 /init 先生成一份项目级 CLAUDE.md，再自己补上真正重要的东西：构建命令、测试命令、目录约定、代码规范、哪些模块不能乱动、提交前必须做什么。文件不需要写长，短、硬、具体 最重要。
如果每次开新会话都要重新解释“这个仓库怎么跑”“测试先跑哪组”“哪些规则必须遵守”，那 Claude Code 的优势基本等于没用上。
3. 学会用 /rewind，别把一次跑偏当事故
Claude Code 自带 checkpointing，会在编辑前自动记录状态。会话走偏、改坏文件、上下文越来越乱时，不必强行在原地抢救，直接 /rewind 回到更早的点，经常比继续纠缠更省时间。
很多人把代理工具用得疲惫，一个典型原因就是舍不得回退，结果让上下文越来越脏。
4. 多任务并行时，用 worktree，不要硬挤在一个分支里
Claude Code 对 worktree 的支持非常实用。处理两个任务以上时，直接给不同任务开不同 worktree：
claude --worktree feature-auth
这样做的好处特别直接：上下文独立、文件状态独立、分支独立，不会出现“这个会话还在改登录，那个会话已经把公共组件一起改了”的互相污染。
如果仓库里有 .env 之类 gitignore 文件，记得配好 .worktreeinclude，不然新 worktree 一开，环境变量和本地配置经常会缺。
5. 把状态栏配起来，看得见模型、分支和上下文占用
Claude Code 的状态栏不是花活，它非常适合显示三样东西：当前模型、当前目录 / 分支、当前上下文占用比例。长时间开发时，这三项信息是最值钱的。
一旦开始混用 Claude 模型、GPT-5.4、不同 worktree、不同任务流，没有状态栏几乎一定会出现“人已经切了，脑子还没切”的情况。
6. 把重复动作写成 hooks 或 skills
凡是“每次都想让代理这么做”的动作，都不该永远靠嘴说。
例如：
- 每次改完代码自动跑一次最小测试
- 每次等待授权时弹桌面通知
- 每次编辑特定目录时自动附加额外规则
- 固定把 lint / typecheck / format 打成一个工作流
这种事用 hooks 和 skills 非常合适。一个终端代理一旦进入“靠结构化工作流做事”的阶段，稳定性会比单纯堆 prompt 高很多。
七、同时用 Claude Code 和 Codex，最顺手的分工方式
真正把两边都用起来之后，比较稳定的分工通常是这样的：
Claude Code 负责：
- 理解项目结构
- 维护项目记忆
- 改多文件逻辑
- 和本地工具链、工作树、权限机制深度配合
- 做长会话、多轮修正
Codex 负责：
- 独立代码审核&查验
- 非交互脚本化任务
- 单次高质量补丁生成
- 批量执行和自动化流水线
- 在另一个模型视角下给出“第二份答案”
一旦把分工想通，终端里的工作流会非常顺：
- 先让 Claude Code 探索代码、列计划、改主线
- 关键节点调用 Codex 做一次独立 review
- 复杂改动进入 worktree 分支单独跑
- 沉淀成 CLAUDE.md、skills、hooks
这时候，终端代理就不再像一个“高级聊天框”，而更像一套可以不断积累的开发环境。
八、最常见的坑，基本都在这些地方
- 把 OpenAI base URL 直接塞给 Claude Code：大概率不行，Claude Code 要的不是原生 OpenAI Responses 接口，而是自己能识别的消息格式或网关格式。
- 还没跑通官方链路，就先上三层转发和切换器：一旦报错，很难判断是模型、代理、认证还是 CLI 本身的问题。
- 在 Claude Code 里直接跑交互式
codex：大多数场景不如codex exec稳。 - 忽略 Bash 环境变量不持久：Claude Code 的 Bash 命令之间默认不保留
export结果，这会导致“上一步明明配了，下一步怎么又没了”。 - 网关报 beta header 错误还一直重试：这种情况通常要优先考虑
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1。 - 代理之后看不到工具搜索就以为功能坏了：当
ANTHROPIC_BASE_URL指向非官方主机时，某些能力默认会保守降级，需要按网关能力再决定是否补开。
九、一个更适合长期使用的推荐组合
如果只追求尽快开始，最简单的组合其实是：
- Claude Code 走官方链路
- Codex CLI 也走官方链路
- 需要时在 Claude Code 里通过 Bash 调一次
codex exec
如果已经明确想把 GPT-5.4 接到 Claude Code 里长期用，最值得投入的一套组合是：
- Claude Code 作为主交互壳
- LiteLLM 作为翻译层
- GPT-5.4 作为重任务模型
- GPT-5.4-mini 作为轻任务模型
- Codex CLI 保留为独立第二代理
如果还要管多账号、多代理、多种 CLI，再把 cc-switch 放到最外层做统一切换。
这个顺序很重要：先理解，后收口；先跑通，后自动化。
十、最后一句
Claude Code 真正值得花时间的，不只是“能不能接上别家的模型”，而是它那套围绕终端、权限、worktree、记忆、hooks、skills 搭起来的工作流。Codex 真正值得引入的，也不只是“模型更强”，而是它在脚本化、审核&查验、独立执行这类场景里，能给出另一种节奏。
所以最值得追求的状态，不是非要把两者变成同一个东西，而是把它们接成一套真正顺手的终端开发体系。
外壳可以保留 Claude Code，主模型可以换到 GPT-5.4，专项任务可以扔给 Codex，记忆和规则继续沉淀在项目里。等这一套跑顺之后，终端里的 AI 开发体验，和 Cursor 那种“边写边聊”的感觉，会完全不是一个层级。
评论