最近一年，“模型变笨了”这种抱怨就没断过。隔三岔五就有人截图说 ChatGPT 的回答开始胡说八道、前言不搭后语，连小学算术都能算错。可你问具体哪些任务变差了、差到什么程度，大多数人又说不清，只能回一句“感觉不对”。我自己的看法是，如果你想确定模型是不是真的降智，不能靠“感觉”，要靠“可复现的检测”。这篇就把我常用的四种快速检测方法完整拆给你看，每个方法怎么操作、怎么判读、容易踩什么坑，都会讲到。就算你不了解模型原理，照着跑一遍，也能在十分钟内得到比较靠谱的结论。

1. 为什么大家都在说“降智”——先把检测基准弄清楚

1.1 什么是降智，准确说是能力波动

“降智”这个词很形象，但它不是一个严谨的技术指标。我在实际测试中理解的降智，是模型在部分任务上的表现明显低于它历史最佳水平，而且不是某一次偶发错误，是在重复测试后依然稳定变差。这种波动可以体现在很多维度：长文记忆丢失、逻辑推理中断、知识时效性退化、多轮对话前后矛盾，还有回答风格变得机械。

但这里有个前提容易被忽略：不同时间点、不同入口看到的模型表现可能来自不同版本。模型厂商经常做小版本升级，今天回答你的可能已经不是昨天那个模型。所谓“降智”，有时候是版本回退，有时候是负载高峰导致的推理不稳定，也有时候是安全策略调整之后，模型变得不敢多说话。把这些情况统统叫作降智，其实不够准确，但对普通用户来说，你关心的不是版本号，而是结果好不好用。所以检测的核心目标就是：在不确定怎么变的情况下，用一组固定题目反复测，看它的能力水位是否有明显下滑。

1.2 四种方法背后的检测逻辑

既然要检测，题目设计就不能随意。我推荐的四种方法分别盯住模型的四个不同能力面：长程记忆能力、数理逻辑推理能力、知识时效性、逻辑一致性。这四块恰恰是模型在日常使用中最常被感知、也最容易退化的维度。

为什么选这四个？首先是长程记忆，它直接对应多轮对话体验，聊着聊着就忘事儿是降智最典型的表现。其次是数理逻辑，这类任务有唯一正确答案，可重复性最强，模型强就是强、弱就是弱，不容易被主观判断干扰。第三是知识时效性，模型的知识有截止日期，一旦能力下滑，它更容易给出模糊、过时甚至凭空编造的信息。第四是逻辑一致性，降智后的模型会变得更爱“讨好”用户，你质疑它它就认错，你诱导它它就顺着说，稍微设计一点矛盾它就开始糊涂。

这四个维度互相独立，却又覆盖了日常使用的大部分场景。后面每一节我会给出一套可以直接抄的测试方法，包含提示词模板、判读标准、复测次数和常见坑点。

2. 方法一：用“编故事+连环提问”测长程记忆能力

2.1 具体操作：我一直在用的测试模板

长程记忆测试的核心不是“让它记住一句话”，而是“让它在连续多轮对话里，准确调动前面埋下的多个信息点”。我会在开头给出一段模拟人物设定，然后连续问五到六个问题，每个问题都依赖前面的细节。

比如我常用的提示词模板是这样的：请记住以下信息：小张是一名项目经理，负责“某跨平台系统”开发，团队有五个人：数据库工程师、前端开发、后端开发、测试、UI设计。项目分三个阶段进行：第一周做需求评审，第三周做界面联调，第五周提交测试报告。有一个风险点：数据库工程师在第四周要请假三天。接下来我会连续提问，你可以随时查考前面的信息。

然后依次问：项目团队里有哪几个人？第二阶段做什么？数据库工程师请假会影响第几周的工作？如果想让测试提前到第四周开始，需要和谁协调？小张要在第五周提交什么？全部回答后，前三轮都没问题的模型，通常会在第四、五轮出问题。原因是信息点越多、间隔越远，模型越容易混淆或遗漏。

降智严重的模型表现很典型：回答越来越简短、突然改口、或者把“测试报告”错记成“测试计划”。我会把这些差别原样记录下来，作为降智判断依据。

2.2 判断标准与可疑信号

判定是否算降智，我一般看三个信号。

一个信号是细节丢失。前期还记得数据库工程师请假的事，问到第三轮开始含糊其辞，说“好像有谁请假但记不清了”，这种情况偶尔出现可以理解，但如果每轮测试都这样，那就说明长程上下文利用能力有明显问题。

第二个信号是张冠李戴。把测试的阶段记错了，把团队人员数量说错了，这类错误属于信息污染，往往出现在模型上下文管理出现异常时。

第三个信号是回答风格突变。前一秒还在用详细列点的口吻回答，后一秒突然变得极简，只剩一句话。这不一定证明降智，但结合内容错误，大概率能说明当前的推理链路不太稳定。

如果一轮测试出现一个以上的信号，我会把可疑等级提高一档，然后再用同一套题复测三次。三次里有一次出现同类错误，属于波动；三次里至少有两次都错，我认为就可以认定能力下滑了。

2.3 避坑心得：同样的题目，至少复测三次

在我自己的测试里，最容易犯的错误是拿一套新题只测一次就下结论。模型是概率输出，同样的提示词每次生成都不一样，个别一次的错误完全可能是随机波动，并不代表整体降智。尤其是长程记忆这类主观性较强的测试，必须通过重复来消除运气成分。

我有两个具体建议：第一，同一套题连续跑三次，每次之间隔一小段时间，比如十几分钟。第二，三次测试里答案完全正确但措辞变化，也属于正常；如果三次里结构都错同一种类型，才算找到了稳定的问题模式。

还需要注意一个冷知识：模型对超长上下文的处理，会随着整个输入内容的长度变化而变化。你的测试如果塞满了无关背景，它有可能把注意力分散掉。所以模板信息要尽量精简，别额外加一堆修饰语和无关数据，让关键信息之间的间隔更短，这样测出来的才是“正常状态下的记忆水平”。

3. 方法二：用数理逻辑题测推理链路稳定性

3.1 设计一道不会被“背题”污染的算术题

网络上的经典逻辑题、鸡兔同笼、约会问题，模型很可能已经在训练数据里见过无数遍。你测试的时候，它可能是背答案而不是真正推理。所以我的建议是自己现编题目，保证题目结构简单、计算步骤明确，但组合方式稍微绕一点点。

举个例子：一家文创店销售两款明信片，A款每套卖三张、共十二元，B款每套卖五张、共二十元，小王一共买了四套，花了五十六元，请问他买的B款套数是多少？这类题目网上很难撞到一模一样的原题，同时它需要列方程或逐步试算，能观察模型的步骤是否完整。

正常的模型会先设未知数，列出一个二元方程，比如A套数加B套数等于四，12A加20B等于56，然后解得B等于一。降智版本用各种方式绕圈，有的直接说答案却没有任何步骤，有的列出错误方程，有的算到一半忽然换了一种价格假设。我更建议把注意力放在步骤完整性上，而不是只看最终数字。因为逻辑链短的模型，即使答案对了，也常会跳步或乱编中间推导。

如果你想加大难度，可以在题目后面加一句：请分步骤说明，并且在每一步后面写上使用了哪个已知条件。这个附加要求能逼着模型暴露它的推理过程。降智模型往往会在这里露出马脚，比如明明没用到某个条件，却说自己调用了它。

3.2 代码类测试与可复现验证

数理题之外，代码题是另一个非常可靠的探针。因为它有硬性可验证标准：代码能不能跑、输出对不对。我会用非常简短的自然语言出题，比如：请写一个函数，输入一个字符串列表，返回每个字符串的长度，并按照长度从大到小排序，如果长度相同则按字母顺序排序。这个问题不涉及复杂框架，几乎任何正式版本都能完成，但推理链路不稳时，输出会变得非常拧巴。

降智模型写出来的代码经常出现三种问题：第一，忘了长度相同时的次排序条件；第二，用了一个莫名其妙的 lambda 嵌套，逻辑是对的但复杂度过高；第三，给出的解释和代码不一致，注释说“先按字母排”，代码实际却只跑了长度排序。

测代码题还有额外好处：可以把代码复制到本地跑一遍，输出结果对不对一目了然。我建议每次测试时固定同一道题，跑完后记录代码是否可直接执行、执行结果是否符合预期，再对比之前几次的记录，就能看出稳定性的变化。代码题适合在长程记忆测试之后做，因为两者能覆盖模型能力的不同侧面。

3.3 避坑心得：别让它用计算器和现成库

我踩过最深的坑，是让模型随便调用现成库或者计算工具。你可以让它手算，或者只允许它写纯逻辑代码，禁止用外部库。我在题目里会明确写：请直接手算，不要使用任何工具；写代码时不要使用排序库，请自己实现排序逻辑。这样做不是想让它写出工程级方案，而是想观察它内部推理是否健康。

另一个容易被忽略的点是：代码题的模型输出可能因为环境配置、版本差异而不同。你在自己电脑上跑通的结果，换一个环境可能就报错。所以做代码题检测时，最好提前固定语言版本，比如 Python 3.12，并且用最简单的运行方式，不要引入虚拟环境依赖。否则你可能把无关的报错误判成模型降智，那就太冤了。

4. 方法三：用带时间锚点的知识题测知识新鲜度

4.1 为什么时间锚点能暴露模型状态

模型的知识是有保质期的。它训练完成之后，世界上的新事件、新标准、新工具，它都不太清楚。所谓“知识时效性检测”，就是用它训练截止日之后的新信息来试它。如果它表现正常，说明至少已经完成了新知识的更新；如果它表现得极其含糊、年代错乱或者直接编造细节，那就说明它当前内部检索和知识组织出了比较大的问题，这就是我们所说的“降智”。

但这里要特别说明一个容易误判的地方：很多用户问模型一个最新事件，模型答不上来或者乱编，这并不一定是降智，可能是它训练数据的客观时效不足。所以时间锚点的核心作用，不是测试它知不知道某个新事件，而是测试它“面对未知知识时，是否还能保持清醒的判断力”。正常模型如果不知道，它会明确说训练数据截止日期、无法确认最新情况；降智模型往往会编一个听上去合理的日期、人名和数据，装作它见过。

4.2 一组安全可靠的时间类问题模板

为了既能测出时效性，又避免涉及具体争议，我通常不会问真实热点事件，而是问行业里相对中性的变化。比如：请举例说明某行业在2023年之后出现的一个新趋势，并说明这个趋势可能带来哪些影响。再比如：假设现在是2025年，请列举一个你在训练数据中没有具体信息、但根据逻辑可以推断的行业发展方向，并用“不确定”标注你的推测。

这就是时间锚点的一种安全用法：不是考事实，而是考“模型是否清楚自己的知识边界”。降智模型会倾向于把推测说得斩钉截铁，好像他真的看过相关资料；状态正常的模型则会给出层次清晰的回答，指出哪些是确定信息、哪些是推测、哪些需要去查阅最新资料。我建议大家测试时用这类中性的科普、技术、行业问题，不要用容易引发争议的时事，以免把“模型不知道”和“模型立场不对”混为一谈。

4.3 避坑心得：答案必须每次都人工核验

知识题有一个硬伤：如果你自己不知道正确答案，你就没法判断模型说错了。所以我每次做时间锚点测试，都会提前花钱花时间把标准答案查好，甚至用两个独立的信息源交叉核对，再拿着标准答案来对照模型输出。绝不直接拿模型输出当答案去验证另一个模型，那样只会制造循环错误。

还有一个很常见的坑，是问题里带的具体时间写得太模糊。比如你问“最近发生过什么”，模型可能理解成去年或者上周，回答就会偏。更好的问法是明确写一个年份：请谈谈某技术方向在2024年内出现的公开进展。年份越精确，越容易判断它给出的是不是合理信息。

最后补充一点心得：知识时效性测试不适合作为唯一判断标准。因为模型版本更新频繁，训练截止日期不等于某次更新后的真实知识覆盖范围。我通常只把知识题当作辅助证据，如果长程记忆和逻辑题都明显变差，知识题再出现编造，那才坐实了降智判断。

5. 方法四：用“追问纠错”和“矛盾陷阱”测逻辑一致性

5.1 追问纠错是怎么操作的

追问纠错听起来很简单：让模型回答一个问题，然后故意反驳它的答案，看它会怎么反应。但这背后其实藏着一个很重要的测试目标：模型是否具备稳定的立场，同时又不至于过度固执。降智后的模型常常会走向两个极端，要么“你说不对我就不对”，要么“完全听不进去用户的合理修正”。

我的操作方式是这样的。第一步，先问它一个确定性问题，比如：如果今天下雨，公园里人少，这是不是因为天气影响游客出行？模型通常会给出一个分析。第二步，我故意说：不对，我觉得天气根本不影响游客出行。看它的回应。正常模型会区分“事实”和“观点”，可能解释天气影响是一个普遍经验，但确实存在例外；降智模型则可能迅速倒戈：您说得对，天气可能不影响出行，是我之前的分析欠考虑。

如果你连续质询三轮，模型每一轮都毫无原则地道歉，那基本可以判定它的逻辑一致性出了问题。因为它在使用的过程中，本质上是被你的语气带偏了，而不是真的理解了你的反馈。

5.2 自相矛盾陷阱的设计

除了追问纠错，我还会用“自相矛盾陷阱”来做更严格的验证。思路是：先让模型接受一个前提，然后用含有矛盾信息的提问看它是否能察觉出来。比如在一段话里故意写：小明每天跑步三十分钟，但他最近因为伤病已经完全停止训练，请分析他如何维持每天跑步的习惯。这个前提本身就是矛盾的，状态正常的模型会主动指出矛盾，告诉你“既然已经停止训练，就无法维持每天跑步”；降智模型可能会一本正经地分析“如何在停止训练的状态下继续每天跑步”，整个过程完全无视逻辑。

另一种陷阱是让模型复述规则再应用规则。我会说：请记住，在这个对话里，所有“红色”都必须被理解为“蓝色”。然后提问：如果一个苹果是红色的，它实际应该是什么颜色？正常模型会指出这是一个约定，在你定义的范围内它应该算蓝色，但现实中仍然是红色。降智模型则会简单结论“苹果是蓝色”并且不再做任何注解，这说明它根本没有维护“双重语境”的能力，知识点和规则被混成一团。

5.3 避坑心得：别把“太听话”当成正常表现

我在实际测试里发现，用户对“太听话”的容忍度非常高，甚至觉得模型能接受纠错就是聪明。但从检测角度看，无底线让步恰恰是很重要的异常信号。所以我会把“主动承认逻辑矛盾”“能区分事实与说法”当作正常标准，而不是“顺着我说就是好”。

另一个要留意的问题是，有些模型在安全限制下刻意表现得更顺从，回复里大量使用“您说得对”“我理解您的观点”。这些礼貌话术本身不是问题，问题在于它后面是否还有实质分析。如果一段回答只有附和，没有论证，没有边界说明，那它的逻辑能力基本可以认定在退化。

我还会做一个小技巧：把同一组矛盾问题里的否定词反过来再测一次，比如把“完全停止训练”改成“维持训练”，看模型会不会突然换一套答案逻辑。如果两次测试结论互相冲突，那说明它连最基本的语境稳定性都很差。

6. 综合成一个30分钟的快速排查流程

6.1 四步连测的标准步骤

上面四种方法单独拿出来都能用，但最靠谱的用法是串成一条流程，在半小时内完成，这样有对比、有基线。我自己用的流程是这样的：

第一轮，花八分钟做长程记忆测试，用第一节的连环提问模板，记录每轮答案是否正确、是否出现态度突变。第二轮，再花八分钟做数理逻辑测试，用自定义算术题加代码题，把输出复制到本地跑一遍，记录最终结果与代码执行情况。第三轮，用八分钟做知识时效性测试，问三个带明确年份的中性问题，人工核对答案。第四轮，用六分钟做追问纠错与矛盾陷阱，记录模型对于反驳和矛盾前提的反应模式。

四轮做完，把所有记录汇总到一张表里。如果四轮中至少有三轮都出现了明显异常，那就可以判断模型当前状态确实偏低，需要调整任务分配或者等待恢复。如果只有一轮异常，那大概率是随机波动，不必过度反应。

6.2 结果速查表：什么情况算降智

为了方便我整理成一张速查表，你测试时可以直接对照：

表格只是参考，不是绝对标准。因为不同模型、不同温度参数、不同提示词都可能影响结果。我建议你第一次测的时候就记录一份“正常基线”，之后每次拿出来对照。没有基线，就没有降智。

6.3 长期记录：给自己建一个能力基线库

最后一个建议，也是我认为最有价值的经验：不要只在听说降智的时候才去检测，而是平时就固定时间做一次记录。你可以建一个非常简单的表格或者文档，写上日期、模型名称、任务类型、回答关键词、结论，隔半个月测一次。长期积累之后，你就能看出模型能力到底是持续上升、周期性波动，还是真的一路向下。

我个人会把测试模板保存在一个文本文件里，凡是需要用到的提示词都复制粘贴，不改动其中的关键限制条件。这样可以保证每次测试的输入基本一致，比较才有意义。

还有一个进阶玩法：同一套题目分别在多个不同入口各测一次，看哪边表现好。有些环境因为推理参数限制，输出会被截断或者简化，看起来像降智，但实际上只是设置问题。这种情况下，你只需要调整环境，不必质疑模型本身。

最后分享一点我的实际感受

做这类降智检测，最好的心态是把它当成“医疗体检”，而不是“打假现场”。体检的意义在于尽早发现问题、调整使用策略，而不是证明“这个模型出了问题，我可以不用了”。我经历过好几次，同一套测试题，某天晚上测试结果惨不忍睹，第二天早上再测又恢复正常，基本可以确认是峰值负载导致的临时波动。所以我的习惯是：第一次测出异常先不信，复测三次，再结合四维结果下结论。你如果不想自己设计题目，把我的模板拿去直接用也行，先测一轮，把结果记录下来，等模型状态有波动的时候再测一轮，两相对照，比什么都清楚。工具是死的，判断能力才是你真正需要练出来的。