从能跑通到敢交付：高难度评测题的四道硬坎

过去半年，给大模型搭建训练环境和评测题（Eval），成了数据行业最核心的赛道。早期的逻辑很简单：找几个程序员，把开源项目或者现成的业务题打包进一个虚拟环境里，再写一段自动打分的脚本。题目能跑通，测试能出分，这批数据就算交货了。

但最近一两个月，不管是买数据的模厂，还是做评测的机构，都撞上了同一个麻烦：现在的模型太擅长在评测环境里找捷径了。

如果一套题只是「能跑通」，模型进场跑上几轮，很快就能摸出里面的门道。它不一定要真把业务问题解决掉，只要找到出题人留下的线索，或者摸清打分脚本的脾气，就能拿到满分。这不是模型在「作弊」，而是它的模式匹配能力已经强到可以绕过题目真正想考察的能力，直接命中评分规则里的缝隙。

前阵子，我们在内部打磨一批终端与复杂工程（Terminal-Bench 类）高难度题目时，特意从 70 多道候选库里挑出 10 道最难的题，让目前综合能力最强的编程模型之一连跑了 80 遍（每道题 8 次独立尝试），又把题目、环境和判卷脚本底朝天查了一遍。

折腾完这一轮，我们最大的感受是：把一道题做到「能跑通」，可能只需要半天；但要做到真正能试出模型深浅、敢交付给客户用于训练和评测，后面还有四道硬坎要过。

第一道坎：别考「照着说明书干活」，要考「几份材料对不上时听谁的」。

现在市面上很多编程或办公评测题，都很像大学期末考试：给一份干干净净的表格，再给一份清清楚楚的说明书，让模型按要求写段代码算个数。这种题，现在的顶级模型不费什么力气就能拿高分。但只要把它们放到真实公司里干活，往往还是会搞砸。为什么？

因为真实工作里，几乎没人会给你一份干净的说明书。

我们在设计这批高难度题时，专门换了一个出题思路：不再给模型单一的干净数据，而是把好几份来源不同、甚至互相矛盾的材料同时丢给它。

打个比方，其中有一道题是帮公司算云服务器怎么买最省钱。如果按传统出题法，就是给一张过去一个月的服务器使用率清单，让模型算个最优套餐。但在真实企业里，财务看的云账单、运维看的监控后台，和系统自带的自动扩容日志，这三本账经常是对不上的。

比如一台按小时租用的服务器，只开了 20 分钟就关机了。监控后台记录这 20 分钟的负载是 90%；但财务的云账单系统是整点出账，不仅会晚一个小时才显示这笔费用，还会把剩下没开机的 40 分钟全按「负载为 0」算进平均值里。

如果模型只是机械地把几张表合并起来算平均数，算出来的采购方案肯定亏钱。它必须像一个老练的财务审计一样，先看懂这三套系统各自的记账规矩，把对不上的时间点和异常账单剔除掉，才能算出真账。

再比如另一道管机房磁带库的题。机房里有两套日志：一套是管理员日常登记的台账，另一套是磁带机自动生成的扫描记录。中间不仅有人不小心把同一张条形码贴纸贴在了两盘不同的磁带上，还有机器因为断电重启，内部时钟被重置回了出厂时间。

模型如果偷懒，直接按文件名或者时间戳排序，马上就会掉进坑里。它得顺着机器每次开机的引导序列号，像侦探拼时间线一样，先把乱掉的先后顺序理顺，才能分清哪盘磁带上的数据才是最新的。

把这些职场里最常见的「烂摊子」放进考题，一个资深行业专家往往要花 3 到 8 个小时才能做完。但也只有这种题，才能看出模型到底是只会背代码模板，还是真的具备在复杂业务里抽丝剥茧的能力。

第二道坎：网上的旧题早被背熟了，得自己写程序「造现场」。

做评测题的第二个头疼问题，是模型「背题」。现在的基座模型几乎把互联网上公开的代码库、技术论坛和题库全读过一遍了。如果你直接从网上搬一个现成的开源项目或者历史故障当考题，模型往往不需要现场推理，凭着预训练时的印象就能把答案默写出来。

为了彻底堵死背题的可能，我们的做法是：不搬运网上的现成数据，而是针对每个业务场景，专门写一套「造题程序」，从零生成全新的业务现场。

比如我们要考模型「怎么帮电影配乐师对齐录音棚的音轨」。我们没有去网上找现成的音乐素材，而是直接用数学公式和音频合成算法，现场生成了一段全新的交响乐排练录音。

造题程序不仅在音频里精准埋入了节拍器的咔哒声、录音师打板的脉冲信号，还顺手伪造了一整套配套的演出排期表、乐谱小节表和录音棚切换日志。

甚至连海洋考察船的水温校准数据、银行老旧系统的二进制交易账本、市政土地的勘测坐标，全都是由底层的物理公式或业务规则脚本现场算出来的。

这样做有两个最实在的好处：第一，这些数据在互联网上从来没有出现过，模型绝对不可能提前背过答案。

第二，题目从此变成了「活水」。只要改一下造题程序里的随机种子和参数配置，哪怕客户那边的模型把这个环境刷上一千遍，每一次进场看到的账单数字、故障位置和音频波形都是全新的，从根源上解决了数据包「用两个月就被模型记住、彻底报废」的问题。

不过，程序化造题在解决背题问题的同时，也引入了一个新的风险——造题脚本本身就是一份完整的标准答案。如果环境打包时处理不当，这份答案就会泄漏给考生。这就引出了第三道坎。

第三道坎：考生和标准答案，绝对不能待在同一间屋子。

这真不是杞人忧天。前不久海外机构审计一些知名榜单时就发现，不少数据供应商为了省事，在打包虚拟环境时，先在容器里运行一遍造题脚本生成考题，然后再执行一行删除命令，把造题脚本和标准答案删掉，最后打包交给模型去考。

听起来好像没毛病？但在计算机系统里，这就好比你把写满答案的草稿纸撕碎扔进了房间角落的废纸篓，却忘了把废纸篓拎出房间。

现在的智能体都是操作系统的老手。它在考场里做不出题的时候，真的会去遍历文件系统、翻查 shell 历史记录、读取 /tmp 和 /proc 下的残留信息，甚至尝试从文件系统的日志里恢复被删除的造题脚本，直接照抄里面的标准答案。

更隐蔽的一种情况是：有些题目需要模型写好一段处理程序，交卷之后，判卷脚本再拿几组新的测试数据去跑模型的程序，看它写得对不对。如果判卷时，新测试数据的标准答案就放在同一个文件系统里，模型的程序完全可以在运行时偷偷打开答案文件读取内容，再原样输出。

为了不给模型留任何钻空子的机会，我们在环境工程上立了一条死规矩：考生考试的容器，和造题、改卷的容器，必须做严格的环境隔离。

首先，造题程序只在专门的「制卷容器」里运行。等考题数据生成好之后，我们只把题目文件单独提取出来，放进一间干干净净的「考场容器」里。造题脚本、生成日志、中间产物，全部留在制卷容器中，绝不进入考场。

模型在这间考场里就算把文件系统翻个底朝天、把每一条 shell 历史都查一遍，也找不到半行造题代码，因为制卷的过程根本就没在这个环境里发生过。

其次，等模型做完题交卷，我们会直接销毁考场容器，只把模型交上来的答卷带进独立的「阅卷容器」打分。哪怕是必须现场运行模型代码来测试的题目，我们也会在运行前，把装着标准答案的文件彻底收回读取权限，让模型的代码在文件系统层面就碰不到答案。

只有把考场纪律做到这个份上，模型拿到的每一分，才真正是凭本事算出来的。

第四道坎：不仅要防模型钻空子，还要给「判卷脚本」挑刺。

很多人以为，题目出难了、考场封严了，评测就算做完了。但我们自己拿顶级模型在这 10 道题上实测了 80 遍之后发现，真正最考验团队专业度的，其实是最后一步——回头去查我们自己写的判卷脚本，看有没有「错放一个坏人」，或者「冤枉一个好人」。

举个最好懂的例子：为什么做不出题的模型，交一张白卷反而能拿满分？

在一些算金融风控或者物理数据的题目里，判卷脚本会检查模型算出来的数字跟标准答案差多少——比如设定一条规则：「只要误差大于 0.001，就算错」。听起来很严密对吧？但如果模型没算出来，往表格里填了一个「空值」或者「非数字（NaN）」呢？

在 IEEE 754 浮点标准下，NaN 与任何数值的比较运算——包括大于、小于、等于——结果都是「不成立」。于是，「误差大于 0.001」这个判断直接失效，判卷脚本没有捕获到异常，顺手就给这张白卷打了个满分。

我们事后复盘发现，根源在于判卷脚本拿到模型输出后，直接跳进了数值比较，缺了最前面一道「这是不是一个合法数字」的门槛检查。补上这一步之后，白卷再也混不进来了。

再比如另一个让人哭笑不得的「防作弊误伤」。有道题为了防止模型投机取巧去复制系统里的参考文件，当时写判卷脚本的工程师加了一条防作弊规则：「如果模型交上来的结果，跟标准答案一模一样、连一个字节都不差，说明它是抄的，直接判零分。」

这本来是为了抓作弊，结果真把模型放进去考的时候出事了：这道题本身是一道确定性的计算题，只要全算对，得出来的表格排布就是唯一的。这意味着，如果一个老老实实算题的模型真的做到了 100% 正确，反而会被防作弊规则当成抄袭，直接判零分。

我们最终把这条规则替换成了对模型运行时的文件系统访问日志做审计——查它有没有碰不该碰的文件路径——而不是在结果层面做「一模一样就是抄」的启发式判断。

还有一类更隐蔽的问题：题面和判卷标准没对齐。

前面提到的那道云服务器算账题，模型其实非常聪明，8 次尝试里有 7 次都成功看穿了云账单和监控日志对不上的陷阱，把最难的业务逻辑全算对了，最后得出的省钱比例是 19.7738%。结果判卷脚本判了它 7 次零分。为什么？因为题面里只写了一句「请输出精确的数字」，没有写保留几位小数。

模型按常见工程习惯保留了小数点后 4 位，而判卷脚本死板地要求必须写到小数点后 6 位（19.773822%）。

再比如一道画土地边界图的题，模型把 66 块土地的面积和边界全算对了，却有 6 次因为「外框尺寸不对」被判失败。

我们放大图纸查了半天才发现，原来是生成标准答案的脚本在地图边缘多留了一个浮点精度级别的残余顶点——坐标偏差不到十亿分之一，肉眼完全不可见——却把标准答案的包围盒撑大了一圈。而模型交上来的图纸干干净净，反而因为包围盒比标准答案小，被死板的脚本扣了分。

把这类判卷漏洞全部修补完之后，我们由此建立了两条出题铁律：所有涉及数值输出的题目，题面必须显式声明精度、单位和有效数字位数；所有标准答案的生成脚本，必须经过至少一轮「残余数据」审计，确认没有浮点噪声污染。

修补完所有判卷漏洞后，这 80 场考试的最终成绩单也出来了：目前最强的编程模型，总通过率约为 27.5%（80 次独立尝试中通过了 22 次）。每一道题的通过率落在八分之一到八分之三之间。

需要坦诚说明的是：每道题 8 次尝试，是在工程成本约束下的折中方案，样本量并不算大，单题通过率的波动区间不窄。我们更看重的，不是这个精确到小数点的百分比，而是失败模式的定性分析。

但即便是 27.5% 这个数字本身，也说明了一件重要的事：这套题在当前最强的模型面前，仍然有足够的区分度，远没有到「天花板效应」。

同时，我们在另外两个不同技术家族的模型上做了交叉验证，确认这套题不是只对某一个模型「恰好难」，而是真正在考察多源推理、工具调用和复杂工程决策这些跨模型的通用能力。

我觉得更有价值的，是把那 58 份没通过的答卷全部摊开、逐一人工复盘的过程。看完这 58 次失败，我们发现模型不及格的原因，完全分成了两类。

一类确实是模型能力还不够。比如在修机房交换机配置的时候，模型为了让报错的那几个接口测试通过，干脆大笔一挥，把配置文件里其他几十个原本正常的接口全删了——这就好比为了让客厅的灯不闪，直接把卧室和厨房的电线全剪断了。这种卷子判零分，一点都不冤。

但另一类失败，却给我们这些出题人提了个醒。比如前面提到的云账单题和土地边界图题，模型其实已经把 99% 的硬骨头啃下来了，最后只是栽在了出题人没交代清楚的格式细节上。如果不去做这种颗粒度的人工复盘，只看冷冰冰的分数，你就会误以为「模型完全不懂算云账单、也不会画地图」。

但拆开一看才明白，问题出在我们的尺子没量准，而不是模型的手不稳。

这种区分至关重要。尤其是当这批数据同时被用作后训练的奖励信号时，一个有缺陷的判卷脚本送出去的不仅是错误的分数，更是错误的训练信号——它会让模型学到「只要删掉多余的配置就能拿高分」或者「精度不重要，差不多就行」这类危险的策略偏好。

为什么要花这么大力气，跟这 10 道题、80 条测试轨迹死磕？因为评测和训练数据这门手艺，到了今天已经变了。

当大模型只能做做简单的课后习题时，大家拼的是谁招的兼职多、谁攒题的速度快。但当模型开始往深水区走，要去接手金融算账、机房排障、工程改造这些真正能替企业省钱的活儿时，粗糙的题库不仅测不出模型的真实水平，还会给模型的后训练送去错误的梯度信号，让模型在错误的方向上越走越远。

说到底，一套真正敢交付给客户的高难度评测集，从来不是把代码往容器里一塞就完事的。出题的人得真懂业务里的烂摊子，搭环境的人得防得住最聪明的模型钻空子，写判卷规则的人还得愿意趴在几十条失败记录里，分清楚哪些是模型真不会，哪些是我们自己的尺子没量准。

而下一阶段的评测竞争，我们认为不再是比谁的题量大、谁攒题的速度快，而是比谁的判卷经得起模型反过来审计，比谁的环境工程堵得住最极端的钻空子路径，比谁能在每一次模型能力跃升之后，仍然拿出一套有区分度的新题。

把这些看不见的笨功夫做扎实了，交付出去的每一个分数、每一条数据，才经得起推敲。

关于 DataMining 德塔曼宁 专注为大模型与智能体研发提供高质量原创任务数据与可执行评测环境。我们交付的不是二手的 CoT，而是带确定性验证器的 Harbor Task、正负对冲的原子级 Rubric 与环境状态快照。 可承接的评测与数据方向：Deep SWE / Frontier SWE 长程代码工程、ALE / Terminal-Bench 真实工位操作、HLE 严格多模态产线、Harvey LAB 与 Automation Bench 专业 Agent、35+ 原子级 Rubrics 行业工作流包，以及 Win11 / Ubuntu 标准化桌面 Agent 镜像。 本文引用的基准、数字与官方发布均为公开第三方成果；文中涉及的能力判断为我们的内部同口径结论，不代表第三方官方结论。