SlopCodeBench 复测：GPT-6 Astra 严格通过率 16.3% 领先 Opus 5.5

注：本文是我们在2026年10月发布的报告的第一部分：第四季度 slop 现状。@gorlanski 和 SlopCodeBench 团队将在第二部分分享他们的分析，并对 slop 模式做更定性的深入探讨。关于我此前对 SlopcodeBench 的几篇报告，参见 benchmarking the new frontier 和 benchmarking fable 5, sol, kimi k3，两篇都深入剖析了 SCB 的核心结构，以及它的每道挑战如何被拆分为多个检查点。

今年5月，SCB 上一次发布时，gpt-5.5 在 slopcodebench 上的严格通过率为 14.8%。本月，我让前沿模型跑完了同样的测试活动，得分最高的是 gpt-6 astra，达到 16.3%。

什么是 SlopCodeBench

更多内容见上面的链接，这里简单回顾一下：在 SlopCodeBench 中，模型要在同一个代码库中连续完成一系列编程挑战，并在单道挑战的 3-8 个检查点中一路继承自己此前的工作。

结果

虽然该基准会报告多种不同的通过率，但我们重点关注的是严格通过率——即模型在多少个检查点中通过了全部测试用例，同时仍然通过所有回归测试。我们在此测试的前沿模型严格通过率落在 12.2-16.3% 区间：

Opus 5.5

Fable 5.1

SOL 6 和 6.1

Astra

GLM 5.3

作为对照，该基准还报告了一个不那么严格的“核心通过率”，这些模型的核心通过率落在 65.8-74.0%。

这里有一件有意思的事，我后面会深入探讨——对某些较新的模型来说，中等推理强度（medium effort）的表现优于 XHigh。在三个完整对照中，XHigh 的成本是 Medium 的 2.11-4.22 倍，而最值得注意的是，opus 5.5 在 medium 强度下的表现反而比 xhigh 更好。（注：就本基准而言，Astra/Sol 系列模型在 xhigh 下*确实*似乎表现更好）

过去几个月里，我跑了该基准的部分子集。一开始是三道题，后来试了六道。这一次：36 道题，每个设置 196 个检查点。由于此前用的是子集，我们无法用更早的子集来衡量进步或退步。完整基准让我们可以把这些结果与官方研究结论作比较。这也意味着，虽然上述两次中较晚那次得到的 fable 5 的 30% 分数很有意思，但它在这里不可比，因为它只覆盖了 36 道题中的 6 道。

更多关于 SCB

SlopCodeBench 分阶段向编程智能体提出一个问题。它先写一个程序，然后收到新需求，并修改已有代码。后续检查点会同时测试新行为和旧行为。

这里的思路是，这更贴近软件的真实构建方式——在构建过程中需求不清晰且不断演变。

对于想复现这些结果的人：我使用了固定版本的 v1.0 目录、默认的 just-solve 提示词、种子 42、any-case runner 通过策略，以及装有 Python 3.12 和 uv 的 Docker。

每个模型和每种强度设置我都只跑了一次。每个检查点都建立在更早检查点的代码之上。有些问题的检查点比其他问题多。每个检查点在通过率中权重相同，因此检查点更多的问题权重更大。

核心通过率与严格通过率

严格：每个测试类别都通过，包括回归测试。

核心：非空 Core 类别中的所有测试都通过。例如，如果模型在检查点 2 失败，它仍可在后续检查点获得核心通过，即使 ck2 的测试仍然失败。

在本次快照中，Astra XHigh 的严格通过数最多。但它对 SOL 6.1 Medium 的领先只有两个检查点。

Opus Medium 以 145/196 领跑核心通过数，但严格通过只有 28/196。

更多强度 == 更多花费，但不一定带来更好的结果

这并不能证明更多推理会损害编程。它说明的是，在这些运行中，更高的强度并不是买到更多严格通过的可靠方式。每个设置只跑一次测试活动，我无法判断运行间的波动有多大。

GPT-6.1 Medium 的记录成本最低，为 178.51 美元，严格通过数与 Astra Medium 相同。Fable 的记录估算成本约为其 8.68 倍，严格通过数却少了三个。

最终代码仍然无法通过测试

检查点成功也不等同于最终得到一个能运行的程序。

代码质量发现——模糊不清

首先——模型在工作过程中留下了大量垃圾代码和草稿代码。我的第一反应是从质量分数中剔除那些随机的临时文件。但我和 gabe 聊了聊，他提出了一个很好的观点：基准就应该衡量模型在代码库中留下了多少垃圾。如果我们不读代码，就必须测量它。测试、草稿代码和生成的副本，不应该仅仅因为不是主程序就免于计入。

我确实使用了一份固定的文件夹名称列表，在两项分析中都排除了已安装的软件包、虚拟环境和缓存。

主要结果分析所有遗留代码。作为对照，我们也在移除一份固定的临时文件和生成文件列表后计算同样的指标。这样我们就能看出清理对数字的影响有多大。规则和实际差异如下。

这些数字覆盖的是全部十次完整运行中相同的 28 道题，而不是全部 36 道题。扫描器无法完整测量八道题中的某些文件（更多内容见 gabe 后面的更新），因此我们对每个模型都排除了这些题。

关于我们如何计算“这段代码中有百分之多少触发了至少一条 slop 规则”，有一些高层面的细节：

扫描器会在每个文件内标记 slop 模式和重复代码。

“覆盖率”是指被这些检查标记的源代码行所占的比例。

每一行只计一次，即使有多项检查都标记了它。

一项检查可能标记整个函数，而并非每一行都有问题。

我们把全部 28 道题中被标记的行数和源代码行数分别加总，然后相除得到百分比。因此较大的程序权重更高。在之前的文章中，我们是对每道题的百分比取平均。

Opus XHigh 的 slop 百分比最低，为 77.75%，而 Opus Medium 为 94.25%。有趣的是，xhigh 版本的严格通过数又一次更少：25 对 28。

虽然 Opus 5.5 Medium 的严格通过数更多，但 Opus 5.5 XHigh 写出的代码干净程度接近约 5 倍。

这可能是因为较新的模型带来了新的／不同的 slop 模式，而论文最初那套 200 多个 linter 针对的是一组手工挑选的模式，这些模式源自 2026 年 3 月原始发表及 2026 年 5 月 v1.1 之前几个月里由智能体撰写的 PR。这些新模型可能产生了我们尚未为其构建 linter 的新的可维护性反模式（更多内容见 Gabe 的后续文章）。

对于过滤后的分数，我们排除名为 _work、tmp、temp、scratch、generated、build 或 dist 的文件夹，以及 *_pb2.py 和 *_pb2_grpc.py 文件。我们对每次运行都使用相同的规则。我们不会猜测代码看起来是否由生成而来，也不会把测试作为一个整体排除。在这些运行中，过滤器只移除了 _work 文件：45 个文件和 41,265 行源代码，全部来自 Opus Medium 最终的 dynamic_buffer 代码。其总行数从 216,881 降到 175,616 行源代码，slop 存在率降到 92.90%。它在 slop 存在率上仍然排名最高。过滤器对其他模型没有任何改变。

正如你可能预料的那样，把代码拆分成更多辅助函数可以降低平均复杂度，却不会让代码更容易修改。代码更少也并不总是更好。

还有大量指标，我很期待听到 Gabe 对这些输出中更偏定性方面的看法。

我的结论

完整基准的困难之处在于一种对我很重要的方式：智能体把主要行为做对的频率，远高于它们在需求变化时让所有已测试行为继续正常工作的频率。

我们在长期维护代码库方面正在进步（5 月到 9 月期间从 14.8% 提升到 16.3%），但没有任何人想让你相信的那么快。我认为在未来相当长一段时间里，我们还得继续维持运转。

注：这是我们 2026 年 10 月报告的第一部分：第四季度 slop 现状。Gabe 和 SlopCodeBench 团队将在第二部分分享他们的分析以及对 slop 模式更偏定性的深入探讨。