从三十个反例开始做评估

第一次做出能回答问题的助手时，最容易留下的是一个成功截图。等到第二天改了提示词，却很难说明它究竟变好了多少：昨天问了什么、哪些条件不同、失败有没有被算进去，都没有留在截图里。

这篇 DIY 练习从三十个问题开始。三十不是通用门槛，只是一个人能够逐条复查的起点。目标是建立一份会随着真实错误生长的小型评估集。

先写出失败长什么样

Agent 评估的一手文章讨论了多步行动带来的评估复杂性。本站的练习把结果、过程和副作用分开记录，避免只凭最终回答是否顺耳来判断系统。

我会为资料助手安排十个普通问题、十个边界问题和十个资料缺失的问题。每个用例都写上预期行为，而不是写一份必须逐字匹配的标准作文。

为每一行补上输入资料的版本。否则一次“变差”也可能只是因为网页内容更新了，评估便无法指出需要修改的地方。

把判断拆成能观察的项目

先检查格式与可执行条件：输出能否解析、引用编号是否属于检索结果、工具参数是否在允许范围。再检查语义：结论有没有证据支持、是否遗漏重要限制、是否需要人来做决定。

语义检查可以由人做，也可以用另一个模型辅助，但不要把模型评语直接当作事实。保存评语、评分规则与人工抽查结果，才能知道评分器是否也在偏离目标。

{
  "caseId": "missing-source-03",
  "expected": "说明资料缺失，不自动补充事实",
  "checks": {
    "validFormat": true,
    "inventedCitation": false,
    "requiresReview": true
  }
}

这是记录格式示意，里面的布尔值不是本站对某个模型的实测结果。真正运行时，应用实际检查结果填入，并保留对应的输入与输出。

保留一组不参与调参的题

如果每次改动都围着同一批错误样例打转，系统可能只是更擅长那批题。可以留一小组题，等一轮修改结束后再看；再加入几条来自真实使用的新问题。

我会同时观察成功率、需要人工接手的比例、行动次数和耗时。一个更准确但每次都拖到预算耗尽的方案，未必适合日常阅读。相反，明确停下来请求判断，有时正是预期行为。

让回归成为一次普通动作

每次改动留下四样东西：改动原因、评估集版本、结果差异、一次失败的完整记录。不要只保存总体平均值；最坏的几条往往更能说明问题。

当一个真实错误被修复，就把它变成下一次运行的用例。评估集由此成为项目的一部分：它记录我们希望系统如何行动，也记录我们曾经误以为已经解决了什么。

相关练习：从一个有边界的 Agent 开始。