怎么判断AI中转站有没有掺水降智？先看输出这4处不对劲

同一个提示词，昨天写得挺利索，今天开始答一半就收尾、动不动就拒答、温度参数像没生效——这种时候你很难分清是模型自己抽风，还是中转站背后换了东西。这篇不教你去跟客服吵架，只给一套能自己跑、能留证据的观察方法：用什么题、看哪几处、日志怎么比对，以及哪些现象其实不是降智。

同一个提示词，昨天写得挺利索，今天开始答一半就收尾、动不动就拒答、温度参数像没生效——这种时候你很难分清是模型自己抽风，还是中转站背后换了东西。说白了，掺水降智不是玄学，它会在输出上留下痕迹，只是你平时没按固定题去跑，所以看不出差别。

这篇不教你去跟客服吵架，只给一套能自己跑、能留证据的观察方法：用什么题、看哪几处、日志怎么比对，以及哪些现象其实不是降智。方法本身不复杂，麻烦在要你连续几天按住同一组题去跑，中间别随意换味道。

掺水不是玄学，它会留下四类痕迹

先把「不对劲」拆开看。中转站如果偷换模型或压质量，最容易暴露的是输出形态：同样的任务，字数明显缩水、原本分点的结构变成一句话带过，或者反过来猛堆废话把长度凑回去。这不是风格问题，是它要交差又要省算力。

第二处是拒答阈值。本来能正常答的请求开始被挡，而且挡得含糊，只说「无法处理」却不给具体理由。第三处是参数失灵，温度压到很低回答照样飘，max tokens 给小了还超长，说明你的参数可能根本没被带上去。第四处是上下文记不住，多轮聊到第三四轮就丢前面的条件，像被塞进了一条窗口更短的通道。这四类不用全中，中两条就值得往下查。

先准备一组你自己能复现的题

手头没有固定题，比对就无从谈起。建议先搭一个小题库，三到五个就够，关键是每次跑同样的内容。题目挑有唯一正确答案、需要几步推理的，答案短、好核对，别用主观写作题，那种题你没法判断是模型差还是口味不同。

• 挑三到五个有唯一正确答案但需要几步推理的题，答案短、好核对
• 加一个长上下文任务：塞一段三千字左右的技术文档，问只有读完才能答的细节
• 补一个格式约束任务，比如「只输出 JSON，不要解释」，看它守不守格式
• 每次测试保存完整请求参数和响应原文，别只截图对话界面，比对全靠这份

长上下文那题尤其有用，很多偷换发生在窗口被压缩的通道上，短问题看不出来，一塞长文档就露馅。格式题则是测它听不听话，守不住 JSON 约束的，往往参数也没真正生效。

日志怎么比对才算数

只看对话界面永远比不出东西，你要看响应体里的几个字段。model 字段能告诉你它自称是谁，usage 里的输入输出 token 数能看出有没有被截断或偷工，finish_reason 则直接说明这次是正常结束还是被掐断。这三项凑一起，大部分偷换和截断都藏不住。

1. 建基线同一组题在官方渠道跑一遍，把响应原文和字段存下来，作为你自己的对照物
2. 同渠道复跑在中转站连续跑两三天、分不同时段跑，单次异常先放着，别急着下结论
3. 先排查常规问题换 Key、看是否被限速、确认额度没用完，这些排掉再谈掺水
4. 看趋势多个时段、多个题都掉，才当成趋势处理；只掉一题，多半是题本身难

这些情况别急着扣帽子

有些「降智」其实是冤枉。上游模型本身在更新，官方渠道同期也在变，这种不算中转站动手脚，去站内模型库核对当时的版本说明就能对上。另一种是你提示词里带了很长历史或多轮上下文，超出通道窗口后表现变差，那是容量问题，不是质量造假。

还有网络抖动导致流式响应被截断，看着像答一半，其实响应头里的 finish_reason 会告诉你真相。我见过有人把超时截断当成偷换模型，跑去质问客服，最后发现是自己客户端设的读超时太短。所以下结论前，先把这几类排掉。

最后说清楚不适用的情况：如果你只是想找一条捷径、不想自己存两次数据对照，这套方法帮不上你。它要的就是固定题、固定参数、留原文，图省事就只能凭感觉，而感觉最容易被带偏。