新模型总被说「降智」：是模型退化还是上下文污染，怎么自己验证
围绕「新版 Codex 模型不如上一代」的争论，拆解感受差异的常见来源：上下文压缩残留、会话污染、采样随机性、套餐与路由差异，以及「问模型版本」这种不可靠取证方式。给出一套可落地的轻量对比测试流程与日常使用检查清单，帮助把主观感受变成可复现的判断。
新模型发布一段时间后，社区里几乎都会出现同一类声音：现在的版本不如刚上线时好用，水平退回到了上一代，甚至更差。最近围绕某个新版 Codex 模型的讨论就是如此——有人确信能力下滑，有人觉得准确率明显提升，还有人认为这类讨论纯属心理作用。
这些说法看似矛盾，其实大多不冲突：每个人面对的任务类型、会话长度、使用节奏和订阅档位都不同，观测到的现象自然不同。真正有价值的问题不是「谁的感觉对」，而是怎样在几分钟内排除掉那些与模型本身无关的干扰项，让判断变得可复现。
争议为什么总是无法收敛
把讨论里的观点分类，大致是三类立场：
- 归因于上下文：长会话反复压缩后，上下文里堆满半成品结论、失败尝试和冗余日志，模型再强也会被拖累。
- 归因于模型本身：新开会话、任务简单，仍然一次过不了，说明是模型侧的变化。
- 归因于观测方式：单次体验的噪声极大，没有固定任务集和对照记录，讨论只能停留在感受层面。
三类说法都有合理成分，但适用边界不同。第一种解释的是「同一个会话越用越差」，第二种针对的是「干净环境下也不如从前」，第三种提醒的是「样本量为 1 的结论不可靠」。混淆这三层，讨论就必然变成各说各话。
先排除最常见的干扰项：上下文污染
长会话是影响输出质量的最大变量，而且它的表现很像「模型变笨」：早期能理解的指令，到了会话后半段开始答非所问；改动范围越来越大，重复修改同一处代码。
可以按下面的顺序自查：
- 换一个全新会话，用最小复现的提示重跑同一件事。不要复述之前的失败过程，只给必要输入和验收标准。
- 检查会话里是否残留大段日志、堆栈、失败补丁。这些都算有效上下文，模型会把它们当线索继续沿用。
- 看工具与指令的数量。MCP 工具、系统级规则、项目规范越多，注意力越分散，任务越容易跑偏。
- 确认是否在压缩之后继续叠加任务。压缩是有损的，被压掉的约束不会自动回来；重要约束应写进项目里的规则文件，而不是只留在对话里。
- 按任务切会话。一个会话只做一件事，完成即归档，比在一个会话里连续处理五件事稳定得多。
如果新会话下问题依旧稳定复现，才值得继续怀疑模型侧。
「新会话也不行」时，还可能是哪些因素
排除了上下文，仍然存在一批与模型权重无关的变量。它们大多无法从外部确认，只能自己观察：
| 可能因素 | 典型表现 | 怎么验证 |
|---|---|---|
| 采样随机性 | 同一提示多次运行，结果好坏参半 | 同一提示跑 3–5 次，看成功率而非单次结果 |
| 版本别名与后端快照 | 界面显示同一版本号，行为却不一致 | 以官方文档的版本说明为准，别只信界面标签 |
| 套餐与限额 | 高峰期响应变慢、长任务被截断 | 换时段对比，记录失败发生的时间点 |
| 任务难度漂移 | 最近在改更复杂的模块 | 拿同一批老任务回放，而不是换新任务测 |
| 期望值上移 | 新模型基线更高，小错误更刺眼 | 用同一验收标准给两个版本打分 |
其中「版本别名」这一项特别容易被忽略：产品端的显示名称未必对应固定的模型快照，具体路由策略以官方最新说明为准，社区里的推断只能当参考。
一个不玄学的自测流程
不需要搭建评测框架，用半天时间就能做出比「我感觉」更可靠的结论。
第一步：建一个小任务集。 从最近两周真实做过的工作里挑 15–30 条，覆盖你常用的场景（改 bug、写测试、重构、读陌生代码、写脚本）。每条记录：输入、验收标准、期望产出。任务要短，单条能在几分钟内判定成败。
第二步：固定条件。 同一批任务、同一套提示词、同一档推理强度、同一时段运行，全程开新会话，附带的工具集保持一致。
第三步：记录而不是回忆。 每条任务记四个字段：
task_id | version | pass(1/0) | retries | manual_edits
pass 只按验收标准判定，不看输出「看起来专业不专业」；manual_edits 记录为了跑通改了多少行，这个指标比通过率更能反映日常体感。
第四步：盲评。 两个版本的输出去掉标识后混在一起打分。人对「新版本」有先入为主的预期，不盲评很容易得出想要的结论。
第五步：看聚合结果。 通过率差 1–2 条任务属于噪声范围；如果某个场景（比如跨文件重构）稳定差一截，那才是有意义的差异。
关于「问模型是哪个版本」
讨论里有一种取证方式：直接问模型训练截止时间，据此断定后端其实是上一代模型。这个方法不可靠。模型对自己的版本、训练数据截止时间、参数规模的回答，主要来自训练语料和系统提示里的描述，经常是过期甚至编造的。它能作为线索，但不能作为证据；同样，模型的自我否定也不能证明它没被替换。
相对可靠的替代做法是行为层面的对照：用同一批任务比较输出风格、拒绝边界、工具调用习惯、对特定 API 写法的偏好。这些特征比自报身份稳定得多，但也只是间接证据。
实际怎么选用：三种策略的取舍
- 固定版本、不做升级：适合交付压力大、流程已经跑顺的阶段。代价是拿不到新版本的收益，且旧版本可能随时下线，需要关注官方弃用公告。
- 双版本并行、按任务分配：新版本处理探索性任务（读代码、写方案），旧版本处理机械改动（批量替换、格式化）。管理成本高，但对稳定性要求高的项目最实用。
- 只跟新版、靠流程兜底：适合个人开发。前提是把验收标准、测试用例和规则文件补齐，让质量不完全依赖模型单次发挥。
如果任务本身是长时间连续运行的（例如让 Codex 整晚跑批量重构），本地机器休眠、网络抖动导致会话中断，往往会被误读成「模型不稳定」。这种情况下可以把长任务放到长期在线的远程 Mac 上执行，整机在新加坡机房、按月租用、远程连接，会话不容易被打断，对比测试的条件也更一致——这只是可选做法之一，短任务本地跑完全够用。
小结
判断「模型是不是变差了」，顺序比结论重要：先清理上下文、开新会话、固定任务集，再看统计结果。多数「降智」体验能被前两步解释，剩下的差异才值得认真对待。至于那些无法从外部确认的部分——后端路由、快照更新、档位策略——以官方最新说明为准，社区推断保留余地。
最后一点值得强调：说出「我感觉最近变差了」本身没有错，它是发现问题的起点。但要让讨论有建设性，就需要把它变成可复现的现象描述：什么任务、什么会话状态、失败在哪一步。这比争论谁的感觉更准有用得多。
