Anthropic 旗下 Claude Code 因一次后台实验设置引发开发者不满。开发者 argofowl 披露，他在排查 Claude Code 表现异常时发现，明明在后台选择了「high」推理程度，但 API 真实请求日志里却出现了数字「10」，相关变化并未写入 Claude Code 更新日志。
据 argofowl 说明，他为此花了一个下午排查问题，期间一度怀疑是 t3 code 崩溃、自己的代码出现 bug，甚至怀疑 Mac 设备本身出了问题。直到打开 API 的真实请求日志，他才看到这个数字，并将问题指向 Claude Code 的推理设置。
「high」被读成 10，引出后台实验
argofowl 发现，从 Claude Code 2.1.237 开始，模型会把「high」推理程度读成 10 out of 100，而这个数值过去对应的是「low」档。
随后，有人进一步梳理发现，Anthropic 将 Claude Code 2.1.236 及以上版本中的 Fable 5 会话纳入了一项「压缩 effort 数值刻度」实验。按照原文说法，老版本以及 Opus 5 不受这项实验影响。
由于这项调整大概率属于 A/B 测试，并非所有用户都会遇到同样情况，争议很快集中到透明度问题：开发者被拉入实验组，但没有提前获知，也没有在更新日志中看到说明。
科技博主 Chubby 转发相关内容后，这一问题在 AI 社区迅速扩散。X 平台上出现大量围绕「Claude 是否变笨」的自测帖，有用户贴出同一段 prompt 在不同版本下的输出对比，也有人翻出自己两周前的会话记录逐行比对。
工程师回应：数字单独看没有意义
面对外界质疑，Claude Code 工程师 Thariq Shihipar 很快作出回应。他表示，团队有时会先在 Claude Code 中测试 API 的服务配置，再决定是否全量推送。
Thariq Shihipar 解释称，这次运行中的实验只是修改了 effort 的数值映射方式，所以部分用户会看到 Claude 说自己是「10」。他还表示，这个刻度并不是 0 到 100，因此该数字单独看「没有任何意义」，用户选择的 effort 级别，实际获得的仍是对应的 effort。
他强调，团队已经做过深入评测，结论是这项调整不会影响模型性能。
另一场争议指向 Opus 5 表现波动
就在 Fable 5 的设置问题引发争议后，Chubby 又把矛头转向 Opus 5，称该模型当前「像是一次显著的降级」。按照原文描述，用户对 Opus 5 的不满主要集中在敷衍、低级错误频发，以及在被指出没有按指令执行后，反复机械回复「你说得对，是我疏忽了」。
原文还提到，几天前已经有人注意到 Opus 5 存在明显「降智」现象。除前述问题外，它还会制造 bug、花费大量时间修 bug，并在同一任务中反复自我纠正。
在网友持续追问后，Thariq Shihipar 公开承认，Opus 5 是一个「表现很不稳定」的模型，状态会忽高忽低。按照他的说法，团队正在努力解决这一问题，而且这是当前的最高优先级。
跑分与用户体感出现脱钩
这场围绕 Opus 5 的争议，也把一个长期存在的问题再次摆到台前：模型跑分与用户体感正在脱钩。
原文列出的成绩单显示，Opus 5 的综合得分为 82.72，SWE-bench Pro 为 79.2%，Terminal-Bench 为 86.7%。但与这些成绩同时出现的，是用户截然不同的主观感受，包括「啰嗦」「偷懒」「爱抬杠」等评价。
也就是说，同一模型一边拿出亮眼测试结果，一边又在真实使用中遭遇大量负面反馈。
版本更新透明度再成焦点
原文认为，「模型变笨」并非 Anthropic 一家独有的问题。随着大模型服务持续迭代，版本更新正在变成整个 AI 行业中不够透明的黑箱。
与传统软件相比，后者通常有语义化版本号、更新日志和回滚机制，开发者能够知道自己正在使用哪个版本，以及具体发生了哪些变化。大模型则不同。在同一个模型名称之下，服务端可能随时进行 A/B 测试、更换量化方案、调整模型路由，甚至改变推理资源。
在这种情况下，用户往往只能依赖自己的实际体感来判断模型是否发生变化，而这种判断又最容易被质疑，也最难被证伪。
这场风波把一个长期存在的问题公开化了：当模型逐渐变成基础设施，稳定性本身就构成了信任的一部分。原文指出，跑分可以用于营销，稳定性则只能靠持续兑现。
参考信息与来源
文中提到的公开讨论包括 Thariq Shihipar 在 X 平台上的回应，以及 kimmonismus 相关帖文。
- https://x.com/trq212/status/2091252347913773169?s=20
- https://x.com/kimmonismus/status/2091178321669198014