学习目标：
- 说清「等攒够几百条用例再建评测集」错在哪里，以及早期改动的效应量为什么让几条用例就能分出胜负
- 按「扎根真实用法、补边缘用例、尽量可自动判分、数量优先于单条质量、专门收模糊用例」设计一批评测用例，每条都配一个可验证的结果
- 用留出集防止把提示词调成「只会做这几道题」，并识别哪些问题自动评测天生看不见、必须靠人工测试补
前置要求：读完第 1–4 课（「看起来做完了」不等于做完了、终态优先的验证对象、确定性验证器、LLM 裁判） | 上一课 第 4 课 << | 下一课 第 6 课 >>
这个场面你多半见过。有人在会上提「我们的 Agent 该有个评测集了」，另一个人接话：「评测集得几百条才有统计意义吧？现在写十条二十条，跑出来的分数不说明任何问题，反而误导人。先把真实用户的 case 攒着，攒够了再统一建。」
听起来很专业，很克制。然后半年过去，用例还在某个共享文档里躺着，提示词已经改了三十版，没有一版说得清到底改好了还是改坏了。
Anthropic 在多 Agent 研究系统的工程复盘里，把这条理由直接点名了：他们经常听到 AI 开发团队推迟建评测，原因就是认为只有几百条用例的大规模评测才有用；而实际上最好的做法是立刻用少量样例开始做小规模测试，别等到能建出更完备的评测再动手1。
这一课要讲清楚的就是这件事：为什么少量用例在早期真的有效，一条用例该长什么样，怎么挑这些用例，以及怎么防止「调着调着，只是把 Agent 调成了这几道题的专家」。
先解释一个词。效应量说的是一次改动带来的差距有多大——是从 71.2% 挪到 72.4%，还是从 30% 跳到 80%。差距越大，需要的样本越少；差距越小，需要的样本越多。这不是玄学，是你用肉眼判断两杯水哪杯更烫时也在用的常识：差 30 度一摸就知道，差 0.5 度得上温度计。
Agent 开发的早期属于前一种情况。官方复盘的原话是：在 Agent 开发早期，改动往往带来剧烈的影响，因为唾手可得的改进空间还很多；一次提示词调整可能把成功率从 30% 提到 80%，效应量这么大的时候，你只用几条测试用例就能看出变化1。
想象一下这个场景：你手上有 6 条用例，改之前过 2 条，改之后过 5 条。你需要 p 值吗？不需要。你需要的是赶紧把这版提示词留下，继续找下一个 30% 到 80%。
他们自己起步时用的规模也不神秘——大约 20 条能代表真实用法的查询1。20 条这个数不是什么魔法阈值，它只是「一个下午能写完、当天就能开始用」的量。
反过来说也成立：当你的 Agent 已经跑到 80% 以上，剩下的改动只能挪动一两个百分点时，几条用例确实分辨不出来了。那时候你需要更多用例——但那时候你也已经有一个真跑得起来的评测集，扩充它比从零建它容易得多。先有尺子再谈精度，而不是等尺子够精再开始量。
评测集不是「一堆提示词」。一堆提示词只能让你人肉看输出，看两遍就烦了，看第三遍开始自我欺骗。
工具工程那篇文章讲得很直接：每一条评测提示词都应该配一个可验证的结果；而验证器可以简单到「标准答案和采样答案做精确字符串比对」，也可以复杂到「请 Claude 来裁判这个回答」2。这正好接上了第 2 课定的成功标准、第 3 课的确定性验证器和第 4 课的 LLM 裁判——那三课教你怎么验，这一课教你拿什么去验。
所以一条能用的用例，至少要写清三样东西：
写成结构化数据大概是这样：
这里的 expected 描述的是终态和可见证据，不是「Agent 该按什么顺序想」。第 2 课的结论在这里继续生效：同一个目标，Agent 可能走出好几条都对的路，别把路径写死。工具工程那篇也提醒过，可以顺带记下你期望它调用哪些工具，用来判断它有没有理解每个工具的用途，但因为解法可能不止一条，别把策略规定得太死、别过拟合到某一种走法2。
mustCallTools 这个字段可能让你想起第 2 课的 expectedTools，两者的关系值得说死。负向断言（mustNotContain、mustNotCallTools——不许说「已为您修改」、不许瞎猜一个单号去查）本质是终态红线，描述的是「不该发生的事没发生」，可以放心硬判。正向的工具断言（必须调过某个工具）就是第 2 课说的轨迹断言，那三条纪律原样适用：只断言集合包含、只列真正关心的一两个工具、它没过但终态过了就记一条观察而不是直接判死。它只有一种场景硬得起来：回复里的关键信息只能来自那个工具的返回。cs-003 就是这种——「已发货」这个判断只可能来自 getOrder，工具没调过，这句话就是编的，所以这条正向断言可以硬判。拿不准的时候，一律按软的算。
顺带说一句：这条用例里 mustNotContain 写着「已为您修改」——它防的是 Agent 嘴上答应改地址、实际什么也没做。这种「口头完成」正是第 1 课的主题。
下面这五条规则，是把 Claude 开发者平台「测试与评估」文档的设计原则和工具工程文章里的做法捏在一起的一套清单——每条后面的引注标了它出自哪边。
一、扎根真实用法。 生成大量评测任务，并且这些任务要扎根于真实世界的用法2；评测要贴合你真实的任务分布3。判断标准很简单：这条 prompt 如果不是从真实日志里抄的，你能不能指着它说「上周有三个用户就是这么问的」？说不出来，多半是你坐在工位上想象出来的用户。
二、别漏掉边缘用例。 官方在「贴合真实分布」这条后面紧跟着一句提醒：别忘了把边缘情况算进去3。真实分布是主体，边缘用例是保险。全是边缘用例的评测集会把你带偏——你会花一个月修一个月出现两次的问题。
三、能自动判分就自动判分。 尽量把题目组织成可以自动判分的形式，比如选择题、字符串匹配、代码判分、LLM 判分3。这条决定了你的评测集能不能反复跑。需要你亲自读五分钟才能判对错的用例，写十条你就再也不想跑第二遍。
四、数量优先于单条质量。 官方的原话是：更多的题目、判分信号稍微糙一点的自动判分，好过更少的题目配上高质量的人工精判3。这条最反直觉，也最省命——你的时间应该花在多写十条上，而不是把某一条的判分标准打磨到完美。
五、专门收一类模糊用例。 文档里明确列出了一类值得纳入的题目：那些连人类都难以达成评判共识的模糊用例3。这类题不是用来提高分数的，是用来暴露分歧的。当你的 Agent 在这类题上摇摆，说明产品层面的规则本身还没定，那是产品该解决的事，不是提示词能解决的事。
还有一条不算「设计原则」但同样要紧的：别把评测环境做得太简单。工具工程文章建议避开那种过于简单或者流于表面的沙箱环境，它们没法用足够的复杂度去压测你的工具；强的评测任务可能需要多次工具调用，甚至几十次2。一个查一次数据库就能答完的题，测不出你的 Agent 在第七次工具调用时会不会把上下文搞乱。
假设你老老实实建了 20 条用例，然后开始调提示词。第一版过 8 条，改一改过 12 条，再改过 16 条，再改过 19 条。爽。
问题是：这 19 条的通过，有多少来自 Agent 真的变强，有多少来自你在提示词里悄悄写进了这 20 道题的特征？比如你发现第 7 条老是失败，于是在系统提示里加了一句「遇到退货问题优先引用 7 天无理由条款」——第 7 条过了，可你真正做的事是给这道题写了答案。
这个现象叫过拟合：模型（或者这里说的整套提示词加工具配置）学会的是训练材料的特征，而不是任务本身的规律。
工具工程文章给的办法就一句话，但很关键：他们依靠留出测试集来确保自己没有过拟合到那些「训练用」的评测上2。
留出集就是从一开始就分出去、日常调优时不看、不跑、不碰的一批用例。它的全部价值来自「没被污染」。用法上有几条纪律值得写进团队约定：
顺带提一句常见的工程做法：把评测挂到 CI 里，每次提交自动跑一遍调优集，和上一版的分数做对比，跌了就拦住。这属于普通的工程实践，怎么编排看你们的流水线，这门课不展开——第 6 课会把「能跑起来的那条评测跑道」搭出来，接不接 CI 是你的选择。
评测集建好、跑通、分数还不错，是不是就可以撤掉人工了？
不能。官方复盘的态度很明确：即使在一个自动化评测齐备的世界里，人工测试依然是必需的1。理由是人工测试者能发现评测漏掉的边缘情况——包括在罕见查询上的幻觉、系统性故障，还有微妙的来源选择偏差1。
第三类值得单独说，因为它太典型了。他们的人类测试者注意到：早期的 Agent 一贯偏向选择那些做过 SEO 优化的内容农场，而放过了排名不高但更权威的来源，比如学术 PDF 和个人博客1。
停下来想想这个偏差长什么样。每一次单独看，Agent 都给出了有引用、有出处、读起来很像回事的答案——事实核查过得去，引用格式过得去，完整性过得去，你写下的那几维都挑不出毛病（除非你的量表里恰好有第 4 课那条「来源质量」维度，而且它的判据又写得足够锋利）。可是把一百次输出摆在一起看，才会浮现出那个模式：它系统性地在挑最容易被搜到的那一类内容。
这类模式你的评测集事先看不见，因为评测集是照着你已经知道的失败模式写的——还没想到的模式，自然没有用例在守。人工测试的作用不是替代评测，是给评测集提供新条目：每发现一个这样的模式，就把它固化成一条用例，下次自动跑。
还有一类东西天然就该进评测集：官方明说「不保证」的行为。 工具调用文档里有一处很好的例子——如果用户的提示词没有提供足够信息来填满一个工具的全部必填参数，Claude Opus 更有可能意识到参数缺失并主动追问；但文档紧跟着说明，这个行为并不保证，对于比较含糊的提示词和能力较弱的模型尤其如此4。
「更有可能」「不保证」这类措辞是一个信号：这件事在你的场景里到底成不成立，得你自己测。凡是你的产品逻辑依赖、但官方只给了概率性描述的行为，都值得配几条用例常态化盯着。
把这一课往回收一收。
工具工程文章给的顺序是：先把工具快速搭个原型，在本地跑通；接着跑一次全面的评测，用来测量之后的每一次改动2。注意「之后的每一次改动」这个说法——评测不是给现状打个分就完事，它的价值在于把后续所有改动变成可测量的。有了它，「这版提示词更好」才从感觉变成结论。
《构建高效 Agent》那篇讲得更狠：跟所有 LLM 功能一样，成功的关键在于测量表现并在实现上迭代；再强调一遍——只有当复杂度能带来可证明的改进时，才值得加5。
这句话的分量得配着上下文读。你在前面九门课里学的那些东西——多 Agent 分工、记忆系统、上下文压缩、检查点恢复——每一样都在增加复杂度。没有评测集的时候，你没法回答「加了这个到底有没有变好」，于是只能凭直觉加，凭直觉加就会一直加。评测集是那个能让你把某个花哨设计删掉的依据。
最后说分寸。
我查遍了这门课引的所有一手材料，没有任何一份给出「评测集要多少条才算够」的门槛。有的只是一个起步规模（约 20 条真实查询）和一条方向性建议（数量优先于单条质量）。所以别去找那个数字，也别信谁随口给的「至少 50 条」。
真正的判断标准是这一课开头讲的那件事：你当前改动的效应量，现有用例还分辨得出来吗？
用例数量跟着分辨需求走，不跟着某个心理数字走。
至于怎么把这批用例真的跑起来——一条任务一个循环、判分怎么分层、除了通过率还该记什么——那是第 6 课的事。这一课你需要带走的是那批用例本身。
How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Define success criteria and build evaluations — Claude API 文档 — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
Tool use with Claude — Claude API 文档 — https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview ↩ ↩2
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
你的任务：起草 10 条评测用例。不需要写代码，用表格或列表都行。构成要求：
每条写清三样：prompt 概要、可验证的结果、用哪类验证器（确定性 / 裁判 / 两者都用）。
交付三样：
id、prompt、expected（或指向量表的引用）、验证器类型、tags。给出至少 3 条填好的实例。prompt ：给 Agent 的输入（用户会怎么说，就怎么写）expected ：一个可以判定的结果（终态、字符串、状态变化，或一份量表）verifier ：谁来判——确定性验证器，还是 LLM 裁判{
"id": "cs-003-address-change-after-ship",
"prompt": "我下的单能改地址吗？单号 SO-88213，我搬家了。",
"expected": {
"mustCallTools": ["getOrder"],
"mustContain": ["已发货"],
"mustNotContain": ["已为您修改"]
},
"verifier": "deterministic"
}