你好，我是拉克先生（Mr Lark）。

现在我选模型，先看它能不能解决我的真实任务，再看它在榜单上排第几。

榜单测的是标准题，不是你的任务

模型榜单每天都在变。一个模型今天登顶，明天就被超过。

但跑分高不代表它能写出我要的语气、改对我的代码、理解我的上下文。我遇到过不少：分数很高的模型，拿来干活却漏约束、编细节、答非所问。

腾讯混元团队的姚顺雨也提到：榜单很容易过拟合，榜单问题多是规范的单轮题；真实用户的问题更模糊，往往只有一两句话，还需要多轮追问。原文

CSuite 的文章给了同一个方向：真正有用的评测，可以来自你自己的 20 个真实输入，而不是几千道公开题。

榜单排的是平均能力。你自己的评测集排的是「哪个模型能做好你的工作」。

评测集也是 few-shot 库

自建评测集看起来有点重：整理 20 个 case，写期望输出，再写评分标准。

但这 20 个 case 还有第二个用途：它们会变成你的 few-shot 示例。

每个 case 都包含 Input、期望输出和评分标准。你记录的不是「模型 A 比模型 B 高 2 分」，而是「我希望 AI 这样回答」。

以后遇到类似任务，把 2-3 个 case 放进 prompt，即使用稍弱的模型，也会因为有了示例更接近你的偏好。

评测集不是一次性表格，它是你的 AI 使用说明书。

先收 20 个真实失败 case

第一版不要追求规模，20 个就够。能看出模型之间的明显差异后，再扩到 100+。

case 来源：你最近 1-2 个月翻车的记录——失败的聊天、没按风格输出的任务、漏掉关键细节的总结、改错边界的代码、出现幻觉的回答、需要反复追问才完成的任务。

真实失败案例比凭空造题更有价值。你要测的不是模型会不会答一道漂亮题，而是它会不会在你经常翻车的地方再翻一次。

每个 case 三样东西

Input：原始 prompt。可以修错别字，但别把问题改得太完美——真实用户本来就会省略背景、混用口语。

期望输出：你理想中的答案。手写也行，让最好的模型生成再由你改到满意也行。

评分标准：拆成可判断的维度，别写「整体不错」：

维度 权重
正确性 40%
完整性 20%
语气和风格 20%
无幻觉 20%

存成 JSONL，每行一个 case：

{"id":"writing-001","input":"改写产品介绍，保留功能点，不要营销腔。","expected":"语气自然、信息完整、没有夸张形容词。"}
{"id":"coding-001","input":"找出移动端按钮换行原因，只给最小修改。","expected":"指出 CSS 原因，并给出不影响桌面端的改法。"}

评分可以用 1-10 分，也可以用 Pass/Fail 加理由。

优先挑边缘案例

评测集需要多样性，但不要平均用力。覆盖写作、代码、总结、搜索、改写、分析即可。

真正拉开模型差距的，通常是边缘案例：语气不对、遗漏约束、误解上下文、编造事实、需要追问却直接回答。

先人工比较，再引入裁判模型

最轻量的做法：把同一个 case 喂给几个模型，手动比较回复。你已经能看出哪个适合写作、哪个适合代码、哪个看起来聪明但总漏关键约束。

想更系统化，做成表格：每行一个 case，每列一个模型输出，旁边放期望输出，最后一列放评分和理由。

再往后，才需要裁判模型打分。裁判模型也会偏，记得抽查。

别追榜单，沉淀自己的标准

公开榜单只适合做第一层筛选。真正影响日常效率的，是模型能不能理解你的语气、代码库、业务上下文和追问习惯。这些问题只能靠你自己的评测集回答。

先收 20 个真实 case → 看到差异后扩到 100+ → 需要稳定流程时加入 Rubric 和裁判模型。

这些 case 还能反过来变成 few-shot，你用它比较模型，也用它让模型更懂你。这比追着榜单换模型可靠。