关于国内怎么用 AI 写代码，流传最广的说法是「要么想办法用 Claude，要么换国产模型」——这是个伪选择。Claude Code 的模型是按请求指定的，同一个客户端里可以让主任务走一个模型、子任务走另一个模型，也可以在会话中途一句 /model 切过去。真正需要判断的不是「选哪一家」，而是「哪类任务该给哪类模型」。这篇给出三种共存方式的具体配置、任务分流的判断依据，以及共存之后会冒出来的三个新问题。
一、「二选一」这个错觉是怎么来的
几乎所有教程教的都是同一个动作：
export ANTHROPIC_BASE_URL="某一家的地址"
export ANTHROPIC_AUTH_TOKEN="某一家的 Key"
这个动作叫「换」。换的语义是排他的——换了 A 就没有 B。于是大量文章顺理成章地把它写成了一道选型题。
但 Claude Code 的模型解析是按请求发生的，不是按安装发生的。它至少有四个独立的模型变量：
ANTHROPIC_MODEL # 主任务默认用哪个
ANTHROPIC_DEFAULT_OPUS_MODEL # 被要求用「最高档」时用哪个
ANTHROPIC_DEFAULT_SONNET_MODEL # 中间档
ANTHROPIC_DEFAULT_HAIKU_MODEL # 轻量档
CLAUDE_CODE_SUBAGENT_MODEL # 子任务用哪个
这五个变量可以指向不同的模型。 只要它们背后的端点都兼容 Anthropic 协议，客户端不关心你混了几家。
「二选一」的错觉，本质上是把「端点只能填一个」误当成了「模型只能用一个」。
二、三种共存方式
2.1 会话内切换：/model
最简单的一种。在 Claude Code 的对话里直接输入：
/model
它会列出当前可用的模型，选一个即可，不用退出会话、不用重启。适合的场景是：正在做一件事，中途发现需要换个能力档位。
前提是你的端点后面挂着多个模型。如果端点只映射了一个模型，这个菜单里就只有一项。
2.2 主任务与子任务分开路由（这条最省钱）
Claude Code 在执行复杂任务时会派生子任务去做杂活——读文件、grep、简单判断。默认情况下，这些子任务可能和主任务用同一个模型。
一次跨文件重构里，子任务的调用次数常常是主任务的好几倍。用高价模型去读文件，是最典型的浪费。
分开指定：
# 主任务：难活，用能力上限高的
export ANTHROPIC_MODEL="你的主力模型"
export ANTHROPIC_DEFAULT_OPUS_MODEL="你的主力模型"
# 杂活：读文件、搜索、简单判断
export CLAUDE_CODE_SUBAGENT_MODEL="你的轻量模型"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="你的轻量模型"
⚠️ CLAUDE_CODE_SUBAGENT_MODEL 这个变量知道的人很少，但它在重度使用下的成本差别是数倍量级的。配置前后各跑一次同样的重构任务，看用量统计就知道差多少。
2.3 多配置文件按项目切换
给不同场景各写一份配置：
~/.claude/
├── settings-a.json # 一套端点
├── settings-b.json # 另一套端点
└── settings-local.json # 本地/私有部署
每份长这样：
{
"env": {
"ANTHROPIC_BASE_URL": "对应的端点地址",
"ANTHROPIC_AUTH_TOKEN": "对应的 Key",
"ANTHROPIC_MODEL": "对应的模型名",
"API_TIMEOUT_MS": "600000"
}
}
启动时指定：
claude --settings ~/.claude/settings-a.json
嫌麻烦可以设 alias，或者用社区的开源工具 cc-switch 做可视化管理，它内置了几十家厂商的预设。
这三种方式可以叠加：用 2.3 决定这个项目走哪套端点，用 2.2 在端点内部分流主子任务，用 2.1 临时救急。
三、什么任务该给什么模型
这是共存之后真正要回答的问题。下面这张表的依据是任务特性，不是厂商排名：
| 任务类型 | 关键需求 | 该给什么 |
|---|---|---|
| 跨文件重构、架构决策 | 长链路推理、不能漏改 | 能力上限最高的那档 |
| 大仓库理解、长文档分析 | 窗口大小 > 推理深度 | 长上下文模型（见第四节） |
| 写测试、补注释、格式整理 | 任务边界清晰 | 轻量模型，别浪费 |
| 读文件、grep、目录遍历 | 几乎不需要推理 | 最便宜的那档 |
| 算法推导、数学证明 | 推理链完整性 | 推理型模型 |
| 需要时效性信息 | 训练语料有截止时间 | 带联网能力的 |
| 中文文档、中文注释 | 语言习惯 | 国产模型往往更自然 |
两条容易搞反的：
① 长文档不一定要用最贵的模型。 一个 1M 窗口的中档模型，在「读完整个仓库再回答」这件事上，可能比 200K 窗口的顶配模型更有用。窗口是硬约束，能力是软约束。
② 「日常编码够用」和「复杂重构够用」是两个结论。 网上很多测评说国产模型「效果也很好」，这个判断在日常编码、读代码、写文档上成立；但在长链路的复杂重构、大规模代码库理解上，和第一梯队仍有可感知的差距。别用一个场景的结论去覆盖另一个场景。
四、共存带来的三个新问题
诚实地说，混用不是白拿的，它引入了三个原本不存在的问题。
4.1 上下文窗口标记：影响最大、知道的人最少
Claude Code 对它不认识的模型 ID，一律按 200K 上下文处理。如果你切到一个 1M 窗口的模型，它会在 200K 就触发自动压缩——你损失了 5 倍上下文，而且它不报错。
你的感受会是「这模型怎么老忘事」，然后你会去怪模型。
自查：
/context
看第一行的分母。是 200k 但你用的是 1M 模型，就中招了。
修法是给模型 ID 加 [1m] 后缀。三条实测注意事项：
[1m]是纯客户端侧的标记，不是上游模型名。带后缀的名字直接发给厂商 API 会报「模型不存在」，这个后缀必须由中间层吃掉- 只给确认是 1M 窗口的模型加，加之前查准官方文档
- 标错比不标更糟：不标最坏是压缩太早（难受但不崩）；标大了会一路顶到上游真实窗口才撞墙，直接 API 报错，而那时会话里已经堆了一堆东西
⚠️ 官方模型也一样，默认 200K，1M 是要显式选的。这不是第三方模型专属问题。
4.2 工具调用行为的差异
Claude Code 重度依赖 tool use（读文件、执行命令、编辑）。不同模型对工具调用的支持成熟度不同，表现出来是：
- 有的模型会漏掉
tool_use的某些参数 - 有的在多轮工具调用后丢失上下文关联
- 流式输出的分片结构不一致，可能导致显示异常
判别方法：让它做一个需要连续三次工具调用的任务（比如「找出所有引用了某函数的文件，逐个打开，统计调用次数」）。能稳定走完的，工具调用支持就是可用的。
4.3 计费口径对不上
混用之后，你的花销分散在多个地方，且计价单位可能不同（有的按 token、有的按次、有的包月）。想知道「这个月到底花了多少」会变得麻烦。
这是聚合类服务的实际价值所在——不是便宜，是把多个口径统一成一个。
五、怎么验证切换真的生效了
切换之后必须验证，否则你可能一直在用你以为已经换掉的那个模型。
🔴 先说一个不成立的方法：问它「你是什么模型」。模型自述的身份可以被系统提示词改写，返回体里的 model 字段也是服务端自己填的，两者都证明不了背后实际调用的是什么。
有参考价值的是这几条：
① 看 /context 的分母。 不同模型窗口不同，分母会跟着变。这是最难伪造的一项。
② 看响应的行为指纹。 有的模型会输出思考过程，有的不会；同一系列的相邻版本，这个行为可能刚好不同。拿行为差异做交叉验证，比问身份可靠。
③ 看错误响应的结构。 用一个故意写错的 Key 发一次请求：
curl -s -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
-H "x-api-key: sk-obviously-wrong" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-4-5-20250929","max_tokens":16,
"messages":[{"role":"user","content":"hi"}]}' | head -c 300
正经实现会返回结构化 JSON 错误体。返回 HTML、纯文本、或者干脆返回 200 的，说明中间那层根本没在转发。
④ 看用量记录的粒度。 后台能不能分项显示输入 token / 输出 token / 缓存 token？只给一个模糊的「剩余额度」、不能逐条审计的，用量上动手脚的空间很大。
六、三条落地路径
要实现多模型共存，有三种做法，成本和维护负担差别很大：
| 做法 | 怎么做 | 适合谁 | 代价 |
|---|---|---|---|
| 各家分别开户 | 去每家厂商注册、充值、拿 Key，自己写多份配置 | 用量集中在一两家、想要最低单价 | 多个账号、多份账单、多套限额，切换要改配置 |
| 本地工具管理 | 用 cc-switch 这类开源工具做可视化切换 |
已经有各家 Key，只是嫌手改 JSON 麻烦 | 解决了切换，没解决多账号和多账单 |
| 聚合网关 | 一个 Key 后面挂多家模型 | 想省掉账号和账单的管理成本 | 多一层中间方，需要按第五节自己验证 |
没有普适答案。用量集中在一家的，自己开户最省；需要频繁跨家切换的，聚合层的价值才显现出来。
七、说明一下 Code2AI 是什么（以及不是什么）
写到这里该说明立场：我们做的是第三种，code2ai.codes。
先澄清一个容易混淆的点：网上有一个名字接近的产品叫 Code2.AI，那是一个把代码库压缩成 AI 可读格式的代码协作工具，和我们不是一回事，也没有关系。我们做的是 API 网关——你的 Claude Code 照常用，只是把请求发到我们这里，由我们路由到不同厂商的模型。
具体形态是本文说的「共存」：
- 一个 Key、一份包月额度，覆盖 Claude 全系、GPT 全系、Kimi、GLM、DeepSeek、Grok 六家
- 额度是共享池，不是各模型独立叠加——强模型扣得快、轻量模型扣得慢，你可以把额度全花在真正需要的模型上
[1m]后缀已经在模型菜单里预置好，不用自己折腾第四节那个坑。窗口没有可靠依据的模型故意没加——按第 4.1 节第三条，标错比不标更糟- 调用记录保留 30 天，可以逐条看
它不适合谁，说在前面：
- 用量集中在单一厂商的 —— 直接去那家开户更省
- 一个月只用几次的 —— 按量计费更划算，包月的价值在可预测性不在便宜
- 需要数据完全不出自己服务器的 —— 应该走私有部署，任何聚合层都不满足这个要求
第五节那四条验证方法，建议你对任何服务商（包括我们）都跑一遍。
八、常见问题
Q：一个 Claude Code 里真的能同时用 Claude 和国产模型吗？
能。主任务和子任务可以指向不同模型（2.2 节），会话中途也能用 /model 切（2.1 节）。前提是端点后面挂着多个模型。
Q：切换模型需要重启 Claude Code 吗？/model 不需要。改环境变量或配置文件需要重启。
Q：混用会不会导致上下文丢失？
切换模型时当前会话的上下文会带过去，但新模型的窗口可能更小，超出部分会被压缩。切到小窗口模型前留意一下 /context。
Q：ANTHROPIC_API_KEY 和 ANTHROPIC_AUTH_TOKEN 用哪个？
不同版本、不同接入方式要求不同。一个不行试另一个，或者两个都设成同一个值。这是最常见的配置失败原因之一。
Q：怎么知道子任务真的走了轻量模型？
看用量记录的分项。配置前后各跑一次同样的任务，对比轻量模型的调用次数——如果 CLAUDE_CODE_SUBAGENT_MODEL 生效了，它的调用次数会明显高于主模型。
Q：国产模型能替代 Claude 吗？
分场景。日常编码、读代码、写文档基本够用；长链路复杂重构、大规模代码库理解仍有可感知差距。所以本文的结论才是「分流」而不是「替代」。
小结
- 「用 Claude 还是用国产模型」是伪选择。Claude Code 的模型是按请求指定的，五个模型变量可以指向不同厂商
- 三种共存方式：
/model会话内切、主子任务分开路由、多配置文件切换，可以叠加 - 最省钱的一条是主子任务分流，
CLAUDE_CODE_SUBAGENT_MODEL知道的人很少但差别是数倍量级 - 分流依据是任务特性不是厂商排名：窗口是硬约束，能力是软约束
- 共存有代价：上下文窗口标记、工具调用行为差异、计费口径分散
- 切换后必须验证，而问模型「你是谁」不算验证
先去跑一次 /context，看看你现在的上下文窗口分母是多少。这一条和你用哪家模型无关，但可能比选哪家影响更大。
