Claude Opus 越用越「蠢」是错觉吗？原因排查与解决思路

同一个模型，刚上手时丢一个问题过去，产出的结果常常超出预期；用了一段时间后，同样的问题却要来回拉扯半天，甚至开始跟你「对喷」。这种落差在 Claude Opus 系列上被反复提起，尤其是从 Opus 4.6 切到 4.7 前后的那段时间，怀疑「降智」的声音特别集中。

但把这件事直接归因于「官方偷偷削弱模型」并不严谨，因为从你敲下回车到看到回答，中间隔着一串变量：客户端版本、实际调用的模型 ID、走的渠道、上下文有多长、提示词怎么写、任务本身难不难。任何一个环节变化，体感都会明显下滑。下面把这些变量拆开，给出可操作的排查顺序。

先分清「模型变笨」和「你拿到的不是那个模型」

社区里最典型的分歧就在这里：一部分人坚称旧版本早已下线，你用的是假的；另一部分人表示通过 API 或 /model 依然能选到对应版本。两种说法都可能成立——官方网页端、官方 API、Claude Code 客户端、第三方 IDE 插件、中转服务的可用模型列表本来就不同步，下线节奏也不一致。所以第一步不是争论谁对，而是先确认你当前这次请求到底发给了谁。

五个可验证的变量

客户端版本确实出过问题

有明确说法是某几个版本的 Claude Code 存在官方承认的行为退化 bug，升级后恢复正常。这类问题成本最低，应该最先排除：

# 以 npm 全局安装为例，先看当前版本
npm list -g | grep claude
# 升级到最新
npm update -g @anthropic-ai/claude-code

具体包名和升级方式以官方文档为准，不同安装方式（npm、原生安装包、IDE 插件）更新路径不一样。

中转服务可能悄悄换了模型

这是被提到最多、也最需要警惕的一点。中转服务的卖点是便宜和方便，但它对你完全黑盒：你请求的是 A 模型，返回的可能是一个能力接近但便宜得多的模型，甚至是国内厂商的模型。表现就是「回答结构还挺像，但推理深度明显不够，还特别爱顶嘴」。

判断方法很朴素：拿一个你已知标准答案的、需要多步推理的问题，分别在官方渠道和中转渠道各跑一次，比较推理过程和错误类型。如果差异稳定复现，基本可以确定渠道有问题。

另外，中转服务还意味着你的代码、提示词、上下文都经过了第三方服务器，涉及公司代码或敏感数据时要格外谨慎。合规的做法是走官方 API、官方订阅或云厂商的托管版本，至少要有明确的数据处理条款。

上下文累积会被误认为变笨

一个会话聊到几十轮之后，早期的约束被压缩、被遗忘，模型开始重复提问或推翻自己先前的结论，体感就是「越用越蠢」。实际上多数客户端在上下文接近上限时会做摘要压缩，信息损失不可逆。

对策很简单：一个任务一个会话。换主题就新开，把必要的背景用几行字重新交代，比在旧会话里修补要高效得多。

交互方式会放大问题

把模型当作 token 预测器而不是同事，这个视角很有用。当你在提示里连续否定、指责、施压，上下文里堆满了负面表述和互相矛盾的要求，模型倾向于给出更保守、更含糊、更容易「摆烂」的回答。这不是玄学，是条件概率的结果。

更有效的做法是把抱怨换成约束：

• 明确产出格式（先给结论、再给步骤、最后给风险）
• 给出可验证的验收标准，比如「必须能通过这 3 个测试用例」
• 一次只改一个点，不要在一条消息里同时要求重构、优化性能、改风格
• 让它先复述你的需求，确认无误再动手

一套按成本排序的排查清单

1. 升级客户端，重启，确认版本号已变化。
2. 确认模型：用 /model 或请求日志核对实际模型标识，别只看界面上的名字。
3. 新开会话复现：用最小可复现的提示，排除上下文污染。
4. 换渠道对照：官方直连跑一次，中转跑一次，记录差异。
5. 换模型对照：在同一提示下比较不同档位的模型，判断是「模型整体退化」还是「这个任务本来就不适合它」。
6. 留证据：把提示、模型标识、时间、输出保存下来。没有记录时，「感觉变笨」几乎无法讨论；有记录才能判断是不是稳定复现。

如果你的工作流是长时间挂着 Claude Code 批量跑任务，本地机器休眠、断网、代理抖动都会打断会话，看起来就像模型中途「失忆」。这类场景下，把执行环境放到一台常年在线、网络稳定的机器上（例如机房里的独享 Mac）是可选做法之一，但它解决的是运行环境问题，不会让模型本身变聪明，别指望它扭转能力上的变化。

如果确认是服务端能力变化，怎么应对

社区里关于「旧版本被削弱」的说法很多，有提到基准测试排名下滑的，也有提到官方以 bug 解释的，但这些具体数据和时间点建议以官方发布说明为准，别把二手转述当成定论。无论原因是什么，你能控制的只有应对方式：

• 任务拆小：把一个大重构拆成「读代码 → 给方案 → 改一个文件 → 跑测试」，每步单独验证。
• 用测试兜底：让模型产出后必须通过既有测试，比自己肉眼审查更可靠。
• 准备备用模型：不同模型在不同任务上的强弱并不一致，代码改写、长文推理、结构化抽取各有所长，把两三个模型组合进工作流，比赌单一模型稳定。
• 别在同一个会话里反复对抗：连续三轮没进展，就换提示、换模型或自己动手，硬耗只会累积无效上下文。

至于「要不要转投别的工具」，取决于你的场景。如果主要工作是终端里的多文件改写和命令执行，Claude Code 这类 agent 形态的工具优势明显；如果只是做问答或单文件补全，换一个更便宜的模型完全够用。切换前先用自己真实的任务做几天对照，别只看别人的评价——同一个模型在不同人手里的体验差异，往往比版本差异还大。

注意事项

• 第三方中转的模型替换、稳定性、数据留存都不可控，涉及生产代码时优先选可追溯的官方渠道。
• 模型可用列表变化很快，某版本是否还能选到，以你所在平台当时的官方文档和 /model 输出为准。
• 「降智」类讨论里混杂着真实的能力波动、渠道问题和心理预期，任何单一解释都不足以覆盖全部情况。
• 升级客户端、切换渠道后建议重新跑一遍固定的对照任务，形成自己的基线，之后才有比较的依据。

小结

体感变差通常不是单一原因：客户端 bug、渠道替换、上下文膨胀、提示方式、模型版本更替都可能参与其中。按「先查自己能控制的、再查渠道、最后才怀疑模型本身」的顺序排查，成本最低。真正的解决办法不是找到一个「永远聪明」的模型，而是把任务拆到可验证的粒度，让每次输出的对错有客观标准——这样无论模型怎么变，你的工作流都不会跟着一起崩。