Anthropic滑跪认错,Claude暗中降智实锤

marsbit发布于2026-08-24更新于2026-08-24

文章摘要

近日,开发者 argofowl 发现 Claude Code 版本 2.1.237 后存在异常:用户在界面选择最高推理档位“high”时,系统后台实际发送的请求参数值为“10”(该数值曾对应旧版的“low”档位)。调查显示,这是 Anthropic 在特定版本中进行的一项“压缩effort数值刻度”A/B测试,但官方未在更新日志中说明,导致开发者耗费大量时间排查自身代码问题。 此事引发AI社区广泛讨论,大量用户自发测试并抱怨Claude模型“变笨”。随后,Claude Code工程师Thariq Shihipar回应称,该实验仅改变了数值映射方式,不影响模型性能,并强调团队已通过评测确认。 与此同时,用户及科技博主指出Claude Opus 5模型也存在问题,表现为输出敷衍、犯低级错误、频繁自我纠正且表现不稳定。工程师承认Opus 5确实存在性能波动问题,并表示正在优先处理。 此次事件凸显了AI行业的一个普遍困境:大模型的官方基准测试分数持续亮眼,但用户的实际使用体验却可能下降,两者出现系统性脱钩。更深层的问题是,大模型的更新与调整缺乏透明度,服务端可能随时进行A/B测试、量化方案调整等,而用户只能依赖主观体感来判断变化,这对开发者信任和模型作为基础设施的稳定性构成了挑战。

Claude一夜变笨,全网吵翻了!

就在昨天,开发者argofowl花了整整一个下午,差点把Claude Code翻了个底朝天。

他一路排查,先是怀疑是t3 code崩了,接着又以为自己的代码出现了bug。

查到最后,他甚至开始怀疑——难道是自己把Mac搞坏了?

当argofowl最终打开API的真实请求日志时,一切真相大白,里面赫然写着一个数字「10」。

然而,在Claude Code后台,他明明选的是「high」,最高档推理程度。

谁曾想,Claude Code的更新日志,一个字都没写。

推理high变成10

Claude Code变笨曝光

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测试,所以不是人人都会撞上。

对开发者来说,这才是真正的痛点。模型强一点弱一点,还能忍。

但你把我拉进了实验组,却不打算告诉我:那我这一下午到底在debug什么?是在调自己的代码,还是在调你的A/B测试?

没想到,科技博主Chubby转发之后,AI圈直接炸了——

看起来,Anthropic把模型悄悄调笨了,却没告诉任何人。

一时间,X上「Claude变笨了吗」的自测帖子刷屏。

有人贴出同一段prompt在不同版本下的输出对比,有人翻出自己两周前的会话记录做逐行diff。

Anthropic认错,工程师下场

面对这场风暴,Claude Code工程师Thariq Shihipar的回应来得很快。

我们有时候会在Claude Code里先测试API的服务配置,再决定要不要全量推。

现在跑的这个实验,只是把effort的数值映射方式改了。所以有些人会看到Claude说自己是「10」。

关键是,这个刻度不是0到100,那个数字单独看没有任何意义,你选的effort就是你拿到的effort。

他强调,团队做了深入的评测来确认,这不影响模型性能。

Opus 5大降智,是真的

刚解决掉Fable的问题,Chubby又直言,Opus 5现在感觉像是一次显著的降级。

它总是敷衍了事,频犯低级错误。一旦被指出没按指令执行,它就只会机械地回复那句——

你说得对,是我疏忽了。翻来覆去,没完没了。

其实,早在几天前,有人就发现了Opus 5明显「降智」的问题。

除了上面提到的问题,它还会制造bug,然后耗费大量时间修bug,同一任务中反复自我纠正.......

在被网友追着问了一圈之后,工程师Thariq公开承认——Opus 5是个「表现很不稳定」的模型,忽高忽低,不稳定。

团队内部正在为努力解决这一问题,这对我们来说是最高优先级。

跑分永远向上

体感一路向下

Opus 5这场风波,撕开的其实是整个行业最尴尬的一道口子:

跑分和体感,正在系统性地脱钩。

一边是亮眼到近乎无可挑剔的成绩单:综合得分82.72、SWE-bench Pro 79.2%、Terminal-Bench 86.7%。

另一边,却是用户截然相反的真实感受:「啰嗦」「偷懒」「爱抬杠」。

最荒诞的地方在于,两种评价同时出现在了Opus 5身上。

而且,「模型变笨」也并非Anthropic一家的问题。

如今,大模型的版本更新,正在变成整个AI行业最不透明的黑箱。

传统软件有语义化版本号,有更新日志,也有回滚机制。开发者可以清楚地知道,自己正在使用哪个版本,发生了哪些变化。

大模型,就不同了。

同一个模型名称之下,服务端可能随时进行A/B测试、更换量化方案、调整模型路由,甚至改变推理资源。

人们手里唯一的仪表盘,只剩下自己的体感。

偏偏直觉,是最容易被驳回、也最难被证伪的东西。

这场风波最大的价值,是把行业长期存在的一道暗伤,彻底摆上了台面:

当模型成为基础设施,稳定性就是一份信任契约。跑分可以用来营销,稳定性只能靠一次次兑现。

参考资料:

https://x.com/trq212/status/2091252347913773169?s=20

https://x.com/kimmonismus/status/2091178321669198014

本文来自微信公众号“新智元”,作者:ASI启示录,编辑:桃子

相关问答

Q开发者argofowl是如何发现Claude Code推理程度被更改的?

A开发者argofowl在排查问题时,最终打开了API的真实请求日志,发现其中显示着一个数字'10',而他在Claude Code后台明明选择的是'high'(最高档)推理程度。这揭示了后台映射已发生变更。

Q根据文章,Claude Code 2.1.237版本及以上的'high'推理程度具体被映射成了什么数值?这个数值过去对应哪一档?

A从Claude Code 2.1.237版本开始,'high'推理程度被模型读取为'10 out of 100'。而这个数字在过去对应的是'low'档的数值。

QClaude Code工程师Thariq Shihipar是如何解释这次'effort数值刻度'实验的?

A工程师Thariq Shihipar解释称,这是一个改变effort数值映射方式的实验,所以部分用户会看到显示'10'。他强调这个刻度并非0到100的线性对应,那个数字单独看没有意义,用户选择的effort级别就是实际获得的effort级别。团队已通过深入评测确认这不影响模型性能。

Q关于Opus 5模型,文章提到了用户反馈的哪些具体问题?

A用户反馈Opus 5模型存在以下问题:感觉像是一次显著的降级,经常敷衍了事、频犯低级错误;在被指出未按指令执行时,只会机械地重复道歉话语;此外,它还会制造bug,然后在同一任务中耗费大量时间反复自我纠正,表现非常不稳定。

Q文章认为'模型变笨'风波暴露了AI行业的什么根本问题?

A文章认为这场风波暴露了AI行业一个根本问题:大模型的跑分(基准测试成绩)与用户的实际使用体感正在系统性地脱钩。同时,大模型的版本更新缺乏透明度,成为一个'黑箱'——服务端可能随时进行A/B测试、调整配置而无需明确告知用户,导致用户只能依赖不稳定且难以证伪的直觉来判断模型变化,这损害了作为基础设施的模型所应提供的稳定性和信任。

你可能也喜欢

Hyperliquid的合规之路:从无需许可到许可制HIP-3

Hyperliquid(基于HyperCore的去中心化交易基础设施)因其无需许可、用户自托管的特点,与美国针对期货交易的严格市场结构法律(涉及注册交易平台DCM、清算所DCO和经纪商FCM)存在根本冲突,因此一直对美国市场进行地理封锁。 为了解决此困境,Hyperliquid成立了政策中心(HPC),积极游说美国监管机构(CFTC、SEC),主张将Hyperliquid视为“中立基础设施”。其核心提议是:允许已受监管的实体(如经纪商、交易平台)在履行其原有KYC、市场监控等合规义务的前提下,利用Hyperliquid的底层技术(如HyperCore)来构建和运营产品,而非要求协议本身改变其无需许可的特性。 作为这一合规路径的实例,Hyperliquid已在测试网推出具备许可权限的HIP-3部署者功能。此类部署允许受监管实体创建仅对白名单用户(即已完成KYC的合规用户)开放的市场,并拥有对用户账户执行特定操作(如强制平仓)的权限,从而模仿传统金融中FCM的职责。尽管这些合规市场会形成独立的订单簿,但通过白名单做市商的桥梁作用,它们仍能共享Hyperliquid主市场的流动性。 总之,Hyperliquid的战略目标并非直接向美国用户开放其原生免KYC前端,而是通过提供工具,让合规机构能在其底层上构建符合美国法规的产品,从而为美国投资者提供间接参与其生态的合规通道,同时保持协议本身的中立性与开放性。

marsbit1小时前

Hyperliquid的合规之路:从无需许可到许可制HIP-3

marsbit1小时前

交易

现货
活动图片