本文是「术语解构」系列之一。上一篇《上下文窗口:标称1M的token,为什么32K就开始变笨》讲的是模型在长文本里如何变笨;这一篇讲一个更让人不服气的情况:什么都没塞,它也变笨了。
社区里有个问题被反复问了很久:如果同一个大模型程序是固定的,同样的输入应该经过差不多的计算。云端算力不够,无非多排一会儿队,回答质量为什么会变差?
2025年8月7日,GPT-5发布。第二天,Sam Altman在Reddit AMA中说,前一天自动切换器(autoswitcher)有一段时间没有正常工作,结果GPT-5“显得笨得多”(seemed way dumber)。GPT-5这个产品名称没有变化,请求却没有进入合适的模型或推理路径。
这个例子还不能证明同一份权重变差,却揭开了一个容易被忽略的事实:你打开的是一个AI产品,不是一份孤立的模型权重。 路由、服务器、推理参数、系统提示词、上下文和工具都夹在中间,任何一层发生变化,最后的回答都可能变样。
一、“降智”不是一个技术指标
模型变笨了,可能是指事实错误增多,也可能是推理题做不出来、长对话里遗漏要求、格式执行变差,或者回答突然变短。还有一种情况,模型能力没明显变化,只是输出风格变得不合口味。
把这些现象都装进“降智”这个词,很容易把不同问题混在一起。排查之前,至少要说明下降的是事实正确率、推理能力、指令遵循、长上下文利用,还是工具调用。
一次完整调用大致经过四层:
| 层 | 主要变量 | 谁能影响 |
|---|---|---|
| 权重层 | 模型版本、微调、蒸馏 | 模型厂商 |
| 推理层 | 数值精度、量化、推理预算、采样与运行时实现 | 模型厂商或部署服务商,部分参数向用户开放 |
| 产品层 | 请求路由、系统提示词、上下文压缩、记忆和工具 | 产品与客户端团队 |
| 输入层 | 当前任务、对话历史、参考资料和约束 | 你 |
可以上表粗略理解成:你实际拿到的能力=权重×推理栈×产品层×输入。这不是可以计算的公式,只是提醒一件事:四个乘数里任何一个变小,体感都是“降智”,而权重只是其中一个。

二、两份官方复盘:问题都不在重新训练模型
Anthropic在2025年9月和2026年4月发布过两份技术复盘。两次“事故”位置不同,用户的描述却很接近:Claude好像突然变笨了。这是目前公开材料里最详细的两次“降智事故记录”。
复盘一,2025年:服务模型的基础设施出了问题
2025年8月初,部分用户开始报告Claude回答质量下降。Anthropic最终找到了三个互相重叠的基础设施问题。
第一个问题是上下文路由错误。8月5日起,部分Sonnet 4短上下文请求被错误发送到为即将上线的1M上下文配置的服务器池,最初影响约0.8%的请求。8月29日的一次负载均衡调整放大了问题。8月31日最严重的一小时,16%的Sonnet 4请求受到影响。Anthropic还估计,在这段时间使用Claude Code的用户中,约30%至少遇到过一次错误路由。
路由具有粘性,一条请求被送错后,后续请求也更可能留在同一个错误服务器池。于是有人连续遇到问题,也有人完全没有感觉,社区里看到的就是随机而不一致的退化。
第二个问题来自TPU服务器配置。一次运行时优化偶尔给本不该出现的token分配高概率,英文回答中可能突然出现泰文或中文(给我用韩文回复我的输入,问它为啥会出现韩文,他认错后改了,之后又反复出现过几次),代码里也会冒出明显的语法错误。
第三个问题与XLA:TPU编译器的近似top-k操作有关。在特定批次大小和模型配置下,它可能返回错误结果,把概率最高的那个token丢掉。Anthropic最后改用精确top-k,并把部分运算统一到fp32,接受了一点效率损失。
复盘中写道(以下为本文翻译):
我们不会因为需求、时段或服务器负载降低模型质量。用户报告的问题完全来自基础设施bug。
这份复盘最有价值的地方,是把“今天怎么忽然变笨了”拆成了可以定位的生产事故。模型名称相同,服务模型的基础设施仍然可能改变输出。
复盘二,2026年:API没变,Claude Code外层改了
2026年3月起,Claude Code用户再次报告质量下降。4月23日发布的复盘明确说,Anthropic API和推理层没有受到影响,问题来自Claude Code、Claude Agent SDK和Claude Cowork中的三项改动。
一个默认值。 3月4日,Claude Code把默认推理强度(effort)从high调到medium,以减少high模式偶尔出现的长延迟。内部评测显示,medium在多数任务上智能略低,但延迟明显减少、token消耗更少。用户很快报告Claude Code不如以前聪明。即使产品做了多轮提示让用户知道可以改回去,大多数人还是停在默认值上。4月7日,Anthropic撤回这项默认设置,Opus 4.7改为默认xhigh,其他模型默认high。复盘自己的评价是:这是个错误的取舍。
一个缓存策略。 3月26日上线的改动原本只想在会话闲置超过一小时后清理一次旧思考内容,降低恢复会话的成本。实现中的bug却让清理动作在此后每一轮继续发生,模型逐渐看不到自己之前为什么做出那些决定,表现为健忘、重复和工具选择异常。顺带还导致缓存持续未命中,用量额度消耗得比平时快。4月10日修复。
两句提示词。 4月16日,Claude Code的系统提示词增加了两条长度限制:工具调用之间的文字不超过25词,最终回答不超过100词。上线前的测试没有发现退化,事后扩大评测范围并逐行移除提示词时,其中一项评测显示Opus 4.6和Opus 4.7都下降了3%。这两条限制在4月20日撤回。
这三个变化影响不同用户、发生在不同时间,叠在一起后很像一场没有规律的全面降智。实际上,推理强度、历史思考和系统提示词分别动了一下。这次复盘的声明措辞和上一次不同,但意思一致(以下为本文翻译):
我们从不故意降低模型质量。
把两份复盘放在一起看:同一份权重,在推理层能被路由错误、精度bug弄坏;在产品层能被一个默认值、一个缓存策略、两句提示词弄坏。 权重一行没改,用户照样觉得变笨了。

三、六个开关,分别握在谁手里
把这些事故放回完整调用链,可以整理出六个更容易排查的开关:
| 开关 | 谁握着 | 有人翻过吗 | 你能做什么 |
|---|---|---|---|
| ① 请求路由 | 产品厂商 | GPT-5路由器失效;Claude短请求被送到1M服务器池 | 有选择时固定模型或推理模式,保存模型与请求信息 |
| ② 推理强度与输出预算 | 厂商定默认值,你能改 | Claude Code默认effort high→medium | 在界面或API开放时显式设置,不依赖默认值 |
| ③ 上下文压缩与记忆清理 | 产品或客户端 | 清理thinking的bug每轮触发 | 长任务保存阶段结论,异常时用整理后的上下文重新开始 |
| ④ 系统提示词与工具配置 | 产品或客户端 | 25词/100词限制,−3% | 对比不同客户端或原始API,确认工具是否成功执行 |
| ⑤ 量化、推理框架与解码实现 | 部署服务商 | 同一开源模型,不同服务商差异见下 | 优先选择可说明模型版本和配置的服务,重要任务先做验证 |
| ⑥ 对话历史与参考资料 | 你 | 见下 | 清除失效信息,把证据、当前目标和限制组织清楚 |

前四个开关已经在两份复盘里出现,这里各补一句“对你意味着什么”。后两个离开放权重模型和日常使用更近,也更容易被误认为模型本身不行,单独展开。
开关①,路由:你以为在用A,其实被送到了B。 GPT-5的自动切换器和Claude的服务器池做的是同一件事:决定你的请求由哪个模型、哪组机器来答。它对用户完全不可见,出错时你唯一的线索就是“今天怎么这么笨”。能做的只有一件事:在能选的地方明确选模型,别把选择权交给“Auto”。
开关②,推理强度:一个默认值的距离。 同一个模型,high和medium之间是“智能略低、延迟显著更少”的距离,而大多数用户从来没打开过那个设置。这是六个开关里唯一一个厂商和你各握一头的:厂商定默认值,你随时可以改,前提是你知道它存在。
开关③,上下文管理:它忘了,但没告诉你。 产品为了省token和延迟,会压缩历史、清理旧的思考内容。做对了你感觉不到,做错了模型就会一边干活一边忘记自己为什么这么干。它不会报错,只会越来越像没睡醒。
开关④,系统提示词:两句话,−3%。 你看不到的那几千字系统提示词,每一行都在影响输出。Anthropic自己的经验是:内部测试几周没发现问题,换更大的评测集逐行消融才看到下降。这也解释了为什么同一个模型在聊天客户端和编程工具里表现得像两个人。
开关⑤:同一份开放权重,不同服务商可能交出不同结果
Kimi K2发布后,月之暗面收到不少工具调用异常的反馈,查下来问题不在模型,在部署。于是他们开源了K2 Vendor Verifier,用同一组4000条请求,比较各家第三方部署与官方API的工具调用表现。
2025年11月15日公布的一轮K2-0905结果中,不同部署的工具调用Schema准确率(返回的JSON是否符合格式)从100%到70%出头不等,其中包括vLLM、SGLang这两个主流开源推理框架的默认部署。部分部署的工具调用触发F1也明显低于官方参考。这里的F1综合了精确率和召回率,不能直接理解为多少请求答错,也不能代表写作、数学或综合推理能力。它证明的是一个更窄也更可靠的结论:同一模型的工具调用行为,会因部署实现而出现可量化的差异。
月之暗面后来在Kimi Vendor Verifier的说明中提到,K2 Thinking发布后,一部分异常基准成绩来自解码参数误用。为减少这类问题,官方API在思考模式下强制使用temperature=1.0和top_p=0.95,同时检查思考内容是否被正确回传。测试中还加入了长输出压力项目,用来暴露短测试不容易发现的KV Cache和量化问题。
这是国内厂商第一次公开量化了一件事:开源权重人人可下载,但你调到的“Kimi K2”表现是否等于官方的Kimi K2,取决于谁在跑它、怎么跑。
那量化本身呢?说句公道话,量化不等于降智。一项覆盖整个Llama 3.1系列、累计超过50万次评测的研究发现,FP8在其测试范围内基本无损,经过良好调优的INT8平均下降约1%~3%,INT4权重量化的表现也比预期更有竞争力。前提是“良好调优”。另一份2026年的第三方测试用社区GPTQ版本的Qwen3-32B,在单张H100上比较BF16、FP8、INT8和INT4(未启用思考模式):INT4在MMLU-Pro上比BF16低1.6分,在HumanEval上低约8分。两组来源不能合并成一组证据,前者是学术论文,后者是特定配置下的单次测试;但方向是一致的:调得好,几乎看不出来;调得糙,在你最在意的任务上先崩。 而你用第三方API时,通常不知道它调得好不好。
非官方中转站还增加了一层难以审计的转发链路。社区里普遍观察是它们可能改采样参数、压缩上下文或替换模型,但公开资料不足以证明具体平台做了什么,不能仅凭使用体感给某个渠道下结论。能确定的只有一点:正规服务商之间尚且有上面那张表的差距,中转站只会更不透明。
开关⑥:你自己也能在不换模型的情况下把它用笨
模型看到的不是你脑子里的当前目标,而是这次请求中实际传入的内容。多轮对话里的旧目标、失败尝试和已经作废的格式要求没有被清理时,它们仍然会参与下一轮生成。
上一篇上下文文章讲过:模型对长输入的利用是U形的,中间是盲区,32K就开始腰斩。这里补两个上次没讲的证据。
一是无关信息的干扰。ICML 2023的一项研究(GSM-IC)构造了带无关信息的小学数学题,加入与解题无关的内容后,受测模型的准确率明显下降。这项实验针对数学推理,不能直接代表所有多轮对话,但它说明无关上下文确实可能干扰模型选择推理路径——不是读不到,是被带偏了。
二是位置的影响有多大。Anthropic当前的提示词文档建议,处理20K token以上的长资料时把文档放在前面、问题放在最后;在其多文档测试中,这种安排最高改善约30%。这是Anthropic特定测试的最高值,其他模型和任务需要单独验证,但方向是通用的:同样的资料,同样的问题,换个顺序,答案质量可以差三成。
所以这个开关怎么翻、怎么翻回来,可以直接对照着看:
| 把模型用笨的做法 | 不让它变笨的做法 |
|---|---|
| 所有资料一次性塞进去 | 只传当前任务需要的资料,过期内容及时删掉 |
| 关键限制埋在长文中间 | 长资料放前面,当前问题、限制和交付格式放最后 |
| 多轮对话里反复改目标,新旧要求打架 | 目标一变就重新整理上下文,必要时新开会话 |
| 开着上一个任务的会话直接问下一个 | 一个任务一个会话 |
| 让模型直接给结论 | 先让它找出相关证据,再依据证据回答 |
| 长任务全靠聊天历史记着 | 把关键决定写进阶段摘要 |
左边每一条你都没换模型,但你已经把四个乘数里最后那个调小了。右边每一条也不花钱,只花你两分钟。这些方法不能消除模型的能力边界,但能减少输入层自己制造的干扰。
四、哪些已经证实,哪些还只是猜测
讲到这里,得把证据的边界画清楚,因为“降智”这个话题最容易滑向阴谋论。
已经证实的: 两份Anthropic复盘证实,错误路由、推理强度默认值、历史思考清理和系统提示词改动,都可能在没有重新训练模型的情况下改变用户体验。GPT-5发布后的公开回应也说明,自动路由故障会让整个产品显得更笨。
可以自己验证的: K2 Vendor Verifier表明,官方API与第三方部署的工具调用表现存在可测量的差异。月之暗面给了方法和数据,你也可以跑。但它没有证明这些服务商偷偷更换了模型,也没有测量它们的综合智能。
目前没有可靠公开证据的: “厂商在高峰期为了省算力,秘密降低同一付费档位的质量”。本文查到的公开材料不足以支持这个判断。Anthropic明确否认自己会因需求、时段或服务器负载降低质量;其他厂商是否存在类似行为,需要相应厂商或独立测试的证据,不能用Anthropic的声明代替。
这里要区分两件事:偷偷降质和公开分档。effort档位、Thinking与Instant模式、免费和付费的服务层级,都是你能看到、能选的产品配置。它们会影响速度、成本和能力,但这不叫降智,叫定价。目前所有被证实的“降智”事件,都是基础设施bug、错误默认值和带来意外副作用的产品改动,而不是被抓到的秘密降质。这不代表未来不会有,只代表现在如果有人告诉你“某厂商晚高峰偷偷换小模型”,你应该先问他数据在哪。
五、不让它变笨:先预防,再排查
六个开关里,①路由和⑤部署你基本管不了,但②③④⑥都有你能碰到的那一头。先把预防做了,能省掉大部分排查。
开关②:别信默认的推理强度。 用Claude Code、Codex、各种IDE插件和Agent框架的人,装好第一件事是把effort、thinking、max_tokens显式设成你要的值。2026年3月那次事故的本质就是一个默认值被改了,而大多数人从来没打开过那个设置。
开关③④:知道你的客户端在替你做什么。 网页版、编程工具、第三方客户端接的是同一个模型,但系统提示词、上下文压缩策略、工具配置各不相同。同一份字幕丢给聊天客户端和编程工具,得到的总结风格可以差很远,这不是模型变了,是外层变了。用哪个工具干哪种活,心里要有数。
开关⑤:能走官方就走官方,走第三方就先验。 月之暗面已经把验证脚本开源了,跑一遍4000条太重,抽一百条比一比Schema准确率和触发一致性,足够判断一个服务商靠不靠谱。
开关⑥: 上一节右边那一列。
预防做完还觉得变笨了,再按下面的顺序查,成本从低到高。
单次回答变差证明不了能力下降。模型输出本来就有波动——K2 Vendor Verifier反复运行官方API时,K2-0905工具调用F1的最低值为82.71%,平均值为84%。比较前需要先把会变化的条件固定下来。
- 先固定,再比较。 记录完整模型ID和版本、系统提示词、对话历史、资料、推理强度、温度、输出上限、工具和联网配置。OpenAI的API文档也提醒,模型在不同快照之间的行为可能变化,需要稳定输出的应用应固定模型版本,并持续运行自己的评测。
- 新开一个干净会话。 用整理后的上下文重来。新会话恢复正常,说明历史上下文或产品的上下文管理(开关③⑥)更值得检查,但单次对比还不能排除随机波动。
- 确认你设的值还在。 检查客户端实际暴露的effort、thinking和输出限制。客户端更新会重置配置,也会像2026年3月那样悄悄改默认值——你以为在high,实际可能已经回到medium。
- 官方API和当前渠道跑同一组题。 只有模型ID、完整输入、采样参数、工具定义和运行次数都一致时,这项对比才有定位价值;一致了,它能直接定位开关⑤。
- 建一套自己的轻量回归题。 从20~30个真实任务开始,每题重复跑几次,记录事实正确率、约束遵循率、工具成功率和信息完整度。这能做日常预警,不能代替严格的统计评测。有了这套题,“以前感觉更聪明”就变成了一个可以回答的问题。
- 查看厂商状态页和技术复盘。 前面两份复盘都是用户先反馈、厂商再发现的。提交反馈时附上时间、模型、客户端版本、完整请求和可复现步骤,比一句“今天变笨了”更容易定位问题。
写在最后
回到开头那个问题:程序是固定的,为什么会变笨?
因为“程序”不止权重。权重像汽车的发动机,但你开走的是整辆车:推理强度决定油门响应,上下文管理影响导航记忆,系统提示词设定行车规则,路由决定请求走哪条线路,部署实现还会改变发动机怎么工作,最后还有你自己的驾驶习惯。发动机没有换,车仍然可能开得不对劲。
这也是这个系列一直在讲的那件事的又一个版本:参数量不等于算力,标称窗口不等于有效窗口,权重不变也不等于能力不变。 发布会上的模型,和你手里的模型,中间隔着整条链路。
下次觉得AI变笨了,先把问题换一种问法:下降的是哪种能力,六个开关里哪个动了?其中握在我手里的那几个,我掰对了吗?能把变量固定下来,“降智”才从一种体感变成可以检查的问题。
你遇到过同一个模型换了客户端或服务商,表现明显不同的情况吗?是怎么发现的?
资料边界说明
第一手(厂商或项目方):
- Anthropic,A postmortem of three recent issues,2025-09-17:https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
- Anthropic,An update on recent Claude Code quality reports,2026-04-23:https://www.anthropic.com/engineering/april-23-postmortem
- OpenAI团队,GPT-5 Reddit AMA,2025-08-08:https://www.reddit.com/r/ChatGPT/comments/1mkae1l/gpt5_ama_with_openais_sam_altman_and_some_of_the/(Altman原话另见TechCrunch 2025-08-08报道)
- MoonshotAI,K2 Vendor Verifier(GitHub,本文引用2025-11-15测试轮):https://github.com/MoonshotAI/K2-Vendor-Verifier
- Kimi,Kimi Vendor Verifier:https://www.kimi.com/blog/kimi-vendor-verifier
- Anthropic,Prompting best practices(长上下文部分,“最高改善约30%”):https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- OpenAI,API backwards compatibility:https://developers.openai.com/api/reference/overview#backwards-compatibility
学术研究:
- Kurtić等,“Give Me BF16 or Give Me Death”? Accuracy-Performance Trade-Offs in LLM Quantization,arXiv 2411.02355(v4)
- Shi等,Large Language Models Can Be Easily Distracted by Irrelevant Context(GSM-IC),arXiv 2302.00093,ICML 2023
- Liu等,Lost in the Middle,arXiv 2307.03172,TACL 2024
- Chen、Zaharia、Zou,How Is ChatGPT’s Behavior Changing over Time?,arXiv 2307.09009——本文未引用其数字:该研究比较的是2023年3月和6月两个不同快照,能证明行为漂移,不能证明同一权重退化,且v1与修订版数字差异很大
第三方测试:
- AIMultiple,LLM Quantization: BF16 vs FP8 vs INT4,2026-03。社区GPTQ量化版Qwen3-32B、单卡H100、未开思考模式,仅作补充案例,不与上述论文合并:https://aimultiple.com/llm-quantization
社区/二手:
- Linux.do相关讨论帖(2026年6月、9月),仅用于引出问题,观点不作为证据
- 关于中转站修改参数、替换模型的说法来自社区观察,无第一手证据,正文已标注
证据适用范围: 厂商材料能说明其公开承认的事故和测试结果,不能自动外推到其他厂商。第三方部署表只覆盖工具调用指标,不代表模型的全部能力。Anthropic的30%、AIMultiple的8分都是特定配置下的测试值,不代表通用收益或损失。