出典:Hacker News原文を見る ↗
原文の著作権は出典元に帰属します。当サイトでは収録、翻訳、体裁調整のみを行います。
解説と影響
导读摘要
正文
一篇题为《为什么 Opus 5 用起来感觉更糟?》的文章在 Hacker News 上引发了热烈讨论。作者在文中从自身使用体验出发,探讨了 Claude Opus 5 在日常工作协作中表现不如预期的现象。该帖由用户 numeri 提交,截至报道时已获得 202 个点赞和 188 条评论,显示出这一问题在开发者社区中引起了相当程度的共鸣。
从讨论热度来看,不少用户似乎对新一代模型的实际表现存在类似的感受。原文作者尝试从多个角度分析这一现象的可能成因,而非简单归咎于模型"退步"。原文未提供具体的评测数据或官方回应,讨论更多集中在主观使用体验的层面。值得注意的是,这类"新版本不如旧版本好用"的反馈在 AI 模型迭代过程中并不罕见,往往与用户对模型行为变化的适应成本、特定任务场景下的表现波动,以及期望值调整等因素有关。
在 Hacker News 的评论区中,用户们围绕模型迭代方向、基准测试与实际体验之间的落差等话题展开了讨论。原文未提供评论区的具体观点摘要,但 188 条评论的规模表明,这一话题触及了 AI 工具使用者普遍关心的核心问题:当模型在标准评测中表现提升时,真实工作场景中的"手感"为何可能反而下降。
这一讨论发生的背景是 AI 模型快速迭代的当下,各大实验室以数月为周期推出新版本,用户往往需要在短时间内适应模型行为的变化。对于将 AI 深度嵌入日常工作流的开发者而言,模型在指令遵循、代码风格一致性、错误率等方面的细微变化,都可能显著影响协作效率。原文未提供 Claude Opus 5 的具体发布时间或与前代版本的对比数据。
参考資料
出典原文
Why does Opus 5 feel worse to work with?
Posted on 2026-08-14
:: Source Code
Why does Opus 5 feel worse to work with?
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.
Baseless speculation
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!