方法论：埋 bug、盲评与公开判据
BugHuntBench 的设计刻意与主流「修复已公开 issue」类基准拉开差异，规则可以概括为四条：
- 预埋真实 bug：105 个 bug 由作者预先埋进两个生产级代码库（仓库一 45 个、仓库二 60 个），每条都有标准答案；bug 清单不公开以维持基准有效性，但测试覆盖率对外发布；
- 各回各家 CLI：模型在各自的命令行智能体中运行——OpenAI 系走 Codex CLI，Claude 系走 Claude Code，xAI 系走 Grok Build CLI（ACP 接入），Meta 的 Muse 走 Muse Code——全程自主翻代码、自主修改，无人工协助；
- 盲评计分：修改后的代码对照隐藏答案盲评，只有「找得到且修得好」的预埋 bug 计分；模型自行额外上报的问题单独记录、不计入总分；
- 判据公开可核对：每一条判分依据公开在 GitHub 仓库，质疑者可以逐条对照；头部配置做了 2 至 5 次重复运行取均值，压低单次波动。
作者特别点出常见的翻车姿势：模型说「这里疑似有 bug」却拿不出修法，计零分。这个判定标准把「报告」与「修复」严格切开，也是后文 bug-maxing 现象的计量基础。
SWE-bench 系列测的是「修复真实公开 issue」，Terminal-Bench 测端到端 CLI 工作流，BugHuntBench 测的是「在无提示的真实代码库里自主发现并修复预埋缺陷」——更接近维护者日常的防御性工作。本站 R-BENCH-14 曾记录 METR 的发现：SWE-bench 分数与真实维护者实测存在约 24 分落差；BugHuntBench 这类小样本、全盲评、判据公开的独立实测，是对大基准落差的一种民间校准手段。
主榜单：谁修得多
以下为 GitHub 榜单全表中的关键行（修好数 /105，均为最高推理档或标注档位；多次运行取均值）：
| 模型 | Harness | 档位 | 运行次数 | 修好 /105 | 耗时 | 总成本 |
|---|---|---|---|---|---|---|
| Sonnet 5.5 | Claude Code | max | 3 | 51.3 | 287 分钟 | $154.03 |
| GPT-6 Astra | Codex CLI | max | 3 | 45 | 90 分钟 | $33.03 |
| GPT-6.1 Sol | Codex CLI | max | 3 | 44.3 | 139 分钟 | $5.88 |
| GPT-5.6 Sol | Codex CLI | max | 2 | 43.5 | 253 分钟 | $95.35 |
| Fable 5.1 | Claude Code | max | 1 | 43 | 73 分钟 | $87.18 |
| Opus 5.5 | Claude Code | max | 3 | 41.7 | 67 分钟 | $58.53 |
| Muse Spark 1.3 | Muse Code / Meta API | max | 5 | 32.2 | 86 分钟 | $18.11 |
| GPT-6 Sol | Codex CLI | max | 3 | 29.3 | 63 分钟 | $9.33 |
| Grok 4.7 | Grok Build CLI（ACP） | xhigh | 4 | 28.8 | 46 分钟 | $22.89（包月口径） |
| Kimi K3 | Kimi Code CLI | default | — | 21 | — | — |
三个直观读数：修得最多的 Sonnet 5.5（max）比次名 GPT-6 Astra 多修 6.3 个，但耗时 3 倍多、成本近 5 倍；GPT-6.1 Sol（max）以 44.3 个的成绩挤进前三，总成本却只有 5.88 美元；开源与国产模型梯队（Kimi K3 21 个、GLM-5.3 19 个、腾讯 Hy4 Preview 18 个）与闭源头部仍有约 20 个以上的差距。另需说明，个别媒体转述的总成本数字与 GitHub 榜单略有出入（如 GPT-6 Sol 有报道写 9.93 美元，榜单为 9.33 美元），本文一律以 GitHub 榜单原始数值为准。
成本反转：每个 bug 多少钱
把总成本除以修好数（按榜单数值折算），排名出现整体翻转：
| 模型 + 档位 | 修好 /105 | 总成本 | 折算单 bug 成本 | 相对倍数 |
|---|---|---|---|---|
| GPT-6.1 Sol（xhigh） | 42.7 | $4.35 | 约 $0.10 | 1 倍（基准） |
| GPT-5.6 Luna（max） | 31.3 | $3.15 | 约 $0.10 | 1 倍 |
| GPT-6.1 Sol（max） | 44.3 | $5.88 | 约 $0.13 | 1.3 倍 |
| GPT-6 Sol（max） | 29.3 | $9.33 | 约 $0.32 | 3.2 倍 |
| GPT-6 Astra（max） | 45 | $33.03 | 约 $0.73 | 7.3 倍 |
| Muse Spark 1.3（max） | 32.2 | $18.11 | 约 $0.56 | 5.6 倍 |
| Opus 5.5（max） | 41.7 | $58.53 | 约 $1.40 | 14 倍 |
| Fable 5.1（max） | 43 | $87.18 | 约 $2.03 | 20 倍 |
| GPT-5.6 Sol（max） | 43.5 | $95.35 | 约 $2.19 | 22 倍 |
| Sonnet 5.5（max） | 51.3 | $154.03 | 约 $3.00 | 30 倍 |
注意这些折算值是本文基于榜单公开数值的推算，作者本人未发布单 bug 成本口径；媒体报出的倍数（如「约六倍差」）对应的是不同配对组合，读数时应对齐比较对象。但结构性结论不受口径影响：单 bug 成本的首尾差在二十倍以上，而且「单位成本最优」与「修复数登顶」不是同一款模型。对预算敏感的团队，这份数据的价值可能高于任何官方分数。
代际退步与 bug-maxing
同门代际对照：GPT-6 Sol 对 GPT-5.6 Sol
本轮最受关注的一组对照是 OpenAI 自家两代中端模型：GPT-5.6 Sol（max）修好 43.5 个，新一代 GPT-6 Sol（max）只修好 29.3 个，少了 14.2 个。作者的评语很直白：看起来是一次大退步。但同期 GPT-6 Sol 只跑了 63 分钟，上一代同档跑了 253 分钟，总成本也从 95.35 美元降到 9.33 美元——速度与成本的收益抵消了部分质量损失。这组数据提醒我们：「新一代」不是一个单维指标，厂商完全可能在代际之间重新分配质量、速度与成本三个旋钮。
bug-maxing：额外发现的价值与噪声
榜单专设「额外发现」列，记录模型上报的埋入之外的问题：GPT-6 Astra（max）报了 55 条，GPT-6.1 Sol（max）报了 65.3 条，GPT-6 Sol 报了 41.3 条。这些不全是幻觉，确实包含真实问题，只是不在预埋的 105 个之内。作者给这种行为起了名字——bug-maxing，并提醒 OpenAI 系模型尤其爱多报。对使用者的启示很直接：AI 交回来的问题清单要先核实再当真，别被画蛇添足的发现带偏节奏；而在代码审查场景里，高额外发现率反而可能是加分项。
档位滑轨：推理档位的价格弹性
作者在帖子线程里补测了 GPT-6 Astra 的四档推理档位，形成一条清晰的价格弹性曲线：
| 档位 | 修好 /105 | 总成本 | 耗时 |
|---|---|---|---|
| max | 45 | $33.03 | 90 分钟 |
| high | 35 | $20.60 | 40 分钟 |
| medium | 34 | $15.78 | 28 分钟 |
| low | 27 | $11.69 | 32 分钟 |
读法有三层：从 high 到 medium 几乎不掉分（35 对 34），多花的近 5 美元买到的增量很小；从 max 到 medium 掉 11 个 bug、省一半成本；而 low 档的 27 个已经贴着 GPT-6 Sol（max）的 29.3 个。便宜档与旗舰档之间是一条连续滑轨，选型要做的只是把每单活放到滑轨上合适的那一格——批量小修用便宜档，硬骨头再上旗舰，这笔账值得每个团队自己算。
其一，分数与账单要一起看：只盯 45 对 29.3 的落差容易忽略单 bug 成本 20 倍以上的分野；其二，档位是隐藏的价格旋钮：同一模型高低档之间能差出一款竞品；其三，榜单之外还有半个成绩单：额外发现率、耗时与运行次数方差，都应进入采购评估清单。
局限与适用边界
- 单人口径：这是个人独立实测，样本为两个仓库 105 个 bug，仓库类型与语言分布未见完整披露，结论不宜直接外推到任意技术栈；
- 运行次数不均：头部配置 3 至 5 次取均值，但 Fable 5.1 等部分配置仅 1 次运行，方差未完全压平；
- 只测「找 bug 修 bug」一件事：真实项目还要读需求、跑构建、过评审，本榜只是其中一个切面；
- 成本口径混用：Grok 系标注「包月口径下限」，与其他按 token 计费的行不可直接比；媒体转述与 GitHub 原表存在零点几美元的出入，本文以原表为准；
- 利益独立性是双刃剑：作者与厂商无关联，可信度高；但缺少第三方复测，目前尚无第二个团队用同一答案键跑出交叉验证。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。