如果你正在找 CC Switch 配置第三方大模型 API 中转站教程，有一个关键点必须先搞清楚：不要一上来就配置 Claude Code、Codex 或 OpenClaw，再让 CC Switch 去接管它们。

正确的顺序是反过来的。

你应该先在 CC Switch 里新增 Provider，把类似 api.clawsocket.com 这样的中转站接进去，然后再由 CC Switch 去分发和切换到不同 CLI 工具。

这个顺序错了，后面基本都会乱。

---

一、先把概念讲清楚：CC Switch 不是中转站

很多人第一次用 CC Switch 会理解错它的角色。

CC Switch 本身不是模型服务，也不是 Claude Code，也不是 Codex。

它更像一个“统一配置管理器”，负责做三件事：管理不同 Provider 配置、在不同 AI CLI 工具之间切换配置、把同一套 API 适配到不同工具。

所以它的结构其实是这样的：

先是一个或多个 API 中转站，比如 ClaudeAPI.com 然后是 CC Switch 管理这些 Provider，再然后才是 Claude Code、Codex、OpenClaw 这些 CLI 工具，最后才是你真正执行任务的地方

---

二、为什么不能反着来配置

如果你先在 Claude Code 或 Codex 里手动配好，再让 CC Switch 接管，会出现一个问题：配置源不统一。

因为这些 CLI 工具本身都会保存自己的环境变量或配置文件，而 CC Switch 管的是另一套配置系统，这样会导致你看起来“切换了”，但实际请求还在走旧配置。

所以正确理解应该是：CC Switch 是入口，不是覆盖层。

---

三、标准接入链路应该是这样的

整个流程应该是：

1. 先准备 API 中转站
2. 然后在 CC Switch 里新增 Provider
3. 再选择目标应用（Claude Code / Codex / OpenClaw）
4. CC Switch 写入或切换配置
5. 最后启动对应 CLI 工具

而不是：

先配 CLI 工具
再交给 CC Switch 管理

这两者的差别，本质是“控制权在谁那里”。

---

四、接入前的基础准备

在实际使用里，你只需要确认三件事：

你有一个可用的 API Key
你的中转站支持 Claude 或 OpenAI 兼容接口
你的 CC Switch 能正常识别 Provider 配置

像 api.clawsocket.com 这一类中转站，一般同时支持 Claude 兼容接口和 OpenAI 兼容接口，这一点对 CC Switch 非常关键，因为它决定了你能不能同时接 Claude Code 和 Codex。

---

五、在 CC Switch 里新增 Provider（核心步骤）

这里才是关键操作。

你在 CC Switch 里新增一个 Provider，本质是在定义一组 API 接入配置。

一般你需要填这些信息：

• 应用类型选 Claude 或 OpenAI
• Provider 名称随便起，比如 ClawSocket Claude
• Base URL 填中转站地址
• API Key 填你的 key
• 模型选择对应的默认模型

比如 Claude Code 场景通常是：

Base URL 用 Claude 兼容入口模型用 claude-sonnet-4-6 或 claude-opus-4-6

Codex 或 OpenClaw 则用 OpenAI 兼容入口，例如：Base URL 形如 /v1 结构、模型用 GPT 或 Claude 兼容映射模型/这里有一个关键点：CC Switch 不关心你背后是 Claude 还是 GPT，它只关心接口是否兼容。

---

六、Claude Code 场景如何配置

如果你的目标是让 Claude Code 走中转站，那么你只需要在 CC Switch 里新增一个 Claude Provider，然后填入：

Base URL 指向中转站 Claude 兼容入口
API Key 使用中转站生成的 key
模型选择 Sonnet 或 Opus

配置完成之后，你不需要再手动写：

export ANTHROPIC_BASE_URL
export ANTHROPIC_API_KEY

因为 CC Switch 会帮你统一写入和切换。

然后你只需要在 CC Switch 里选中这个 Provider，再启动 Claude Code 即可。

---

七、Codex 场景如何配置

Codex 更偏 OpenAI 兼容接口，所以配置逻辑不同。

你在 CC Switch 里新增 Codex Provider 时：

Base URL 一般要带 /v1
API Key 使用同一中转站 key
模型填写 GPT 系列或兼容模型

比如结构通常是：

/v1/chat/completions

这一类接口的重点不是模型名字，而是请求格式是否符合 OpenAI 标准。

---

八、OpenClaw 场景的配置方式

OpenClaw 本质上和 Codex 类似，也是 OpenAI 兼容体系。

所以在 CC Switch 里配置时逻辑一样：

Base URL 使用 OpenAI 兼容入口
API Key 使用统一 key
模型可以用 Claude 或 GPT 映射模型

这里更重要的是模型选择，而不是接口本身。

因为 OpenClaw 更偏长任务执行，如果是复杂任务，一般会用 Opus，如果是普通编码任务，会用 Sonnet。

---

九、CC Switch 对中转站的真正要求

如果你要让 CC Switch 正常工作，一个中转站至少要具备这些能力：

支持 Claude 兼容接口（给 Claude Code 用）
支持 OpenAI 兼容接口（给 Codex / OpenClaw 用）
支持模型列表接口（用于自动识别模型）
支持标准 Bearer 鉴权或 Anthropic Key

如果缺少模型列表接口，并不会导致完全不可用，但会影响自动识别体验，需要手动填模型名。

---

十、如何验证配置是否成功

配置完之后不要直接跑复杂任务，应该先做最小验证。

你可以按这个顺序来：

先在 CC Switch 里切换 Provider
再重启目标 CLI 工具
然后执行一个简单问题，比如让它回答当前模型名称

如果能正常返回，说明链路是通的。

如果失败，一般问题集中在三个地方：

API Key 错误
Base URL 不对
CLI 没有重新加载配置

---

十一、一个非常重要的工程结论

CC Switch 本质上不是“工具增强器”，而是“配置调度层”。

它解决的问题不是模型调用，而是：

多个 CLI 工具共用一套 API 接入体系时，如何统一管理。

而 API 中转站的作用，是把 Claude / GPT / Gemini 这些模型统一成标准接口。

所以正确理解应该是：

中转站提供能力
CC Switch 管理能力入口
CLI 工具执行能力

这三层是分开的。