实践是检验AI的唯一标准

几周前我见了位模厂的朋友，他说自己有一个自用的Benchmark，有一些极其冷门的题目，可以更精准地对新发的模型有体感，

显然，在中国模型们把榜单刷飞了的当下，这个Benchmark很有价值。

于是我问哥们有没有兴趣把Bench开源了，他说，「任何一个公开的Benchmark都将是被模型刷榜的废纸，这玩意只适合自己琢磨自己的。 」

虽然哥们不想公开自己的个人Benchmark，但他想用自己的经验和方法来教更多的人如何结合现有的工具建立自己的Benchmark。

于是写了一篇Bench指南给大伙。

以下是他写的：

我之所以要建自己的Benchmark，主要有三点原因：

1.让我放心做喷子

我的个人Benchmark在年初喷GLM瘸腿，现在喷DeepSeek Coding能力不足的时候，给了我非常大的底气。

网民是真可怕，说GLM不好、DS不行好似犯了天条。

2.好奇模型什么时候能替代掉我的大部分工作

3.建立我个人的知识库

01

好的Benchmark源自真实场景

在与大模型打交道的过程中，相信很多人一定经历过这样的场景：

稍微修改了一下 Prompt，感觉效果好像变好了，但又不确定是不是心理作用；

换了一个号称「Ultra、SOTA、国产之光」的新模型，结果在某些日常任务上效果反而开始雪崩；

跑了几个经典场景，感觉还行，可一上线或者批量使用，各种匪夷所思的错误层出不穷。

这些问题从传统NLP时代就一直存在。这也是Benchmark存在的意义：

需要完整验证一个场景下模型能不能Work，你不应该挑几个试试就下结论，评测需要尽可能模拟某个场景的实际状态。

建立Benchmark的目的，一是为了有立场，二是为了定义立场。纯显示分数也没有意义，人需要归因，去看数据的分布，才知道下一步该改 Prompt、换模型，还是补流程。

而好的Benchmark一定是从真实场景里长出来的。

从前在工业场景下，很多的Benchmark是先从客户那边获取到具体的case，然后再人工泛化。

现在有了大模型后，很多的Benchmark就是跑去公开数据集里抄题目，或者让模型根据一个case批量合成几百个case。

但在我眼里，任何不贴合实际场景的Benchmark都是立不住脚的。

个人场景应该是完全由自己遇到的问题累积汇总而成，至少第一版必须完全从真实场景里总结出来，不能直接造。

真要批量造case，请用聪明模型去测蠢模型。

02

怎么设计Benchmark和case

我Benchmark中有部分常识题一直存活到了GPT-5时代。GPT-4的Aha时刻出现的时候，其实很多传统NLP的复杂case还是能难住模型。

首先要注重数据分布。

我的Benchmark能活得比较久，是因为我给它设置的应用场景覆盖比较广。

我是一个物理和计算机双修的学生，然后还辅修了一个文学专业。

所以我的整个Benchmark覆盖了数学、物理、计算机、文学、历史、我求职中遇到过的面试题，以及我工作中遇到的业务难题。

我大概的数据分布是数学、物理、计算机理论知识各10%，历史知识 5%，生活常识 5%，文学 20%，Coding 和工作问题占40%。

这个分布是我整个人认知和经历的体现。

虽然年初GLM解决了我很多的Coding case，但它没有办法很好地回答计算机专业里 Limits of Computation （可计算性的边界）的题目。

还有一些比较偏僻冷门的历史问题，国产模型到现在也没法回答。

比如我就阴暗地加入了清军入关的细节事件（从一些明末史料里看到），俄罗斯在二战的几次战略和军备决策（大学有门课叫Russia’s Today），甚至会问 KV-1能不能击穿百夫长正面装甲。

而文学方面，模型会对run-on sentence（两个本该独立成句的分句被硬塞进一句里）、sentence fragments（句子残片）矫枉过正，也会对混乱时序出现误解。

最大的坑是衔接词滥用和修辞手法错判。

首先模型不太能看出手写文章的衔接词滥用问题，因为它自己就是这么干的；

其次当你用夸张修辞时，模型会说这段文字逻辑有问题，还会强行把一些梗或者人想表达的内容纠正成平庸的内容。

如果case跑挂了，问题可以归因成以下四种类型（源自 Bloom’s Taxonomy）：

事实性知识：孤立的基本知识节点，比如「法国的首都是巴黎」

概念性知识：各成分之间的关系与结构，比如因为A所以B的因果链。大模型出来后我还对它做了语义、逻辑、时序的细分

程序性知识：如何做的方法、步骤、算法与技能）

元认知知识：对自身认知的意识和监控，比如「我不确定」「我可能错了」。

这种归因方式最大的好处是，让非技术同学具体知道模型哪不行，再后面根据结果去优化模型/Agent了。不干优化的朋友不用学。

03

如何建立起你自己的Benchmark？

理解了前文后，我们接下来直接上手。

对非技术人员，电子表格就是最好的数据库。我们可以把复杂的嵌套 JSON 降维成一张表格。

首先是攒题。

case不需要专门去憋，想到什么就记录什么，你的文档里有什么就让模型帮你梳理。

平时用AI被坑一次，就攒一个。当场把那段对话原样存下来，丢进一个固定的地方，比如在备忘录里建个「AI 翻车」的文件夹。

隔几天把它们抄进题库，再写一句你本来希望它怎么答，这句话就是后面判定规则的底子。

起步攒个二三十个就够了，不需要上来就是几百题。分布照着自己平时用 AI干的活来，用得多的场景就多放点。

其次在题库里放题和判定规则。

表格拆成两页（可以直接复制到 Excel / Notion / 飞书表格）：一页放题，一页记成绩。题库不变，成绩单每跑一次加一遍。

如上图，其中D列的判定规则不要写成「必须包含某个词」。

我最常用的方法是，答案里必须提到什么；不能出现哪种做法；漏了哪一点就算挂。

拿 CASE-002 举例，如果写成「不得包含‘保证收益」，靠谱的模型多半会说一句「没有哪只股票能保证收益」做投资风险提示，这样反倒会被判挂了。

最后则是成绩单页。被测模型、Prompt 版本、运行环境这三样就是变量，要求每次只动一样。

比如CASE-001 只把 Prompt 从 v1.0 换到 v1.1，模型和环境都没动，结果从挂变成过，说明Prompt 改对了。

你的Benchmark一定会越来越快被模型击穿，尤其在Coding场景。

但其实某个场景被击穿无所谓，还有更多领域可以测试模型边界。

被SOTA模型打爆了也不丢人，现在我的Benchmark更多是为了看各家模型之间的差距。

04

邪修之交给 Agent 自动跑

如果你手头有现成的 AI 助手（如 Workbuddy/千问办公/豆包工作），最邪修的做法是直接把你的 JSON 结构当任务说明书，让 AI 按照 JSON 里的规则自己考自己。

你也不需要写 Python 脚本去解析 JSON。

表格攒好后，直接丢给 Agent，让它照着上面那个 JSON 的格式，把每一行转成一条 case，存进一个叫 my_cases.json 的文件。

然后给 Agent 发送下面这段指令（想测哪个模型，就先在 Agent 里切到哪个模型）：

单独起一个子任务（子 Agent 或新会话）作答，只给它 input 里的 system_prompt 和 user_input，别给 expected 和 evaluation。回答原样拿回来，判卷你来做。
对照 must_include 和 must_not_include 逐条检查，写出命中还是没命中。
按 score_weights 分项打分，每项引用回答原文做依据，总分对照 pass_score。
不管过没过，都在 execution_history 末尾追加一条：model、prompt_version、score、passed、failure_reason、tested_at，旧记录不动。没过的，在 failure_reason 里写明属于哪一类：Facts 事实性 / Relations 概念性 / Procedures 程序性 / Meta 元认知知识。
最后给我一张表：通过率、错误集中在哪一类、和上一次比哪些由挂变过、哪些由过变挂。

5年前我要做一个Chatbot，我得手搓2000条的Excel。现在只需要一句话就能办到。

模型实在太擅长把非结构化的内容拆解为结构化信息，自动化流水操作也不需要技术介入。

虽然我的 Benchmark 不能公开，但照着这篇搓一份自己的也不费事。

下次大伙喷哪家模型要是有人说你犯了天条，直接把结果甩出来公开处刑。

（本文封面由ChatGPT生成，纯人工写作）