代码能力评测的口径：SWE-bench Verified 与 LiveCodeBench 各自测什么

两个分数回答的是不同问题。SWE-bench Verified 的解决率衡量智能体能否在真实 Python 仓库中根据 issue 修改代码并通过测试；LiveCodeBench 当前榜单快照的 Pass@1 衡量模型能否解出指定时间窗口内的竞赛编程题。前者是模型与智能体框架的联合结果，后者主要是受控提示下的算法解题能力，不能相互替代。

分数也不是脱离设置的模型常数。统一 mini-SWE-agent 口径下，GLM-5 与 MiniMax M2.5 分别为 72.8% 和 75.8%；模型方在 OpenHands 或 Claude Code 等设置下自报 77.8% 和 80.2%，差 5.0 与 4.4 个百分点。SWE-bench Verified 统一榜首仅领先 1.0 个百分点；在 500 题、题目独立且结果不配对的近似下，差值 95% CI 为 -4.3–6.3，Holm 校正后 p = 1.000，不足以宣称稳定领先。

数据与方法

SWE-bench 从 12 个 Python 仓库的真实 GitHub issue 与对应 pull request 构造任务。模型获得 issue 描述和修复前代码库，补丁只有同时通过新增的 fail-to-pass 测试与回归测试才算解决 ^[1]。Verified 从人工审查的 1,699 个样本中保留 500 个；93 名有 Python 经验的开发者参与，每题由三人独立标注，以筛掉描述欠明确、测试有问题或存在其他重大缺陷的任务 ^[2]。

本站 SWE-bench 数据取官方 Bash Only 视图中 mini-SWE-agent 2.0.0 的完整 13 条成绩。该视图把模型放进同一 minimal bash 环境，使用简单 ReAct 循环；官方明确说明 2.x 改用 tool calling，不能与 1.x 直接比较，且 2.x 不设置 temperature ^{[3] [4]}。本文对 Top 10 计算 95% Wilson 区间，对九组相邻名次做非配对两比例 z 检验，并用 Holm 法校正多重比较。MDE 采用双侧 α = 0.05、power = 0.8、p = 0.5 的保守近似。

LiveCodeBench 从 LeetCode、AtCoder 与 CodeForces 的新竞赛题持续收集数据，并以题目发布日期切时间窗口。论文定义了代码生成、自修复、代码执行与测试输出预测四种场景；本文榜单快照只取 Code Generation，程序必须通过全部隐藏测试才算正确 ^[5]。页面筛选窗口为 2024-08-01 至 2025-05-01，官方数据实际命中 279 题，最新题为 2025-01-05 ^[6]。官方 build/v5.json 提供每个模型在每道题上的 Pass@1；本文保留题内聚合值，以题目为单位做 2,000 次 bootstrap。比较榜首与第二名时，对 279 道共同题目的逐题差值做配对 bootstrap，并以 5,000 次符号翻转检验报告 p 值及 Cohen’s dz；固定种子为 20261015。

评测设置对照只纳入实际打开且找到原文设置的模型方报告。Z.ai 用 OpenHands、定制 instruction prompt、temperature 0.7、top_p 0.95、16,384 输出 token 与 200K context 报告 GLM-5 的 77.8% ^[7]。MiniMax 用覆盖默认 system prompt 的 Claude Code 框架，四次运行平均为 80.2%；同一模型换成 Droid 与 OpenCode 默认 prompt 后为 79.7% 与 76.1% ^[8]。这些数字用于整套设置的敏感性分析，不并入统一榜排名。

结果

两个 Benchmark 对应两种优化目标

SWE-bench Verified 优化的是端到端仓库修复：定位文件、阅读长上下文、编辑多处代码、运行工具并保持回归测试不破坏。它没有把模型与 scaffold 分离；工具、提示、上下文管理、token 预算和重试策略都会进入最终解决率。统一 mini-SWE-agent 榜的价值正在于固定其中一部分变量，较接近模型横向比较。

LiveCodeBench Code Generation 优化的是从完整题面生成可通过测试的程序。它对算法推理、语言实现和测试鲁棒性敏感，却不要求在已有大型代码库中定位缺陷、理解工程约束或维护回归兼容。论文虽提供自修复、执行与输出预测场景，本站当前固定窗口排名只代表 Code Generation ^[5]。

整套评测设置的分差大于榜首差距

GLM-5 的 OpenHands 自报比统一 mini-SWE-agent 高 5.0 个百分点；MiniMax M2.5 的 Claude Code 四次平均比统一口径高 4.4 个百分点。MiniMax M2.5 在三个模型方设置之间从 76.1% 到 80.2%，范围为 4.1 个百分点。该范围比统一榜首 1.0 点差距更大，但不能归因于 scaffold 本身：提示、采样、上下文、运行次数和基础设施也同时变化 ^{[7] [8]}。

因此，“模型 X 在 SWE-bench Verified 得 80.2%”信息不足。最少还要写出 agent、agent 版本、提示是否修改、推理档位、token 与时间预算、重试次数、运行聚合方式和成绩责任方。统一榜适合比较同一框架中的模型；模型方自报适合说明某套完整系统能达到什么水平。

榜首差距没有超过当前分辨率

统一榜首 Claude 4.5 Opus 为 76.8%（95% CI：72.9%–80.3%，n = 500），Gemini 3 Flash 与 MiniMax M2.5 都为 75.8%（95% CI：71.9%–79.3%）。榜首差 1.0 个百分点，远小于保守 MDE 8.9 个百分点；Top 10 九组相邻比较经 Holm 校正后均不显著。

这不证明模型能力相同。它只说明聚合分、500 题和非配对近似不足以分辨这些细小差距。模型其实在同一批题上评测，取得逐题结果后应使用配对方法；重复运行还应报告题目级成功率分布与重测方差。

时间窗口能降低污染风险，但不会自动消除污染

LiveCodeBench 给每题记录发布日期，并建议只用模型知识截止日期之后的题。论文观察到 DeepSeek 与 GPT-4o 在各自截止日期后的 LeetCode 题上明显下降，把这种时间分段作为旧题可能受污染的证据 ^[5]。当前固定窗口榜首 O4-Mini (High) 为 74.6%（题目 bootstrap 95% CI：69.2%–79.6%），第二名 Kimi-k1.6-IOI-high 为 73.8%（68.5%–78.9%）。共同 279 题上的配对差为 0.7 个百分点（95% CI：-4.3–6.1，符号翻转 p = 0.892，Cohen’s dz = 0.017），没有证据支持榜首稳定领先。

固定窗口的代价是可比性随时间变化。若所有模型共用一个旧窗口，新模型可能在训练中见过题；若每个模型只测其截止日之后的题，各模型面对的题目集合又不同。较稳妥的报告方式是同时给出一个共同窗口和一个模型后截止窗口，并公开题目数、难度构成及实际最晚题目日期。

SWE-bench Verified 没有靠当前榜单窗口隔离训练时间。OpenAI 在 2026-02-23 表示不再用它评估前沿发布：其对 138 个高频失败任务的审计中，59.4% 存在实质性测试或描述问题；同时，被测前沿模型都能在部分任务上复现 gold patch 或题面细节，显示至少存在训练暴露 ^[9]。这项后续证据意味着 Verified 仍可用于受控系统回归与历史比较，但不应单独承担“最新模型真实软件工程能力”的结论。

讨论与局限

样本限制

SWE-bench 统计只使用 500 题聚合解决率，没有逐题配对结果，也没有统一重复运行。Wilson 区间与两比例检验假设题目独立、两模型结果不配对；同仓库任务可能相关，这一近似可能低估不确定性。MDE 是 p = 0.5 的规划近似，不是观察到的最小真实效应。LiveCodeBench 的逐题 Pass@1 已是每题多次生成后的聚合值；本文区间刻画题目抽样不确定性，不刻画同一道题内生成波动。

口径限制

统一 mini-SWE-agent 控制了 agent 与版本，但模型的 reasoning setting 仍不同，部分模型也未报告该字段。模型方对照同时改变框架、提示、采样、上下文和运行聚合，本文只能把差异解释为“整套评测设置敏感”，不能识别单一因果因素。两个 Benchmark 的分数单位都写成百分比，也不构成跨榜可比尺度。

外推限制

SWE-bench Verified 只覆盖 12 个 Python 仓库的 500 个历史任务；LiveCodeBench 当前快照只覆盖竞赛式代码生成，且页面窗口上界晚于实际最新题日期。两者都不能直接外推到新建项目、跨语言维护、代码审查、安全修复、需求澄清或长期协作。公开题集还会随模型训练时间累积暴露风险。

**编者观点：**代码能力报告应采用“双轴 + 设置卡”：一轴报告仓库级修复，另一轴报告时间切分的竞赛代码生成；每个分数旁固定展示数据窗口、任务数、agent 与版本、提示与预算、运行次数、来源类型和不确定性。榜首差距小于统计分辨率时，应写“未区分”，而不是把排序位置当作能力事实。