降智了怎么办：四步排查与更换决策

你一直用得好好的模型，某天开始答案变短、变敷衍、写代码老出错，第一反应往往是「这站降智了」。但输出变差的原因至少有四层：上游官方状态、你自己的提示词与上下文、中转环节的路由与掉包、以及你选的档位本身。这篇给一份固定顺序的排查流程，四步走完再决定是换站、换模型还是原地不动，最后附一张换站成本清单，避免凭一次糟糕回答就搬家。

你一直用得好好的模型，某天开始答案变短、变敷衍、写代码老出错，第一反应往往是「这站降智了」。但输出变差的原因至少有四层：上游官方状态、你自己的提示词与上下文、中转环节的路由与掉包、以及你选的档位本身。把这四层拆开查，才不至于凭一次糟糕回答就搬家。

下面给一份固定顺序的排查流程：四步走完再决定是换站、换模型还是原地不动，最后附一张换站成本清单。顺序很重要，跳步会把不同层的问题搅在一起，越查越乱。

第一步：先排除官方侧和服务状态

最容易误判的一层就是这里。官方侧限流、维护、故障期间，所有走这个上游的站点都会一起变糊，你换到别家也照样糊，白白折腾。所以第一步不是怀疑站点，而是先看上游本身有没有事。

• 到 /ai-status 看当时的服务状态与故障公告，别把官方抖动当成站点问题；具体状态以页面当时显示为准
• 同一个模型换个官方渠道或另一家站再问一遍同一句话，两边都差说明不是单一站点的事
• 留意是不是高峰期整体变慢变糊：排队和截断会让回答变短，这不等于模型能力被降
• 判断口径：只有「同一时段、同一提示词、多入口结果一致变差」才值得继续往下查

第二步：确认是不是自己的输入变了

排除了官方侧，第二步该照镜子。很多人最近调过系统提示词、换过参数、往会话里塞了超长上下文，观感变化其实来自这些改动，而不是模型本身。这一步的动作就是把变量找回来。

• 回看你最近改过什么：系统提示词、上下文长度、温度、附件大小，任何一项变动都会改观感
• 上下文塞太长会挤掉有效信息，答案自然显得笨；把长会话拆成新会话再试一次
• 同一句话连问三次看波动：模型输出本来就有随机性，单次回答没法当证据
• 列一张变量对照表，后面几步都靠它对齐

第三步：用对照请求验证有没有被掉包

到这一步才是真正验「有没有被换模型」。关键不是比答案好不好看，而是比行为特征稳不稳定——同一批探针题打到官方入口和你怀疑的站点，看结构、长度、格式遵守度是否一致。一次不一致记下来再复测，别一次就定性。

1. 准备固定探针题选几道能暴露行为差异的题：要求严格格式输出、长文本信息召回、明确的拒答边界。题目固定下来，每次复测都用同一批。
2. 双入口各打一轮同一批题分别发给官方入口和疑似站点，把原始回答和耗时都存下来，别只凭印象记。
3. 比对行为而非文采重点看格式是否守、拒答边界是否同、长文本召回是否一致，再顺带看回答长度的量级。
4. 复测再定性隔一段时间重复一轮。到 /detect-site-degradation 看现成的复测节奏思路，检测工具到 /tools/verify 做真假在线实测，评分口径到 /tools/verify#scoring-rules 核对。

第四步：决定换站还是换模型，先算换站成本

查完前三步，结论无非三种：官方波动，等；自己的输入问题，改；真的被掉包或长期不达标，考虑动。但「考虑动」不等于立刻搬，先算成本。换模型通常比换站便宜，优先试同档位另一个模型或官方直连，很多问题出在档位而不是站点。

• 适合先不换的情况：只是高峰期波动、问题集中在某个模型、你的用量小且对稳定性要求不高
• 适合换的情况：对照请求反复不一致、客服说不清路由来源、账单口径对不上
• 换之前把证据留好，参考 /dispute-evidence-keep 的留存做法，跟站点交涉时用得上
• 别选在大促或官方故障期搬家，那会儿两边都不稳，判断容易失真

一次糟糕回答不构成证据，三次以上可复现的行为差异才值得动手。