a03 教你设计第一套评测集的内容（矩阵/配比/模板），这篇教你怎么让它「活」：种子任务 → 失败固化生长 → 回归集守底的三步飞轮，加难度校准（Goldilocks band）、失败三筛子、冒烟/核心/全量三层跑法。与 a03 是「内容设计」与「生命周期」的互补。
先修：a03（Eval Set 实战）。已读完 a03、准备真正动工建集的人。12 周时间线（6→23 个任务）展示了健康评测集的生长节奏。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
评测集的价值在「准」不在「大」——你一开始不知道 Agent 会犯什么错，凭空设计只会造出一堆它本就不会错的无效用例。让它在真实使用中生长，条条命中要害。
① 去重（同类已有则调权重不新增）；② 严重性 × 频率（优先高风险高频）；③ 能否写出稳定判定标准（写不出先别收）。
任务难度要落在「不太易也不太难」的甜区：太易大家满分、太难大家零分，都没有区分力。最有信息量的是「当前 Agent 有时能过、有时过不了」的临界任务。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
前面几讲我们一直在读别人的基准——读懂它们、也拆解了一个好基准是怎么造出来的。但有一句话我们反复念叨：公开基准 ≠ 你的业务。这一讲，我们就来做那件真正拉开团队差距的事——从零，为你自己的业务，建一套专属评测集。
我先把话说重一点：会刷榜的人很多，但有一套贴合自己业务、还在持续生长的评测集的团队，凤毛麟角。后者才是把"凭感觉迭代"变成"靠数据迭代"的分水岭。
先说清楚，为什么再好的公开基准，都替代不了你自己的评测集。三个硬伤：
一是覆盖不到你的业务。GAIA 不懂你的退款 policy，WebArena 里没有你们的后台系统。你最关心的那些场景——你的业务规则、你的工具、你的边界情况——公开基准一个都不测。
二是抓不到你的失败模式。你的 Agent 会怎么翻车，是由你的具体场景决定的。你的真实流量才知道。公开基准照不出你的"专属病症"。
三是公开的会被污染、会饱和。它们的分数越来越不可信、越来越分不出强弱。而你自己的、不公开的评测集，天然没这个问题。
结论很简单：公开基准用来选型和借设计；专属评测集用来做真正的质量决策。打个比方：公开基准像驾照考试的标准科目，证明你"会开车"；而专属评测集像你每天实际要走的那条路——有哪个路口爱堵、哪段限速、哪里常有行人。能开车不等于能把"你这条路"走好，后者才决定用户体验。
不要一上来就想攒一个大而全的评测集——从一个很小的集合起步，让它在使用中持续生长。
很多团队卡在第一步，就是因为把"建评测集"想成了一个浩大的、要先标几百上千条数据的工程，于是迟迟不开工。这是个误区。正确的姿势是反过来的：先用很小的集合跑起来，再让它在真实使用中自己长大。
为什么这样对？因为评测集的价值不在"大"，在"准"——准确命中你 Agent 真实会犯的错。而你一开始根本不知道它会犯哪些错，非要凭空设计，只会造出一堆"它本来就不会错"的无效用例。让它在使用中生长，每一条新用例都来自一个真实的失败，条条命中要害。
起步的目标不是"全面"，是"能跑起来、能照出明显问题"。10 到 20 个手工挑选的任务，通常就够发现 Agent 最扎眼的毛病了。
这些种子任务从哪来？三个最好的来源：
关键提醒：每个种子任务都必须带判定标准（没判定标准的不叫 task）。别只写"用户要退款"，要写清楚"成功 = 钱真退了 + 邮件状态一致 + 退款前查过订单状态"。
用退款 Agent 举例，一组合格的种子任务大概长这样——注意它怎么覆盖全景图的不同维度：
| # | 种子任务 | 在考什么（全景图维度） |
|---|---|---|
| 1 | 正常可退订单的退款 | 任务完成（happy path） |
| 2 | 已发货、按 policy 不可退的订单 | 任务完成 + 守规矩（该拒绝） |
| 3 | 退款接口超时 | 错误处理 / 自恢复 |
| 4 | 请求人身份与订单不符 | 安全（越权） |
| 5 | 同一订单重复发起退款 | 一致性 / 防重复执行 |
| 6 | 模糊请求"我要退钱"（没给订单号） | 该不该向用户澄清 |
你看，光是 6 个用心设计的种子任务，就已经把"happy path、policy、错误、安全、一致性、澄清"全扫到了。这比 100 个全是"正常退款"的用例有用得多。
这 6 个任务，是拿全景图"扫"出来的。它们不是拍脑袋来的——拿三层 × 四维当清单逐格扫：挨个维度问自己一句"这一维，我有没有一个任务在测它"。再叠上三层：这些任务里，有没有几个是专门看轨迹（过程对不对），而不只看端到端（成没成）的？很多评测集不是做得不够多，而是做得不够"全维"——一股脑全堆在"端到端 × 任务完成"那一个格子里。用全景图扫，能逼着你往别的格子也放上种子。
每发现一个新的失败，就把它变成一个新任务，加进评测集。
无论这个失败来自哪——线上用户的投诉、内部试用时的翻车、你 review 轨迹时发现的"它这次蒙对了但其实很危险"——都把它固化成一个带判定标准的 task，存进评测集。这样做有三个好处：
随着 Agent 变强，你还要主动加更难的任务去挑战它——评测集要始终"压着" Agent 一点点，它才有持续改进的方向。一个停止生长的评测集，很快就会被 Agent 追平，然后失去区分能力（又是"饱和"）。
这背后是一个叫难度校准（difficulty calibration）的概念：评测任务的难度要落在一个"不太易、也不太难"的甜区（有人叫它 Goldilocks band）——太易了大家都满分、区分不出好坏；太难了大家都零分、也看不出进步。最有信息量的任务，恰恰是那些"当前 Agent 有时能过、有时过不了"的。评测集正是靠不断补进这种"临界难度"的任务，来保持它的区分力。
但不是每个失败都值得变成任务。生产里失败成百上千，无脑全收会让评测集迅速臃肿、还塞满重复。收之前过三道筛子：① 去重——它是不是已有任务的同类？是就只调整权重、不新增。② 看严重性——后果大不大、出现频率高不高？优先收"高风险 + 高频"的。③ 能不能写出稳定的判定标准？写不出清晰判定的，先别收，否则它只会变成噪声。一句话：评测集要长，但要长肌肉，不要长脂肪。
第 0 周：拿全景图扫出 6 个种子任务，跑起来——发现"退款接口超时"那条直接崩，记一笔。第 2 周：内部试用，有人发现 Agent 对"部分退款"（只退一件）处理错了 → 加任务 #7、#8。第 4 周：上线小流量，冒出一个谁也没想到的场景——用户用了优惠券，退款金额该不该含券值？争论半天 → 加任务 #9，并顺手补了 oracle。第 8 周：一次 prompt 优化后，#2（已发货拒退）悄悄退步了，幸好它在回归集里、CI 当场拦住 → 没出事故。第 12 周：评测集 6 → 23 个任务，每一个都来自真实失败或真实争论，全维覆盖、条条命中要害。
你看，它从来不是"一次设计好的"，而是一周周"长出来的"。一年后，这套集合会成为新人理解"我们的 Agent 会怎么错"的最佳教材。
生长不等于喜新厌旧。那些 Agent 已经搞定的老任务，不要扔，要永久留在一个"回归集"里。
回归集的作用，是防止退步。Agent 的改动经常是"按下葫芦浮起瓢"——你修好了 A 场景，却悄悄弄坏了三个月前早就搞定的 B 场景。如果没有回归集，这种隐性退化神不知鬼不觉，直到用户投诉。有了回归集，每次改动都让它跑一遍，退步当场就会被逮住。
这也是为什么评测集最终要接进 CI、当成上线门禁的一部分。这里你先记住：新用例驱动进步，回归集守住底线，两者缺一不可。
这三步不是一次性的，而是一个持续转动的飞轮：真实使用/试用 → 发现失败 → 固化成带判定标准的新 task → 加入评测集 → 修复 Agent / 跑评测 → 通过的老 task 沉淀进回归集守住不退步 → 继续真实使用（飞轮再转）。
飞轮转得越久，你的评测集就越贴合业务、越值钱。它会慢慢变成团队最重要的资产之一——一份精确记录着"我们的 Agent 在真实世界里会怎么错"的活档案。
为了让你今天就能开工，给一个任务（task）的字段模板：
id：退款-006；描述/输入：用户："我要退钱"（未提供订单号）；初始状态：该用户名下有 2 个订单，其中 1 个可退、1 个不可退；判定标准——结果目标：未在信息不全时擅自退款，最终引导用户确认了具体订单；过程目标：主动向用户追问订单号，而不是瞎猜；参考解（oracle）：一条已知正确的处理轨迹（证明此任务可解、也用来校验评分器）；难度：中（需澄清 + 多轮）；来源：2026-06 线上一次误退款事故；评分器：代码查 outcome（无错误退款）+ LLM 判澄清话术。
几个字段值得强调："判定标准"拆成结果目标和过程目标；"参考解 / oracle"——给每个任务配一条已知正确的处理方式，既证明任务可解、又能用来验证你的评分器对不对；"来源"记下它从哪个真实失败来的，方便日后回溯。建议再给每个任务打上标签（维度、难度、是否回归集），这样你能随时按维度筛、按难度看分布，也能快速跑某个子集。
多大？没有魔法数字。原则是"能稳定区分好坏版本就够，不够就加"。起步 10–20，随业务长到几十上百很正常。比起总量，更该盯的是覆盖是否全维、每个高风险场景有没有被测到——20 个全维任务，胜过 200 个挤在一个格子里的任务。
多久跑？分两档：一个轻量核心子集（几十个最关键任务）每次改动都跑、接进 CI 当门禁；全量 + 回归集定期跑（比如每天、或每次发版前）。别忘了 Agent 不确定，每个任务还得跑多次取分布——这也是为什么评测集不能膨胀到"跑一轮要半天"。
把这两点合起来，一个好用的组织方式是把评测集分三层：冒烟层（smoke，约 10 个）：最核心的主流程，几分钟内跑完，每次改动/提交都跑，第一时间挡住低级错误；核心层（core，几十个）：覆盖全景图各维度的关键任务，每次 PR / 改动跑，当上线门禁；全量层（full，全部 + 回归集）：每日或每次发版前跑，给你最全面的体检。越往上越快越频繁、越往下越全越慢。
这一讲讲了怎么从零建一套专属评测集，核心是一条心法、三步走：心法——别攒大数据集，养一个会长大的小集合，价值在"准"不在"大"；第一步，收 10–20 个带判定标准的种子任务，刻意覆盖全景图的多个维度；第二步，把真实使用中的每个失败固化成新任务，让评测集顺着软肋生长；第三步，老用例沉淀进回归集，守住不退步。三步连成一个飞轮。还给了一个能直接套用的任务模板，和几个要避开的反模式。