编码评测的信号与噪声：先审题，再信排行榜

先说结论

编码评测最先要证明的不是模型强，而是题目公平。提示、测试和参考补丁三者只要不一致，失败就可能是数据缺陷；测试覆盖不足时，成功也可能是假阳性。排行榜小数点后的差异，建立在 task 质量审计之后才有意义。

问题

真实开源 issue 是为人类协作写的，常依赖讨论、上下文和维护者默契。把它自动切成孤立题目后，隐藏测试可能要求提示没说的细节，或只接受参考实现的形状。OpenAI 报告其流水线在 SWE-Bench Pro 的 731 个公开任务中标记 200 个破损任务，独立人工标注识别 249 个，并据此估计约 30% 任务有问题。该比例属于厂商对特定版本的审计，本站未复核。

核心机制

四类高频噪声需要分开：过严测试把实现细节当需求；欠规格提示遗漏隐藏断言；低覆盖测试让残缺实现通过；误导性提示把 Agent 引向与 grader 相反的行为。有效审计不是让另一个 Agent 看标题猜标签，而是同时检查题目、仓库约定、模型尝试、失败 trace、测试与 gold patch，再由多人独立裁决争议。

接入 Zero-to-AI 的实践

对每个编码 case 建立“Base → Source”证据链：Base 是干净提交与原始失败；Source 是可见需求、直接调用者和既有测试；候选补丁只是被测输出。先让人工参考解通过全部 grader，再用至少一个功能等价但实现不同的替代解测试 grader 是否过严；再注入一个只修表面症状的坏解，确认低覆盖测试会拒绝它。trajectory 用来解释失败，不直接替代功能判定。

低成本实验

输入： 选 6 个本仓历史小修复，每个保留问题描述、基线与测试。

步骤：

1. 不看原补丁，先让两位审阅者分别写验收条件。
2. 运行原补丁、一个等价替代解和一个故意不完整解。
3. 把失败归入四类噪声或真实能力失败，并记录证据行。
4. 只有争议 case 才升级给第三位审阅者。

成功证据： 原补丁可通过，等价解不被实现细节误杀，不完整解不能蒙混过关；每个标签能指向提示或测试中的具体冲突。

停止线： 无法获得可运行基线、参考解或隐藏断言的设计依据时，不发布模型排名，只把 case 标成“待审计”。

误区

• “难题零分说明模型弱”：大量重复 trial 仍零分时，应先怀疑题目或环境。
• “五人投票就是真相”：人数不能弥补未读代码与测试的表面判断。
• “删掉坏题即可”：先保留版本、标签与删除原因，否则下一版会重复引入。

原文与证据边界

官网标题和日期与给定来源一致。文章中的任务数量、比例和人审结果均为 OpenAI 报告；本文没有取得数据集快照与标注记录，不能独立确认约 30% 的估计，也不把它外推到所有 SWE 类评测。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。