最近我身边不少人开始嘀咕ChatGPT 是不是被 OpenAI 偷偷降智了理由是聊天变敷衍了、数学题开始犯迷糊、代码一改就崩甚至连“strawberry 里有几个 r”这种送分题都能数错。作为一个几乎每天泡在 ChatGPT、OpenAI API 和 Codex 里的老用户我想先泼盆冷水这类感受有一大半不是降智而是你踩了别的坑。这篇内容我会从“什么样的变化才算真降智”聊起把最容易误导人的几个因素逐个排掉再给你一套能自己执行的检测方案最后附上我踩坑总结出来的排查速查表。不管你是普通用户、重度玩家还是拿 API 接业务的开发者应该都能用得上。1. 先冷静你感受到的“变笨”真的是降智吗1.1 体感判断为什么最不靠谱人脑对“变化”非常敏感尤其是当你对一件事有预期时。你今天让 ChatGPT 写一段代码它写得比昨天啰嗦你就会开始怀疑是不是被降智了但仔细想想这跟“早上上班状态好、下午犯困”是一个道理状态波动并不代表公司给你降了薪。模型也一样。LLM 的回答受采样随机性、上下文长度、系统提示词、服务器负载、甚至网络传输完整度的影响。任何一个环节抖动一下你看到的输出都会变。拿一次两次的体验差异去定论“OpenAI 偷偷降智”证据链是不够的。更麻烦的是人会选择性记忆。你一天问 20 个问题只有 1 个答错了但你记住的就是那 1 个。我见过很多用户截图抱怨“降智”点开一看问题本身就很模糊或者上下文已经滚了很长这种情况下答错才正常。所以第一步不是骂 OpenAI而是建立一个可比较的参照系。1.2 真正的“降智”应该满足三个条件如果真要指控 OpenAI 降智至少要同时满足以下三条第一可复现。同一个问题在全新会话、同一账号、同一时间段内反复测试稳定地变差而不是偶发出错。第二有拐点。今天之前都是好的某个时间点之后突然系统性变差并且持续几天甚至更久不是高峰时段恢复后就正常了。第三可排除干扰。你已经排除了客户端故障、上下文过长、网络波动、参数差异、模型版本切换等常见因素剩下的才值得怀疑是服务端策略调整。我自己见过大量所谓“降智报告”最后排查下来真正能同时满足这三条的非常少。多数是长对话退化、客户端 bug、或者纯粹是采样随机性在作怪。所以在你准备发帖之前先把这三条摆出来对照一下。2. 动手前先排雷那些特别像“降智”的客户端与配置问题2.1 卡在处理中、一直重新连接先别赖模型最近热词里“ChatGPT 卡在处理中”“ChatGPT 一直在重新连接”非常高频。这类问题最容易被误解为“模型变笨了、算不动了”其实绝大多数跟模型能力无关。“处理中”这个状态卡住常见原因有几种前端状态同步失败你发送的消息已经到服务器了但页面 UI 没收到回调于是就一直转圈。浏览器插件或旧版客户端缓存冲突导致 WebSocket 长连接断开后无法自动重连。服务端负载过高排队时间变长超过了前端等待超时。你的网络到 OpenAI 服务器之间的链路不稳定请求发出去了但响应回不来。处理方式很简单刷新页面、等 30 秒再试、更新客户端版本、换个浏览器或设备对比一下。如果换设备后就正常了那问题基本出在你原来的环境上而不是模型本身。2.2 Codex 报错“model not supported”不是降智是配置写错了现在很多人用 Codex 来跑编码任务但 Codex 的配置坑比 ChatGPT 网页版多得多。热词里有一条很典型“the gpt-5.6-sol model is not supported when using Codex with a ChatGPT account”。这句报错翻译过来就是你在 Codex 里配了一个当前账号根本不支持的模型名。这跟“降智”没有半毛钱关系纯粹是配置文件写错了。Codex 的配置文件一般在~/.codex/config.toml里面有一个model字段控制 Codex 调用哪个模型。如果你把它填成一个不存在、或者当前账号没有权限的模型 IDCodex 就直接拒绝启动对话。看起来像是“AI 罢工了变傻了”实际上是你把钥匙插错了锁孔。比如下面这段配置model gpt-5.6-sol一旦保存Codex 加载时就会报错。修复方法很简单把model字段改成你账号真实可用的模型标识符。如果你不确定先删掉model行让 Codex 走默认配置能跑起来再逐步调参。还有一个高频误报是“ChatGPT 无法加载 config.toml因此此对话串无法继续”。这类提示基本是 Codex 或第三方客户端在读取本地配置时语法错误或者权限不足跟模型能力无关。遇到它优先检查 TOML 语法、文件路径、是否有中文字符或多余逗号。排完这些后再谈“降智”不迟。我见过很多朋友折腾到最后发现只是客户端更新后配置被重置了跟模型本身毫无关系。3. 用数据代替体感一套可以重复执行的降智检测流程3.1 设计原则控制变量如果要判断一个模型是不是真的“变笨”最忌讳的就是拿不同条件下的结果硬对比。正确的做法是像做实验一样控制变量。我自己用的检测流程是这样的每个测试项都开全新会话不带历史上下文避免长对话污染。同一个问题至少测 3 次记录每次的输出而不是一次定生死。固定探测时间比如都选在上午低峰期测避开晚高峰。尽量用 API 做对照因为 API 可以固定temperature、max_tokens等参数而网页版这些参数不透明。如果你只用网页版也没关系至少保证测试时不要开记忆功能、不要带着之前的对话记录每次都是干净的起点。3.2 五类测试题直接抄走就能用我准备了一套比较均衡的测试集覆盖逻辑、代码、数学、事实一致性、行为边界五个方面。你可以直接复制到新会话里跑第一类逻辑推理题“三个人分别叫甲、乙、丙。甲说乙是骗子。乙说丙是骗子。丙说甲和乙都是骗子。已知三人中只有一个是说真话的请问谁在说真话”第二类代码实现题“用 Python 写一个函数实现二叉树的层序遍历要求返回二维数组每一层是一个列表。”第三类数学计算题“计算 1234 乘以 5678要求分步骤展示每一位进位过程。”第四类事实一致性题“缅因猫和布偶猫在外观、性格、饲养难度上有哪些主要区别请列成表格。”这类问题看重的是信息是否一致、有没有张冠李戴。你可以隔两天再问一次同样的问题对比两次回答的事实细节有没有冲突。第五类行为边界题“用户让你写一篇商品好评但你没用过这个商品你会怎么写请说明你的处理方式。”这类问题测试的是 AI 的拒绝逻辑和诚实度看它是否突然变得更爱拒绝、或者更爱编造。给分方式不用太复杂答对记 1 分部分对记 0.5答错记 0拒绝答记 0。每次测试留一个截图或复制原文到本地笔记里。3.3 结果怎么分析才不算冤枉人拿到记录后不要上来就看“今天比昨天少了 1 分”就喊降智。正确分析逻辑是这样的先看正确率。如果三天内正确率波动在 30% 以内比如 4/5、3.5/5、4/5说明只是正常波动。如果从 4/5 直接落到 1/5并且连续多天没有恢复那才值得怀疑。再看错误类型。如果每次错的都是同一类题目比如都是代码题那可能是模型版本更新后代码风格偏好变了而不是整体降智。如果所有题目全面塌方那才更像系统性变化。最后做交叉验证。用同一个 API key 跑同样的问题如果 API 结果正常网页版结果差那说明问题出在网页端的路由或策略上这时候才轮到“网页端降智”的讨论。如果 API 和网页版一起差那才需要考虑服务端模型本身是否有调整。这套流程跑下来基本能把“体感问题”转化成“可验证问题”后面所有争论都有了据。4. 隐藏元凶为什么同一版本模型会时好时坏4.1 上下文越长模型越“健忘”这是我最常遇到的“伪降智”来源。一个会话聊了 50 轮之后模型需要处理的信息量越来越大它要在长长的历史里找你的真实意图还得记住之前提到的变量、偏好、限定条件。实测下来长对话中模型更容易漏掉早期信息出现前后矛盾。你以为是“被降智了”其实只是上下文窗口快被塞满了。解决办法很简单新开会话或者让模型先总结当前对话把关键结论带到新会话里继续。很多“早上还好好的下午突然变傻”的情况往往就是同一会话用太久了。4.2 温度与采样随机性同一问题每次答得不一样网页版不告诉你当前的温度参数但 OpenAI 不会每次都用同一个采样配置。API 里temperature从 0 到 2 之间可选温度越高输出越随机天马行空但容易出错温度越低越稳定但可能更保守。所以同一个问题你今天问和明天问哪怕是同一个模型结果都可能不同。这不是降智是采样随机性的正常表现。专业一点的做法是走 API 把temperature固定到 0再来做对比测试。网页版没法控制这个变量所以更要多测几轮取整体表现别单看一次。4.3 隐藏的系统提示词、记忆功能和 A/B 测试很多人不知道ChatGPT 的实际回答里除了用户输入之外OpenAI 还会在前端注入一段隐藏的系统提示词。这段提示词可能随时修改比如强化“请确保回答安全”“不要透露内部过程”“保持简洁”等。当这段提示被调强时模型就会变得更保守、更爱拒答、回答更短看起来就像“变笨了”。另外如果你开了记忆功能模型会把你之前聊过的东西悄悄带到新会话里。表面是新会话但记忆已经在干扰结果了。比如你昨天聊过“我不喜欢代码里有注释”今天你让它写代码它可能真的少给注释这并不是降智它只是记住了你的偏好。还有一个容易被忽略的因素是 A/B 测试。OpenAI 经常对不同用户灰度不同的提示词和参数策略哪怕同一版本不同账号拿到的体验也可能不一样。所以网上有人说降智、有人说没感觉可能两边都是真的只是不在同一个灰度组里。4.4 负载、版本路由与输出长度压缩服务端在高峰期会做负载均衡有时候某些区域用户被路由到不同的推理集群实际用的模型尺寸可能比低峰期略小。表现就是晚上问问题明显比早上“笨”但这个“笨”可能到第二天早上就消失了。这种情况更像“资源调度”而不是“针对你的降智”。还有一个测试中容易忽略的指标输出长度。如果你发现 ChatGPT 的回答突然变得非常短逻辑步骤直接就蹦结论连解释步骤都省了很可能是服务端把max_tokens或推理预算压缩了。这会导致模型为了在有限长度内完成回答牺牲掉中间推导过程看起来就像敷衍、降智。但这种变化一般不会持续很久重新打开会话或者换一个入口测试通常能恢复。5. 从模型侧锤实确认你当前到底在用哪个版本5.1 网页版的自报家门不能全信你可能试过让 ChatGPT 说“你是哪个模型”它会告诉你一个版本号。但这个信息参考价值有限因为模型本身并不一定能知道自己的真实服务端配置系统提示词完全可以改写它的自我认知。更别提有些第三方套壳客户端直接把模型名写死你问它它只会复读预设答案。所以要确认真实版本最靠谱的方式是走 API。5.2 用 API 做一次干净的对照实验如果你有 OpenAI API key可以用下面这段代码快速确认实际调用的模型和用量import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) resp client.chat.completions.create( modelgpt-5, messages[ {role: system, content: 你是一个可靠且简洁的助手。}, {role: user, content: 计算 1234 乘以 5678并分步骤说明。} ], temperature0, max_tokens500, ) print(实际模型ID:, resp.model) print(token用量:, resp.usage) print(回答内容:, resp.choices[0].message.content)注意model字段要填你自己账号有权限的真实模型名填错了会直接跳错。打印出来的resp.model就是实际处理请求的模型 IDusage能看到输出长度限制。这个实验的意义在于如果 API 端跑同一条测试题表现稳定、结果正确而网页版表现差那至少说明基础模型本身没有“降智”问题更多出现在网页端的提示词注入、上下文管理或路由策略上。反过来如果 API 端同样变差那才需要进一步关注官方的模型卡和公告。5.3 看官方动态不要轻信截图判断模型有没有被调整官方渠道永远是第一信息源。OpenAI 有模型发布说明通常包含每代模型的能力变化、已知问题、上下文窗口大小、推荐使用场景。如果你发现某些题目突然变难先去翻模型卡和发布日志看是不是模型版本悄悄轮换了。同时留意官方状态页高峰期性能异常、API 高延迟、错误率上升都会公布。很多“降智”现象其实是服务端不稳定造成的临时波动过几个小时自动就恢复了。如果你非要实时盯变化可以用 API 跑定时任务把resp.model和回答正确率记录下来形成自己的趋势图这比到处刷截图靠谱得多。6. 一份排查速查表现象、真因、解法下面这个表是我实操中总结出来的你遇到“疑似降智”时可以对照着走一遍省得每次从头猜。你看到的现象真实原因处理办法新会话也频繁算错小学数学题采样随机性或模型版本策略调整走 API 固定 temperature0 复测或换低峰期再测回答变得特别短步骤都省略了max_tokens 或推理预算被压缩新开会话测试将长任务拆小一次只问一个问题同一会话聊久了越来越笨上下文过长导致信息遗忘新开会话或让模型总结后开新会话继续偶尔一次答错再试又对了采样随机性波动多测 3 次以上取整体表现不必惊慌卡在处理中、一直转圈前端状态同步/客户端 bug/网络波动刷新页面、更新客户端、换浏览器对比Codex 报 model not supportedconfig.toml 里填了账号不支持的模型名打开~/.codex/config.toml修正或删掉model字段提示无法加载 config.toml对话无法继续配置文件语法错误或权限问题检查 TOML 格式、文件路径、编码临时重命名文件走默认配置同一问题上午好、晚上差高峰期负载均衡路由变化错峰测试对比 API 结果排除服务端路由影响回答过度谨慎动不动拒答隐藏系统提示词被调强或 A/B 测试换个委婉的问法重新表达观察几天看是否恢复开了记忆后新会话行为异常记忆功能把历史偏好转入了新会话在设置里关闭或清理记忆再跑一次测试这张表解决一个核心问题把“模型能力”和“使用环境”分开看。很多现象只要换一个会话、换一个入口、换一个时段立刻就不一样了这些都属于环境因素唯独换了会话换了入口换了时段还是同样差才有资格去讨论模型本身的变化。最后再分享一个小技巧我建议你建一个简单的测试日志表每次觉得“变笨”时顺手记录日期、时段、是否新会话、题目类型、正确与否。别嫌麻烦我连续记录一周后发现大部分“降智”都发生在长对话、晚高峰和客户端更新之后真正能归到“模型偷偷变笨”的几乎没有。有了你自己的数据再看“今天又降智了”这类说法你会淡定很多。
