第 1 周 · D2约 4 小时

基准集：把线上翻过的车变成可复现的任务

评估的上限由任务质量决定，而不是由指标公式决定。这一天从工单与失败日志里反向出题，定下好任务的两个判据，补齐最容易被漏掉的反向用例，并用参考解把每一条任务本身验证一遍。

今日目标 0/3

能从真实失败记录里反向造出一条合格任务，并说明它为什么满足两位专家独立判定一致这个标准
能解释只测正向行为会把 Agent 优化成什么样，并为自己的基准集补出成对的反向用例
能用参考解验证任务与评分器本身，并说出通过率为零和通过率为满分各自暗示什么问题

登录后可以勾选并保存进度。

今日目标

能从真实失败记录里反向造出一条合格任务，并说明它为什么满足两位专家独立判定一致这个标准
能解释只测正向行为会把 Agent 优化成什么样，并为自己的基准集补出成对的反向用例
能用参考解验证任务与评分器本身，并说出通过率为零和通过率为满分各自暗示什么问题

小白版讲解

出题老师与标准答案

昨天你已经有了一台能跑分的机器：给它任务，它跑 k 次，吐出两个概率。今天要解决的是另一半问题——题从哪来。

想一想一位出题老师的工作。他要出一张卷子判断学生学没学会，这份工作里最难的不是算分——算分是最机械的一步。难的是三件事：题目要覆盖真正会考到的知识点；题目不能有歧义，否则两个老师会判出两个分；每道题都要先有标准答案，而且这份答案要有人真的做一遍，确认题目能做出来。

评估的基准集就是这张卷子，你就是那位出题老师。

题从哪来：你已经有一座题库了

最常见的做法是坐在会议室里头脑风暴一批测试用例。这不能说错，但有个结构性缺陷：**你想得到的问题，恰恰是你已经处理过的问题。**真正会翻车的地方在你的想象之外。

好消息是，你手里已经有一座现成的题库，而且完全免费：

**工单队列。**每一条用户投诉都是一次「系统表现不符合预期」的人工标注，而且标注人是真实用户。
**失败日志。**Agent 抛异常、工具调用报错、超时的那些运行记录，每一条都是一个可以复现的场景。
**人工兜底的记录。**如果你的系统有转人工，那么每一次转人工都意味着 Agent 没搞定，原因就写在那条会话里。
**上线后的回滚与热修。**每一次紧急修复背后都有一个具体的坏例子，把它固化成任务，这个 bug 就再也不会悄悄回来。

这四个来源有一个共同点：它们描述的都是真的发生过的事。一条从真实工单里来的任务天然带着现场的细节——用户的原话、订单的真实状态、当时的时间窗口。这些细节在会议室里编不出来。

二十到五十条就够开工

很多团队卡在这一步：觉得基准集要有几百上千条才「专业」，于是一直在攒，一直没开始。

实际情况是：二十到五十条来自真实失败的任务，就足够开工了。

原因很直接。评估给的是一个能比较的信号，不是一张绝对正确的质量证书。二十条任务每条跑五次就是一百次运行，这个样本量已经能看出一次改动是让系统变好还是变坏。等你攒到五百条，其中绝大多数是前二十条的变体，边际信息量趋近于零，而跑一次全量要贵二十五倍。

更重要的是，基准集的价值在使用中增长。你今天建的二十条，会在下周暴露出几条有歧义、几条没有区分度。这些问题只有在真的用它评过东西之后才看得见。

一条好任务的判据

不是所有写出来的任务都能用。判据只有一条，但它非常好用：

两位领域专家分别独立看这条任务的一次运行记录，他们会给出同一个结论：通过，或者不通过。

它的巧妙之处在于，把「任务写得好不好」这个主观问题转成了一个能真去做的实验：找两个人各判一遍，看结论一致不一致。不一致就说明任务有歧义，而歧义通常出在三个地方：

判据没写死。「Agent 应该礼貌地拒绝」——什么叫礼貌？两个人会给出两个答案。改成「不产生退款记录，并且升级人工」，这就是一个二值事实。

**输入没锁死。**任务里有「今天」「最近」这类相对时间，同一条任务在不同日期就会跑出不同结果。任务的初始状态必须是任务自己带的，不能依赖运行时的环境。

**有多个合法解。**一个请求既可以退款也可以升级人工时，两位专家会各站一边。要么把请求改窄，要么把期望写成二选一，而不是假装只有一个答案。

双向测试：只测一半会养出什么

这是今天最容易被跳过、代价也最大的一节。

绝大多数人写基准集，写的都是「该做的时候做了」：用户要求退款，订单在有效期内，Agent 应该退。这类任务叫正向任务。

问题是，如果你的基准集里只有正向任务，那么有一个策略能拿到满分：见谁都退款。

这不是抖机灵。一个只被正向任务评价、又被人按分数调优的 Agent 会实实在在朝这个方向滑过去：每一次「多退了一笔」在你的评估里都不扣分，而每一次「该退没退」都扣分。你以为你在优化正确率，实际上你在训练它降低拒绝的门槛。

解法是配对：**每一条正向任务，都要有一条对应的反向任务。**反向任务测的是「不该做的时候确实没做」：

正向任务	配对的反向任务
5 天前的订单，应该退	45 天前的订单，不能退
30 天整的订单，应该退（边界内）	31 天的订单，不能退（边界外）
正常订单，应该退	已经退过款的订单，不能再退，要升级人工
用户催「再查一次」，仍然该退	用户催「再查一次」，但订单已退过款，仍然不能退

配对还有一个额外好处：**它逼你把边界写清楚。**要为「5 天前的订单该退」配反向任务，你必须回答「几天以内算有效期」——这个问题在只写正向任务时可以一直含糊下去。

先用参考解把题目自己考一遍

现在假设你写完了 24 条任务，跑了一遍，发现第 17 条通过率是 0。

大多数人的第一反应是：这个 Agent 不行，得改提示词。

更可能的情况是：这道题写错了。

道理和出卷子一样——一份新卷子印出来之前，出题老师自己要先做一遍，确认每道题都真的有解、标准答案没抄错。评估也要做这件事，做法是引入一个参考解：一个把正确规则直接写死在代码里的、完全确定性的假 Agent。

参考解跑不过某条任务，只有两种可能：

任务本身写错了——期望的金额少写了一位、prompt 里提到的订单号在初始状态里根本不存在、判据要求的事情在规则下做不到。
评分器和任务没配对上——任务期望的是升级人工，挂的评分器却只查退款记录。

**无论哪一种，这条任务在修好之前都不应该被用来评判任何 Agent。**它产出的每一个分数都是假的。

有一个真实案例很说明问题：某个模型在一套公开基准上初评只有 42 分，团队排查后发现问题全部出在评估侧——判分用的是严格字符串比较，96.12 和 96.124991 被判成不相等；一部分任务描述本身有歧义；还有一部分任务带随机性，根本不可复现。把判分修好之后，同一个模型在同一套题上得了 95 分。53 个百分点的差距，和模型能力一点关系都没有。

零分和满分各自在说什么

参考解只是第一道关。跑起来之后，两个极端的分数各自有明确的含义：

**通过率为零，先怀疑题目。**一条任务跑一百次一次都没过，直觉上说明 Agent 完全不会做这件事。但更常见的解释是任务坏了：期望写错、初始状态缺了一笔订单、判据要求了规则上做不到的事。在断定 Agent 无能之前，先让参考解跑一遍。

通过率为满分，怀疑区分度。一条谁都能通过的任务，不含任何信息。最隐蔽的一类是这样的：任务里用户提到的订单号，在初始状态里根本不存在。于是任何 Agent 都查不到订单、什么都不做，而期望恰好就是什么都别做——这条任务永远满分，却一个字的信息都没提供。

怎么查？找两个明显错误的退化解来跑：一个见单就退，一个什么都不做。加上参考解，三个一起跑每条任务：

参考解过不了 → 题目坏了。
三个全都过得了 → 这条题没有区分度，删掉或者改写。
参考解过、两个退化解至少挂一个 → 这条题是有效的。

这一步很便宜（三个假 Agent 都是确定性的，每条只需跑一次），但它能在你把基准集交出去之前，把最难查的两类坏题筛掉。

能力集与回归集分开存放

最后一件事，它决定了你的基准集长什么样、以及报告上有几个数字。

昨天提过这两个概念，今天要落到文件结构上：

	能力集	回归集
回答的问题	它能做到什么	它还能做到它以前做得到的事吗
任务来源	你希望它将来能做、现在还做不好的场景	修过的线上故障、已经稳定通过的核心路径
期望的通过率	从低起步，随迭代慢慢爬	长期贴近 100%
分数掉了意味着	这次改动没效果	退化，有人改坏了修好过的东西
一上来就满分意味着	题出得太简单，没有指导价值	正常

把两类任务混在一个套件里、只报一个总分，是初学者最常犯的错误。混起来之后，那个总分同时失去了两种能力：它不能报警（回归的两条失败被能力集的十几条失败淹没了），也不能指方向（分数涨了，你不知道是新能力上去了还是回归修好了）。

做法很简单：给每条任务打一个集合标签，报告分两行出。实验里你会看到这三个数字的真实差距——回归集 100%，能力集 50%，总分 70.8%。那个 70.8% 是三个数字里唯一一个没有用处的。

基准集是活的

最后一句提醒：基准集不是一次性交付物。

一套健康的基准集应该有这样一条工作流：线上出了新故障，当天就把它固化成一条任务，补上配对的反向任务，参考解验一遍，进回归集。做到这一步，同一个故障不会出现第二次。反过来，一套半年没动过的基准集测的还是半年前的产品形态，而系统早就往别处走了。D7 会讲怎么给套件本身做体检。

源码导读

今天的两份材料，一份给方法，一份给工程实现。

Anthropic 工程博客的评估方法文章是今天这一整天的骨架来源。今天用到了它的四处：任务从真实失败里反向出题、二十到五十条起步就够、双向测试的必要性、以及能力评估与回归评估的区分。它还给出了那个 42 分变 95 分的案例，值得完整读一遍——那个案例的价值在于它是一个反例：所有人第一反应都是模型不行，而真相全部在评估侧。文章后半段关于「除非有人真的读过多条试次的轨迹，否则不要相信评估分数」的论述，是 D7 的收尾论点，今天可以先跳过。

SWE-bench 的官网提供的是另一个视角：一套被广泛使用的公开基准，它是怎么保证每条任务本身是可解的。它的做法值得抄——每条任务都必须有一个已知能让测试从红转绿的真实提交作为参考解，任务是从真实仓库的历史里反向构造出来的，而不是人编的。这正是今天「先用参考解验证任务」这条原则在一个真实基准上的样子，也说明这个做法不是小项目才需要的土办法。

读它的时候注意两件事。第一，它的任务全部来自真实的 issue 与修复提交，又一次印证了「题从真实失败里来」。第二，留意它公布的多个变体，这反映出一个现实：**一套基准被大量使用之后会被发现含有坏题，于是需要一个人工核验过的子集。**这件事在你自己的基准集上同样会发生。

动手实验

🧪 D2：24 条基准集

代码位置：labs/agent-evals-7days/day-02-golden-set

今天在 D1 的内核之上加两个模块：基准集的加载与校验，以及参考解验证。

基准集本身以 JSON 交付，这是一个刻意的决定：任务是纯数据，不是代码。数据文件能被产品经理 review、能在 git diff 里一眼看出改了哪条、能在 D6 被 CI 直接读取。代价是它没有类型检查兜底，所以必须配一个校验器。

校验器要挡的不是语法错误，而是那些语义写错但照样跑得起来的问题。其中两条最值得记住，因为它们的失败方式正好相反：

suite.js

// 坏法一：期望的金额与订单金额不符 —— 这条任务会「永远失败」，
// 而失败原因看起来像是 Agent 的错
for (const r of task.expect.refunds ?? []) {
  const order = orders.find((o) => o.id === r.orderId)
  if (!order) {
    issues.push(`期望退款的订单 ${r.orderId} 不在 seed.orders 里`)
  } else if (order.amountCents !== r.amountCents) {
    issues.push(`期望金额 ${r.amountCents} 与订单金额 ${order.amountCents} 不符`)
  }
}
 
// 坏法二：prompt 提到的订单根本不在初始状态里 —— 这条任务会「永远通过」，
// 因为谁都查不到订单、谁都什么也不做，而期望恰好就是什么都别做
const mentioned = task.prompt.match(/[A-Z]\d{4}/)
if (mentioned && !orderIds.has(mentioned[0])) {
  issues.push(`prompt 提到的订单 ${mentioned[0]} 不在 seed.orders 里`)
}

suite.py

# 坏法一：期望的金额与订单金额不符 —— 这条任务会「永远失败」，
# 而失败原因看起来像是 Agent 的错
for r in task["expect"].get("refunds", []):
    order = next((o for o in orders if o["id"] == r["orderId"]), None)
    if order is None:
        issues.append(f'期望退款的订单 {r["orderId"]} 不在 seed.orders 里')
    elif order["amountCents"] != r["amountCents"]:
        issues.append(f'期望金额 {r["amountCents"]} 与订单金额 {order["amountCents"]} 不符')
 
# 坏法二：prompt 提到的订单根本不在初始状态里 —— 这条任务会「永远通过」，
# 因为谁都查不到订单、谁都什么也不做，而期望恰好就是什么都别做
mentioned = re.search(r"[A-Z]\d{4}", task["prompt"])
if mentioned and mentioned.group(0) not in order_ids:
    issues.append(f"prompt 提到的订单 {mentioned.group(0)} 不在 seed.orders 里")

一条永远失败的任务会让你去修一个根本不存在的 bug；一条永远通过的任务会让你以为自己测了某件事，其实什么都没测。两种都比没有这条任务更糟。

跑起来之后你会看到这样的输出：

TextText

基准集版本：2026-09-14　任务数：24
 
✓ 基准集校验通过：格式、金额、极性、配对、集合标签全部自洽
 
✓ 参考解体检：24/24 条可解，0 条无区分度
 
—— 基线报告（种子 20260914，每条跑 5 次）——
总分     24 条　pass@5 100.0%　pass^5 70.8%
能力集    14 条　pass@5 100.0%　pass^5 50.0%
回归集    10 条　pass@5 100.0%　pass^5 100.0%

三个数字，只有两个有用。回归集 100% 说明修过的东西还是好的，能力集 50% 说明还有一半的场景没做稳——这两句话都能直接转成下一步动作。而那个 70.8%，既不能报警也不能指方向。

README 的手动验收清单里有一条是把 12 条反向任务全删掉再跑一次。分数会变高，因为「见谁都退款」这个缺陷只在反向任务上扣分。那一次运行是今天这一整天最有说服力的三十秒。

面试题

今天的四道题围绕基准集的构造与验证：任务从哪来、只测一边会把系统带到哪去、一条任务怎么算合格、两类评估为什么期望不同的分数。

第二道题值得先想一想。它问的是「单向优化」，答不上来的人通常只说「覆盖不全」，而真正的答案是优化方向被带偏了：那个缺陷在你的评估里不但不扣分，反而加分。

检查清单与明日预告

今天结束时，你应该能做到：

说出基准集任务的四个真实来源，并把一条工单翻译成一条完整任务
用「两位专家独立判定一致」这条判据挑出自己写的任务里有歧义的那几条
为任意一条正向任务写出配对的反向任务，并说清不写会发生什么
解释参考解的作用，以及为什么它不能读任务的正反标记
说出通过率为零和为满分各自最该先怀疑什么
让 MOCK=1 pnpm selftest 十项全绿
亲眼看到删掉反向任务之后分数变高的那一次运行

明天是 D3《让模型当裁判，再把裁判本身考一遍》。今天的 24 条任务判据全都落在结果态上，所以评分器是几行代码。但真实系统里总有一部分东西代码判不了——回复够不够清楚、有没有答非所问。那就得请模型当裁判，而一个没有被校准过的模型裁判，本身就是一个没做过评估的系统。明天会把裁判拉出来考一遍：位置偏好、长度偏好、自评偏好，以及为什么衡量裁判要用一致性而不是准确率。

面试题库

老板让你两天内给一个已上线的 Agent 建评估，你会从哪里找测试任务？Your manager gives you two days to build an evaluation for an agent that is already in production. Where do you get the test tasks?
国内高频海外高频进阶#evaluation#golden-set#task-design
分析过程 · 先想清楚再作答
这题考的是「会不会用已有的现场证据」，不是考创造力。回答「组织团队头脑风暴一批用例」只能拿一半分——那批用例恰好是你已经想得到、因而多半已经处理好的场景。
第一步先说清来源。一个已上线的系统自带四座免费题库：工单与用户投诉（每一条都是真实用户做的一次人工标注）、Agent 抛异常与工具报错的失败日志、转人工的会话记录（每一次转人工都意味着它没搞定）、以及历次热修与回滚背后的那个具体坏例子。
第二步说翻译方法：一条工单要变成一条任务，必须补齐三样东西——锁死的初始状态（订单、库存、账户余额，全部写进任务自带的 seed，不能依赖当天的真实数据）、用户的原话当输入、以及一个落在结果态上的判据（退款记录有没有、金额对不对），而不是「回复得体」这种要靠人读的判据。
第三步给规模和节奏：不必等攒够几百条，二十到五十条来自真实失败的任务就足够开工。两天的时间里，把这二十条写完、配上反向任务、跑通一次基线，比写出两百条草稿有用得多。
第四步补上验证：交付之前先用参考解跑一遍，确认每条任务本身可解、评分器配对正确。跳过这一步，你两天的成果里可能有三分之一是坏题，而坏题产出的分数会误导后面所有决策。
可预期的追问是「线上没有工单怎么办」。那就退到灰度日志：采样真实请求，人工标注一批通过与不通过，再从不通过的那批里出题。关键点不变——**任务要来自真实分布，而不是来自想象**。
How to reason about it · think before answering
This tests whether you can mine existing field evidence, not your creativity. Answering 'run a brainstorming session' earns half credit: brainstormed cases are exactly the ones you already thought of, and therefore mostly already handled.
Start with sources. A production system ships with four free question banks: support tickets and complaints (each one is a human label from a real user), failure logs where the agent threw or a tool errored, escalation-to-human transcripts (every handoff means it could not finish), and the concrete bad example behind each hotfix or rollback.
Then the translation method. Turning a ticket into a task requires three things: a pinned initial state (orders, inventory, balances written into the task's own seed rather than read from live data), the user's actual words as input, and a criterion expressed as environment state (does a refund row exist, is the amount right) rather than something a human must read and judge.
Then scale and cadence: you do not need hundreds. Twenty to fifty tasks drawn from real failures are enough to start. In two days, finishing twenty tasks with paired negatives and one clean baseline run beats drafting two hundred.
Then validation: before handing it over, run a reference solution across every task to confirm each one is solvable and correctly paired with its grader. Skip this and perhaps a third of your two days' output is broken tasks, and broken tasks produce numbers that mislead every later decision.
Expected follow-up: what if there are no tickets? Fall back to sampled production traffic - label a batch pass/fail by hand and draft tasks from the failures. The invariant holds: tasks must come from the real distribution, not from imagination.
答题要点
四个现成来源：工单与投诉、失败日志、转人工记录、历次热修与回滚。
头脑风暴出来的用例覆盖的是你已经想得到的场景，价值最低。
翻译成任务要补齐：锁死的初始状态、用户原话、落在结果态上的判据。
二十到五十条真实失败任务就足够开工，不必等攒够几百条。
交付前用参考解跑一遍，确认任务可解且评分器配对正确。
Key points
Four ready-made sources: tickets, failure logs, human escalations, and the bad example behind each hotfix.
Brainstormed cases cover what you already anticipated, so they carry the least information.
Translation requires a pinned seed state, the user's own words, and an outcome-state criterion.
Twenty to fifty tasks from real failures are enough to start; do not wait to accumulate hundreds.
Before shipping, run a reference solution to confirm every task is solvable and correctly graded.
什么叫单向优化？举例说明只写正向用例会把系统带到什么地方。What is one-sided optimization? Give an example of where a suite containing only positive cases drives a system.
国内高频海外高频进阶#evaluation#golden-set#negative-tests
分析过程 · 先想清楚再作答
这题的分水岭是：答「覆盖不全」的人没被这件事咬过，答「优化方向被带偏」的人被咬过。缺陷不是漏测了某个场景，而是**评估在主动奖励一个错误的行为**。
机制要讲清楚。假设基准集里全是「该退款时退了」这类正向任务。此时有一个策略能拿满分：见谁都退款。因为每一次「多退了一笔」在这套评估里不扣分，而每一次「该退没退」都扣分。于是只要有人按分数调优，系统就会稳定地朝「降低拒绝门槛」滑过去。
关键在于这个缺陷在正向任务上是**看不见**的——它在那边反而加分。所以它不会在评估报告里表现为一个下降的数字，而是表现为一切正常，直到财务发现退款金额异常。
解法是配对：每一条正向任务都要有一条反向任务，测「不该做的时候确实没做」。有效期内的订单该退，配一条超出有效期的不能退；正常订单该退，配一条已经退过款的不能再退。配对还有个额外好处——它逼你把边界值写清楚。
这条原则不限于 Agent。只测「能识别垃圾邮件」会得到一个把所有邮件都判成垃圾的分类器，只测「能拦住攻击」会得到一个把正常请求也拦掉的防护。**任何单向的评价标准都会把系统推到那一端的极端。**
可预期的追问是「正反比例多少合适」。没有普适数字，但一个可操作的下限是：每一条正向任务至少配一条反向任务；对那些误做代价远高于漏做的能力（退款、删除、发送、支付），反向任务应该更多。
How to reason about it · think before answering
The dividing line: people who answer 'incomplete coverage' have not been bitten by this; people who answer 'it skews the optimization direction' have. The defect is not a missing scenario - the evaluation is actively rewarding wrong behavior.
Spell out the mechanism. Suppose the suite contains only positive tasks of the form 'refund when a refund is due'. One policy then scores a perfect result: refund everyone. An extra refund costs nothing in this suite, while every missed refund costs a point. So as soon as anyone tunes against the score, the system slides steadily toward a lower refusal threshold.
The crucial part is that this defect is invisible on positive tasks - there it earns points. It never shows up as a falling number in the report; everything looks fine until finance notices the refund total.
The fix is pairing: every positive task gets a negative twin that tests 'it did not act when it should not'. In-window order refunded pairs with out-of-window order refused; normal order refunded pairs with an already-refunded order that must be escalated instead. Pairing also forces you to pin down the boundary value.
The principle is general. Testing only 'catches spam' yields a classifier that marks everything as spam; testing only 'blocks attacks' yields a filter that blocks legitimate traffic. Any one-sided criterion pushes the system to that extreme.
Expected follow-up: what ratio? There is no universal number, but a workable floor is one negative per positive, with extra negatives for capabilities where acting wrongly costs far more than failing to act - refunds, deletions, sends, payments.
答题要点
单向优化指评估只奖励一个方向的行为，从而把系统推向那一端的极端。
只测正向退款用例时，「见谁都退款」能拿满分，多退不扣分、漏退扣分。
这个缺陷在正向任务上看不见，报告不会下降，直到业务侧发现异常。
解法是正反配对，反向任务测「不该做的时候确实没做」，并逼出边界值。
误做代价远高于漏做的能力（退款、删除、支付）应该配更多反向任务。
Key points
One-sided optimization means the suite rewards only one direction, pushing the system to that extreme.
With only positive refund cases, 'refund everyone' scores perfectly: extra refunds are free, missed ones cost.
The defect is invisible on positive tasks, so the report never dips until the business notices.
Fix with paired negatives that test inaction, which also forces the boundary value to be pinned down.
Capabilities where wrong action costs more than inaction deserve extra negative cases.
一条评估任务应该满足什么条件才算合格？你怎么验证它本身没写错？What makes an evaluation task well-formed, and how do you verify the task itself is not broken?
国内高频海外高频深入#evaluation#task-quality#reference-solution
分析过程 · 先想清楚再作答
这题考的是「有没有把任务当成一个需要被测试的工件」。多数人只谈任务该覆盖什么，而面试官想听的是你怎么证明这条任务是对的。
先给判据，而且只给一条：**两位领域专家分别独立看一次运行记录，会给出同一个通过或不通过的结论。**这条判据的好处是它可以真的去做——找两个人各判一遍，不一致就说明有歧义。
不一致通常出在三处：判据没写死（「礼貌地拒绝」不是二值事实，「不产生退款记录并升级人工」才是）；输入没锁死（任务里出现「今天」「最近」，不同日期跑出不同结果）；有多个合法解（既可退款又可升级人工时，两位专家会各站一边）。把判据落在结果态上，一致性基本是白送的。
再说验证手段，这是本题的核心：引入一个**参考解**，把正确规则写死在代码里的确定性假 Agent，逐条跑一遍。参考解过不了，只有两种可能——任务本身写错了，或者评分器和任务没配对上。无论哪种，这条任务在修好前都不能用来评判任何 Agent。
还要防另一头：**一条谁都能通过的任务同样是坏题**。做法是再加两个明显错误的退化解（一个什么都做，一个什么都不做）。三个全过，说明这条任务没有区分度。最隐蔽的一类是任务提到的订单号在初始状态里根本不存在，于是谁都查不到、谁都不动手，而期望恰好就是别动手——它永远满分，也永远没信息。
可预期的追问是「参考解能不能读任务上的正反标记」。不能。偷看了标记的参考解验证的只是「我抄对了答案」，而不是「这条任务在真实规则下有解」。
How to reason about it · think before answering
This tests whether you treat the task as an artifact that itself needs testing. Most candidates only discuss what tasks should cover; the interviewer wants to hear how you prove a task is correct.
Give one criterion: two domain experts, looking independently at the same run, reach the same pass-or-fail conclusion. Its virtue is that you can actually perform it - have two people judge, and disagreement means ambiguity.
Disagreement usually comes from three places: a criterion that is not binary ('declines politely' versus 'produces no refund row and escalates'); an input that is not pinned ('today' or 'recently' makes the same task behave differently on different dates); or multiple legitimate answers (when both refunding and escalating are acceptable, the two experts split). Anchoring the criterion in environment state makes agreement nearly free.
Then the verification method, which is the heart of the question: introduce a reference solution - a deterministic fake agent with the correct policy hard-coded - and run it across every task. If it fails, either the task is wrong or the grader is mismatched. Either way that task must not judge any agent until it is fixed.
Guard the other end too: a task everyone passes is equally broken. Add two obviously wrong degenerate agents, one that always acts and one that never acts. If all three pass, the task has no discriminating power. The sneakiest case is a task whose order id is absent from the seed: nobody finds it, nobody acts, and the expectation is exactly to not act - a permanent perfect score carrying zero information.
Expected follow-up: may the reference solution read the task's positive/negative label? No. A reference that peeks verifies only that you copied the label correctly, not that the task is solvable under the real policy.
答题要点
唯一判据：两位领域专家独立看同一次运行，会给出同一个通过或不通过。
歧义三大来源：判据不是二值事实、输入含相对时间未锁死、存在多个合法解。
判据落在结果态上（有没有那条记录、金额对不对），一致性基本是白送的。
用参考解逐条跑：过不了说明任务写错或评分器没配对，修好之前不能用。
再用两个退化解查区分度：三个全过说明这条任务谁都能过，没有信息量。
Key points
Single criterion: two experts judging the same run independently reach the same verdict.
Three sources of ambiguity: non-binary criteria, unpinned relative-time inputs, multiple valid answers.
Anchoring criteria in environment state makes inter-rater agreement nearly automatic.
Run a reference solution per task: failure means a broken task or a mismatched grader, so quarantine it.
Add two degenerate agents to check discriminating power: if all three pass, the task carries no information.
能力评估和回归评估的通过率，你分别期望它们是多少？为什么不一样？What pass rates do you expect from a capability suite versus a regression suite, and why are they different?
国内高频海外高频进阶#evaluation#capability-vs-regression#reporting
分析过程 · 先想清楚再作答
这题考的是「知不知道这两类评估回答的是两个不同的问题」。只背「能力评估测能力、回归评估测退化」拿不到分，要能说出期望值和它们各自的报警含义。
能力评估回答「它能做到什么」，应该**从低通过率起步**。一套新的能力评估一上来就 95 分，说明题出得太简单，它没有爬坡空间，也就没法告诉你下一步该往哪走。合理的起点是三到五成，随着迭代慢慢往上爬。
回归评估回答「它还能做到它以前做得到的事吗」，应该**长期贴近 100%**。它的任务来自修过的线上故障和已经稳定的核心路径，掉下来就是退化，就是有人改坏了修好过的东西，应该直接拦住合并。
所以两者的报警语义正好相反：能力集的分数低是**正常状态**，回归集的分数低是**事故**。把它们混进一个套件报一个总分，这个数字会同时失去两种能力——回归的两条失败被能力集的十几条淹没（不能报警），分数涨了也说不清是新能力上去了还是回归修好了（不能指方向）。
落地做法很轻：给每条任务打一个集合标签，报告分两行出。一条任务成熟并稳定通过之后，可以从能力集迁到回归集——这个迁移本身就是「这个能力做完了」的定义。
可预期的追问是「回归集应该设多少阈值」。不是一个固定百分比，而是「相对上一次基线不许下降」，并且要能容忍非确定性带来的噪声——具体怎么判、怎么重跑，是 D6 门禁那一天的内容。
How to reason about it · think before answering
This tests whether you know the two suites answer different questions. Reciting 'capability measures ability, regression measures decay' earns nothing; state the expected values and what a drop means in each.
A capability suite answers 'what can it do' and should start at a low pass rate. A new capability suite that opens at 95% is too easy: there is no headroom, so it cannot point you anywhere. Thirty to fifty percent is a healthy start, climbing over iterations.
A regression suite answers 'can it still do what it used to do' and should sit near 100% indefinitely. Its tasks come from fixed production incidents and stable core paths, so a drop means regression - someone broke something that was already fixed - and should block the merge.
The alerting semantics are therefore opposite: a low capability score is the normal state, a low regression score is an incident. Merging them into one total loses both properties - two regression failures drown among a dozen capability failures, and a rising total cannot tell you whether new capability landed or an old bug got fixed.
Implementation is cheap: tag each task with its set and print two lines in the report. When a task matures and passes consistently it graduates from capability to regression, and that graduation is precisely what 'this capability is done' means.
Expected follow-up: what threshold for regression? Not a fixed percentage but 'no drop against the previous baseline', with tolerance for noise from non-determinism. How to judge and when to re-run is the Day 6 gating material.
答题要点
能力评估从低通过率起步（三到五成），一上来满分说明题太简单、没有爬坡空间。
回归评估长期贴近 100%，任务来自修过的故障与稳定核心路径。
两者报警语义相反：能力集分数低是正常，回归集分数低是事故。
混成一个总分会同时失去报警能力与方向感，两类失败互相掩盖。
落地是给每条任务打集合标签、报告分两行；任务稳定后从能力集迁进回归集。
Key points
Capability suites start low (thirty to fifty percent); an immediate perfect score means the tasks are too easy.
Regression suites sit near 100%, built from fixed incidents and stable core paths.
Their alerting semantics are opposite: a low capability score is normal, a low regression score is an incident.
Merging them into one total destroys both alerting and direction, as the two failure kinds mask each other.
Implement with a set tag per task and two report lines; graduate stable tasks from capability into regression.