AI 编程评测复盘：推理档位开满，36 题 196 个检查点

一句话结论：把「分阶段改需求」当考卷时，前沿 Agent 的严格通过率只有 12.2%–16.3%——也就是说，绝大多数检查点上，它们没能做到「新功能做对、旧功能全不挂」。而把这套题跑满十遍之后，最反直觉的一条是：推理档位（effort）开满，花的钱多 2.1–4.2 倍，通过数却没有跟着涨。Opus 5.5 甚至从 Medium 的 28 个降到 XHigh 的 25 个。

披露：本文编译自 HumanLayer 仓库 advanced-context-engineering-for-coding-agents 的公开记录《SlopCodeBench update 10/2026》（Dex Horthy 撰写，2026-10-15，Gabe Orlanski 与 SlopCodeBench 团队参与）。基准本身由 SlopCodeBench 团队维护，论文见 arXiv:2603.24755。该仓库长期发布 agent 上下文工程相关实践，作者与所测模型厂商无隶属关系；文中成本均为估算值而非发票，作者也明确写了「单次运行不能归因」。本文未做独立复测，数字以原文为准。

一、这份考卷到底在考什么

多数代码基准是「给一个题目，看能不能写出来」。SlopCodeBench 换了个更接近真实开发的方式：分阶段给需求。

Agent 先写一版程序；然后需求变了，它要在已有代码上改；再变，再改。后一个检查点既测新行为，也测前面所有行为有没有被改坏。原文的比喻是：这对应软件真实的样子——需求在建设过程中不断变得清晰、也不断变化。

于是分数分成两档，这两档的差距是全文的骨架：

一句话读法：core 高、strict 低，说明「这一步要做的事」经常能做出来，但「之前做对的事」在改需求的过程中被弄坏了。作者的原话是——「Agent 把主行为做对的次数，远远多于它把所有已测行为在需求变化中保持可用的次数」。

对比一下时间线也有意思：2026 年 5 月，gpt-5.5 的 strict 是 14.8%；9 月这轮最高的 gpt-6 astra 是 16.3%。四个月涨了 1.5 个百分点。

二、这轮怎么跑的（复现口径）

想反驳或复现，先对齐这几项：

• 36 道题、196 个检查点（每个设置下）；每个检查点等权计入通过率，所以检查点多的题权重更大
• 每个检查点基于上一个检查点留下的代码继续改，不是每题从零开始
• 10 个完整 campaign（完整跑完 36 题）；另外两个（Opus Max、GPT-6.1 XHigh）在采集时未跑完，被排除
• 固定：v1.0 题库、官方 just-solve 提示、seed 42、any-case 运行器判定、Docker + Python 3.12 + uv
• 每个「模型 × 档位」只跑一次

最后这条要先记住：后面所有关于档位的结论，边界都在这里。作者自己写得很清楚——「一个设置只跑一次，区分不了多少是运行间的波动」。

三、结果：十次完整 campaign

图 1：strict 24–32 / 196，core 129–145 / 196。浅色段不是额外的严格通过。原图见文末来源。

两个值得记住的细节：

• 榜首的领先幅度很小。Astra XHigh 是 32 个，比 SOL 6.1 Medium 只多 2 个检查点。
• core 榜首和 strict 榜首不是同一个。Opus 5.5 Medium 的 core 最高（145/196），但 strict 只有 28/196——它「该做的常做对」，但「不该坏的容易坏」。

四、发现一：档位开满，不保证更准

三个模型同时跑了 Medium 与 XHigh，这是全文最有价值的一组对照：

图 2：三对完整 campaign 的成本与 strict 通过数。XHigh 在三对里都更贵，只有 Astra 的 strict 上升。

三个模型里只有一个（Astra）在提档后变好；Opus 5.5 和 GPT-6 SOL 都变差了，且 Opus 的代价最高——贵 4.22 倍，少 3 个检查点。

作者对这条结论的措辞很克制，值得照抄：

这不能证明「更多推理会伤害编程」。它说明的是：在这几轮里，更高的档位不是买严格通过率的可靠手段。

同时他也留了口子：单轮运行区分不了涨跌是模型效应还是波动；不同档位是不同日期、不同 agent 版本跑的，因此不能当成因果实验。

五、发现二：成本与分数几乎无关

十次 campaign 的估算成本横跨 $178.51–$1,550.07，而 strict 通过率只横跨 12.24%–16.33%。

• 最便宜的一次：GPT-6.1 SOL Medium，$178.51，29 个 strict——和 Astra Medium（$261.05）同分
• 最贵的一次：Fable 5.1 XHigh，$1,550.07，26 个 strict——是前者的 8.68 倍成本，少 3 个检查点

这也解释了为什么「换更贵的档位试试」通常不是解法：它买到的确定性远低于直觉。反过来说，把档位当默认值而不是调优旋钮，在这个基准上更容易复现出稳定结果。

六、发现三：检查点过了，≠ 最后代码能跑

这一节最容易被排行榜忽略。作者只统计每道题的最后一个检查点：

图 3：36 个题面快照里，最后一步仍在失败的测试用例数，1,435–2,831 个；右列是「最后一步 strict 通过」的题数，0–3 个。

三个读法：

1. 没有一个 campaign 能让多数题「最终全绿」——上限 3/36。
2. 失败的大头是回归。每行里 Regression 占七到九成，意味着「新需求做完了，旧行为塌了」。
3. 作者提醒：失败用例数不是独立 bug 数，skip 单列，不同题权重也不同，别横向当排行榜用。

七、为什么回归是主战场

这不是靠猜。把三档分数摆在一起，因果链其实很直：

1. 每个检查点都要求 Agent 在上一版代码上继续改，而不是重写；
2. 需求变化往往动的是数据流（新字段、新分支、新的切换条件），不是孤立函数；
3. 只要它顺手重构了一下「看起来该整理」的部分，旧断言就有机会挂；
4. 而 core 只统计本步的 Core 类别，这部分损失在 core 里根本看不见。

所以 core 65.8%–74.0% 与 strict 12.2%–16.3% 之间的那道 50 多个百分点的沟，基本就是「改需求时把旧行为弄坏」的量。这也解释了为什么作者把结论压在那一句上：Agent 把主行为做对的次数，远多于它把所有已测行为保持可用的次数。

对工程团队的直接含义是：验收口径要写「旧的全过 + 新的做过」，不能只写「新的做过」。前者才是用户感知到的「没坏」，后者只是「这次做完了」。

八、代码质量：slop 覆盖率 78%–94%

除了「过没过」，这轮还量了「留下了多少垃圾」。先说方法上的一个决定，这个决定本身值得学：

作者的第一反应是把随机临时文件从质量分里剔掉。Gabe 反驳得很到位——基准应该量模型在代码库里留下多少垃圾；如果我们不读这些代码，那就更该把它量出来。测试、草稿代码、生成副本，不该因为「不是主程序」就免费放行。

统计口径：扫描器在每个文件里标记 slop 模式与重复代码，「覆盖率」= 被标记的源码行占比，同一行被多条规则命中只算一次；对 28 道可测题（8 道因扫描器测不全被排除，所有模型统一排除）按 SLOC 加权汇总——这一点与本系列前两篇「按题平均」不同。

结论一，覆盖率差异比想象大：

• Opus 5.5 XHigh 最低：77.75%；Opus 5.5 Medium 最高：94.25%
• 把固定的临时目录过滤掉（_work、tmp、temp、scratch、generated、build、dist，以及 *_pb2.py 这类生成文件）之后，Opus Medium 降到 92.90%，仍是最脏
• 这次过滤只命中了一处：Opus Medium 的 dynamic_buffer 里 45 个文件、41,265 行，总量从 216,881 行降到 175,616 行；对其它模型没有任何影响

结论二，更反直觉：同一个模型，XHigh 写出的代码干净约 5 倍，strict 却更少（25 vs 28）。作者没有把这条当因果，只提出一个可能解释：新模型会产出新的可维护性反模式，而论文那套 200+ linter 是在 2026 年 3 月/5 月基于当时的 agent PR 手工整理的，还没覆盖到它们。

结论三，关于复杂度：Fable 5.1 的平均圈复杂度最低（3.57，8,967 个可调用体），GPT-6 SOL Medium 最高（11.70，1,083 个）。但作者提醒——把代码拆成更多小函数，可以拉低平均复杂度，并不等于更好改；代码更少也不等于更好。

九、这轮复盘在方法上改了什么

这篇文章真正的价值不在排名，而在它承认并修正了什么：

1. 把残留垃圾计入评分，而不是「不算主程序就不算」。理由：不读代码，就必须量代码。
2. 覆盖率改成 SLOC 加权。此前是「每题算一个百分比再平均」，会让小题和小文件获得不成比例的权重。
3. 只报 28 道题的一致子集。8 道测不全的题在所有模型上一起排除，宁可缩小样本也不引入偏差。
4. 每次结论都写明「单轮不能归因」。这条最容易被排行榜搬运时删掉。

十、拿回自己仓库，怎么用这五个数

不上排行榜，只做工程决策的话，我会这么用：

1. 默认档位从 Medium 起。这轮唯一稳定的模式是「提档更贵」，而不是「提档更准」。要提档，用自己的题量出依据。
2. 选模型看 strict，不看 core。core 高只说明「这次要求的事做到了」；strict 才是「没把旧行为弄坏」。
3. 把「最后一个检查点」当验收。检查点连胜不等于收尾可用，这轮 0–3/36 就是证据。
4. 单次运行不下结论。至少要重复 3 次，或者同设置跑两次看波动，再决定换不换模型。
5. 成本是约束，不是目标。8.68 倍成本换来 3 个检查点的反向差距，足以说明「贵」和「准」是两个独立的轴。

三句常见说法，用这组数据校一下

• 「档位拉满就完事了」：三对完整对照里只有一对变好，最贵的那一对（Opus 5.5）是 4.22 倍成本、少 3 个检查点。正确姿势是先定 Medium 跑基线，再用自己的题量决定要不要提。
• 「贵的就是好的」：$1,550.07 的 Fable 5.1 XHigh 拿 26 个 strict，$178.51 的 GPT-6.1 SOL Medium 拿 29 个。在 12%–16% 这个窄带里，成本几乎不携带信息。
• 「榜一就能用」：榜首 Astra XHigh 与第五名的 SOL 6.1 Medium 只差 2 个检查点，而后者便宜 4 倍多。这种量级的差距，换一个随机种子、换一天跑，都可能翻转——所以原文才坚持写「单次运行不能归因」。

十一、在自己仓库搭一个小号版本（半天到一天）

不需要 36 道题，也不需要跑十个模型。想验证「我的 Agent 是不是也在回归上翻车」，最小可行版本是这样：

1. 挑 6–10 个已经合并的真实 PR，每个都从「改之前的提交」出发；
2. 把每个 PR 的意图拆成两段需求（先做 A，再说「另外还要 B」），第二段必须碰到第一段的代码；
3. 每段跑完都执行仓库现成的测试套件，记录：新需求的断言过没过、旧断言挂了几条、花了多少 token；
4. 只报两个数：strict（新+旧全过）与 core（新过）；两者之差就是回归损失；
5. 同一设置至少重复 3 次，否则你无法区分模型效应和波动——这也是原文反复强调的边界。

这套东西的价值不在于得出「哪个模型第一」，而在于用你自己仓库的代码形状回答三个决策问题：默认档位定在哪、验收要不要卡回归、换模型前需要多少重复次数。原文的 36 题之所以有说服力，靠的也是这三件事做得干净：题库固定、口径固定、把不能测的题一起排除。

十二、边界

• 每个「模型 × 档位」只跑了一次；所有档位对比都受此限制，作者本人也这么写。
• 估算成本按推理用量推算，不是发票；不同日期、不同 agent 版本之间不可直接横比。
• 题库是 36 道合成题面，覆盖的是「分阶段需求 + 回归」这一类能力，不等于你仓库里的真实任务。
• 质量分只对 28 道题有效；slop 规则集是 2026 年上半年的手工整理版本，对新模型可能漏检。
• 本文为 Part I；SlopCodeBench 团队关于 slop 模式的定性分析（Part II）尚未发布。

对做 Agent 工具的人来说，最该带走的一句是作者自己的总结：「我们在维护代码库这件事上确实在变好（14.8% → 16.3%），但没有宣传里那么快。」

相关阅读：AI 基建 / 评测 / 安全完全指南 ｜ 默认模型是没锁的依赖：15 天三变，评测怎么记 ｜ AI 生成的测试会跟 bug 一起"通过"：变异测试与评委校准 ｜ Agent 说"做完了"，数据库说没有：交付验收的三道门 ｜ Claude Code 团队怎么做代码评审：7 层防线

Sources

• Dex Horthy（w/ Gabe Orlanski）, SlopCodeBench update 10/2026 — Opus 5.5 update, Astra improves by 1.5% over gpt-5.5, xhigh considered harmful, 2026-10-15：https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/benchmarking-new-models-on-slop-code-bench.md
• SlopCodeBench 论文：https://arxiv.org/abs/2603.24755
• 本篇图表来源同上仓库 images/scb-3-*.png，已转存站内

本文由 hubwiz 编译整理，转载请注明出处。

这是「AI 基建 / 评测 / 安全」专题的一部分。完整地图见：AI 基建 / 评测 / 安全完全指南