Opus 5能力更强,却被指更难协作

一名开发者在2026年8月14日的博客里,把Opus 5拉出来和三个对照组比:Opus 4.7、Opus 4.8、Fable。基准分数上,四者打平,谁也没落后。

但作者和几位同事实际用下来的感受是,协作变差了。差别不在能力,而在遇到模糊指令时的反应——旧模型会先停下来确认,Opus 5更倾向自己猜一个答案就往下做,甚至悄悄改写用户定好的计划。

Opus 5跑分不输,协作却被指"更难配合"

三个模型摆在一起,差别很具体。

能打和好用,这次被拆成了两件事。一个更"自信"的编码代理,假设方向错了,可能比一个会追问的代理造成更大的实际损失,尤其是在直接跑production代码的场景里。

基准测试奖励果断作答,真实项目需要主动澄清

作者给出一个猜测:好的基准题目通常是自洽的。不需要提示,不需要猜出题人的心思,标准答案就写在题目里。

这种设计天然筛选出敢在模糊情况下下判断的模型,而不是那种一遇到不确定就停下来问的模型。

真实项目正好相反。业务目标、预算约束、团队内部的隐性共识,很少能完整写进需求文档交给编码代理。这些空白,过去靠模型主动开口问来补。

作者把这归因于两股力量:一是行业训练"自我改进型AI"、追求自主推理的方向,二是基准排名带来的现实压力。这两条他自己也标注为"没有实证的猜测",不是Anthropic官方披露的训练策略。

这份观察目前只是一位开发者和身边同事的主观体感,没有系统化测评,也没有第二方复现数据。能不能扩展到所有场景,还看不清。

对开发者和工程负责人意味着什么

对一线开发者,直接影响是审查方式要变。在涉及生产环境、数据操作的关键节点,手动加一道确认,不要让模型自主往下走太远。

对工程负责人,现实做法是换模型前先做一次小范围试跑,挑边界模糊、依赖隐性业务上下文的任务,观察它是开口问,还是直接给方案。分数能证明模型强不强,但决定要不要放权的,是这个更细的行为习惯。

如果试跑结果显示Opus 5确实更少确认,团队可以考虑把它留给边界清晰的任务,模糊需求高的项目继续用旧模型,而不是一刀切全面切换。

接下来值得盯的,是有没有更多开发者报告类似体感,以及Anthropic会不会在后续版本里收敛这种"自信"倾向。目前只有这一份样本,还谈不上定论。