在 SlopCodeBench 上对 Opus 5 的基准测试
来自 SlopCodeBench 的基准结果表明，Anthropic 的新 Claude Opus 5 模型在多步骤编码任务上相较于 Opus 4.x 仅有有限提升，同时往往会生成更复杂、更“糟糕”的代码。评论者认为，当前 LLM 在长期可维护性、重构以及避免不必要抽象方面仍然吃力，而 harness 设计和提示词的重要性可能不亚于底层模型本身。许多人呼吁更好的基准、人类基线，以及明确奖励简洁性和代码健康的 RL 信号，尤其是在一些开发者表示在复杂、持续性的工作中更偏好旧模型或 Anthropic 的 Fable 的情况下。
Opus 5 与更早模型的整体反应
- 许多人认为 Opus 5 只是比 Opus 4.8 略好一点，并没有那种“哇”的提升。
- 有些人更喜欢 4.8 的行为和语气；Opus 5 被描述为过度自信、冗长、学院派，会生成“slop”和迂腐的审查意见。
- 少数人报告了真实的生产力提升，尤其是把 Opus 5 medium 作为更快、更便宜的 4.8 x-high 替代品，而把 Fable 留给最难的任务。
SlopCodeBench 与代码可维护性
- SlopCodeBench 被称赞为少见的基准，它测试的是纵向行为：多次功能添加以及代码质量如何演变。
- 有人提到 Opus 5 的严格通过率约为 24%，而 Opus 4.6 约为 17%；一些人认为这是幅度不大但确实存在的提升，另一些人则认为仍然低得无法接受。
- 关键担忧是：模型会随着时间增加大量函数和复杂度；当前的 RL/基准很少惩罚复杂性，因此模型不会学会简化。
Harness、提示词和代理工作流
- 一些人认为，“slop”通常是 harness/系统提示词问题：给代理太多自由、又不限制修改位置，就会积累出一团乱。
- 静态“skills”或模板化工作流有时会降低 SlopCodeBench 上的表现，可能是因为浪费上下文，并在绿地任务上强迫使用次优工作流。
- 其他人报告了成功经验，包括：
- 将修改限制在狭窄的接口边界上。
- 定期进行专门的“refactor turns”或全代码库审查轮次。
- 在项目配置文件中明确要求偏好简洁和 DRY 代码。
模型行为、退化与基准测试
- 一些用户觉得模型（包括 Fable）在发布后会退化，可能是由于量化之类的降成本改动；另一些人引用公开追踪器，显示总体上大多是单调改进。
- 有人担心实验室可能会对类似基准的输入做特殊处理，从而让公开基准变得不那么可信。
- 参与者呼吁更稳健的评测套件（包括可维护性指标），并指出大多数团队缺乏构建这些套件的专业能力。
“slop” 真的重要吗？
- 有个讨论提出一个问题：如果缺陷依然很少、客户也满意，那么丑陋/复杂是否重要？
- 回应直接把这与长期变更成本和 AI 代理效率联系起来：混乱的代码对人类和模型来说都更难修改。
- 据称最近的论文（被提及但未详细展开）发现，“更干净”的代码能提高代理的导航和效率。