用 Claude Code 接 GPT-5.4 中转站：为什么能用，CLAUDE.md 和记忆还是否有效？-公众号：白日梦与诗

最近我遇到一个很典型的问题：

我平时用的是 Claude Code（CC），并且通过 cc-switch 来切换不同配置。之前常用的是 Claude 的中转站，可以跑 claude sonnet 4.6 或 claude opus 4.6。但最近 Claude 大模型线路不太稳定，我又看到有一些中转站提供 gpt-5.4。

这些中转站大多走的是 New API 兼容格式，所以我自然会问：

既然请求格式看起来差不多，为什么 codex 配 gpt-5.4 没连上，claude 配 gpt-5.4 却能用？
如果底层已经是 gpt-5.4，那我在 Claude Code 里问“你是什么模型”时，为什么它还是说自己是 claude sonnet 4.6？
在这种情况下，CLAUDE.md、记忆文档、Skills SOP 这些东西还是否有效？

这篇文章就是把这些问题一次性讲清楚。

一、先说结论

如果你现在的用法是：

外层工具：Claude Code
配置切换：cc-switch
后端路由：某个兼容接口的 GPT-5.4 中转站

那么更准确的理解应该是：

你仍然是在用 Claude Code 这套壳子和工作流，只是底层推理模型可能被路由到了 GPT-5.4。

所以：

CLAUDE.md：继续有效
记忆文档（memory）：继续有效
.claude/skills/：继续有效
自定义 agents / tools / workflow：继续有效

但同时也要知道：

会话里显示的“模型身份”，不一定等于真实后端模型
执行风格和遵循度，可能会因为底层模型不同而发生变化

二、为什么 codex 配 GPT-5.4 没连上，但 claude 配 GPT-5.4 能用？

这是很多人第一次折腾中转站时最容易困惑的地方。

1. 不能只看“模型名”

gpt-5.4 只是后端模型名的一部分信息。一个 CLI 能不能连通，通常还取决于：

鉴权方式是否兼容
请求路径是否兼容
请求体字段是否兼容
流式返回格式是否兼容
tool calling / function calling 的协议是否兼容

也就是说：

不是模型名一样，就一定能被另一个客户端直接使用。

2. Claude Code 能跑，说明中转站更像是在“伪装成 Claude 兼容接口”

如果你把这个 gpt-5.4 的中转站配置在 cc-switch 的 claude 侧，结果 claude 命令能正常跑，那通常意味着：

这个中转站至少在外层接口上，足够兼容 Claude Code 当前所需的协议
虽然后端实际可能是 GPT-5.4，但它对外暴露的是一种 Claude/Anthropic 兼容壳

所以流程更像是：

Claude Code → 按 Claude 协议发请求 → 中转站做转译 → GPT-5.4 返回结果

3. codex 连不上，不代表模型不能用

这通常只说明一件事：

这个中转站并不兼容 codex CLI 所要求的那套接口细节。

也就是说，问题不一定在模型本身，而在于：

codex 想要的是一套 OpenAI/Codex 风格的交互协议
这个中转站虽然底层是 GPT-5.4，但对外并没有把这套协议完整实现出来

所以出现：

claude 侧能用
codex 侧不能用

是完全可能、也很常见的。

三、那我现在到底算在用什么模型？

这个问题一定要分成两层来看。

1. 外层运行框架：你在用 Claude Code

你当前的工作环境里，真正主导行为的是：

Claude Code 的 system prompt
项目里的 CLAUDE.md
.claude/skills/
memory 文档
tool use 规则
agent 机制

这些都属于 Claude Code 客户端层 / 框架层。

所以从工作流角度说，你确实仍然是在用：

Claude Code

2. 底层推理模型：可能已经被换成 GPT-5.4

如果 cc-switch 把请求实际转发到了某个 GPT-5.4 中转站，那么真正执行推理的模型，可能已经不是官方 Claude，而是：

GPT-5.4（经由中转站路由）

所以更准确的说法是：

壳子是 Claude Code
脑子可能是 GPT-5.4

这两个并不矛盾。

四、为什么我问“你是什么模型”，它还是说 Sonnet 4.6？

这也很正常。

因为在 Claude Code 里，模型身份的很多信息来自于：

客户端环境注入
当前会话上下文
运行时预设的模型描述

而不是来自于“我实时检测到了中转站背后到底连的是哪个模型”。

所以当你问：

你现在是什么模型？

会话里的回答很可能仍然是：

Claude Sonnet 4.6
Claude Code
claude-sonnet-4-6

但这并不一定能证明：

后端就真的是官方 Sonnet 4.6

更准确的理解是：

会话身份会沿用 Claude Code 的设定，但真实后端可能已经被路由成了 GPT-5.4。

所以这里要刻意区分两件事：

会话身份

Claude Code
Sonnet 4.6
Anthropic 风格 system prompt

真实后端

可能是 GPT-5.4
也可能是某个中转站包装过的其它模型

这也是为什么你会看到一种“看起来像 Claude，实际可能不是官方 Claude”的状态。

五、CLAUDE.md 和记忆文档还是否有效？

有效。

只要你还是通过 Claude Code 在运行，这些本地机制通常都还在：

CLAUDE.md
auto memory / MEMORY.md
.claude/skills/
自定义 agents
项目级规则
工具调用约束

因为这些不是后端模型自己决定的，而是 Claude Code 客户端在本地注入和调度的。

也就是说：

本地规则层

仍然是 Claude Code 在管：

先读什么文件
遵守哪些 SOP
回复语言是什么
哪些工具优先使用
文章默认放到哪个目录

远端推理层

由中转站背后的模型负责：

理解问题
组织答案
生成文本
跟随规则的稳定程度

所以答案不是“完全一样”，而是：

规则系统还是同一套，但执行它的底层模型可能换了。

六、那是不是就和以前完全一样？

不能说“完全一样”，只能说：

框架一样，后端可能不一样。

这意味着你的使用体验通常会分成两部分：

一样的部分

仍然走 Claude Code 命令行
仍然读 CLAUDE.md
仍然加载记忆文档
仍然能调用 skills / agents / tools
仍然延续你原来的工作流

不一定一样的部分

对长 system prompt 的服从度
对 SOP 的严格执行程度
工具调用习惯
中文表达风格
长上下文连续性
对细节约束的稳定性

也就是说，虽然“能跑”，但质量、风格、守规矩程度未必完全等价于官方 Claude。

七、最值得记住的一句话

如果你以后再遇到类似情况，可以用这句话来判断：

只要你还是用 Claude Code 这个客户端在工作，那 CLAUDE.md、memory、skills 和整个本地工作流通常都还有效；变的只是后端推理模型，不一定是工作流本身。

八、架构图：Claude Code、cc-switch、中转站、GPT-5.4 的关系

下面这张图可以帮助快速理解你当前这套链路到底是怎么工作的。

flowchart TD
    A[苏苏在终端输入 claude] --> B[Claude Code 客户端]
    B --> C[加载本地规则]

    C --> C1[CLAUDE.md]
    C --> C2[Memory 记忆文档]
    C --> C3[Skills / Agents / Tools]
    C --> C4[项目级工作流与系统提示词]

    B --> D[cc-switch 当前配置]
    D --> E[claude 配置项]
    E --> F[中转站 API\nAnthropic/Claude 兼容外壳]
    F --> G[真实后端推理模型\nGPT-5.4]
    G --> F
    F --> B

    B --> H[最终在终端呈现回答]

    style B fill:#e8f0fe,stroke:#4a78ff,stroke-width:1px
    style F fill:#fff4e5,stroke:#ff9800,stroke-width:1px
    style G fill:#f3e5f5,stroke:#9c27b0,stroke-width:1px
    style C fill:#e8f5e9,stroke:#43a047,stroke-width:1px

这张图对应的核心含义是：

你操作的入口仍然是 Claude Code
本地规则仍然由 Claude Code 加载
cc-switch 决定请求发到哪个配置
中转站可能只是一个兼容协议的转发层
真正做推理的模型，可能已经是 GPT-5.4

所以最终出现的状态就是：

用的是 Claude Code
跑的是 Claude 风格工作流
背后算力可能是 GPT-5.4

九、适合怎么理解这件事？

我现在更推荐一种不容易混乱的说法：

不要问：我到底是在用 Claude 还是 GPT？

因为现实里你可能是在用一个“混合态”：

工具链是 Claude 的
协议壳可能是 Claude 兼容的
后端模型却是 GPT 的

更应该问：哪一层没有变，哪一层变了？

没变的层

客户端：Claude Code
规则：CLAUDE.md
记忆：memory
技能：skills
工作流：你的 Obsidian + CC 体系

变了的层

实际推理模型
响应风格
遵循规则的稳定度
与某些 CLI 的协议兼容性

这样理解，你就不会再被“为什么它说自己是 Sonnet 4.6”这种现象绕进去。

十、最后总结

把这篇文章浓缩成三句话：

codex 配不通、claude 能用，通常不是模型问题，而是接口兼容层不同。
你现在依然是在用 Claude Code 这套壳子，只是底层推理模型可能已经被 cc-switch 路由到了 GPT-5.4。
因此 CLAUDE.md、记忆文档、Skills 和本地工作流通常依然有效，只是执行质量可能和官方 Claude 不完全一样。

如果你也在折腾中转站、多模型切换、或者“Claude 壳接 GPT 脑”的混合工作流，希望这篇文章能帮你把概念理顺。

创建者：苏苏 + Claude Code
创建时间：2026-03-06

白日梦与诗

探索

用 Claude Code 接 GPT-5.4 中转站：为什么能用，CLAUDE.md 和记忆还是否有效？