中转站检测 降智、掺假与偷换模型

同一个提示词，昨天答得利索，今天开始胡言乱语；同名的模型，输出风格跟前几天完全不是一回事——大概率不是你错觉。但「感觉变笨」和「真的被换了模型」是两码事，中间夹着限速降配、上下文截断、系统提示词被改、缓存串号好几种可能。这篇给一套从轻到重的验证动作，帮你分清哪一种，再决定要不要继续用。

同一个提示词，昨天答得利索，今天开始胡言乱语；同名的模型，输出风格跟前几天完全不是一回事。这种时候大概率不是你错觉，但也别急着下结论说是偷换。从「感觉变笨」到「真的被换了模型」中间夹着好几种可能：限速降配、上下文被截断、系统提示词被站点改过、缓存串号、路由到了别家分组。这篇给一套从轻到重的验证动作，帮你分清到底是哪一种，再决定要不要继续用。

先说结论方向：单次变差基本说明不了什么，连续多天、全天都差、换了时段也差，才值得按流程查。下面按「先分清现象、再做可复现测试、最后按顺序排查」三步走。每一步都有能落地的动作，不需要你懂底层实现。

先分清：降智的三种表现和各自的成因

把「变差」拆成三类看，比笼统说降智有用得多。第一类答得糙：长回答被截断、拒绝率变高、指令遵循变差，常见原因是站点砍了上下文长度上限，或者换成了同系列更便宜的小模型顶替。第二类答得怪：中文夹杂英文、格式对不上、明显像别家的风格，多半是模型被偷换，或者你的请求被路由到了另一个分组。第三类答得飘：同一个问题前后给的答案不一致，先怀疑缓存串号、并发限速或高峰负载，不一定是模型本身的问题。

最省事的判断抓手是看变化发生的时间分布：只在晚上高峰变差，偏性能和限速；全天都差、且从某一天起一直差，才偏模型被换。要注意不适用的情况：你最近改过提示词、换过客户端、调过温度和输出长度上限——这三样任何一样动了，都先排除掉再谈检测，否则很容易冤枉站点。

想核对模型规格，别靠记结论，直接到 /models 看该模型公开的规格口径，再用 /benchmarks 一类公开榜单做旁证。但要清楚一点：榜单测的是模型本体，不是这家站点的实现，分数高不等于这家中转站没动手脚。

三个可复现的小测试：固定题目、固定参数、留证据

检测的核心是「可复现」。同一批题、同一组参数、同一时间段，发给你信任的对照渠道和目标站点，比对结果。题目建议准备三道：一道严格格式题，要求输出固定结构的 JSON 或表格；一道长上下文回忆题，在几千字里埋一个只有读全了才答得出的细节；一道知识边界题，问它某类问题上的固定立场或拒答习惯。

1. 锁参数温度调到最低、输出上限给足、关掉联网和任何工具调用。参数不锁，结果没法比。
2. 同一批题双发同一批题同时发给官方或信任的对照渠道、以及目标站点，尽量同一时段发。
3. 比四件事能不能答对、输出结构是否一致、语气与用词习惯是否一致、响应里有没有该模型不该出现的痕迹（陌生自我称呼、别家默认拒答话术）。
4. 留证据把每轮的请求参数、原始返回、时间点存一份，别只截图结论。后面要退款或迁移，这些是唯一能拿出来的东西。

这套方法的边界也说清楚：如果你的用途本来就是创意写作，输出没有标准答案，逐题比对会失效。那种场景改用「风格签名 + 格式遵循度」来判——看它是否稳定遵守你给的格式要求、用词习惯是否前后一致，而不是看答得对不对。

测出来不对劲，按这个顺序排查再决定

测试结果不好，先别急着换站，按从轻到重的顺序排查，能排掉一大半误判。每一步都只改一个变量，改完重测，不要一次动好几项。

• 换一个小额或试用 Key 重测，排除单账号被限速降配
• 换时段重测，排除高峰排队导致输出被截断
• 确认请求里的模型名和站点文档写的是否一致，有些站靠别名映射，名字对不上不等于偷换
• 问客服要该模型的上下文上限、是否走缓存、是否与其他模型共用通道，提问口径可参考 /about 里公开的检测说明
• 以上都排除了还是同一现象，再按站点侧问题处理

确认是站点侧问题后，四个动作按顺序做：停止继续充值；导出账单与调用记录；把出问题的请求样本整理成一页；用小额余额继续观察而不再加码。这一页样本在跟客服沟通或决定迁移时都用得上，比一句「感觉变笨了」有力得多。

决定换站之前，先到 /sites 和 /rankings 看目标站有没有可核验的检测记录，再按 /tools/speed-test 量一下自己的延迟基线，别刚跳出降智又掉进高延迟。价格是否划算，到 /price-watch 核对当时的数字。不适用的情况：如果只是偶尔一次答歪，先重试两次再下结论，单次异常不足以判定掺假。