新模型发布几天后就「变笨」？原因拆解与自测清单

新模型刚上线那几天，往往表现惊艳：指令跟得紧、代码一次过、思路清楚，连边角需求都能照顾到。可用上一两周，不少人开始觉得它「变笨」了——同样的活要来回改好几轮，回答变慢，甚至频繁遇到 Selected model is at capacity. Please try a different model. 这类提示。于是「首发满血、之后掺水」「偷偷换成量化版本」的说法就传开了。

这种感受值得认真对待，但也很容易误判。下面把讨论中出现的几种解释拆开来看，并给出可以自己动手验证的做法。

先确认：你说的「变笨」是哪种表现

不同症状指向的原因完全不同，先对号入座：

• 指令遵循变差：忽略明确约束、擅自扩大或缩小改动范围、忘记前置条件。
• 输出风格漂移：答案变短、变敷衍，或反过来变得又长又空。
• 速度与延迟：首个 token 出现变慢，长任务动辄半小时起步。
• 被拒绝或降级：频繁出现容量不足提示，实际被路由到别的模型。
• 稳定性变差：同一个提示，今天好用明天翻车，抖动明显变大。
• 成本变化：同样的任务消耗的 token 明显变多或变少。

把这些分开记录，比笼统地说「变笨了」有用得多。

可能的原因：五类解释

一、服务端的容量与路由

这是最容易被忽略、也最容易被证实的一类。新模型发布初期，厂商通常会给足资源；热度过去后进入日常调度，高峰期排队、限流、按负载把请求路由到更小的模型或更低精度的推理实例，都会直接体现在体感上。那句 at capacity 提示，本身就是后端在告诉你「现在资源紧张」。

二、推理配置与权重版本

社区里流传最广的猜测是：评测期用满血权重，之后换成量化或蒸馏版本以节省算力，好腾出卡训练下一代。另一种可能是推理侧参数被悄悄调整，比如思考预算、最大输出长度、系统提示模板。这些说法逻辑上成立，但厂商基本不公开，属于推测而非定论，不宜当成事实传播。

三、商业优先级

企业客户和个人用户在配额、路由优先级上的差别是客观存在的。当资源紧张时，个人订阅被排在后面并不奇怪。这解释了「为什么同一时刻别人用得挺顺，我这里一直在转圈」。

四、用户侧的适应与基线漂移

有个很贴切的类比：降噪耳机刚买时觉得效果惊人，用久了觉得「降噪没以前好了」，一部分原因是耳朵适应了新基线。模型也一样——刚换新模型时对比的是旧模型，差距被放大；用熟之后开始注意到它的失误，好感回落。这时再回头用旧模型，反而会觉得旧模型更蠢，于是陷入「到底谁退步了」的困惑。

另外两个常被低估的因素：

• 长会话上下文污染：一个会话聊到几十轮，早期无关内容仍在影响输出，表现自然下滑。
• 任务难度漂移：前一周在做熟悉的活，后一周开始啃硬骨头，主观上就觉得模型不行了。

五、缺少一致性评测标准

模型能力对普通用户接近黑盒，既没有公开的版本号变更日志，也没有第三方持续复测。没有统一的度量，讨论只能停留在体感层面。

自测清单：先分清「真变化」和「错觉」

想下结论，最稳妥的方式是建立自己的小型回归测试。步骤不复杂，但要严格控变量。

1. 建一个固定题集。 挑 20–50 条你真实工作中的任务，覆盖指令遵循、代码修改、长文总结、边界条件处理。为每条写下验收标准，而不是只存「感觉不错的答案」。

2. 控制变量。 同一时段跑、同样的系统提示、同样的工具开关状态、每次都新开会话、限制相近的上下文长度。任何一项变了，结果就不可比。

3. 固定版本标识。 尽量使用带明确版本/快照名的模型标识，避免用会随时间漂移的别名。别名指向哪天被切换，你往往无从得知。

4. 记录可量化的指标。 只靠记忆对比几乎没有说服力。

5. 交叉验证。 用不同入口（客户端与 API）、不同时间段、必要时不同账号各跑一轮。如果只有某个入口差，问题大概率在入口而非模型本身。

6. 至少观察一周。 单次差异可能只是采样随机性，看趋势而非看某一天。

降低影响：让关键任务不押在波动上

不管原因是什么，工程上都可以把不确定性隔离掉：

• 关键任务锁版本、备两手。 主用模型 + 一个稳定可用的备用模型，随时可切。
• 拆小任务、短会话。 每次只给必要上下文，做完就新开会话，减少历史污染。
• 写清验收标准。 把「不要动哪些文件」「输出必须包含什么」直接写进提示，比事后返工便宜。
• 遇到容量提示就退避重试。 指数退避 + 错峰，必要时自动切备用模型，不要原地死磕。
• 保留失败样本。 出问题的提示与输出原样存档，既是排查依据，也是向厂商反馈的材料。
• 长期在线的任务，先解决环境稳定性。 像 Claude Code 这类要连续跑重构、批处理或定时任务的场景，本地机器休眠、断网、代理抖动都会放大「模型不稳定」的错觉。如果本地设备性能吃紧或需要长时间常驻，可以考虑把执行环境放到一台整机独占、长期在线的远程 Mac 上（例如放在新加坡机房的独享 Mac mini，按月租用、远程连接），网络与设备因素就被排除在外，剩下的差异才更可能是模型本身。

注意事项

• 别用第三方中转来「换更满血的实例」。 来路不明的中转服务无法保证转发的是你指定的模型，掺入更小模型甚至旧版本的情况时有耳闻；同时你的提示和代码会经过陌生链路，还有账号被牵连的风险。稳定的对比前提是走官方渠道。
• 不要合租、买卖账号。 违反服务条款，出问题时你连申诉的余地都没有。
• 把推测和结论分开写。 「量化版本替换」是合理猜测，不是已证实的事实；对外分享时标明证据强度。
• 以官方说明为准。 模型版本、下线计划、配额策略都属于强时效信息，遇到变更请查官方文档与发布公告，别信二手转述。
• 善用反馈渠道。 有指标的自测记录比「感觉变笨了」更容易被认真对待。

小结

新模型「发布即巅峰」的体感，可能是服务端限流与降级、推理配置调整、商业优先级、用户适应与度量缺失共同作用的结果，其中只有一部分能靠外部观察验证。与其在讨论里互相说服，不如花半天搭一个固定题集，把通过率、延迟、token 消耗记下来跑一周：数据支持怀疑，就去反馈或换方案；数据不支持，说明更像是基线漂移，调整用法即可。对关键业务来说，锁版本、留备用、控上下文，永远比赌某个模型一直保持首发状态更可靠。