Opus 5更强了，写代码却更费人盯

有开发者整理自己和同事的使用感受后指出：和 Opus 4.7、Opus 4.8 以及 Fable 比起来，和 Opus 5 协作更像“退步”。这不是说它能力变弱了——作者明确承认它比 4.7、4.8 更强，基准表现也能和 Fable 掰手腕——而是它用起来更需要人盯着，没那么省心。

背后被点到的矛盾很具体。基准题往往是封闭、可判定、能一次做完的任务，训练和筛选会偏向那种遇到含糊处也敢大胆假设、而且多数时候猜对的模型；反过来，会停下来问清楚、等方向的模型，在这种评分逻辑里容易吃亏。前沿实验室又同时扛着自改进、往更高能力冲的压力，这两种力叠在一起，就容易把模型往“敢下结论”的方向推。

问题在于，真实写代码很少像基准那样干净。需求意图、业务边界、预算约束、未写进上下文的默认项，很难一次全塞进提示词里；总会有歧义和取舍。作者想要的，恰恰是代理在必要时会停下来问，而不是在有真实后果时自作主张猜一个“看起来最像对的答案”。

这也把日常工具选择的分歧摊开了：基准分数更高，不等于协作手感更好。换模型、调工作流、加审查节点时，若只看榜单，可能忽略“是否还要人持续看管”这件事；而模糊需求多、改动代价大的场景里，敢猜的模型未必更省事。材料停在作者的使用感受和机制推断上，没有给出官方回应或可量化对比。