在 SlopCodeBench 上基准测试 Opus 5，我们获得了更好的基准测试。我之前写过类似的话：一个模型维持代码质量的能力没有好的基准测试。 这并不完全真实。我最喜欢的就是揭示一个好的开头。上周五，我深入研究了 SlopCodeBench，这是 UW Madison 的 @GOrlanski 实验室发布的一个新的（2026 年 3 月）长期代码基准测试。它解决了我对编码基准测试最在意的问题——即使是“更大”的复杂基准也会提前透露整个问题：相比之下，SlopCodeBench 中的每个挑战都有多个“检查点”——模型不会提前知道整个问题，而是必须随着新要求的披露逐步演化代码库。这是一篇不错的论文，篇幅不长，你应该读一读。这个基准测试的酷之处在于它是未饱和的——在运行时，最好的模型 GPT-5.4 和 Opus 4.6 的严格通过率分别为 11% 和 17%。在 SlopCodeBench 上基准测试 Opus 5，上周五我通过 SlopCodeBench 的一个子集运行了三种 Claude 模型（Opus 4.8、Sonnet 5 和 Opus 5），并观看了六个小时的实时情况。Opus 5 在技术上胜出，但我认为它们都没有做得很好。我会很快发布更多结果，包括 Fable 和 5.6 Sol 的测试。大标题是：Opus 5 在我运行的小子集基准测试中的得分为 24%——这比 Opus 4.6 在原论文中的 17% 严格通过率高出不多。所有被测模型在每个挑战过程中显示出相当显著的冗长、复杂性和许多其他代码异味指标的增加，Opus 5 在同一组挑战中编写的函数/可调用数量是 Opus 4.8 的五倍。我个人对这个 23% 通过率的解读是，SlopCodeBench 最终给出了一个信号，这是我一直只能凭感觉争论的事情——对于真实形状的软件工程工作，一次构建一个问题时，今天的模型无法在没有引导的情况下运行。我选择的基准子集让我从代码库中挑选了 3 个问题，总共 17 个检查点，难易程度混合的问题被标记为： circuit_eval — 简单（8 个检查点）database_migration — 中等（5 个检查点）dynamic_config_service_api — 难（4 个检查点）最后有一个附录，详细解释了所有 17 个检查点，但我不会把所有内容放在这里。然后，我在所有三种模型中并行运行它们，为每个检查点提供了一个新的上下文窗口。所有模型都得到了相同的提示，并在 Claude 代码平台上运行。 我决定关注的指标是严格通过：所有新内容都是绿色，包括从之前的检查点继承的每个回归测试。如果解决方案存在缺陷，则模型在检查点上失败——通过将模型的输出（用于运行的 CLI 或某些情况下的 API 服务器）与产生的入口点进行一组持出黑箱测试来检测缺陷。模型为 ck1 编写代码，评估平台针对 ck1 运行黑箱测试。模型为 ck2 编写代码，评估针对 ck1 和 ck2 运行黑箱测试等。再一次，严格通过标准意味着，如果模型在检查点 4 中出现问题，它就无法通过后续检查点，因为失败的代码部分会持续向前（除非模型无意中修复了在检查点 4 中出现问题的评估案例，但我们在实践中没有看到这种情况）。在所有 9 次测试中，没有任何模型在任何挑战的结尾时间通过所有检查点，甚至在标记为“简单”的问题上。在运行期间，Sonnet 的第一个检查点成本更高，但到问题 1 结束时，Sonnet 成为了三者中最便宜的（看起来一旦基础搭建完成，工作转变为维护时，成本节省就开始主导）。对于第一个挑战，上一代的模型稳步累积缺陷，Opus 5 在检查点 4 和 5 各存在一个缺陷。在前两个小时内，Opus 5 是唯一至少有任何严格通过的模型——开始时连续通过三个检查点。随着进行，情况发生了变化。Claude 勤奋地更新 HTML。与其他模型相比，Opus 5 在问题 1（circuit_eval）上技术上更好。但在轻松通过前三个检查点后，之后的每个解决方案至少存在一个缺陷（测试用例失败）。最终结果 如果我们的成功定义是“达到最后的检查点而没有缺陷”，那么 Opus 5 在所有三个问题中都失败了，但它的失败等级稍低于其他模型。对于成本与缺陷的报告，我真的讨厌 Claude 的表述，但我决定留下这一句：每美元购买正确性。没有人买到足够的正确性。（显然，这个基准的小子集不能明确告诉我们花更多的钱是否会提高通过率）至于严格通过，Opus 5 获得了四个通过（24% 通过率）（circuit_eval 的前三个检查点，加上 database_migration 的 ck1）。Opus 4.8 和 Sonnet 5 都...