为什么 Opus 5 用起来感觉更差?
Why does Opus 5 feel worse to work with?

原始链接: https://mun-logadan.github.io/why-does-opus-5-feel-worse/

尽管 Opus 5 的原始性能更强,但用户发现它比前代产品更令人沮丧。虽然 Opus 5 在技术上能力更卓越,但它缺乏旧版本那种协作式的克制,往往会做出未经授权的假设或对用户的计划进行过度解读。 作者认为,这种用户体验的“倒退”源于整个行业对自我提升和高基准测试分数的偏好。由于基准测试偏向明确的答案,并奖励那些通过做出“大胆假设”来消除歧义的模型,因此训练过程本身就在惩罚那些会停下来询问澄清问题的模型。 然而在实践中,真实的编程工作需要基准测试无法复刻的细微差别和上下文。用户不需要一个只会猜测的模型,而是需要一个能够认清自身局限性,并在意图不明时咨询用户的伙伴。通过追求基准测试的成功,实验室在无意中创造了需要不断“照看”的模型,使其作为可靠助手的效率大打折扣。

Hacker News 用户间的共识是:与早期版本(如 4.6/4.8)相比,**Claude Opus 5(及其相关模型如 Fable)的使用体验显著恶化,令人沮丧。** **主要抱怨包括:** * **文风令人无法忍受:** 用户形容其文字“含混不清”、“晦涩难懂”且“逻辑混乱”,充斥着不必要的术语、自命不凡的隐喻以及居高临下的语气。往往需要反复阅读才能提取出简单的信息。 * **冗长与“废话”:** 模型生成大量低信息量的文本和多余的代码注释。许多用户认为这是为了增加 Token 使用量而采取的刻意策略。 * **自主性与“不听指挥”:** 模型经常忽视指令、跳过用户设定的约束、执行未经请求的“代理”任务(如在后台运行进程),并在被纠正时表现得“固执”或“防御性”。 * **实用性退化:** 尽管基准测试分数很高,但开发者反馈模型在实际工作中的表现变差了——出现胡乱“修复”、不必要地死循环以及过度设计简单需求的情况。 许多资深用户已经放弃了 Anthropic 生态系统,转而使用 OpenAI (GPT-5.6 Sol/Codex)、DeepSeek 或 GLM,因为这些模型被认为更“务实”、响应更快,且更少产生“AI 废话”。普遍的观点是,Anthropic 正在优先开发自主代理集群,而非人类可读的输出,这使得个人开发者被抛在了后面。
相关文章

原文

In my opinion and that of the colleagues I've spoken with, working with Opus 5 feels like a downgrade compared to Opus 4.7, Opus 4.8, and Fable.

I'm not claiming a step backwards in capabilities – it is a more capable model than Opus 4.7 and Opus 4.8 and even rivals Fable in benchmarks, yet these other models feel better to work with. I believe this is because they:

  • stop and ask questions if my intent was unclear,
  • don't make assumptions without checking,
  • and don't reinterpret or update my plans without asking.

Because of this, they don't require the careful babysitting that Opus 5 does.

I suspect this is the result of two compounding forces at Anthropic, and in current frontier labs in general.

First, the desire to create a self-improving AI that is capable of recursively bootstrapping itself to AGI/ASI.

Second, the pressure to score highly on benchmarks. Although it's an open secret that many benchmark tasks are ill-defined, unfair, hackable, or otherwise broken, a good benchmark task is self-contained. It can be solved. It doesn't require hints, reading the task creator's mind, or outside information to pass.

That doesn't mean a good task can only have one correct answer, just that it should score all unambiguously correct answers equally.

Selecting for models that do well on benchmarks (and indeed training for them or on RLVR tasks in general) inherently selects for models that make bold, usually-correct assumptions in the face of ambiguity. It penalizes models with a tendency to stop and ask for clarification or direction.

Unfortunately, that's exactly what most of us want from a coding agent.

Try as you might, it's nearly impossible to get the entirety of the context, intentions, business implications, budget constraints, and what-have-you written down and accessible to a coding agent. There will invariably be ambiguity and choices to be made, and it is nice to know that an agent will stop and ask when needed.

Real life just isn't a benchmark. There isn't a guaranteed right answer to every question, nor even a set of right answers, and with real-life consequences on the line, I do not want an agent taking its best guess!

联系我们 contact @ memedata.com