怎么判断AI中转站有没有“掺水降智”？三步实测真实模型响应输出

很多人用中转站跑着跑着觉得「不对劲」：回答变浅、格式不听话、该推理的不推理。到底是模型被换小了，还是提示词、参数、网络在捣乱？这篇给一套三步实测流程——先固定变量，再做同题对照，最后读输出特征，帮你把「感觉降智」变成能复现的证据。方法通用，不针对某一家，也不替你下结论，最终数字请到站内检测页核对。

很多人用中转站用着用着就觉得「不对劲」：回答开始变浅，格式要求不听了，该一步步推的地方直接给结论。问题是这种感受很主观，可能是模型真被换了，也可能是你自己改了提示词、参数被覆写、上下文被截断，或者纯粹是模型本身的随机性。这篇不讲怎么选站，只讲怎么测——用一套三步实测流程，把「感觉降智」变成能复现、能留证的判断。

方法不针对某一家，也不替你下结论。最后你手里应该有几组成对的请求和响应，能说清楚「在本次条件下表现为怎样」。涉及具体数值，比如某站的响应时间、稳定性读数，到站内 /tools/speed-test 和 /about 核对当时的数字，别拿记忆里的旧数据比。

先分清「降智」的三种可能，别一上来就骂站

「降智」这个词被用得太宽了。同一个现象背后至少有三种原因，处理方式完全不同。不先分流，你会把参数问题当成模型被换，跑去找客服对质，结果站方一查是你自己的客户端覆盖了系统提示。

• 真降智的关键词是「同时」：理解力、推理、格式三项一起掉，才像被路由到更小或更旧的模型。
• 假降智往往是单点故障：温度被调高、最大输出被限、系统提示被中转层覆写、长对话被截断，都只影响某一项。
• 正常波动最容易被误判。模型输出本来就有随机性，两次不同不等于被换。想先搞清随机性和复现性的关系，可以看站内 output-stability-reproducible 那篇，再回来做这里的检测。

第一步：把测试变量锁死，让两次结果可比

检测的第一原则是可复现。如果两次测试的客户端、提示词、参数、时段都不一样，那结果差异根本说明不了什么。这一步不产出结论，只产出「可比性」。

1. 统一入口同一个客户端、同一段提示词、同一组参数。别一边用网页聊天一边用脚本调 API，两边的系统提示和默认参数很可能不同。选定一种就一直用它。
2. 压低随机性温度调到 0 或最低档，能关的采样随机项都关掉。这样同一题的两次结果才有可比性；如果还飘，说明随机性来自上游，记下来。
3. 设计题面题面要能区分模型档次，覆盖三项里的至少两项：多步推理、固定格式要求、长上下文引用。别用「你好」这种谁都能答的题。
4. 保存原始数据存原始请求和原始响应，不要只截图聊天框。聊天框会吃掉你发的系统提示、参数和实际传给上游的内容，出问题时你手里没证据。

对照基准

优先用官方直连或本地能跑的同名模型；没有就退而用同一站的两个分组互比。

可比性

两次测试除被测对象外，其余条件全部相同，差异才有归因价值。

第二步：做同题对照，看差异出现在哪一层

变量锁好之后，把同一组题分别打到「你怀疑的站」和「对照来源」，比的是结构不是措辞。同一句话换个说法不算差异，推理步骤有没有、约束有没有遵守才是差异。

• 至少做三组题：一组考推理、一组考格式约束、一组考长文本引用。单题结果说明不了问题。
• 每组跑两到三次，看的是稳定性而不是单次对错。
• 重点看失败模式：错的都是同一类，更像被换模型；错得随机，更像参数或上游波动。
• 对照测试的完整做法站内 slow-degraded-ab-tests 已经讲透，这篇只补「怎么把对照结果读成掺水证据」这一层。

第三步：读输出里的特征，找「不像这个模型」的痕

对照能告诉你「有没有差异」，读输出特征能帮你判断「差异像不像换模型」。这一步靠的是识别痕迹，不是靠问它「你是什么模型」——身份自述可以被提示词伪造，只能当线索不能当证据。

• 自称与身份：问它是什么模型，回答前后矛盾、混用两个名字、或者在追问下改口，值得记一笔，但别单独采信。
• 能力边界突变：原本能做的小学奥数、代码补全、严格 JSON 输出，突然集体失败，比单个题错更有信号。
• 格式遵守度：要求严格 JSON 或固定字段，掺水后往往开始加解释、包 markdown、字段名漂移，这是很典型的痕迹。
• 长上下文表现：给一段指定文本问细节，降智的典型症状是「答得像没看过」，而不只是答错一两个点。
• 语言与风格漂移：用词习惯、标点风格、回答长度结构整体变了，也值得记录，但要先排除你自己改了提示词。

判据与误判排除：什么情况下你的结论不成立

这一步是自我否决。在给出「掺水」结论之前，先逐条排掉能造成假象的原因。排不掉，就别下结论。

• 你自己改了提示词、换了客户端、开了新会话历史——这三种都能造成「降智假象」。
• 上游本身在维护或限流，会导致响应残缺或重试，看起来像降智。
• 样本量不够：单次异常、单题失败都不构成证据，至少要三组题、每组跑两到三次。
• 时间窗不一致：跨时段、跨天对比，容易把上游高峰期波动误读成掺水，测试尽量放在同一时段做。

结论只写「在本次条件下表现为」，不写绝对化判断。留证方式和举证思路，站内 dispute-evidence-keep 有更细的做法，可以配合着看。

留下可复现的证据，再决定要不要继续用

检测做完，真正有价值的是你留下的证据包。它不仅帮你决定要不要继续用，也决定了你和站方沟通时说话有没有分量。

• 证据包四件套：原始请求、原始响应、时间戳、对照来源的响应，全部存本地，别只存在站内聊天记录里。
• 复测节奏：发现问题后隔一段时间跑一次同题，看是持续出现还是一过性。持续的更像模型或路由问题，一过性的更像限流。
• 处置顺序：先确认不是自己参数问题，再问客服要渠道说明，最后才考虑降级使用或迁移。
• 在线实测入口用站内 /tools/verify，长期盯质量变化用 /tools/quality-monitor，读数口径和检测项含义到 /about 核对。

一页速查：出门前照着过一遍