黄金测试集：数据集本身就是测试套件

黄金测试集是评估一个 prompt 程序时所依据的、带版本管理的用例集合：每个用例 = 一个输入（用户请求、场景、文档、trace 前置条件）+ 一个期望（理想输出、必须包含的事实/实体、禁止出现的内容，或用来评判的评分标准）。它在 Software 3.0 里扮演的角色，正是单元测试套件在 Software 1.0 里扮演的角色——主流做法的第一条戒律说得很直白：没有黄金测试集的团队没有测试，只有凭感觉。

用例的来源（三条信息流）

1. 生产日志——从真实流量中采样的真实请求，是你实际要面对的分布（纯合成的用例集会偏离现实）。
2. 构造出来的边界用例——对抗性措辞、边界长度、多语言变体、空输入/垃圾输入。
3. 事故化石化——每一次生产事故，一旦被修复，就会变成一个永久的用例。测试集只会因痛苦而单调增长，从不缩减。（在结构上等同于 um 的棘轮机制：每一个被抓住的缺陷，都被提升进机器本身。）

机制

测试集以 JSONL 形式存在于代码仓库中，或者作为 LangSmith / Braintrust 里的数据集存在（带版本、可标注）。典型规模：起步时 50–100 个用例，成熟后到数百个；要小到让一次完整运行能塞进 CI（预算约 30 分钟），又要大到足以覆盖行为面。期望的形式从精确字符串匹配（便宜但脆弱），到必须/禁止断言，再到供 LLM 裁判 使用的评分标准文本，跨度不小。用例带有标签（能力维度、风险区域），使回归能被定位到具体位置。

已知的坑

对测试集过拟合（prompt 把测试题背下来了——要定期从生产环境刷新）；期望过时（产品对"好"的定义已经变了，测试集没跟上）；无基线打分（一个测试集只有相对于当前系统的基线才有意义——见 regression-ci）。

与 um 的关系： 被审计的账本本身就是一个免费积累起来的黄金测试集——每一个通过的成果物加上它逐条规则的判定结果，都是一个已标注的用例；缺的只是在机器发生变化时能重新跑一遍的 harness（regression-ci）。

Up：testing-software-3-0

来源：evals 主流实践（DeepEval/Promptfoo/LangSmith/Braintrust 指南，2026-07 现状核查）——Software-3.0 测试的基础层