最近聊 Claude Code 的人很多，但真正的问题不是“又出了什么新玩法”，而是很多人的工作流突然断了。
我只关心一个更实际的问题：如果 Claude Code 这套工作方式还想继续用，能不能把后端模型换成 GLM-5.2，先把个人项目跑起来？
我先看的不是广告，而是真实测评
图：Entelligence 在 Claude Code harness 里比较 GLM-5.2 和 Claude Opus。
Entelligence 的角度很贴近这个问题：他们不是单纯问模型几道题，而是把 GLM-5.2 和 Claude Opus 放进 Claude Code 的 agentic coding harness 里跑 45 个任务。
他们给出的结果是：45 个任务里，GLM-5.2 和 Opus 都解出 25 个；43/45 个任务上，两者结果一致；GLM-5.2 在开启 prompt caching 后，成本大约是 Opus 的 46%。
Opus 仍然是上限，GLM-5.2 更像成本效率路线
图：Braintrust 对 GLM-5.2 和 Opus 4.8 做长上下文检索评测。
Braintrust 的长上下文检索测评更适合解释两者定位：Opus 的优势是上限，复杂长上下文、细粒度检索、跨文件推理，它更稳。
GLM-5.2 的优势是成本效率。Braintrust 的测评里，它在长上下文任务上接近 Opus，但平均成本低了约 76-78%。
所以我不会说“GLM-5.2 平替 Opus”。更准确的说法是：Opus 是上限模型，GLM-5.2 是把大量日常 Claude Code 工作流重新跑起来的成本效率模型。
安全和代码任务里，GLM-5.2 也不是低配玩具
图：Semgrep 在安全任务 benchmark 中测试 GLM-5.2。
Semgrep 的测评偏安全任务。他们用 IDOR benchmark 测模型，GLM-5.2 在 prompt-only 方式下拿到 39% F1，超过他们文中列出的 Claude Code 配置结果。
这里不能简单外推成“GLM-5.2 全面超过 Claude”。Semgrep 自己也强调，benchmark 结果跟 harness、prompt、任务形式关系很大。
但它说明了一件事：国内/开源权重模型已经不是只能做便宜问答。在某些代码推理、安全审查、结构化分析任务里，GLM-5.2 已经有真实公开结果可以参考。
真正要替换的是 Claude Code 的后端模型
图：Anthropic 官方 Claude Code Settings 文档。
Claude Code 的价值不只在模型，还在工作方式：终端里接项目、读文件、推进任务。更接近原工作流的做法，是保留 Claude Code 这个工具形态，把后端模型切到一个 Claude / Anthropic 兼容接口。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
怎么用 GLM-5.2 接 Claude Code
-
确认本地 Claude Code 还能启动。
-
拿到 Claude / Anthropic 兼容的 Base URL、专属 Key、模型名和额度查询页。
-
先跑短任务，比如解释函数、改小脚本、生成配置片段。
-
再跑小项目，让它读一个小目录、定位一个报错、给修改建议。
-
最后才试长上下文任务。
哪些体验我会保留期待，哪些不会
我会期待 GLM-5.2 做日常代码解释、小脚本修改、配置文件生成、报错排查、中文语境下的说明和总结、个人项目里的低成本试错。
我不会期待它完全替代 Opus：超长上下文里保持极高一致性、非常复杂的多步 agent planning、大型代码库全局重构、每一次工具调用都像原生 Claude 一样顺滑。
这不是在说某个接口差，而是在说模型定位不同。Opus 买的是上限和稳定感，GLM-5.2 买的是成本、可用性和国内模型替代路线。
最后说一句很实际的
如果 Claude Code 最近突然不可用，我更建议先把链路跑通：Claude Code 是否还能启动，Base URL 是否填对，Key 是否能用，Model 是否是 glm-5.2，短任务是否能返回，小项目是否能推进。
我把这次查到的公开测评、配置笔记、测试步骤和常见错误整理成了一份小清单。如果你也想自己试一遍，可以私信关键词：Claude Code 备用模型。
先跑通，再决定要不要继续用。
