从真实业务难题构建模型评测

模型在榜单上领先，不代表它能做好你手里的工作。DEV 与 Kaggle 的这场评测挑战，把问题落到了具体任务上：时区换算、运行时内存、版本 API、代码审查，以及两个肉眼几乎分不清的字母。

五个获奖项目指向同一个结论：答案看起来合理、代码能够运行，仍然不足以证明模型理解正确。对程序员更有用的评测，应该从自己熟悉的难题出发，用可核验的事实和实际执行结果检查它。

答对常识题，为什么还会栽在具体条件上

时区项目问了 19 个前沿模型：11 月 Calgary 上午 9 点，Toronto 是几点？

按获奖项目的描述，Alberta 在 6 月停止切换时钟，因此答案应为 10:00，但 19 个模型全部回答 11:00。这里的政策变化是原文提供的测试前提，不能把它直接当成已经独立核验的现实信息。

这个项目更有价值的设计，是用公共时区数据库生成标准答案，而不是手写答案。数据库更新后，测试也能重新运行，让评测跟着事实变化。

另一个项目检查的是知识能否用对地方。作者实测了 PHP 数组与 Go goroutine 的内存占用，两种语言各覆盖四个版本，再向 12 个模型提问。表现最好的模型能引用相关发布说明，却仍会把变化套到错误情境；多数模型答错时也表现得很有信心。

知道一条更新记录，和知道它何时适用，是两种能力。

不过，原文没有列出这些语言版本、内存测量值和运行环境，所以我们只能认可评测思路，无法据此修正具体的内存估算。

代码能跑，为什么还要检查模型的解释

Blender 项目让十个模型为四个指定版本编写脚本，并逐一放进对应版本执行，题面包括 Blender 5.0。

有些脚本可以正常运行，模型却声称版本之间没有变化。作者要求每份答案列出它依赖的版本变化，才暴露出这个缺口。

运行成功只能说明当前脚本通过了当前场景。它可能没有触及发生变化的 API，也可能恰好走了仍兼容的路径。原文没有解释每个案例的具体原因，但它提醒我们：执行结果与版本知识需要分别检查。

历史漏洞项目则把检查往前推了一步。作者将包括 Ariane 5 在内的 26 起高代价软件故障，重建为小型代码样本，让 13 个模型模拟上线前审查。

模型几乎每次都能报出问题，却经常给错理由，甚至对完全不接触数据库的代码报告 SQL injection。作者还加入了伪装版本和已经修复的版本，分别检查模型是否只认出了著名事故，以及是否会对正确代码继续报警。

评审能力不能只按「有没有报错」计分，还要看理由是否成立、修复后是否停止报警。

输入里的一个错字，也可能污染后续答案

罗马尼亚语项目测试了 43 个模型，关注两组外观极其相似、但与土耳其语对应字符不同的字母，例如 Braşov 与 Brașov。

输入正确时，模型通常能拼对；输入先用了错误字符，约三分之一的回答就会沿用错误。污染还会扩散到模型自行选择的词，并不局限于复制原句。

作者尝试用一句指令纠正罗马尼亚语，结果又破坏了土耳其语，因为另一种字符在那里才是正确写法。

这说明，修复规则需要带上语言和使用范围。一次看似成功的纠错，如果只在原来的题目上复测，很容易把问题转移到别处。

我的判断

我认可这些项目把评测对象从「回答像不像专家」，推进到了「结果和理由能否被验证」。公共数据库、真实运行时、修复后的代码，都能提供比模型自信程度更可靠的依据。

但这篇获奖介绍没有给出完整的模型名单、提示词、采样设置和逐项结果，也没有提供与其他评测方法的对照数据。因此，它更适合作为评测设计案例，不能据此给模型排出可靠名次，更不能推断所有模型在所有任务上都如此。

几种方法也各有边界：执行测试可以验证行为，却未必验证解释；要求列出依据能暴露矛盾，但依据仍需外部核验；历史漏洞样本便于复现，却可能受到训练数据记忆的影响。作者用伪装与修复版本缓解了最后一个问题，原文没有证明它被完全排除。

能拿来做什么

• 评估 AI 生成的版本迁移代码时，把「代码在目标版本执行成功」与「准确说明依赖的 API 变化」分开验收，避免一次运行通过掩盖版本理解错误。
• 让 AI 做代码审查时，同时准备缺陷样本和对应的修复样本，要求它指出具体触发路径，并检查它是否仍对修复后的代码误报。
• 处理多语言文案时，把含错误字符的输入也纳入测试；增加纠错指令后，再检查其他语言中原本正确的字符是否受到影响。
• 给团队建立小型评测集时，优先收集业务里已经遇到的难题，并尽量让标准答案来自数据库、测量或执行结果，方便更换模型后重复验证。