编码模型推理强度越高，性价比越好吗
文章重析 SlopCodeBench 已公布数据：Opus 5.5 的 medium 配置通过 28 个检查点，xhigh 通过 25 个，后者估算成本为前者的 4.22 倍。作者未自行运行基准，并强调每种配置仅一次实验，需谨慎解读差异。
完整中文译文
注明来源的资料汇编，加上两个小型离线脚本。主要来源：Dex Horthy（与 Gabe Orlanski 合作），《SlopCodeBench 2026 年 10 月更新：Opus 5.5 更新，Astra 比 gpt-5.5 提高 1.5%，xhigh 被认为有害》（HumanLayer，2026-10-15）。基准论文：Gabriel Orlanski 等人的《SlopCodeBench：衡量 Coding Agent 在长周期迭代任务中的退化》（arXiv 2603.24755）。第二组数据：paddo 的《默认设置是对的：Opus 5.5、Sonnet 5.5 和 GPT-6 Sol 在真实工作中的 effort 级别》（2026-09-29）。相关讨论：Hacker News 帖子（截至 2026-10-21 获得 283 分）。我没有运行 SlopCodeBench，也没有运行任何 Coding Agent。下文全部是在离线环境中重新分析已发布的数据，每个数字都注明了来源。
HumanLayer 在 10 月发布的 SlopCodeBench（SCB）文章，本周登上了 Hacker News 首页，副标题很有挑衅意味：“xhigh 被认为有害。”背后的发现是：Opus 5.5 在 medium effort 下，196 个检查点中有 28 个严格通过；到了 xhigh，只剩 25 个，估算成本却变成了 4.22 倍（193.47 美元对 817.04 美元）。GPT-6 SOL 从 30 个降到 26 个，成本变成 2.11 倍。只有 GPT-6 Astra 有所提高，从 29 个升到 32 个，成本变成 2.91 倍。
Horthy 值得肯定的一点是，他在文章里就作了限定：每种设置只跑了一轮，因此“这不能证明更多推理会损害编码表现”。HN 上的讨论也分成了几个熟悉的阵营：“我一直开到 max”“medium 最适合我”，以及“跑五次，再给个置信区间”。本文站在最后一位评论者这边。我想看看这些数字究竟能支持什么结论，按每次通过的成本重新排列榜单，再给你一个小脚本，让你在自己的 repo 上做同样的 A/B 测试。
SCB 测什么，以及它为什么比 SWE 类基准更难
SCB 会分阶段给 Agent 布置问题。Agent 先根据规格实现一个 CLI 或 API，然后接收新需求，在自己之前写的代码上继续扩展。过程中没有新的参考实现，也看不到测试。论文包含 36 个问题、196 个检查点。隐藏测试分为四组：Core、Error、Functionality 和 Regression，其中 Regression 包含此前所有检查点的测试。
严格通过：当前检查点的所有测试类别都通过，包括 Regression。
Core 通过：只要求当前检查点的核心测试通过。
两者之间的差距，就是整个问题的关键。在 Horthy 的运行结果中，各模型的 Core 通过率为 65.8%–74.0%，严格通过率却只有 12.2%–16.3%。Agent 实现新功能的成功率，远高于让旧功能继续正常工作的成功率。论文还发现，77% 的任务轨迹出现了结构退化加剧，75.5% 出现了代码冗长程度上升；与包含 473 个人类 Python repo 的对照样本相比，Agent 代码的冗长程度是其 2.3 倍。
如果你想复现，原文给出的配置是：固定使用 v1.0 目录、默认的 just-solve prompt、seed 42、any-case 通过策略，以及安装 Python 3.12 和 uv 的 Docker 环境。题目位于 gabeorlanski/scb-problems。
第一次分析：28 对 25，算得上信号吗？
scb_effort_math.py 读取已发布的表格，执行标准比例检验，只依赖标准库。下面所有分析都有一个前提限制：这些检验把 196 个检查点当成相互独立的抛硬币事件。但它们并不独立。同一个问题中的检查点共享代码，一次回归就可能让后续所有检查点都无法严格通过。因此，我报告的区间偏窄，真实情况中的噪声还要更大。
以下是我在本机运行 scb_effort_math.py 的结果，输出经过裁剪：
Opus 5.5 strict 28->25 (-3), cost x4.22 (+$623.57); no extra strict passes bought
Fisher exact two-sided p (unpaired, indep. approx) = 0.768
paired best case: 3 discordant all one way -> exact sign-test p = 0.250
GPT-6 SOL strict 30->26 (-4), cost x2.11 (+$271.63)
paired best case: 4 discordant all one way -> exact sign-test p = 0.125
GPT-6 Astra strict 29->32 (+3), cost x2.91 (+$497.57); $165.86 per extra strict pass
paired best case: 3 discordant all one way -> exact sign-test p = 0.250
最关键的是“配对检验的最佳情况”这一行。Medium 和 xhigh 跑的是同样的 196 个检查点，因此正确的检验只关注两种设置结果不一致的检查点。净差距为 3，意味着至少有 3 个检查点的结果不一致。即使这 3 个全部偏向同一边，精确双侧 p 值也只是 2 × 0.5³ = 0.25。无论这些结果怎样配对，都无法让这个差距达到统计显著。Opus Medium 严格通过率的 95% Wilson 区间，在独立性近似下是 10.1%–19.9%，而全部十轮运行的严格通过数，即 24–32 个，都落在这个区间内。
需要多少数据才能得出定论？在 α = 0.05、统计功效为 80% 的条件下，区分 14.29% 和 12.76%，每种设置大约需要 7,800 个独立检查点，相当于各跑约 40 轮完整 SCB。没人会为此买单。
诚实的解读是：只看严格通过数，SCB 无法区分 medium 和 xhigh。“有害”说过头了，“xhigh 更好”也一样。
第二次分析：真正清晰的信号是每次通过的成本
成本没有同样的噪声问题。这里的差距是 2–4 倍，而不是上下浮动 3 个检查点。把每轮运行的估算成本除以严格通过数，结果如下，仍来自同一个脚本，部分列已裁剪：
campaign strict $ $/strict
GPT-6.1 SOL Medium 29/196 178.51 6.16
Opus 5.5 Medium 28/196 193.47 6.91
GPT-6 SOL Medium 30/196 245.69 8.19
GPT-6 Astra Medium 29/196 261.05 9.00
GLM 5.3 XHigh 24/196 365.13 15.21
GPT-6 SOL XHigh 26/196 517.32 19.90
GPT-6 Astra XHigh 32/196 758.62 23.71
GPT-5.6 SOL XHigh 28/196 753.30 26.90
Opus 5.5 XHigh 25/196 817.04 32.68
Fable 5.1 XHigh 26/196 1550.07 59.62
四轮 medium 运行的每次严格通过成本，全都低于六轮 xhigh 运行。Astra XHigh 是唯一换来了额外通过数的设置：相较 Astra Medium，每多通过一个检查点，大约要花 166 美元。对于困难的迁移任务，这个价格可能值得；对于日常修改，它不是个好默认值。
paddo 的独立基准也指向同样的结论。它选取了生产环境 TypeScript monorepo 中六项已经合并的真实改动，每个级别运行 20 次，并用原始修复的测试来评分。Opus 5.5 在 medium 下有 13/20 次运行完全通过，xhigh 下为 12/20，max 下为 11/20，对应成本分别为 44.10、139.79 和 307.16 美元。他发现的一个例外是 Sonnet 5.5：max 下达到 13/20，medium 下为 11/20，但成本约为 35 倍。我的脚本算出，这个差距的 Fisher 检验 p 值约为 0.75。paddo 也提醒，他使用的 Claude effort 级别是推断出来的，因为请求记录里没有保存这一设置。
两套构建方式不同的基准，通过数都有很大噪声，成本差距却都很清楚。应当把 effort 当成控制花费的旋钮，而不是控制质量的旋钮。paddo 的说法是：“花费调节旋钮。”
第三次分析：在你自己的任务上做 effort A/B 测试
把自己的 repo 当作基准。挑选 10–20 项各自带有测试、已经合并的改动，从每项改动的父提交开始，用两个 effort 级别分别重做，并记录完整测试套件是否通过。下面是文档中的两个关键信息，我没有运行其中任何一条命令：
# Claude Code: per-session flag (also /effort, or CLAUDE_CODE_EFFORT_LEVEL)
claude -p "$(cat ticket.md)" --effort medium
# Codex CLI: per-run config override (persistent key lives in ~/.codex/config.toml)
codex exec -c model_reasoning_effort='"medium"' "$(cat ticket.md)"
每次运行记录一行，字段为 task_id,effort,run,passed,broke_existing,cost_usd，并按任务对运行结果进行配对：
python effort_ab.py results.csv medium xhigh
effort_ab.py 会报告严格通过率、回归情况、每次严格通过的成本，并对两种设置结果不一致的任务执行精确配对符号检验。它的规则刻意设得保守：只有当更贵的设置在配对结果不一致的任务上胜出，且 p < 0.10 时，才切换过去。否则，继续把便宜的设置作为默认值，把更贵的设置留给失败后的重试。这也是 paddo 的结论。我只用明确标注为合成数据的 demo_results_SYNTHETIC.csv，对脚本做了冒烟测试。这些数字不能说明任何模型的表现，因此这里不引用。
无论如何，HN 讨论里有三个习惯值得借鉴。把 formatter 和死代码警告设为必须通过的门槛，因为几位评论者提到，Astra/SOL 输出的换行有时很奇怪，甚至会缺失。要求 Agent 在结束前运行完整测试套件，因为正是回归问题拉开了 Core 通过与严格通过之间的差距。还要检查 diff 大小，因为 paddo 发现，在一项改动中，Opus 新增的代码从 medium 下约 480 行，增加到了 max 下约 830 行。
任何模型、任何 harness、任何 effort 级别，都没有实际运行。没有跑过 SCB，也没有重做 paddo 的测试。
至于 SCB 的低质量代码指标是否更偏向 xhigh，Horthy 报告称，Opus XHigh 被标记的代码占比为 77.75%，Medium 为 94.25%。他也指出，linter 可能没有覆盖较新模型的代码模式。我没有分析这部分质量数据。
claude -p ... --effort 和 codex exec -c ... 这两条命令来自当前文档，没有执行过。
SCB 的 effort 对比不包含 high 和 max，几位 HN 评论者也指出了这一点。
当你的大多数 Agent 运行都因为回归而失败时，更多思考主要换来的是更多 token 和更大的 diff。默认使用 medium，要求 Agent 在结束前运行完整测试套件，只有重试时才提高 effort。如果你想知道 xhigh 对自己的代码库有没有帮助，拿自己已经合并的 20 项改动做配对检验，会比任何榜单标题都更有参考价值。
作者 YongBo Yu，是一名居住在多伦多的 AI 工程师。更多内容见 yongbo-yu.vercel.app 和 GitHub。
如需采取进一步操作，可以考虑屏蔽此人和／或举报滥用行为。