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

每个在没有评估（evals）的情况下发布 AI 功能的团队都会对自己讲同样的故事：我们会以后再添加衡量标准，等到找到产品与市场契合点（PMF）之后，等到提示词（prompt）稳定之后，等到下一次发布之后。六个月后，提示词已经被四位工程师和两名产品经理修改过，其行为支撑着三个客户集成，团队发现“以后添加评估”意味着要从从未为此目的结构化过的生产日志中重建意图。本应开发新功能的季度变成了考古季度。

这不是规划错误。而是一个复利错误。为了更快发布而跳过评估的团队，正是那个将花费十二周时间从不完整的追踪（traces）中重建评估基础设施、为二月份所谓的“正确”含义争论不休、并悄悄移除没人能证明依然有效的功能的团队。追赶的成本超过了内置的成本——不是一点点，而是随着每一次未经回归检查就发布的提示词修改而倍增。

从“快速行动”到“盲目运营”的漂移

这种转变在任何一周内都是无形的。第一周，提示词是一段话；编写它的工程师记得每一个决定。第六周，一名 PM 从客户电话中粘贴了三个例子；理由是“这在演示中感觉更好”。第十二周，第二名工程师增加了一个“处理边缘情况 X”的子句，因为一个支持工单提到了它。第二十周，没人知道删除任何一行是否会导致回归，所以没人敢删除。

领先指标是社交性的，而非技术性的。当 PM 开始在 Slack 线程中协商提示词修改——“我们能不能加一句话告诉它不要那么啰嗦？”——团队就已经跨越了门槛。提示词现在是一个没有规格说明、没有版本管理纪律、也没有测试的共享表面。每一次更改都是一场赌博，而庄家正在通过客户投诉来兑现风险。

第二个指标：基于三个客户工单的紧急修复回滚。团队无法区分“影响许多用户的真实回归”和“来自单个集成的响亮投诉”，因此他们根据最响亮的信号进行回滚。在这种情况下这是合理的——因为没有评估，客户工单就是唯一的衡量标准——但这意味着提示词的行为正被最近投诉的人所左右。产品方向变成了样本偏差的函数。

第三个指标是一句话：“如果有回归我们会知道的，因为用户会告诉我们。”这句话应该触发警报。这意味着团队已将质量信号外包给客户，而客户既不系统也不廉价。每一次回归都意味着一个支持工单、一次信任受损，以及工程师一个下午的触发因素追踪。检测每个 bug 的成本比评估套件的运行成本高出几个数量级。

延迟衡量的复利成本

软件技术债务是线性累积的。评估债务则是复利增长。原因是，每一次未经回归检查的提示词修改都会创建一个新的未知行为承诺——无论团队是否有意，某些用户现在都在依赖这种行为。六个月的修改产生了一个充满了隐式契约的表面，没人记录过，也没人能验证。

最近的行业调查显示，技术债务修复可能消耗高达 29% 的 AI 实施预算，而在推迟基础衡量和治理的情况下，项目面临 15% 到 22% 的进度延误。这些数字实际上低估了 AI 的特殊情况，因为传统技术债务的成本是固定的：重构一个混乱的模块需要多长时间就是多长时间。而评估债务的成本是无限的，因为“以后添加评估”的行为要求你首先决定那些你从未定义过的情况下的正确输出是什么——而做出这些决定的人已经离开了，改变了主意，或者从一开始就从未达成共识。

当生产日志没有为了评估而结构化时，考古问题最为严重。团队发现他们的追踪捕获了最终输出，但没有捕获中间的工具调用（tool calls）；或者捕获了提示词模板，但没有捕获填充后的上下文；或者捕获了回复，但因为 PII 脱敏处理太激进，丢失了用户的实际问题。重建评估数据集需要先重建日志流水线，而日志流水线需要没人想追溯做出的产品决策。

与此同时，提示词继续累积修改。团队现在正在同时重构两件事——提示词和提示词的衡量——同时还试图发布触发重构的任何功能。这就是为什么“下个季度再做”变成了“下半年再做”，最终变成了一个拥有三个月授权的专门突击小组。

早期评估的实际成本

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

一个有用的基准成本比大多数团队认为的要低：三十到五十个精心挑选的输入示例，并带有预期的行为属性（不是精确的字符串匹配——而是“拒绝提供医疗建议”、“在讨论价格时包含免责声明”、“提取三个必填字段”）；一个针对所有示例运行当前提示词并将输出与最后一个已知良好版本进行对比的脚本；一个在修改提示词的 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 功能的教训：先上线后测量，是高级工程师制造“职业生涯杀手级烂摊子”的方式。最健康的团队会在亲身经历教训之前，就将其编入流程。其余的团队则在生产事故和季度路线图重写中缴纳学费。