自己想用例一定漏：AI 项目验收的三层测试集

传统项目上线前的验收是「功能对不对」，看一眼就知道。AI 项目不是 —— 同一个输入今天答对明天答错，你甚至说不清"对"的边界在哪。

于是大多数人的验收动作变成：自己坐下来想几个案例，挨个试一遍，感觉还行就发。这条路一定漏。 你想得出来的案例，恰好是你已经考虑过的那些；真正会出事的是你没想到的那类输入 —— 而"没想到"这件事，靠再多想一会儿是补不上的。

要补上，得让用例的来源不再是你的脑子。三层测试集各管一段：

第一层：黄金用例打底

先要有一份人工精选的用例集，覆盖常见场景和边界情况，每条都标好期望输出。这是地基 —— 它的作用不是发现新问题，而是保证基础功能没被改崩。

选用例的标准是"错了就算严重事故"，不是"这个场景很典型"。数量不用多，几十条足够，但每一条都得是你愿意为它回滚发布的那种。

关键在于它必须能自动跑。人工点一遍的用例集，第三次改 prompt 的时候就没人跑了。

第二层：evals 把跑批变成一条命令

有了用例集，需要一个东西把"批量跑一遍、和期望比对、出报告"这套动作固化下来。OpenAI 的 evals¹（钉在 8eac7a7，2026-04-14）就是干这个的：它既是跑批框架，也是一个公开的 benchmark 注册表。

README 开头那句话说得很直白：

If you are building with LLMs, creating high quality evals is one of the most impactful things you can do. Without evals, it can be very difficult and time intensive to understand how different model versions might affect your use case.

后半句才是重点 —— 没有 evals，你根本没法判断换个模型版本会不会把你的场景搞坏。这不是"测试做得更规范"的问题，是"换模型时你敢不敢发"的问题。

它的价值在于把用例写成配置而不是脚本：用例、评分方式、模型三者解耦，换模型只是改一个参数。自己攒的测试脚本往往把这三样揉在一起，跑第二个模型时才发现得重写。

如果不想引入整个框架，自己写个跑批脚本也行，但要保证同样的解耦。别把模型名写死在断言里。

第三层：线上失败回灌

前两层都还是"你想到的"。真正让测试集长出你想不到的那部分，只有一个来源：线上跑起来之后的失败记录。

具体做法：生产环境里把差评、报错、异常输出持续收集下来，定期挑出有代表性的，补进离线测试集。下次发布前的跑批就自动带上它们。

这一步是整套方案里唯一能突破"你的想象力上限"的环节，也是最容易被跳过的 —— 因为它要求线上有反馈通道（至少有个点踩按钮）、有日志留存、还得有人定期去看。缺了任何一环，测试集就永远停在上线那天的水平。

回灌之后，一条线上事故就变成一条永久的回归用例。同样的错不会犯第二次，这是这套东西真正的复利所在。

三层之间的关系

黄金用例保下限，evals 保变更不退化，线上回灌保覆盖面持续增长。少一层的后果各不相同：

• 没有黄金用例，改一行 prompt 就要人工全量回归，改不动
• 没有 evals，换模型只能靠感觉，不敢升级
• 没有回灌，测试集永远停在上线那天，线上出过的事还会再出

先建第一层，让它能一条命令跑起来；第三层的通道尽早埋，因为它需要时间积累。