感觉模型变笨了怎么查：固定任务、历史和完成条件

同一个模型名字，今天修不好的问题昨天能修；换个新会话又正常，很容易让人怀疑模型“变笨了”。这种感受值得记录，但下一步要把它缩小成能检查的事实：哪项任务失败，输入和工具结果是否相同，失败从哪一轮开始。

本文于 2026 年 11 月 10 日查阅官方测试设计资料和中文讨论。下文给出可直接采用的公开任务与记录方法，没有跑模型对照，不提供性能排名，也不据此判断任何服务商替换了模型。

新模型发布后也可以沿用这套方法：Fable 5.2 的选择与试用建议把官方定位、账号范围和公开任务验收分开，方便判断是否值得更换当前模型。

先给“效果差”写一个能复查的句子

“回答很水”可以改成“要求只返回三个字段，却加了前后解释”；“修不动”可以改成“修改后原失败用例仍然失败，还删除了输入校验”。这样才知道下一次修改有没有帮助。

官方测试设计文档建议先定义具体、可测、与任务相关的成功条件，再设计用例。对个人开发者，先保留几项经常做的真实任务即可，不必先造一个复杂评分系统。

下面是一项完全公开的演示任务：

从下面记录中提取未完成的工单，只返回 JSON 数组。
每项只能含 id 和 owner，按 id 升序；owner 缺失时用 null。
不推测姓名，不添加解释。

T03 | done | Mei
T02 | open |
T01 | open | Lin

预期结果：

[
  {"id": "T01", "owner": "Lin"},
  {"id": "T02", "owner": null}
]

这里的完成条件分别是：过滤正确、顺序正确、字段固定、缺值不编造、JSON 可解析。它只检查一个简单提取任务，不能代替代码、视觉、工具或长文能力测试。若实际需求是稳定 JSON，继续看结构化输出说明，不要把自由文本提示的结果当成强制 Schema 功能验收。

先比较新旧会话，再讨论模型差异

把同一个公开任务放进新会话，不带旧讨论、角色卡和工具。如果新会话恢复，优先检查历史是否过长、压缩是否丢失关键事实、前面是否有冲突指令。这个结果只能缩小范围，不能证明模型服务完全没变化。

长任务里，模型还依赖文件、搜索和工具返回。新旧两次运行读到不同版本的代码，即使提示词相同，也不是同一输入。检查时保存公开文件的内容或版本号，记录工具是否成功，不要只留用户最后一句话。涉及会话长度时，可参考上下文超限检查。

一次只改变一项，并留下失败样本

一张记录表可以这样写；这是模板，不是测试结果：

记录项	应保留的内容
时间和版本	时区、客户端版本、配置更新时间
实际路径	服务域名、协议、精确模型 ID；不含凭据
输入状态	新会话或历史范围、公开文件版本、启用的工具
完成条件	哪些字段、文件或行为必须满足
观察结果	哪一项通过或失败，必要的脱敏片段
单项变化	这次只改了哪一个配置或输入

先固定任务、历史、工具和支持的参数，再比较一个变量。不要一边换客户端，一边换提示词、模型档位和资料来源，最后只给某个模型记一次“差评”。模型生成有波动，单次成功或失败都不宜外推；对关键任务重复观察并保留每次结果，也要给尝试设上限。

如果失败只在工具之后出现，检查模型到底收到什么结果；如果只在切换模型后出现，检查列表、别名与能力。不要为了制造“公平”硬塞目标模型不支持的参数。

模型自报身份与单题识别为什么不够

10 月 19 日的 V2EX 讨论里，原作者描述一次项目生成不理想，回复中既有对中转的怀疑，也有识别工具误判和模型自身表现的争论。查阅时有 39 条回复。它证明用户有这个困惑，没有证明某个未具名平台发生了模型替换。

另一篇中文实践讨论强调小任务、验证与保留失败案例，这些适合作为工作方法；其个人经验同样不能当所有人的效果数据。本文不采用社区金额、识别概率或未经复查的性能结论。

模型回答的品牌、一道 SVG 题、文风相似，都受到提示、历史、采样和任务范围影响。它们可以提示继续核对，却不足以独立确认上游身份。涉及服务承诺时，仍需配置、可取得的请求信息和供应商证据。

使用 Nbility 时，可从用量日志关联这次模型请求，并按求助日志模板提交时间、版本、模型和具体失败条件。比起“它变笨了”，一份能说明哪一步没完成的记录，更容易得到可执行的修复建议。