怎么判断AI中转站有没有掺水降智，常见问题和做法

你付的是某个模型的价，回你的却可能是更便宜的模型，或者同一个模型被调低了输出长度、掐掉了推理过程。单看一两次回答很难确认，容易被“感觉变笨了”带偏。这篇给一套能自己复现的做法：先准备好对照题和记录字段，再把返回结果和日志逐项比对，最后按证据强弱决定是继续用、找对方核对还是换一家。

你付的是某个模型的价，回你的却可能是更便宜的模型，或者同一个模型被悄悄调低了输出长度、掐掉了推理过程。单看一两次回答很难确认，容易被「感觉变笨了」带偏。这篇给一套能自己复现的做法：先备好对照题和记录字段，再把返回结果和日志逐项比对，最后按证据强弱决定继续用、找对方核对，还是换一家。

别指望有一个开关一按就知道真假。中转站掺水往往是间歇性的，白天正常晚上降档，或者只在长上下文、复杂推理时露馅。所以核心不是「问一句看他聪不聪明」，而是固定题目、固定参数、多轮记录，用可比的原始数据说话。下面按排查顺序走一遍。

先分清「掺水降智」到底指哪几种情况

很多误会出在把不同问题混成一个「变笨了」。先分类再判断，手法完全不一样：换模型是能力全景变了，截短输出是后半段质量断崖，缓存顶替是同一题答案过于一致。分类清楚后，你才知道该盯哪几个字段。

准备一组固定测试题和一份记录表

测试题不用多，但要覆盖不同能力面，固定提示词和温度，每次都原样跑。建议四类各留两道：长上下文（给一段材料问细节）、指令跟随（多条格式约束）、多步推理（需要列步骤的算术或逻辑题）、结构化输出（要求返回严格 JSON 或表格）。这样差异能定位到具体能力，而不是笼统说「不行」。

• 长上下文：塞几千字材料，问结尾处的一个具体细节，看会不会漏读或瞎编
• 指令跟随：给三条互相约束的格式要求，看漏几条
• 多步推理：要求先列步骤再给结论，看推理过程是否被省略
• 结构化输出：要求返回可解析的 JSON，看格式是否还守得住
• 每类留两道，防止单题偶然性

记录字段比题目更重要。每条至少留：请求时间、模型名、输入与输出 token 数、结束原因、响应头、完整原文。跑之前先测一遍自己这边的延迟基线，到 /tools/speed-test 量一下，后面看到响应变慢变短时，能分清是中转站问题还是本地网络问题。

把返回结果和日志逐项比对

拿到记录后按三层看，从硬信息到软判断，别一上来就凭感觉。第一层是元信息，最客观；第二层是内容指纹，看生成行为有没有变；第三层是横向对照，和官方或另一家中转站跑同一组题，找差异集中在哪类题上。

1. 核对元信息看返回的模型标识是否和你请求的一致，结束原因是不是被截断，token 用量和你实际输入长度能不能对上。这一层对不上，基本可以怀疑了。
2. 算内容指纹同一题连跑几轮，看结果自相似度是否异常高（缓存或模板的嫌疑），以及推理步骤、格式要求是否还满足。要求列步骤的题直接给出结论，就是信号。
3. 横向对照同一组题分别打到官方接口和另一家中转站，比较错误分布。差异集中在长上下文和多步推理上，比总体「感觉差一点」有说服力得多。

证据分级和下一步动作

不是所有异常都值得去找客服吵架。先把证据分强弱：元信息对不上最强，同题结果高度雷同次之，只有个别题变差最弱。前两类值得拿记录去要解释，第三类先回头排除自己这边的原因（参数变了、提示词改过、网络抖动）。

动作顺序建议固定下来：留证（截图加原始响应，别只截对话气泡）→ 换时段复测一轮 → 拿记录问客服 → 仍对不上就降级使用或换站。别只凭一次问答就定罪，也别因为对方一句「官方限流」就长期接受质量下滑。各家中转站的当前可信度状态可以到 /sites 对照着看，价格和模型资料以 /price-watch 上当时的数字为准。