先构建你的评估套件，再构建你的功能
功能上线了。模型很棒。而当它第一次在客户面前出错时，没人能告诉你它是在变好还是变坏。这就是评估套件晚于功能出现时的后果。而通常，它根本不会出现。
这是我一直看到的一种模式。团队因为模型演示效果好就去构建一个 AI 功能。演示成了全部的质量标准。功能上线后，关于它的每一个后续决策都是凭感觉做出的——它是不是感觉更好了？供应商是不是说新模型更好了？有没有客户投诉？团队驾驶着一架没有仪表的飞机，而这架飞机就是模型——一个不打招呼就会自行改变的唯一部件。
而解决办法与直觉相反：在构建功能之前，先构建评估套件。评估是地基，不是最后一步。
评估套件究竟是什么
评估套件是 AI 的测试集。一组输入，配有已知正确的输出，拿去跑模型，按模型答对的频率打分。它的形状和 code 的测试套件一样——一组必须通过的用例——但有一个区别：输出是模糊的。答案可以以多种方式正确，因此打分必须基于判断，这意味着评估套件一半是测试，一半是评分标准。
这个套件有三部分。黄金集：几百个手工整理的用例，覆盖重要场景和边界情况，每个都配有已知正确的答案。回归集：过去抓到过真实 bug 的用例，永久保留，让一次修复永远不会悄悄地把旧问题再弄坏。还有评分标准：对每种任务类型“好”意味着什么的定义，白纸黑字写下来，这样打分就不再是凭心情。
这就是整个套件。它并不高深。它是软件团队做了四十年的事的 AI 版本，而跳过它就等于在没有测试的情况下发布 code——它能一直用，直到某天不行了，而代价要晚些时候才会显现。
评估套件就是你的测试套件。模型就是你的 code。而和 code 一样，模型会不打招呼地改变——套件就是你发现变化的方式。
为什么它必须先来
评估之所以要先来，是因为它改变了随之而来的每一个决策。
在功能之前先构建套件，功能就会围绕着一个目标被构建。你可以试两个模型，挑那个在你的用例上得分更高的，而不是演示效果更好的。你可以对照评分标准来调提示词，而不是凭感觉。你可以对一个在你边界用例上失利的“优秀”模型说不。评估把模型选择从一场演示竞赛变成了一次测量。
在功能之后才构建评估，你得到的是这一切的事后版本。模型已经选好了，提示词已经写好了，功能已经摆在了用户面前。姗姗来迟的评估只能记录那些它本是为之而建的失误。它能告诉你模型不好。它无法告诉你本该选哪一个。
让它先来的另一个原因：评估是团队弄清“好”意味着什么的方式。编写黄金集迫使对话发生——边界情况有哪些，错误的答案长什么样，每一种错误的代价是什么。那场对话才是功能的真正规格。先写评估的团队在构建之前就发现了需求。跳过它的团队在事故之后才发现需求。
最小可行套件
反对的理由总是同一个：构建一个评估套件听起来像一个大项目，而功能必须上线。最小可行套件回答了这一点。它就是五十个用例加一个周末。
五十个用例，与领域负责人一起用一个下午整理出来：十个最常见的请求、十个最难的、十个最危险的、十个看起来相似但需要不同答案的，以及十个过去弄坏过类似系统的。用一个周末运行它们、打分，并写下评分标准。这就是种子。套件从这里成长——每一个生产 bug 都变成一个回归用例，每一种新任务类型都获得自己的黄金集，每一次模型升级都要对照整套东西打分。
五十个用例的套件抓不住一切。它会抓住大事，它会迫使规格对话发生，它还会给你一个可以盯着的数字。拥有五十个用例和一份评分标准的团队，比拥有一个精彩演示却别无他物的团队要好上无数倍。
让它得以坚持的规则
评估套件的死亡方式和每个测试套件一样：当它不再被使用时。让它活下去的规则很简单——任何模型变更都必须先跑一次评估才能上线。新模型版本、新提示词、新温度参数、任何新东西：跑一遍套件，比较分数，只有在更好或持平时才上线。这就是全部纪律，也正是让软件里的测试保持诚实的那套纪律。
你现在正在构建的功能，将由你本周构建的评估套件来维护。模型会变，供应商会更新，数据会漂移，而每一个这样的时刻都是一个套件能给出答案的决策。先构建它，保持小巧，让它成为把关口。演示告诉你模型能做这项任务。评估则告诉你，下个月、当一切都变了之后，它是否还能。
在功能之前构建套件。五十个用例、一个周末，外加一条规则：没有分数，任何东西都不上线。这就是全部做法，也是你信赖的 AI 与你只是寄予希望的 AI 之间的区别。