把“变笨”换成可以复现的问题
“以前能做、现在不会了”是有用的观察起点，但不是模型被替换的结论。先保留同一任务的输入、期望结果、失败输出和发生时间，再记录模型标识、接口地址、参数与客户端版本。比较时不要同时换模型、提示词和工具设置，否则很难知道差异来自哪一步。
常见的待核查方向包括实际模型或路由变化、thinking 相关参数被裁剪、上下文被截断、工具或结构化能力未透传。这些是诊断假设，不能凭主观语气或一两道题确定原因。模型生成本身也有波动，题目歧义、提示冲突或上游临时错误都可能影响表现。
五个值得记录的信号
| 观察信号 | 先做什么对照 | 仍需排除什么 |
|---|---|---|
| 同一任务反复遗漏明确要求 | 固定输入，记录多个独立样本 | 随机波动、指令冲突 |
| 长文本末端信息经常丢失 | 分别检查首段、中段、末段线索 | 客户端是否实际发送全文 |
| 工具调用变成普通文字 | 核对工具定义与响应字段 | 工具选择配置、模型能力限制 |
| 结构化结果无法解析 | 保存 schema 与未经手改的响应 | 拒答、截断、格式本身无效 |
| 思考设置或响应形态明显变化 | 比较参数透传及分项证据 | 上游版本或协议差异 |
这些信号的价值是帮助组织复测。不要把其中任意一项包装成百分之百的假模型识别方法，也不要通过让模型背诵身份来替代接口证据。若准备公开问题，应说明样本范围、时间与已排除的变量，让别人能够理解结论的边界。
按真实字段读报告
本站原始报告使用 target_model 表示请求目标，protocol 与 mode 表示协议和检测模式，timestamp 表示这次记录的时间。results 中每项有 name、status、details 等字段；total_score 和 verdict 是归纳值，不能替代逐项证据。字段反映检测请求，不自动证明服务商内部执行了哪个模型。
阅读 status 时区分 pass、fail、skip 和 error。通过表示本次检查达到该项预期；失败表示该项观测未达预期；跳过与错误不能写成“已经验证通过”。若报告根本缺少一项，也不能把缺失反向解释为已测失败。详情页的样本量和检测模式同样影响可作出的判断。
在 OpenAI 协议报告中，可核查 structured_output 与 function_calling 等分项；Claude 协议中的 thinking_signature 是字段形态线索。本站并未借此完成官方密码学身份认证，签名字段符合预期不等于已经证明请求来自官方。具体检测名称以该份报告实际存在的条目为准。
结构化失败不只有一种原因
OpenAI 官方文档说明，结构化输出要求与 schema 对齐，但客户端仍需处理拒答等响应。由此不能把所有解析失败都归因于中转站偷换模型。查看官方说明。先检查目标模型与端点支持情况，再确认结果是否完整、是否发生拒答、是否经过客户端二次加工。
同样，工具结果出错可能来自工具本身。把“模型没按协议请求工具”“应用没有执行工具”“工具执行返回错误”分开记录，才能针对实际环节反馈。只贴最终聊天截图通常不足以区分这几类问题。
一套可重复的自查顺序
第一步，使用有权调用且可撤销的测试 Key，移除敏感数据。第二步，固定短任务与参数，确认基础请求可完成。第三步，只增加一种能力，记录原始响应和耗时。第四步，在相同模型与条件下重复，并在你有权限的环境作对照。第五步，把结果按日期、模型、模式归档，再看变化是否持续。
本期本站关闭了长上下文检测入口和对应提交参数，因此普通报告不能被宣传成已验证长上下文。你可以核对应用自己的输入发送记录，但不要把未执行的容量档位补写成通过，更不应为了得到某个标签而修改原始报告。
最后到推荐榜与相关站点详情交叉查看。榜单是历史中位评分的排序，不是故障归因工具。若证据还不足，结论就写“尚不能判断”，并列出需要补测的条件；这比把一次异常定性为降智更能帮助后续排查。