Opus 5在SlopCodeBench实测：正确率换代码量
Benchmarking Opus 5 on SlopCodeBench
我亲自跑了三个Claude模型在SlopCodeBench上的表现。这个新基准测试模拟了真实开发中需求逐步披露的场景，不再一次性给出全部问题。结果显示，Opus 5虽然以24%的严格通过率领先，但代价是代码量激增，生成的函数数量是Opus 4.8的五倍。所有模型最终都未能无缺陷地完成挑战，这揭示了一个残酷现实：目前的AI模型在真实软件工程场景中，仍无法实现完全无人值守的自动化开发。
每一美元都买到了正确性，但没人买得足够多。
HN 评论区
118- robbomacrae
太棒了！我最近也刚好看到了这篇论文和基准测试。这是我找到的第一个开始关注那些我认为在生产代码编写中一直至关重要的非功能性需求和长期需求的基准测试。
现在模型已经足够强大，能够解决~大多数单点时刻的问题，所以这一点尤其相关。
一些相关但零散的思考：
- 确定性评分真是太好了
- “可维护性”到底是什么，可能是一个由这些信号描述的高维空间；要搞清楚这个空间在哪里，可能需要进行一些人工标注
- 另一个我一直在思考、且越来越常被提及的信号是系统的状态空间；我最近看到形式化方法（formal methods）出现的频率越来越高
- WilcoKruijer
这符合我对 Opus 5 的体验：相比 Opus 4.8 有了不错的提升，但并没有像 Fable 那样带来革命性的感觉。
我现在已经把 Opus 4.8 xhigh 替换成了 Opus 5 medium，用的 token 更少了，速度也更快了。我能理解有人会对它的写作风格感到恼火，但对于完成工作来说，这真的完全不影响我。我真的很享受使用它的过程。
- jrflo
我很想看看原始的测试结果。
我怀疑大多数模型都会错过包含 `default_value` 的 `database_migration` Checkpoint 2 测试，因为它既可以被解释为 JSON 字面量，也可以被解释为 SQL 表达式。
可能还有其他测试也会因为论文中未提及的原因而容易失败。
我觉得一个很酷的实验是：在依赖关系允许的情况下，调整功能实现的顺序（例如：先做 checkpoint 3，然后是 2，接着是 5，最后是 4）。这样就可以考虑到某些 checkpoint 比其他 checkpoint 更难的情况。
- dmrivers
我有一段时间没加入你们的聊天了，但很高兴看到你把这一切整理了出来。我真心觉得 Opus 5 提升并不大。我唯一感到“哇”的时刻是 Opus 4、4.6 以及 Fable，那是在特朗普政府进行“脑叶切除”之前。
- Vgoose
写得真好。过度的函数调用（excessive function thing）一直让我抓狂；我在 Claude.md 里明确地防范了这一点。
我发现模型通常不擅长在实现新功能的同时管理重构和复杂度。但我曾尝试过一种“半放手”的方法取得了一些成功：先拆解任务，然后在第二遍中对抗性地提示模型，让它去寻找新的粗糙边缘、复杂度区域，或者可能简化代码库的重构点。
所以，我很想看到这个基准测试，但其中穿插一些定期的“重构回合”（refactor turn）。
同时也非常期待看到 Fable 的基准测试结果；就个人经验而言，那是唯一一个我觉得可以真正信任、无需仔细审查其代码的模型。