你的评估准则是真正的产品规格书 —— 且没有产品经理签过字

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 YAML 文件，编写了 47 个加权标准，以便 LLM-as-judge 能够为每一个追踪（trace）生成一个分数。六个月后，那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则（rubric）不是对规范的衡量 —— 它就是规范，就像编译器不是对语言的描述，而是它的运行真相。就像编译器一样，评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分？哪个标准的权重是 0.3 而不是 0.05？哪些行为在评估准则中缺失，从而完全未被计算？每一个都是产品决策。而它们都没有出现在最初的任务书中。

揭露这一问题的诊断性问题虽然令人不安，但询问的成本很低：将当前的评估准则和原始的产品任务书放入同一个文档中并排阅读。尝试这样做的团队几乎总会发现，评估准则已经偏离了任务书 —— 通常是倾向于那些容易评分的指标，而不是用户关心的东西。两个季度的研发进度实际上是在衡量一个略有不同的产品。

这种转化是如何发生的（以及为什么它是隐形的）

评估准则偏离产品任务书并非出于恶意，甚至不是因为粗心。这是一个无人负责的翻译问题的必然结果。产品经理使用方向性的语言写作，因为产品任务书就是由方向性语言组成的：“感觉很有帮助”、“不居高临下”、“尊重用户的时间”。这些都无法“编译”。工程师需要具有确定性的标准，以便 LLM 评审员能在不同运行中保持评分一致，因此他们进行了翻译。

翻译需要做出任务书中未明确的选择。“感觉很有帮助”变成了“回答了字面上的提问，且提供了一个相关的后续跟进，除非用户的意图是快速查询”。这一操作化过程中的每一个词都是一个产品决策。快速查询是否会因为不请自来的后续跟进而被扣分，还是说后续跟进是一个加分项？“回答字面问题”的权重是等于“有用的后续跟进”，还是更高？如果模型完美回答了问题但后续跟进略有偏差 —— 是给 1.0 分、0.7 分还是 0.5 分？

工程师做出了决定，因为如果不这样做，工程师的代码就无法运行。这个决定是合理的。这个决定没有记录在案。这个决定发布了。将此乘以 47 个标准，再乘以六个月内评估准则的每一次迭代，评估准则已经积累了数百个产品决策。它们都没有出现在产品路线图、设计文档或发布任务书中。产品经理每周审查模型输出并点头称赞，是因为输出结果符合评估准则 —— 而不是因为它们符合原始规范。

编码在无人审计的评估准则中的决策

有三类隐形的产品决策往往占据主导地位。它们值得被命名，因为一旦命名，就更容易防范。

分值边界决策。 当评估准则使用 0 / 0.5 / 1 量表（或 1-5，或任何序数）时，分值之间的界限就是产品决策。“助手正确识别了问题，但解决了一个密切相关但略有偏差的问题”是给 0.5 分还是 0 分？这个答案决定了你的评估是更倾向于“显著失败”（fail-loud，明显的错误）的模型，还是“软失败”（fail-soft，看似合理的错误）的模型。大多数用户更喜欢显著失败 —— 软失败会更快地摧毁信任 —— 但大多数由工程师编写、旨在优化评分者间一致性的评估准则，会将软失败计为部分分，因为它们更容易评分。

权重决策。 几乎每个分析式评估准则都会分配权重，而大多数权重在选定后就再未被修改过。一个权重为 0.05 的标准几乎是不可见的 —— 模型可以在每个追踪中都违反它，而总分几乎不动。如果“不让客户感到匆忙”被转化为了一个权重为 0.05 的单一标准，而“任务完成度”有六个总权重为 0.6 的标准，那么评估准则就单方面决定了客户体验的重要性大约只有任务完成度的十二分之一。产品经理几乎肯定不这么认为。

缺失标准决策。 评估准则中不存在的标准是最危险的，因为它们在评估内部是不可观察的。如果你的评估准则对正确性、完整性、语气和安全性进行评分 —— 但从未评分助手是否能优雅地处理与之前回答相矛盾的后续问题 —— 那么“矛盾情况下的优雅自我修正”就是未被评估的，这意味着它未经过测试，也就是说它取决于模型的默认表现。你的产品在这一类别中是有特定行为的。你只是不知道它是什么。

为什么评分标准会向易于评分的内容偏移

每个评分标准都存在一种强烈的、结构性的倾向，即向那些能产生稳定、可辩护分数的准则偏移。维护评分标准的工程师希望实现评分者间的一致性（LLM 裁判之间，以及 LLM 裁判与人类之间），因为一致性低会导致评估充满噪声，而充满噪声的评估无法起到任何把关作用。因此，评分标准的自然演变过程是：产生噪声分数的准则会被重新表述为更具体的内容；无法重新表述的准则会被剔除；而能产生清晰分数的准则会被保留并经常被复制。

这种演进的终点是一个评分表现完美的评分标准——高一致性、低方差、清晰的仪表盘——但衡量的内容却与用户真正想要的东西略有偏差。最近关于基于评分标准的评估研究正记录了这种偏移，例如 RULERS 框架明确指出“与人类评分边界的尺度失配”是除评分标准不稳定性（rubric instability）和不可验证推理（unverifiable reasoning）之外的三种常见失败模式之一。

同样的倾向也存在于准则选择层。“回答是否事实正确”易于评分且能产生清晰的数据。“回答是否让用户觉得自己被当作一个称职的成年人对待”则难以评分，会产生充满噪声的数据，因此它要么不会出现在你的评分标准中，要么作为一个没人信任的、权重极低的综合项存在。猜猜用户真正关注的是哪一个？

这不是评分标准设计得好坏的问题。这是一个优化压力的问题：评分标准正在针对测量属性（低方差、高一致性）进行优化，而不是针对产品属性（预测用户满意度、捕捉潜在质量）进行优化。如果没有抗衡力量，测量属性总是会胜出。

将评分标准视为一等公民的产品交付物

解决方法不是写出更好的评分标准，而是重新界定所有权，并将已经应用于功能规格说明（feature specs）的严谨性同样应用于评分标准。以下三个具体举措行之有效：

PM 拥有评分标准，就像 PM 拥有规格说明一样。 这不是指“PM 签署季度更新”——而是 PM 拥有该文档，审查每一次变更，并且当评分标准与产品简报（product brief）不一致时由 PM 负责。谁来编写 YAML 这一实现细节无关紧要；关键在于文档上写着谁的名字，以及在下一次产品评审中谁需要为其内容辩护。如果答案是“六个月前设置它的工程师”，那么无论你的评估数据看起来多么漂亮，你的治理体系都已经失效了。

像对待功能规格说明一样对评分标准进行变更控制。 每一个新增的准则、每一次权重的修改、每一个重新定义的评分边界都应该在决策日志中记录日期，并附上一行理由说明和一行关于预期用户行为变化的说明。这听起来很重；其实不然。准则层面的决策已经在发生了——只是发生在会被遗忘的 Slack 讨论串中。将它们放入版本化文档中几乎不需要成本，却能让评分标准变得可检查。

定期进行评分标准 vs 产品简报审查。 每季度一次（或与你的发布周期相匹配的任何节奏），将当前的评分标准与原始产品简报以及简报的最新修订版放在一起。在同一个房间里阅读它们。记录评分标准中每一个无法追溯到简报内容的准则，以及简报中每一个评分标准未涵盖的声明。第一份清单是“评分标准的范围蔓延”；第二份清单是“我们声称在意但未衡量的行为”。这两份清单几乎总是存在；而且往往都令人感到不安。

捕捉“工程便利性”准则的跨职能审查

一种值得警惕的特定失败模式是：准则的存在是因为它们易于评分，而不是因为产品端的需求。这些准则往往围绕着语法上可检测的模型输出特征：回复长度、是否有项目符号、结构化输出模式（schema）的合规性、引用数量、拒答率跟踪。工程团队想要这些准则，因为它们很稳定。产品团队可能在意，也可能不在意——并且可能完全不认同评分标准所暗示的方向。

一个有用的练习：与 PM 一起审视当前评分标准中的每一个准则，并询问：“如果我们完全删除这个准则，用户会在一个月内察觉到差异吗？”如果答案是“不会，但它能稳定我们的评分”，那么这些就是工程便利性准则。保留它们未必错误——稳定的评分具有实际价值——但它们应该被明确标记，并据此赋予权重。它们不应默默地吞噬本属于面向产品行为的权重。

反向进行同样的练习：与工程师一起审视产品简报，并询问：“如果模型开始在这一部分规格说明上表现失败，我们的评分标准中有任何准则能察觉到吗？”每一个“不”都是评估中的一个漏洞。漏洞可以用不完美的准则来填补；一个不完美准则的成本远低于一个未衡量行为的成本。

评估反映的是模型的能力，而非用户的需求

最隐蔽的评分准则偏移（rubric drift）发生在评分者（无论是人类还是 LLM）趋向于对容易评分的内容达成一致，而不是对重要的内容达成一致时。在 LLM-as-judge 的流水线中，这种趋同是机械式的：评分准则的制定者不断迭代标准，直到评分者间一致性（inter-judge agreement）超过某个阈值，而那些能够通过阈值的标准，往往是具有明显表面特征（surface signals）的标准。侧重表面特征的标准更有利于那些表面功夫做得好的模型。

随之而来的复利效应是，你开始根据这些标准下的得分来选择模型、提示词（prompt）甚至是产品功能——这意味着你选择的正是你的评分准则过度偏重的那些表面特质。久而久之，产品就会变成评分准则所奖励的样子。如果评分准则奖励听起来很详尽的多段式回答，你的产品就会变得啰嗦。如果评分准则奖励自信的断言，你的产品即使在不该自信的时候也会表现得非常自信。用户会比仪表盘更早察觉到这种变化。

摆脱这种困境的方法是保留至少一个人工标注的、昂贵的、低容量的评估渠道，且该渠道不经过评分准则——即由了解产品意图的人员根据原始需求（brief）而非 YAML 文件对一小部分追踪记录（traces）进行评分。当廉价的评分准则分数与人工渠道出现分歧时，说明评分准则已经发生了偏移，需要重新对齐。这相当于评估领域的“金丝雀发布”：规模小、成本高、速度慢，但它是唯一能捕捉到廉价路径在结构上无法察觉的故障模式的手段。

周一早上要做的事

如果你在运营一款 AI 产品，且从未进行过“评分准则 vs 需求说明”的审查，请在本周安排一次。这种练习通常只需两个小时，但得出的结论往往严重到足以让你重写评分准则。在此期间，请做出三个防止问题再次发生的结构性改变：将评分准则纳入版本控制，并将 PM 设为变更的必要审核人；要求对每一次标准修改都记录一行决策日志；在日历上安排每季度的定期评分准则审计，并要求 PM 和工程负责人共同出席。

评分准则本质上仍然是一种“翻译”。评估 AI 产品不可避免地要将方向性意图转化为可评分的标准，而这种翻译过程总会引入一些原始需求中未曾做出的决策。我们的目标不是消除这种翻译，而是让翻译过程变得可见、可审计且责任明确。如果一个产品经理只写了一段需求描述却从不看 YAML 文件，这不叫授权，这叫失职。在 AI 产品中，YAML 就是产品本身。