Codex 变笨了？「降智」感受的判断方法与排查清单

感觉变笨，通常对应哪几种真实情况？

常见有四类：模型自动路由到轻量版本、额度窗口处于受限状态、上下文过长导致注意力稀释、任务本身超出模型能力边界。

• 模型路由：高峰期或特定功能会切换到更轻的模型。
• 额度受限：接近上限时任务可能被降级执行。
• 上下文过长：历史消息过多挤占有效推理空间。
• 任务难度：复杂重构类任务本身波动就大。

先做哪些对照测试？

用固定变量法逐个排除：同提示词、不同时间、不同模型、不同任务各测一轮，记录差异再下结论。

1. 1用同一条提示词在两个时间点各跑一次，对比输出。
2. 2在模型选择器手动指定更高档模型，重复实验。
3. 3用一个明确简单的小任务验证基础能力是否正常。
4. 4在全新对话里重试，排除上下文干扰。

额度和上下文的影响怎么排除？

先查看当前额度状态，再把长会话切换成新对话；两步做完再评价模型表现，结论才可信。

额度接近上限时，系统可能改用轻量模型或降低任务优先级，表现就会接近「变笨」。等窗口恢复后再测试，若表现恢复，说明与模型本身无关。

长时间连续对话会积累大量上下文，同样的问题在新对话里可能表现截然不同。把重要任务放在干净的会话里执行，本身也是使用习惯优化。

什么时候可以判断是服务侧问题？

套餐正常、额度充足、简单任务也异常，且多个模型同时异常时，更可能是平台侧波动，可查服务状态说明。

• 官方服务状态页有对应时段的异常说明。
• 高峰时段多个用户同时反馈类似现象。
• 异常在数小时后自行恢复。

和封号、套餐降级有关系吗？

通常没有。封控伴随明确提示；套餐状态不会悄悄降级，设置页显示的档位即当前实际权益。

如果账号被限制，官方会给出明确通知路径。仅凭输出质量变化推断账号状态，容易做出错误处理，比如重复下单或更换账号。

排查无果后怎么反馈？

整理对照测试结果与时间点，用最小必要信息提交给官方支持或交付渠道，不要附带完整凭据。

1. 1记录异常发生的具体时间与使用入口。
2. 2附上同提示词的前后输出对比。
3. 3说明已完成的排查项与结果。
4. 4提供订单号用于核验套餐状态。

怎么区分任务本身波动和真实异常？

看两个指标：异常是否跨任务类型出现、是否跨模型出现。单一任务的波动多数是任务难度问题，跨维度的持续异常才更值得上报。

建立自己的基线：固定一组常用提示词，在正常时期记录典型输出特征。遇到疑似异常时先跑基线，比对结果比凭感觉准确得多。

注意排除本地变量：更换了依赖版本、仓库规模翻倍、提示词悄悄变长，都会让输出看起来变差。把这些变量逐项固定后，剩下的差异才是真实的模型侧变化。

若确认异常跨任务、跨模型持续出现，记录时间段与截图，按官方支持或交付渠道的流程反馈，并附上已完成的对照实验，处理效率会高很多。