Anthropic 疑似在 Claude Code 中降低努力等级

Anthropic appears to be A/B testing reduced effort levels in Claude Code

Anthropic 疑似在 Claude Code 中降低努力等级

最近使用 Claude Code 的用户发现,Fable 模型似乎变笨了。经过排查,问题出在 Anthropic 正在进行的 A/B 测试上。从版本 2.1.237 开始,部分用户的会话被纳入实验组,原本代表最高强度的“high”努力等级,在服务器端被悄悄映射为仅相当于旧版“low”等级的 10/100 数值。这一变更并未在更新日志中说明,导致许多开发者误以为是 t3 code 或自己的应用出现了故障,白白浪费了大量排查时间。这场无声的测试让不少用户感到无奈,直呼 Anthropic 有时实在让人难以忍受。

如果这周你觉得 Fable 变笨了,那并不是你的问题。
  1. pizzafeelsright

    不管 Opus 5 在做什么,都不该发生这种情况。

    提示词是“读取并用新数据更新配置文件”。在 4.6 版本上,这项工作只需不到 2 分钟:读取文件、解析新数据并打补丁。

    Opus 5 的结果:花了 43 分钟拉取容器、运行沙箱、创建测试套件,甚至评估了整个仓库,完全超出了配置文件的范围。

    两者:都只修改了一个文件。

  2. trq_

    大家好,我是 Claude Code 团队的 Thariq。我在 Twitter 上发过这条,现在在这里再发一次:

    我们有时会在 Claude Code 中测试 API 服务配置,然后再正式推出。目前有一个正在运行的测试,它对数值型的 effort(努力程度)值的映射方式有所不同。

    这就是为什么 Claude 可能会告诉某些用户,在高努力模式下它的值是“10”。这个刻度不是 0-100,单看这个数字本身没有意义,你选择的 effort 等级就是你实际得到的 effort。我们进行了深入的评估,确认这不会影响模型性能。

    体验应该是一样的,但如果你看到明显的性能回退,请点击 /feedback 并发送 ID 给我。我会赠送积分。

  3. boredumb

    这不仅仅是 Anthropic 的问题,但为什么我们要允许计费基于一种模糊不清、完全由运营商控制且缺乏对齐激励的 token 呢?

    如果我有用户输入,然后对其进行清洗并注入到提示词中以执行某些操作,我完全不知道这会花多少钱,也没有真正的方法来准确衡量。一个平行的例子是 DigitalOcean 或 AWS,我可以去测量/限制我的计算、文件系统、内存、启动时间等,虽然可能无法精确到最后一分钱分配的 FLOP,但我可以在真实的预算和真实的约束下运行事务。相比之下,对于 LLM,我不得不……先通过分词器预运行一个清洗过的用户提示词,然后让 LLM 猜测它可能会做什么并给出 token 消耗估算,最后再基于这些估算以某种合理的方式为用户采取行动?

    也许我漏掉了什么关于设置现实且静态护栏的方法,但我看不出在大规模场景下,除了向 VC 资金乞求、不断砸钱直到有人想出办法外,有任何严肃的方法能利用 token 计费模型来处理需要用户自由文本输入的事务。

    *澄清一下我刚才的胡言乱语……

    我们应该基于资源使用本身来计费和提供控制,而不是基于一个不透明的 token 概念,更何况我们连控制其资源使用的任何旋钮都调不动。

  4. hpone91

    Thariq 在 Twitter 上的更新:https://x.com/trq212/status/2091247114869432543

    “我们有时会在 Claude Code 中测试 API 服务配置,然后再正式推出。目前有一个正在运行的测试,它对数值型的 effort(努力程度)值的映射方式有所不同。

    这就是为什么 Claude 可能会告诉某些用户,在高努力模式下它的值是“10”。这个刻度不是 0-100,单看这个数字本身没有意义,你选择的 effort 等级就是你实际得到的 effort。我们进行了深入的评估,确认这不会影响模型性能。

    体验应该是一样的,但如果你看到明显的性能回退,请点击 /feedback 并发送 ID 给我。我会赠送积分。”

  5. monideas

    Fable 上的这种现象太糟糕、太明显了,以至于我把 Max 订阅(200 美元)降级到了 Pro(20 美元)。它基本上已经没用了。Codex 5.6 Sol 实际上非常好,我会再开一个账号来获取更多的使用额度。

  6. Insimwytim

    LLM 用户不想付出努力,所以他们把任务外包给 LLM。

    LLM 似乎也不想付出努力!

    这是 AGI 吗?

  7. N_Lens

    我怀疑不仅仅是这样,还有大量关于“橡皮筋式”调整使用限制以及将请求路由到后端不同模型的“优化”。激励机制太强了。

  8. ricardobeat

    我几乎 exclusively 在低努力模式下使用 Opus 5,效果很好。特别是在高努力模式下,它似乎会跑向完全未被要求的旁支末节。Sonnet 5 似乎也是如此。旧模型并没有这种行为。

    仅仅六个月,氛围就发生了翻天覆地的变化,今年二月时,Claude 还是大家最喜欢的 LLM,遥遥领先。

同日更多故事

2026-08-22