Opus 5 在 SlopCodeBench 测试：通过率 24%，代码质量与复杂度表现几何？-CSDN博客

在 SlopCodeBench 上对 Opus 5 进行基准测试

之前觉得目前没有好的基准测试来衡量模型维护代码库质量的能力，其实不完全对。上周五深入研究 SlopCodeBench，它是威斯康星大学麦迪逊分校 @GOrlanski 实验室在 2026 年 3 月发布的长周期编码基准测试，解决了编码基准测试提前透露整个问题的困扰。其每个挑战有多个“检查点”，模型需随新需求逐步“进化”代码库。该基准测试是“不饱和”的，测试时 GPT - 5.4 和 Opus 4.6 的严格通过率分别仅为 11% 和 17%。

在 SlopCodeBench 上测试 Opus 5

上周五让三个 Claude 模型（Opus 4.8、Sonnet 5 和 Opus 5）在 SlopCodeBench 的子集测试并观察六小时。技术上 Opus 5 表现最佳，但整体都不太好。Opus 5 在小基准子集通过率为 24%，仅比 Opus 4.6 的 17% 略高。每个挑战中，测试模型的冗长性、复杂性等代码质量指标显著增加，Opus 5 编写的函数/可调用对象数量是 Opus 4.8 的五倍。24% 的通过率表明，目前模型在实际软件工程工作中，一次解决一个问题时，还不能无人干预可靠运行。

基准测试子集

让 Claude 从仓库选 3 个问题共 17 个检查点，涵盖易、中、难不同难度：circuit_eval（简单，8 个检查点）、database_migration（中等，5 个检查点）、dynamic_config_service_api（困难，4 个检查点）。对三个模型并行测试，每个检查点用全新上下文窗口，所有模型用相同提示，在 Claude 代码测试框架运行。关注指标是“严格通过”，若模型解决方案有“缺陷”则判定该检查点未通过，通过黑盒测试检测缺陷。在 9 次测试中，没有模型能在任何挑战中通过所有检查点。

测试过程

Sonnet 模型首检查点成本高，首个问题结束时成成本最低。首个挑战中，上一代模型缺陷累积，Opus 5 仅在检查点 4 和 5 各出现一个缺陷。测试前两小时，Opus 5 是唯一有严格通过记录且连续通过三个检查点的模型。但连续通过前三个检查点后，后续解决方案至少有一个缺陷。

最终结果

以“无缺陷地通过最后一个检查点”为成功标准，Opus 5 在三个问题上都失败，但表现比其他模型略好。成本与缺陷报告中有“每一分钱都换来了正确性，但没人花够钱”的说法。Opus 5 通过 4 个检查点（通过率 24%），Opus 4.8 和 Sonnet 5 都只通过 1 个检查点（通过率 6%），均为 database_migration 的检查点 1。这表明对下一代模型而言，这是不饱和的基准测试。

代码质量评估

几乎所有编写的代码都触发了冗余检测

所有模型绝大多数代码行至少触发一个基准测试冗余规则，Opus 4.8 为 98%，Opus 5 为 93%，Sonnet 5 为 89%。各模型被标记为冗长的代码行比例从检查点 1 的约 65% 增加到检查点 8 的 80%。尝试将规则应用到 TypeScript 单仓库，因 SlopCodeBench 检测器仅支持 Python，让 5.6 - Sol 生成规则子集，只生成 76 个冗余检测器。Opus 5 自动生成解决方案每千行代码冗余触发次数是经过 99% AI 生成且仔细审查的 TypeScript 单仓库的 11 倍多。

这些模型编写了大量函数

Opus 5 编写函数数量是其他两模型的 5 倍。Opus 4.8 编写单用途函数比例近 50%，Sonnet 5 单用途函数占比最高达 71.5%。个人不认为编写大量小函数是坏事，曾是《代码整洁之道》的忠实信徒。

所有模型的复杂度随时间增加

约一年来凭直觉认为模型会随时间降低代码库质量，现在有数据支持。没有模型能在所有挑战中不增加复杂度通过所有检查点。Opus 5 平均复杂度最低，但编写 2000 个函数。Sonnet 和 Opus 4.8 应对复杂度增加选择增大单个函数规模，Opus 4.8 复杂度增加 70%，单个最差函数圈复杂度达 93。Opus 4.8 重复度从 4.6% 增加到 16.8%，检查点 3 是转折点。Opus 5 重复度基本平稳，从 2.41 到 2.64。若相信重复度是重要指标，过去约三个月有一定进步，但并非非黑即白的问题。

更优的软件质量评估标准

代码质量指标不能完全说明问题，模型易提高其得分。“通过逐步披露的规范的所有验证”是评估“模型能否长期维护代码库”的现实标准，严格通过率高表明模型擅长构建易维护代码库。随着 Fable / Sol 等前沿模型在调试和逆向工程方面能力卓越，成本、时间和令牌使用等指标评估可能更重要。“在 8 个检查点内完成一个完整功能的开发”虽慢，但可无人值守执行且能通过确定性验证，比“另一个模型是否认为这段代码整洁”的评估方式好。可让前沿模型完成前 N 个检查点代码编写，看较弱模型能否完成第 N + 1 个检查点，放大判断智能模型维护代码库能力的信号。

可衡量的指标

SlopCodeBench 为凭经验判断的事情提供依据，目前模型在实际软件工程工作中不能无人干预可靠运行。它是值得关注的未来指标，若模型在该基准测试通过率达 80% 以上，会更有信心让其无人干预工作。不预测何时能达到，重要的是有可靠信号判断趋势。

下一步计划与改进方向

将深入研究 SlopCodeBench 问题，挑选与日常开发工作匹配的问题。可同时进行 9 个并行测试，1 - 2 小时完成，而非 6 小时。尝试将规则应用到 TypeScript 单仓库，因仅支持 Python，移植规则到其他语言会很有趣。除关注严格通过率和总缺陷数，探索基准测试更多维度更有意思。目前测试结果未评估在软件开发流程约束条件下模型的代码质量和成功率。