打开任何季度计划电子表格，你都能找到团队交付的每一个功能、每一张外包发票、每一项云服务支出。你找不到的是那些从未发生的停机事故、在触达客户前被拦截的幻觉退款，或者是凌晨 2 点被评测（eval）拦截的 Prompt 回归。这些“非事件”没有 SKU。它们不产生工单、没有复盘报告，也没有 Slack 讨论串。因此，当评测预算面临续约时，它在与拥有 Demo 的功能争夺人力配额——而且几乎每次都会输。
这不是勇气的问题。这是一个衡量标准的问题。评测投资同时兼具安全网和测试套件的属性：它悄无声息地产生复利，在规避灾难中体现价值，而其全部价值都建立在“反事实（counterfactual）”之上。财务部门在结构上对反事实视而不见。如果你领导一支 AI 团队，你的工作不是去争论评测是否重要——这一点每个人都会点头同意。你的任务是让那些只相信电子表格的人，能够看懂这种具有复利效应且无形的投资回报。
为什么评测的价值在结构上是不可见的
安全团队在过去二十年里一直深受此问题困扰，并给它起了一个名字：预防悖论（prevention paradox）。一个安全项目表现得越好，其价值就越不明显。在预算委员会看来，一个从未发生安全漏洞的首席信息安全官（CISO）所领导的部门简直“无所作为”。投入 200 万美元用于端点检测，从而防止了一场价值 1500 万美元的勒索软件攻击，在账面上体现为 200 万美元的成本和 0 美元的收益——因为那场 1500 万美元的攻击是假设性的。实践者称之为“无形保护悖论”，它产生了一个恶性循环：你投资，投资奏效，灾难的缺席让投资显得不必要，支持力削弱，组织悄然变得更加脆弱。
评测是 AI 产品的预防层，它们完全继承了这一悖论。每一个在部署前捕获回归错误的评测，都将潜在事故转化为了“非事件”。非事件就是胜利。根据定义，非事件在事后也是无法衡量的——你无法向别人展示那个没有接收到错误医疗建议的客户，因为根本没有这个客户，没有记录，空无一物。
与功能开发的这种不对称性是残酷的。一个功能会带来 Demo、发布文章和持续上升的使用增长曲线。而当团队尽职尽责时，评测套件产生的数字只会保持平稳。“平稳”在董事会的汇报材料里可不好看。因此，无论评测预算实际上创造了多少价值，它在进入每一次优先级讨论会议时，在叙事上就已经输了。
评测不是 QA 开销——它们是加速工具
领导者可能犯下的最昂贵的认知错误，就是将评测归类为“质量保证（QA）”。在大多数组织的思维模型中，QA 是交付的一种“税收”——是你通往生产环境途中必须经过的、减慢速度的关卡。如果评测是税收，那么削减它们就能换取速度，而任何提高速度的压力都会转化为削减评测的压力。
这种模型完全反了。一个好的评测套件才是让你能够快速交付的关键，因为它是“快速行动”与“快速行动并破坏客户信任”之间的防线。如果没有评测，对 Prompt、模型版本、检索索引或工具定义的每一次修改，都是一场盲目的赌博。没有这张安全网的团队实际上并不会交付得更快——他们交付，然后被教训，接着因为恐惧而慢得像蜗牛爬，不得不手动测试每一个更改，因为他们没有自动化手段来获知破坏了什么。
斯坦福 HAI 的《2025 年 AI 指数报告》指出，拥有结构化评估工作流的组织所经历的生产事故显著减少。大约三分之一的组织将“质量”列为 AI 部署的首要障碍——它是阻止原型变为产品的绊脚石。评测并不是在生产之路上拖慢你脚步的东西；相反，评测的缺失才是让你困在“原型坟场”的原因。相应地重塑这一预算项。它不是“QA 开销”，而是“部署速度保险”，而速度是你的 CFO 已经知道如何衡量价值的东西。
将评测覆盖率与速度及事故联系起来的指标
反事实价值无法直接衡量，但可以通过财务部门已经信任的替代指标来使其变得“易于理解”。目标不是造一个虚假的 ROI 数字，而是建立一组随时间推移共同变化并讲述完整故事的指标。
关键路径的评测覆盖率。 在退款、医疗或法律索赔、不可逆的工具调用、PII 处理等高风险行为中，有多少比例设置了阻断性评测？这是 AI 领域的“测试覆盖率”，它回答了每个高管都能理解的问题：“有哪些是我们没有检查的？”源自事故的评测比例。 在你的总评测案例中，有多少是从真实的生产事故中回填的，又有多少是预先设计的？一个健康且上升的比例是组织学习能力的直接证据：每一次失败都被转化为了永久性的回归测试，从而确保不再复发。回归拦截率。 上个季度在部署前的 CI 阶段触发了多少次评测失败？每一个失败都是一个有据可查的“险情”。这是你最接近“预防悖论”真实写照的东西——一份因为某些拦截而未发生的事故清单。部署速度。 每周交付到生产环境的更改次数，以及从提交到部署的交付周期。将其与评测覆盖率对比绘图。你想要讲述的故事通常是：覆盖率和速度同步增长，因为信心是消除手动测试瓶颈的关键。遗漏事故率（Escaped incident rate）。 单位流量下由 AI 行为引起的生产事故。这是一个滞后指标。当覆盖率名副其实时，即使部署速度加快，这个数字也会呈下降趋势。这种组合是你能展示给财务部门的最具说服力的图表。 这些都不是直接的金额数字，你应该抵制制造虚假金额的诱惑。真正有说服力的是相关性：覆盖率上升、速度上升、遗漏事故下降，季度复季度。这是一个 CFO 可以认可的模式，因为它将投资与他们已经关心的两件事联系了起来——交付速度和风险。
一个警告：如果评测不具备阻断力，那么评测覆盖率就毫无意义。运行一个失败仅作为建议而非强制拦截的套件，只会产生一个“没长牙齿”的覆盖率数字。真正重要的指标是阻断性评测的覆盖率——即那些真正能阻止部署的质量关卡。建议性评测只是在“演戏”，而当预算收紧时，演戏是最先被砍掉的，因为每个人私下里都知道它并没有起到任何作用。
在宕机发生前，让复利增长清晰可见 评估（Eval）投入具有复利效应。你添加的每一个源自事故的案例都是永久性的——它能针对该故障模式提供永久保护，无论未来如何更换模型或重写提示词（prompt）。如果你拥有一套能在一小时内准确告知变更内容的测试套件，那么原本需要数周、让人提心吊胆的模型迁移工作，就会变成一次常规的 Pull Request。这种复利效应就是完整的财务理由，而这恰恰是单季度电子表格无法体现的。电子表格按项目出现的季度进行定价；而复利资产从本质上就会被误定价。
这是一个领导力任务，而非工程任务。工程师可以构建测试套件；但他们无法在冲刺（sprint）周期内改变组织对它的核算方式。以下三个举措会有所帮助。
首先，为“隐形胜利”提供展示平台。每月进行一次“未发生的事故”回顾——列出回归测试捕获的问题清单，并为每一项打上“若发生则会导致的面向客户故障”标签——这能将“无事发生”转化为可见的成果。你并不是在创造价值；你是在让已有的价值被看见。
其次，提前为负面影响定价。“我们需要评估预算，因为一次宕机将损失 X”这种论点，在宕机发生后的第二天会比发生前的一天显得软弱无力得多，然而在发生前的那一天，往往没人想听这个。对你的产品可能发生的最糟糕 AI 故障进行事前剖析（Pre-mortem）——例如错误的剂量、泄露的记录、六位数的错误交易——附上一个真实数字，并在它还是假设阶段时就记录在案。当预算争夺战到来时，你不是在做预测；而是在引用领导层已经看过的数字。
第三，将评估预算与速度指标挂钩，而非质量指标。“这笔钱用于提升质量”会招来“质量还可以，削减它”的回应。“这笔钱保障了我们每周交付 N 次且不影响客户的能力”则会引发完全不同的对话，因为现在削减预算有了显性且有归属的代价：团队变慢了，而且必须有人签字同意这一点。
在评估预算争夺战中获胜的团队，并不一定是拥有最佳评估方案的团队。而是那些在足以证明其价值的宕机发生之前，就让“反事实”变得清晰可见的团队——他们将一种复利的、隐形的资产转化为了财务部门能够认可的故事。趁现在电子表格仍将你的评估套件视为纯成本时，就开始这项工作吧。否则，你只能在以后的事后分析报告中去做这件事，到那时，该预算项终于变得可见，却是出于最糟糕的原因。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
