“以后再加评估”的陷阱：测量债务如何产生复利效应

早期评估的实际成本​

在开始阶段跳过评估的论点是，它们是过早优化。这个论点能站住脚一周。在那之后，一个最小评估栈的实际成本是以工程天数而不是周来衡量的。

一个有用的基准成本比大多数团队认为的要低：三十到五十个精心挑选的输入示例，并带有预期的行为属性（不是精确的字符串匹配——而是“拒绝提供医疗建议”、“在讨论价格时包含免责声明”、“提取三个必填字段”）；一个针对所有示例运行当前提示词并将输出与最后一个已知良好版本进行对比的脚本；一个在修改提示词的 PR 上运行此脚本的 CI 钩子。仅此而已。这个基准可以捕捉到大部分本来会发布的回归，并创建了未来评估可以扩展的产物。

团队甚至跳过这一点的原因是文化上的，而非技术上的。早期 AI 工作感觉像是在做原型，而评估感觉像是生产纪律。但其不对称性在于，原型代码很容易丢弃，而提示词行为——一旦用户依赖它——就不是。生产中的提示词就是一份合同，而没有测试的合同是一项随使用量增加而增长的负债。

编写三十个例子还迫使团队进行一场平时会回避的富有成效的对话：这个功能到底应该做什么？将“它应该是乐于助人的”转化为三十个具体案例的过程，会揭示出那些在发布后才会浮现的冲突。评估集至少是一个规范产物，它的成本低于设计文档，且对行为的约束力更强。

防止漂移的强制机制​

个人自律无法规模化。那些能够避免评测债（eval debt）的团队，依靠的是组织层面的强制机制，这些机制让“绕道而行”比“走正路”更困难。

第一项是“发布前评测”门槛：如果没有经过整理的评测集（eval set）并达到最低通过阈值，任何 AI 功能都不得上线。这项规定颇具争议，因为它会推迟发布，但推迟正是其目的所在。一个无法定义何为“正常工作”的发布，注定要在以后压力巨大的情况下被迫定义它。执行这一门槛的团队会发现，定义评测集只需要两到三天，却能节省数个季度的补救工作。

第二项是将评测债视为一项可追踪的工程指标。展示未修复 Bug、未处理事故和过期 TLS 证书的同一个仪表板，也应该显示评测覆盖率陈旧或缺失的 AI 功能。让批准路线图的领导层看到这些债务，能将对话从“我们该不该增加评测？”转变为“本季度我们要消除哪些债务？”

第三项是 Prompt PR 规范：如果没有附加评测增量（eval delta），Prompt 的变更就无法合并。PR 模板中包含一个字段——“评测影响”——它要么是评测运行结果的链接，要么是明确的“不适用，此 Prompt 未经测量”，而后者会触发单独的讨论。这与要求在代码 PR 中包含测试的模式相同，效果也一样：团队会学会随着变更同步编写评测，而不是事后补课。Prompt 回归测试将 Prompt 视为代码；没有测试的 Prompt 就是未经测试的代码。

第四项是从第一天起就掌控上游日志。如果功能上线时带有追踪功能，能够记录完整的 Prompt、上下文窗口、工具调用和输出，且格式便于后续过滤为评测集，那么团队就为自己赢得了在不重建日志系统的前提下追溯构建评测的机会。这在发布时成本极低，但在第六个月时却无可替代。那些将每个请求保存在可查询存储中并保留 90 天的团队——即使尚未对它们进行评测——其恢复曲线与那些只存储聚合指标的团队有着本质的不同。

诚实的核算​

为了快点上线而跳过评测的团队，平均速度并不快。他们在头三个月跑得更快，在接下来的十二个月里却跑得更慢。收益是前置且显见的；成本则是后置且隐蔽的，往往表现为“在开发更多功能之前，我们需要稳定平台”——这种表述掩盖了根本原因。

一个有用的练习：当团队打算跳过评测时，写下以后补上它们的预期成本。要具体化。当原作者调到其他团队后，谁来构建评测集？谁来负责追溯性的日志管道？当利益相关者对 Prompt 的预期行为产生分歧时，谁来仲裁？“考古”需要多少周，期间会耽误什么功能的发布？如果诚实的回答是“我们不知道，大概要一两个季度”，那么这就是“以后再加评测”的代价——它绝非零成本，也不是“等有空时花几天就能搞定”的小事。

陷阱不在于团队不知道评测的重要性。问起来时，大多数团队都会点头表示认同。陷阱在于跳过评测的代价在第一季度是不可见的，而到第三季度则会占据主导地位。等到买单的时候，当初做决定的团队已经离开了，接手代码库的团队有着不同的优先级，而整个工程组织只学到了一个通用于下一个 AI 功能的教训：先上线后测量，是高级工程师制造“职业生涯杀手级烂摊子”的方式。最健康的团队会在亲身经历教训之前，就将其编入流程。其余的团队则在生产事故和季度路线图重写中缴纳学费。