Dex Horthy 发布 SlopCodeBench 最新结果：GPT-6 Astra 以 16.3% strict pass rate 领先

dex· @dexhorthy · X·2026-10-28 00:16· 1 小时前AI 评分55

AI 导读

Dex Horthy 发布 SlopCodeBench 最新结果，GPT-6 Astra 以 16.3% strict pass rate 领先，高于 5 月 gpt-5.5 的 14.8%，测试覆盖 36 个问题、196 个 checkpoint。

正文 · 原文

花了一段时间才把这些全部整理到一起，但很高兴分享最新的 SlopCodeBench（scbench dot ai）发现。感谢 @gorlanski 帮忙整理这些内容——这些发现应该很快会进入主结果排行榜。https://x.com/i/article/2111206187945603072

【X 长文】Astra 在 SlopCodeBench 上击败 Opus 5.5，xhigh 被认为有害

注意：这是我们 2026 年 10 月报告的第一部分：Q4 的 slop 现状。@gorlanski 和 SlopCodeBench 团队将在第二部分分享他们的分析，以及对 slop 模式更定性的深入探讨。关于我之前在 SlopcodeBench 上的报告，请参阅 benchmarking the new frontier 和 benchmarking fable 5, sol, kimi k3，两篇都包含对 SCB 核心结构以及每个挑战如何拆分为 checkpoint 的更深入探讨。

5 月上次发布 SCB 时，gpt-5.5 在 slopcodebench 上获得了 14.8% 的 strict pass rate。本月，我用同样的 campaign 运行了前沿模型，得分最高的是 gpt-6 astra，达到 16.3%。

什么是 SlopCodeBench

更多内容见上方链接，但快速提醒一下：在 SlopCodeBench 中，模型在同一个代码库中完成连续的编码挑战，并在单个挑战的全部 3-8 个 checkpoint 中继承之前的工作。

结果

虽然该基准报告了多种不同的通过率，但我们关注的是 strict pass rate——即模型在多少个 checkpoint 中通过了所有测试用例，同时仍然通过所有回归测试。我们在此测试的前沿模型 strict pass rate 在 12.2-16.3% 范围内：

- Opus 5.5

- Fable 5.1

- SOL 6 和 6.1

- Astra

- GLM 5.3

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

这里有一件有趣的事，我会深入探讨——对一些较新的模型来说，medium effort 的表现优于 XHigh。在三个完整配对中，XHigh 的成本是 Medium 的 2.11-4.22 倍，最值得注意的是，opus 5.5 在 medium effort 上的表现比在 xhigh 上更好。（注：对于这个基准，Astra/Sol 模型在 xhigh 上*确实*似乎表现更好）

过去几个月，我运行了该基准的子集。我从三个问题开始，然后尝试了六个。这次：每个设置 36 个问题和 196 个 checkpoint。由于我们之前使用的是子集，因此不能用较早的子集来衡量进步或退步。完整基准让我们能够将这些结果与官方研究结果进行比较。这也意味着，虽然后两次中 fable 5 的 30% 得分很有趣，但在这里不可比较，因为它只覆盖了 36 个问题中的 6 个。

更多关于 SCB

SlopCodeBench 分阶段向编码智能体给出问题。它编写程序，获得新需求，并修改现有代码。后续 checkpoint 会同时测试新行为和旧行为。

这里的想法是，这更贴近软件的真实构建方式——在构建过程中需求不明确且不断演变。

对于想要复现这些发现的人：我使用了固定版本的 v1.0 catalog、原版 just-solve prompt、seed 42、any-case runner pass 策略，以及带有 Python 3.12 和 uv 的 Docker。

我对每个模型和每个 effort 设置各运行了一次。每个检查点都建立在更早检查点的代码之上。有些问题的检查点比其他问题多。每个检查点对通过率的贡献相同，因此检查点更多的问题权重更大。

Core 与 Strict 通过率

- Strict：每个测试类别都通过，包括 Regression。

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

在此快照中，Astra XHigh 的 strict 通过数最多。但它对 SOL 6.1 Medium 的领先仅有两个检查点。

Opus Medium 以 145/196 领先 Core 成功率，但 strict 仅通过 28/196。

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

这并不能证明更多推理会损害编码。它说明在这些运行中，更高的 effort 并不是购买更多 strict 通过数的可靠方式。每个设置只跑一次，无法告诉我运行间波动有多大。

GPT-6.1 Medium 的记录成本最低，为 $178.51，strict 通过数与 Astra Medium 相同。Fable 的记录估计值约为其 8.68 倍，strict 通过数却少了三个。

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

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

代码质量发现 - 模糊

第一 - 模型在工作时留下了大量垃圾和草稿代码。我的第一反应是从质量分数中移除随机临时文件。但我和 gabe 聊了聊，他提出了一个好观点：基准测试应该衡量模型在代码库中留下了多少垃圾。如果我们不阅读代码，就需要测量它。测试、草稿代码和生成的副本可能不应该仅仅因为它们不是主程序就获得免费通行。

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

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

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

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

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

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

- 即使多个检查标记同一行，我们也只计算一次。

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

我们将所有 28 个问题中被标记的行和源代码行汇总，然后相除得到百分比。因此较大的程序权重更大。在之前的帖子中，我们改为对每个问题的百分比取平均值。

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

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

这可能是因为较新的模型带来了新的/不同的 slop 模式，而论文最初那套 200 多个 linter 的测试集，聚焦于一组手工整理的规则，这些规则源自 2026 年 3 月原始发表及 2026 年 5 月 v1.1 之前数月内由 agent 编写的 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 对这些输出中更偏定性方面的看法。

我的结论

这个完整基准测试的难点对我来说很重要：agent 在保持主要行为正确方面，远比在需求变化时保持所有已测试行为正常工作方面做得好得多。

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

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

来源：dex · x.com