Claude Code 努力程度级别 A/B 测试与用户反馈

Anthropic 在 Claude Code 中对努力程度映射进行 A/B 测试

Anthropic 正在对 Claude Code（版本 2.1.236+）中数值努力程度值如何映射到 "effort" 设置进行服务器端 A/B 测试。在这些测试中，与 "high" 努力程度设置相关的数值可能会被映射到比之前版本更低的数字（例如，100 分中的 10 分），导致一些用户认为模型性能或 "intelligence"（智能）有所下降。

技术实现与官方回应

Claude Code 团队的 Thariq 澄清，这些更改是服务器端 API 服务配置。显示的或记录的数值——例如在 high effort 设置下显示的 "10"——是内部映射，并不一定代表实际努力程度的 0-100 量表。

根据 Claude Code 团队的说法，就实际模型性能而言，用户选择的努力程度级别仍然保持不变。团队坚称，深入的评估已经确认这些映射更改不会影响模型性能。鼓励经历明显退化的用户使用 /feedback 命令并提供其会话 ID 来报告问题。

用户对模型性能的感知

尽管有官方保证，但几位用户报告了较新模型版本输出质量的明显下降，特别提到了 "Fable" 和 "Opus 5"。

• 任务执行效率低下： 一位用户报告称，在 4.6 版本上原本只需不到两分钟即可完成的一个简单的配置文件更新，在 Opus 5 上花费了 43 分钟，涉及了超出请求范围的不必要的 sandbox 和测试套件。
• 离题与过度工程化： 一些用户观察到，与旧模型相比，Opus 5 和 Sonnet 5 在设置为 "high" 努力程度时，往往会产生不请自来的离题内容，特别是在设置为 "high" 努力程度时。
• 模型退化： 一些用户由于感知到 Fable 模型的质量下降，已经降级了他们的订阅或切换到了其他替代模型（例如 Codex 或 GLM-5.3）。

社区关于 AI 激励机制与计费的讨论

该事件引发了关于 LLM 提供商透明度的更广泛的社区讨论。用户对 "enshitification"（产品变得越来越难用以实现利润最大化）的过程以及基于 token 的计费模式同样不透明的性质表示了担忧。

"Why are we allowing billing to take place in tokens that are nebulous and fully controlled by the operators who have no aligned incentives?"

批评者认为，基于 token 而非原始计算或资源使用量的计费模型允许提供商在后端更改模型行为或路由，而用户无法察觉，这可能导致用户在支付更高成本的同时获得较低质量的响应。