不要在 Claude Code 中使用其他模型
- 内容介绍
- 文章标签
- 相关推荐
如题，Claude Code 允许你修改环境变量，通过调整 BASE_URL 和 API_KEY 的方式，接入非官方源。其核心是让你能配自己的企业源，通常特指 Vertex AWS 及授权企业的 Opus4.6 / Sonnet4.6。
而不是你 Claude Code Router 或 LiteLLM 接的本地部署的模型或者另外的其他国产厂的source，这会带来非常严重的性能损耗和降智行为。
基于 Claude Code 使用的国产模型都会有不同程度的降智行为，相关评测也不具备说服力，只能说明你测的模型相较于 Opus4.6 来说无法驾驭 Claude Code。
原因有几点：
- Claude Code 只适合 Claude 模型使用
Claude Code 提供的是一套 strategy 和 环境，这套环境塞入了26个初始工具和将近20k的零启动规约，使用严格的 XML 提示词将你的 skills，mcp，hook，CLAUDE.md 以及其他来自各个目录的 .claude/ 规则全都扫进上下文，加上你的 user prompt 和 compact memroy，整个运行压力非常沉重，起手僵直直接打满。对于这种极端复杂的 context，是否进行管针对性的微调训练是关键因素，方差极大。对于一个国产模型或者开源模型来说，使用更轻量的上下文负担工具效果会更好，例如 opencode，kimi code， kilo，trae 等。 - Claude Code 的接口协议适配问题
比如某个版本后引入了新的特性，新的接口参数，新的规约指纹特征，这都可能导致整个调用链彻底崩溃。最明显的表现就是某个 step 之后会话莫名其妙就结束了，看起来像是被提前中断一样。还有就是不可控的上下文，A社只要稍微改一下指纹特征就能让你的缓存失效击穿，带来巨额账单。 - Claude Code 产品本身在跟着 Claude 模型成长迭代
一些有利于拓展模型能力边界的特性随着模型能力提升而被逐渐内化至产品之中，这些设计在 Agent 的长程运行中被自主调用触发。例如 agent team，auto plan，harness pipeline 等。这些有利于提高生产力和稳定性的设计对模型能力本身是有极大挑战的，强强结合如虎添翼，这种正反馈链路带来的结果就是，Anthropic 团队使用 Claude Code 参与模型训练的全流程，而更加强大的模型彻底解放产品经理的想象力，各路 side project 神奇先生作为针对新的更强大的 Claude 模型可以驾驭的机制被添加到 Claude Code 中。如此反复，带来的结果就是，Claude Code 是一个专为 Claude 更强大的模型家族设计的铁驭，只有当你替换的模型具备 Claude 模型同水准的能力且有适应 Claude Code 的体质，你才有可能在这个组合下得到比较可控的输出（这也是为什么有些厂喜欢蒸馏 Claude 模型）。
以上。
网友解答：--【壹】--：
贻笑大方
--【贰】--：
我的意思是，可以用 opencode 之类的 + coding plan
--【叁】--：
大佬，请问像OpenRouter、Poe这类，声称是和厂商直接合作的Claude模型的API，使用的效果和Claude官方API，以及企业源（Vertex AWS 及授权企业的 Opus4.6 / Sonnet4.6）效果是否存在差别？
因为这些官方中转虽说相对比较权威，但说白了本质还是个黑盒，所以也不太确定这点。
--【肆】--：
因为有时候Claude max被封号了，只能临时找补，谁想呢
--【伍】--： 0xkk:
（这也是为什么有些厂喜欢蒸馏 Claude 模型）
佬还想请教一个问题，关于这段，是不是可以理解为，蒸馏Claude越多的，和Claude逻辑与性能越接近的模型，虽然肯定比不上原装，但理论上和Claude Code的适配度更强。
--【陆】--：
昨日是不是同样的帖子亦有发过。
--【柒】--：
……… 我要有稳定的正版克劳德我肯定不用第三方
--【捌】--：
Vertex，AWS，Azure，效果一样。
但是如果是从 OpenRouter 和 POE 走 Claude，效果差距很大
--【玖】--：
这段文字看着怎么有点不像人话，机翻还是ai生成？最后，蒸馏以为只有a畜没蒸馏别人吗
--【拾】--：
相关但非因果。越是蒸馏 Claude 的模型，coding bench 分数彪的越快。但他们蒸的永远是三个月以前的 claude，而 claude code 平均一周两个版本，要硬追会过拟合，三方工具使用能力一般都是涌现出来的。适配度更强一般看接口层的协议适配，现在这些模型都不弱了。
--【拾壹】--：
GLM呢？他不是针对cc特调了
--【拾贰】--：
好像有佬友举报了，被system下架了，理由是 AIGC，有点抽象
--【拾叁】--：
手敲的，有点难理解的话我用 AI 润色一下？
--【拾肆】--：
你有 claude code 和 OpenRouter 贡献的高质量数据和场景信息，蒸 gemini 和 gpt 的意义已经不大了。
--【拾伍】--：
感谢指点，太专业了佬
--【拾陆】--：
我咋感觉我今天还是昨天看到过这个帖子
--【拾柒】--：
ai润色要截图了，自己手敲就不用
--【拾捌】--：
奇怪呀，我好像之前看到过这个话题，这是又开了一个吗
--【拾玖】--：
有时候没办法啊，kimi、glm实在没办法也只能用
如题，Claude Code 允许你修改环境变量，通过调整 BASE_URL 和 API_KEY 的方式，接入非官方源。其核心是让你能配自己的企业源，通常特指 Vertex AWS 及授权企业的 Opus4.6 / Sonnet4.6。
而不是你 Claude Code Router 或 LiteLLM 接的本地部署的模型或者另外的其他国产厂的source，这会带来非常严重的性能损耗和降智行为。
基于 Claude Code 使用的国产模型都会有不同程度的降智行为，相关评测也不具备说服力，只能说明你测的模型相较于 Opus4.6 来说无法驾驭 Claude Code。
原因有几点：
- Claude Code 只适合 Claude 模型使用
Claude Code 提供的是一套 strategy 和 环境，这套环境塞入了26个初始工具和将近20k的零启动规约，使用严格的 XML 提示词将你的 skills，mcp，hook，CLAUDE.md 以及其他来自各个目录的 .claude/ 规则全都扫进上下文，加上你的 user prompt 和 compact memroy，整个运行压力非常沉重，起手僵直直接打满。对于这种极端复杂的 context，是否进行管针对性的微调训练是关键因素，方差极大。对于一个国产模型或者开源模型来说，使用更轻量的上下文负担工具效果会更好，例如 opencode，kimi code， kilo，trae 等。 - Claude Code 的接口协议适配问题
比如某个版本后引入了新的特性，新的接口参数，新的规约指纹特征，这都可能导致整个调用链彻底崩溃。最明显的表现就是某个 step 之后会话莫名其妙就结束了，看起来像是被提前中断一样。还有就是不可控的上下文，A社只要稍微改一下指纹特征就能让你的缓存失效击穿，带来巨额账单。 - Claude Code 产品本身在跟着 Claude 模型成长迭代
一些有利于拓展模型能力边界的特性随着模型能力提升而被逐渐内化至产品之中，这些设计在 Agent 的长程运行中被自主调用触发。例如 agent team，auto plan，harness pipeline 等。这些有利于提高生产力和稳定性的设计对模型能力本身是有极大挑战的，强强结合如虎添翼，这种正反馈链路带来的结果就是，Anthropic 团队使用 Claude Code 参与模型训练的全流程，而更加强大的模型彻底解放产品经理的想象力，各路 side project 神奇先生作为针对新的更强大的 Claude 模型可以驾驭的机制被添加到 Claude Code 中。如此反复，带来的结果就是，Claude Code 是一个专为 Claude 更强大的模型家族设计的铁驭，只有当你替换的模型具备 Claude 模型同水准的能力且有适应 Claude Code 的体质，你才有可能在这个组合下得到比较可控的输出（这也是为什么有些厂喜欢蒸馏 Claude 模型）。
以上。
网友解答：--【壹】--：
贻笑大方
--【贰】--：
我的意思是，可以用 opencode 之类的 + coding plan
--【叁】--：
大佬，请问像OpenRouter、Poe这类，声称是和厂商直接合作的Claude模型的API，使用的效果和Claude官方API，以及企业源（Vertex AWS 及授权企业的 Opus4.6 / Sonnet4.6）效果是否存在差别？
因为这些官方中转虽说相对比较权威，但说白了本质还是个黑盒，所以也不太确定这点。
--【肆】--：
因为有时候Claude max被封号了，只能临时找补，谁想呢
--【伍】--： 0xkk:
（这也是为什么有些厂喜欢蒸馏 Claude 模型）
佬还想请教一个问题，关于这段，是不是可以理解为，蒸馏Claude越多的，和Claude逻辑与性能越接近的模型，虽然肯定比不上原装，但理论上和Claude Code的适配度更强。
--【陆】--：
昨日是不是同样的帖子亦有发过。
--【柒】--：
……… 我要有稳定的正版克劳德我肯定不用第三方
--【捌】--：
Vertex，AWS，Azure，效果一样。
但是如果是从 OpenRouter 和 POE 走 Claude，效果差距很大
--【玖】--：
这段文字看着怎么有点不像人话，机翻还是ai生成？最后，蒸馏以为只有a畜没蒸馏别人吗
--【拾】--：
相关但非因果。越是蒸馏 Claude 的模型，coding bench 分数彪的越快。但他们蒸的永远是三个月以前的 claude，而 claude code 平均一周两个版本，要硬追会过拟合，三方工具使用能力一般都是涌现出来的。适配度更强一般看接口层的协议适配，现在这些模型都不弱了。
--【拾壹】--：
GLM呢？他不是针对cc特调了
--【拾贰】--：
好像有佬友举报了，被system下架了，理由是 AIGC，有点抽象
--【拾叁】--：
手敲的，有点难理解的话我用 AI 润色一下？
--【拾肆】--：
你有 claude code 和 OpenRouter 贡献的高质量数据和场景信息，蒸 gemini 和 gpt 的意义已经不大了。
--【拾伍】--：
感谢指点，太专业了佬
--【拾陆】--：
我咋感觉我今天还是昨天看到过这个帖子
--【拾柒】--：
ai润色要截图了，自己手敲就不用
--【拾捌】--：
奇怪呀，我好像之前看到过这个话题，这是又开了一个吗
--【拾玖】--：
有时候没办法啊，kimi、glm实在没办法也只能用