在 SlopCodeBench 基准测试上评测 Opus 5 模型
Hacker News 摘要原标题：Benchmarking Opus 5 on SlopCodeBench
这篇文章详细介绍了一项关于 AI 编程模型能力的评测。作者针对 Claude 家族的新模型（Opus 5、Sonnet 5、Opus 4.8）在 SlopCodeBench 基准测试上的表现进行了深入分析。
核心评测背景
作者认为，目前的 AI 编程评测存在一个严重缺陷：它们往往一次性提供问题的全部需求，这与真实的软件开发过程不符。SlopCodeBench 的不同之处在于它是一个长周期的编程基准测试。它要求模型在多个检查点中逐步演进代码库，随着时间的推移，新的需求会不断出现。这意味着模型必须不仅要解决当前问题，还要维护代码库的质量，以便应对未来的变化。
评测模型与方法
评测涉及了三个模型：Opus 4.8、Sonnet 5 以及最新的 Opus 5。作者选取了 SlopCodeBench 中的三个不同难度的挑战：
• circuit_eval（简单）：包含 8 个检查点，涉及电路模拟、CLI 开发、多种文件格式支持和电路优化。
• database_migration（中等）：包含 5 个检查点，涉及数据库迁移工具开发、数据转换、外键管理和回滚功能。
• dynamic_config_service_api（困难）：包含 4 个检查点，涉及 REST 服务设计、架构注册表、变更管理工作流和全局策略保护层。
评测采用了严格通过的标准。这意味着模型产出的代码必须通过所有新旧测试用例。如果模型在第 4 个检查点引入了缺陷，除非它在后续步骤中无意间修复了该缺陷，否则后续所有检查点都将被判定为失败。
评测结果分析
即使是目前最强的模型，在面对需要长期维护的代码任务时表现依然不尽如人意：
• 通过率低下：Opus 5 虽然表现最好，但也仅获得了 24% 的严格通过率。在 17 个总检查点中，它只通过了 4 个。相比之下，Opus 4.8 和 Sonnet 5 的通过率仅为 6%。
• 无法独立运行：没有一个模型能完整地通过任何一个挑战的所有检查点，即使是标记为简单的任务。这表明目前的 AI 模型在无人看管的情况下，尚无法胜任真实世界的持续开发工作。
• 成本与正确性：在 Opus 5 上投入的每一美元确实换取了更多的正确性，但目前的投入产出比还不足以达到完全正确的程度。
代码质量与“废话”指标（Slop Meter）
该评测引入了 41 项指标来衡量代码的质量和“废话”程度，包括代码行数、复杂度、重复度、分解能力和规则违反情况等。
• 复杂度增长：随着检查点的推进，所有模型的代码复杂度都在稳步上升。Opus 4.8 的表现最为极端，其最差函数的循环复杂度在 8 个检查点后飙升了 70%。
• 冗余代码：模型写出的代码中，绝大部分都触发了“冗余”规则。Opus 5 的冗余代码触发比例高达 93%。
• 函数爆炸：Opus 5 编写的函数数量是其他模型的 5 倍。虽然这符合保持函数简短的编程原则，但也带来了巨大的冗余开销。
• 代码重复：在需求开始与初始设计发生冲突时（通常在第 3 个检查点左右），Opus 4.8 的代码重复率从 4.6% 激增至 16.8%。
结论与未来展望
作者指出，代码质量指标虽然有趣，但并不能完全代表代码的可维护性。真正的可维护性体现在模型是否能在后续的检查点中继续成功实施新功能。
目前的 AI 模型在构建单次任务时表现优异，但在“熄灯运行”（无人干预）的持续迭代场景下仍显笨拙。作者认为，如果未来某个模型能在 SlopCodeBench 这类衡量长期迭代能力的测试中获得 80% 以上的得分，我们才能真正放心地让 AI 独立接管代码库。
此外，作者还提出了一个有趣的思路：使用最强的模型编写前几个检查点的代码，然后观察稍弱的模型（如 Sonnet 或 Haiku）是否能基于这些代码完成后续任务。这种方法可以更清晰地检验强模型产出的代码是否真的易于理解和修改。