ProgramBench 是一个评测 AI 语言模型能否"从零重建开源程序"的黑盒基准：AI 只拿到编译好的二进制文件和文档，却要重写出一整套能复现原行为的代码。但不少新手会发现，某些测试不计入总分——它们被标记为gold_fail、dummy_pass等忽略原因。这篇新手解析带你一次性看懂：7 类测试忽略原因分别意味着什么，以及被排除计分的记录藏在哪里。

一、先用 30 秒看懂 ProgramBench 的评分流程 💡

要理解"为什么排除计分"，先要理解 ProgramBench 怎么打分：

1. 准备阶段：把一个开源 CLI 工具（多为 Rust/Go 项目）编译进 Docker 镜像，并删掉源码；
2. 重建阶段：AI Agent 只能与编译好的二进制交互，从零重新实现整个程序；
3. 评分阶段：用一组行为测试（behavioral tests）自动对比"重建版"与原程序的行为。

其中有一个关键角色：gold solution（参考标准解），即原始程序本身。一套测试要计入评分，前提是它对"标准答案"稳定通过、且对"假答案"能暴露问题。一旦某个测试不满足这两条，它就会被记录忽略、排除计分。

官方对忽略规则的完整说明见 CLAUDE.md，每个被排除的测试都带有reasons[].id，用于解释"为什么"。

二、7 类测试忽略原因一览表（建议先收藏）

记住一条总原则：所有被忽略的测试无论原因都会从评分中剔除，id只是给你看的"诊断标签"（informational，仅供参考）。

三、逐个拆解：每类忽略原因到底在说什么？

1. gold_fail —— 标准答案都过不了，测试本身有缺陷

如果一个测试在 gold solution（原始程序）上每次运行都失败，说明它不是"难"，而是"坏"：确定性失败的测试区分不了任何实现，只会被剔除。

gold_fail还覆盖一类隐性坏题——golden output 漂移（golden-output drift）：gold 二进制本身没问题，但当初录制的"标准输出"已经过期，比如相对构建工具链不可复现、内嵌了构建时间戳（build-stamp）、或依赖了外部资源。重放时对不上，标准答案照样挂。

仓库中的真实例子：canop__broot.d6c798e/tests.json 里的test_send_option_with_socket就是被gold_fail排除的。

2. gold_flaky —— 标准答案"时过时不过"

gold_flaky表示测试在标准答案上非确定性：有的运行通过，有的运行失败。典型来源是计时竞态、网络抖动、TUI 界面快照漂移这类 flake（偶发不稳定），而不是真缺陷。

注意它和gold_fail的区别：gold_fail是"每次必挂"，gold_flaky是"看运气"。两者都会被排除，但语义完全不同。

3. dummy_pass —— "空壳程序"也能通过，毫无区分度 ⚠️

这是新手最容易误解的一类：dummy_pass表示一个极简的"dummy"（空壳）可执行文件也能通过该测试。

想象一场考试，随便交一张白纸也能拿满分——这道题就失去了筛选能力。对 ProgramBench 来说，测试必须能把"真实现"和"桩（stub）"区分开；空壳都能过的题，对重建质量毫无贡献，因此排除计分。

真实例子见 canop__broot.d6c798e/tests.json：test_write_default_conf_idempotent被标记为dummy_pass，记录里还带了标注时间戳和标注者（timestamp、user）字段，说明该忽略是由维护者人工确认的。

4. outcome_dependent_presence —— 测试"时有时无"

这类测试在某些评测运行中出现、另一些运行中不出现（presence 取决于运行结果）。计分的分母忽大忽小，题目本身不可靠，只能整体剔除。

5. slow_or_hang —— 卡死或超时

测试在调用中途**挂起（hang）**或超过时长阈值。一个卡死的测试会拖垮整场评测，因此直接被排除。

6. dependency_ignored —— 被"连坐"的依赖测试

如果某条被保留的测试通过@pytest.mark.dependency(depends=[X])依赖于一个已被忽略的测试X，会发生什么？

X在收集阶段就被剔除，pytest-dependency会把依赖它的测试直接跳过——结果它会以"未解决"计入成绩，但这不是提交者的错。所以这类测试同样被标记忽略，且原因的note字段会记录前置条件，形如depends on ignored test <X>。

7. ignored_manual —— 人工排除

最后一条最简单：维护者手动判定某测试不计分（比如人工复查后发现测试写法有误）。前面dummy_pass例子中带user字段的记录，就是人工标注的痕迹。

四、新手实操：去哪里查"某条测试为什么被忽略"？🔍

所有忽略记录都以结构化 JSON 形式落在每个任务的tests.json里，路径结构是：

src/programbench/data/tasks/<owner>__<repo>/<hash>/tests.json

其中关键节点是branches.<分支hash>.ignored_tests[]，每条记录长这样：

{ "name": "eval.tests.test_cmd_execution.test_cmd_quit", "reasons": [ { "id": "dummy_pass" } ] }

• name：被忽略的测试全名；
• reasons[].id：上文 7 类原因之一（一条测试可以带多个原因）；
• 可选的note、timestamp、user补充人工判定信息。

任务的基本信息（仓库、commit、语言、难度）则在同目录的 task.yaml 中，例如 canop__broot.d6c798e/task.yaml 标明了这是hard难度的 Rust 项目。

代码侧的读取逻辑也很直白：load_data.py 中的get_ignored_tests()会遍历所有分支，把{branch}/{测试名}收集成集合；随后 eval.py 的without_ignored()在计算成绩时把这些测试从结果中剔除。

五、被排除计分的测试还会运行吗？会影响分数吗？

这是新手最关心的问题，答案分两层：

• 会不会影响分数？不会。被忽略的测试从"期望通过的集合"和"实际结果集合"中同时剔除，所以分母分子都不含它，榜单分数不受影响；
• 标签的作用是什么？纯粹是"诊断信息"。它告诉你这个任务里哪些题被作废、为什么作废，方便维护者后续修复或复核。

顺带一提，评测产物本身也公开可查：test_runs/correct 与 test_runs/incorrect 下各有一份示例提交和对应的.eval.json，里面逐条记录了每个测试的status（passed/not_run等），可以对照 calculator 任务的评测测试 理解"一条测试在评测中如何被判定"。官方使用指南 docs/README.md 也明确提示：由于存在非确定性的分支与测试，计算最终分数时建议直接使用programbench info的结果。

六、新手常见疑问 FAQ ❓

Q1：剔除测试后，分数还会公平吗？会。剔除的对象是"对标准答案都不可靠"的题，它们无论算给谁都构成噪声。ProgramBench 保留的正是能稳定区分实现好坏的测试。

Q2：看到gold_fail是不是说明 AI 写错了？不是。gold_fail说的是"原始程序本身都过不了这道题"，与任何提交无关。它指向的是测试缺陷或标准输出漂移。

Q3：gold_flaky和gold_fail我该按什么标准记？记住一个词就够了：fail= 每次必挂（确定性），flaky= 看运气（非确定性）。

Q4：怎么快速确认某个任务有哪些测试被排除？打开该任务目录下的tests.json，看branches下每个分支的ignored_tests数组即可，例如 sharkdp__bat.f822bd0/tests.json。

写在最后

gold_fail、gold_flaky、dummy_pass、outcome_dependent_presence、slow_or_hang、dependency_ignored、ignored_manual——这 7 个标签本质上是 ProgramBench 的"质检记录"：一道题只有既考得倒"假答案"、又稳定放得行"真答案"，才有资格进入计分。理解了这套排除机制，你再看榜单分数和任务数据时，就不会被个别失败的测试名误导了。