很多人已在用 Claude Code 的工作流，但手上只有 OpenAI 的额度，或者某个任务就是想跑 GPT。默认状态下 Claude Code 只认自家的模型通道，直接改个名字通常连不上。这篇按「先分清能不能接、再选通道、再配环境变量、最后验证」的顺序走一遍，每一步都给可执行的检查动作，配完能立刻判断是通了还是卡在哪一层。
很多人已经习惯了 Claude Code 的工作流，但手上只有 OpenAI 的额度，或者某个具体任务就是想跑 GPT。默认状态下 Claude Code 只认自家的模型通道，直接把模型名改成 GPT 通常连不上，报错还会指向一堆看不懂的方向。这篇按「先分清能不能接、再选通道、再配环境变量、最后验证」的顺序走一遍，每一步都给可执行的检查动作，配完能立刻判断是通了还是卡在哪一层。
先说一个前提：这不是官方承诺支持的玩法，而是利用接口兼容性把底层通道换掉。所以凡是被组织策略锁定、配置权限不在自己手里的环境，改了也不生效，别在这上面耗时间。下面所有改动，都假设你对本机配置有完全控制权。
先判断你到底能不能换：三件事对上才动手
动手前先分清诉求。一种是真想让 Claude Code 的对话回答由 GPT 产出；另一种只是想让同一批任务多一个模型做对照。后者其实用外部工具各跑一遍更省事，不必改开发环境。如果确认是前者，再往下看前置条件是否齐全。
- 手上有一个可用的 OpenAI 兼容 key，或者一个能返回兼容协议的网关地址
- 对这台机器的环境变量和配置文件有修改权限
- 愿意先备份原配置——改坏之后至少要能退回去
- 确认当前用的是哪套配置来源：全局配置、项目级配置还是环境变量，三者优先级不同，改错地方会「看着改了其实没生效」
选通道：直连官方、走网关、还是本地中转
三条路都能走通，差别在网络条件、可控性和信任成本。先按自己的实际情况选一条，不要三个一起改，否则出问题时分不清是哪层的锅。
| 通道 | 适合谁 | 典型坑 |
|---|---|---|
| 直连官方 | 网络能访问 OpenAI 接口域名、只要 GPT 一家 | 连不上时一直报超时，容易误判成配置写错 |
| 聚合网关或中转 | 想一个入口随时切模型、手上多家 key | 多一层延迟和一层信任，得先筛入口 |
| 本地兼容层 | 断网、或数据不出本机 | 小模型在长上下文代码任务上容易掉链子 |
走网关这条路，先到 中转站目录（/sites） 看有没有可用的入口，并按 模型可信度排行（/rankings） 做初筛；不同通道的实际计费和规格差异很大，动手前先到 官方 API 价格（/official-api） 和 换模型前先比一比率和额度（/ai-nav/category/ai-api） 对一遍当时的数字，别只盯着一个单价做决定。
配置动作：改哪几个地方，一步一验证
这一节是全文唯一要动手的地方。原则是：一次只改一个变量，每改完立刻验证一次，不要把地址、密钥、模型名一起写进去再一次性试。下面按顺序来。
- 备份原配置把现有的配置文件复制一份带日期的副本，或先确认环境变量清单。改坏时能直接覆盖回去，比事后回忆改了什么靠谱。
- 确认配置来源弄清当前生效的是全局配置、项目级配置还是环境变量，三者的覆盖顺序不同，只改优先级低的那一层等于没改。
- 写入地址和密钥接口地址和密钥写进环境变量，不要硬编码进配置文件。密钥只留本机，别提交进仓库。
- 填模型标识模型名必须用通道方文档里给的完整标识，很多「连不上」其实是模型名对不上。具体可用标识以通道方当期说明为准，别自己拼。
- 最小验证先发一句不依赖工具调用的短指令，看有没有返回；通过后再试一次读文件或改文件，确认工具调用这条路也通。
顺带一提：验证时不要拿复杂任务当第一次测试。长指令一旦失败，你分不清是通道问题还是模型没处理好指令。
验证与排查：按这个顺序找问题，别乱猜
出问题时的正确姿势是分类，而不是反复改配置。报错基本落在三类：认证失败、模型不存在、连接超时。先看清是哪一类，再决定动哪里。
| 现象 | 大概率原因 | 先查什么 |
|---|---|---|
| 认证失败 | key 错、key 过期、key 与网关不匹配 | 换一把 key 或换一个地址试 |
| 模型不存在 | 模型标识写错、通道没开这个模型 | 回到通道方文档核对标识 |
| 连接超时 | 网络不通、地址写错、节点太远 | 绕开客户端直连接口试一次 |
第二步很关键：用同一把 key 和地址，绕开 Claude Code 直接在命令行请求一次接口。能通说明问题在客户端配置，不通说明在通道本身，这一下就砍掉一半排查范围。第三步确认改动是否真的加载，重启终端或会话，光改文件不重启是常见白忙。第四步看速度基线，到 接口测速：先量出你的延迟基线（/tools/speed-test） 量一遍，延迟突然翻几倍通常意味着走到了很远的节点或在排队，而不是模型变慢。
最后一步容易被忽略：把这次改动的配置版本和时间点记下来。后续模型换代时按 模型换代了要不要跟：迁移、验证与回退清单（/guides/model-upgrade-migration-checklist） 走流程，别裸切。
什么情况下别这么折腾
不是所有场景都值得换底层模型。下面几种情况，换了反而添麻烦，提前判断能省下不少时间。
- 任务高度依赖 Claude Code 原生工具链的深度行为，换模型后行为差异可能比预期大，要重新验证一遍再纳入日常使用
- 只是偶尔想对比两个模型效果，用同一个提示词在两边各跑一遍更省事，不必动开发环境
- 涉及公司代码或客户数据，先确认所选通道的数据留存与训练使用条款，合规没谈清之前不要接
- 只想临时试一下，别放在主力机器上改，用一台能随便折腾的环境或独立配置目录
常见问题
改完配置但 Claude Code 还是用原来的模型，怎么回事？
先确认改动有没有被真正加载，多数情况是没重启会话或改错了配置层级（全局与项目级同时存在时以优先级高的为准）。再核对模型标识是否和通道方给的一致。最后用同一把 key 在命令行直接请求一次接口，能通就说明问题在客户端这一侧。
换成 GPT 之后，工具调用、读文件这些还能正常用吗？
取决于通道是否完整实现了工具调用相关的协议字段，很多廉价网关只做了对话补全，工具调用会静默失败或直接报错。判断方法很简单：先发普通对话，再让它读一个文件，两步都过才算可用。只过第一步的通道，别拿来做日常开发。
走中转站和直连官方，怎么选？
直连改动少、链路短，但需要网络能通且账号可用；中转的优势是入口统一、方便随时切模型，代价是多一层延迟和一层信任。选之前到中转站目录和模型可信度排行里看一眼当期情况，涉及敏感代码时优先选数据条款清楚的通道。
