LinkyMonitor / Claude 降智

Claude 降智是什么？怎么判断是不是中转站掉包了模型

你觉得它变笨了，但你不确定这是错觉、是上游限流，还是中转站把你的请求转给了更便宜的模型。 这三种成因的处理方式完全不同——分不清，换一家站也解决不了问题。

最后更新 2026-08-15 · 阅读约 6 分钟

「降智」其实是三件不同的事

社区里说的「降智」是一个感受词，不是一个诊断。同样一句「今天 Claude 好笨」， 底下可能藏着完全不同的东西：

前三类是中转站的行为问题，第四类未必是谁的错，第五类根本不是「降智」。 先分类，再行动——否则你只是在不同的站之间轮换，而没有任何证据说明哪一家更好。

为什么「直接问它是不是 Claude」不管用

最常见的自检方式是发一句「你是什么模型」，然后看它怎么回答。这个方法的问题在于， 它检验的不是模型身份，而是模型愿意说什么：

• 模型并不可靠地知道自己是谁。它对自身型号的说法来自训练数据和系统提示，不是运行时的自省。
• 系统提示可以覆盖答案。转发层加一句「你是 Claude」，任何模型都会照着说。
• 这个问法太出名了。正因为人人都这么问，它也是最容易被针对性处理的一条路径。

同样的逻辑也适用于「让它做一道难题看答得对不对」——单次答对答错受随机性影响很大， 证明不了稳定的身份。要判断，得看那些不由模型自述、而由协议本身暴露的东西。

可以客观观察的四类信号

1. usage 字段的结构

同一段固定 prompt，输入 token 数应当是稳定的。如果同样的输入在不同时间被算成不同的 token 数， 或者和官方接口跑出来的数字对不上，说明中间有人在改写。缓存命中数、 thinking token 是否单独计数，也都是可比对的结构特征。这部分展开在 Token 虚标与倍率对账。

2. 能力探针

与其问「你是谁」，不如测「你能不能做只有这个型号才能做的事」。例如显式关闭 thinking 后响应里是否仍出现 thinking 内容、声明的上下文长度是否真的吃得下、 缓存写入后第二次请求是否真的命中、工具调用与结构化输出是否按规范返回、 stop_reason 是否符合预期。这些都是协议层面的事实，不依赖模型自述。

3. 延迟与 TTFT 的分布

不同规格的模型，首字延迟和总耗时的分布是不一样的。单看一次没有意义， 但同一条链路的分布如果整体平移，通常意味着后面换了东西。

4. 输出长度与终止原因的分布

相同任务下输出长度突然整体缩水，或 stop_reason 的构成发生变化， 都是值得记录的偏移。

一次检测为什么不够

假设你今天测了一遍，全绿。这能说明什么？只能说明你测的那一次是正常的。

• 掉包可以是部分的。按比例、按时段、按用户分流，只把一部分请求转到便宜模型，抽检大概率抽不到。
• 配置可以随时改。你测完之后，后台改个开关就是另一回事，而你不会再测第二次。
• 恢复正常不等于没发生过。问题消失了，但你这几天多花的钱和跑坏的任务不会回来。

所以真正有用的问题不是「它现在正不正常」，而是「它这一个月里，有没有哪几天不正常」。 这需要的是持续记录，不是一次体检。