[WB-Bench-Code] script_verifier 判分脚本中途异常退出时，未执行的检查项不计入分母，导致分数偏高

你好，感谢开源这套评测框架。我们在使用 code 子集时发现 script_verifier 家族的判分方式有一个边界问题，会让部分提交拿到偏高的分数。下面是复现和分析，供参考。

问题

script_verifier 家族的 tests/verifier.py 是线性执行的：所有检查项串在一个 try 块里，结束时由 finally: write_reward() 统计。检查项之间夹着未被 safe_record 包裹的裸语句，这些语句会直接调用被测代码。

一旦某条裸语句抛出异常，整个 try 块中断，后续检查项既不会执行，也不会进入 RESULTS。而分母取自 len(RESULTS)：

def write_reward():
    passed = sum(1 for item in RESULTS if item["passed"])
    total = len(RESULTS) or 1
    reward = {"overall": passed / total, ...}

结果是：被测代码越早让判分脚本崩溃，分母越小，分数反而越高。

最小复现

以 performance-hard-template_cache 为例。在官方 tests/gold.patch 的基础上，只删掉 jinja_like/cache.py 中 set() 的零容量守卫（1 行），用来模拟一个 除了没处理 cache_size=0 之外完全正确 的实现：

     def set(self, key, value):
-        if self.max_size <= 0:
-            return
         if key in self._items:

这样在 cache_size=0 时会对空的 OrderedDict 调用 popitem()，抛出 KeyError。

mkdir ws && tar xzf environment/workspace.tar.gz -C ws
cd ws && git init -q . && git apply ../tests/gold.patch
# 再应用上面那个 1 行的反向补丁
WORKSPACE=$PWD LOG_DIR=/tmp/log python3 ../tests/verifier.py
cat /tmp/log/reward.json

实测结果

Start with tests/verifier.py, especially the linear try/finally flow, safe_record usage, RESULTS collection, and write_reward(). Run the provided workspace.tar.gz reproduction for performance-hard-template_cache and compare the defective implementation with the independent-check result. Done means an exception in one check cannot inflate the score by excluding later checks from the denominator.