PM 与评测之间的翻译鸿沟：当发布决策超越了词汇表

AI 功能的上线决策会议（go/no-go meeting）表面上是一个数据驱动的仪式。工程团队会带来一系列评估数字——评测专家分数变化（judge score deltas）、切片准确率（slice accuracies）、相对于基线的回归百分比（regression-against-baseline percentages）——然后由与会者做出决定。这看起来非常严谨。但通常并非如此。

一句话概括这种失败模式：有能力解读评估切片权重的人没有决策权，而有决策权的人看不懂切片。产品经理（PM）主导发布决策。工程师掌握数字背后的含义。在这两者之间存在着翻译鸿沟，谁在会议上表现得最自信，谁就能填补这个鸿沟。

问题的征兆在于，“87% 准确率就发布”和“87% 准确率不发布”都可以基于同一份评分卡找到依据，这取决于你更看重哪个切片。当同一份数据集支持截然相反的结论，且决定性因素是辞令上的自信而非证据时，你拥有的就不是一个数据驱动的流程，而是一场以电子表格为背景的辩论。

这不是哪一方的能力问题。PM 的业务能力并不差，工程师也没有隐瞒信息。问题在于结构性的：评估维度的演进速度超过了共享词汇的建立速度。因此，团队花真金白银产出的成果——一套经过仔细切片、以基线为锚点的评估集——在决策者面前变得晦涩难懂。

PM 实际上是如何看评分卡的

非工程师在阅读代码差异（diff）时，是从周围的对话中推断意图的，而不是从差异本身。他们观察谁看起来更有信心，谁在闪烁其词，今天早上 Slack 频道里说了什么。代码差异只是一个道具。

PM 阅读评估评分卡的方式也是一样的。面对一张充满数字的表格——intent_accuracy: 0.91，macro_F1: 0.78，adversarial_pass: 0.83，regression_vs_baseline: -1.2pp——PM 无法判断其中哪一项对 本次 发布至关重要。所以他们退而求助于对话。工程负责人点头了吗？数字比上周上升了还是下降了？有没有人表现出明显的担忧？

这导致决策看起来是指标驱动的，实际上却是“氛围驱动”的。PM 并不是在权衡数据切片。他们是在权衡人。

而且这种鸿沟是不对称的，这让情况变得更糟。构建评估的工程师非常清楚哪个切片最关键——他们知道 macro_F1 下降是因为罕见的“账单争议”意图出现了回归，他们也知道账单争议只占流量的 0.4%，但却占投诉量的 30%。这些背景信息只存在于他们的脑海中，而不在评分卡上。因此，除非工程师恰好主动提出，并且恰好赢得了全场的认可，否则决策就是在缺乏背景信息的情况下做出的。

更糟糕的是，工程师通常有解读能力却没决策权。他们可以说“我建议暂缓”，但 PM 拥有发布日期、路线图承诺以及已经排在日程表上的销售电话的掌控权。如果 PM 对“AI 质量”的心理模型落后了两个季度——因为自从上次有人带他们熟悉评估维度以来，评估层面又增加了六个新的切片——那么决策权和解读权就彻底脱钩了。

评估集是一个跨职能的产物

团队将评估集视为一种工程工具，然后却对谁在阅读它感到惊讶。评估集不仅仅是一个防止回归的关卡。它是一个 沟通产物，它的受众比编写它的团队要广泛得多：PM 阅读它来做发布决策，工程经理阅读它来进行人力争取，支持负责人阅读它来预测工单量，有时法务部门也会阅读它进行风险审批。

如果你接受这一点，那么接下来会有三个结论。

首先，评分卡需要一个固定的模板，让 PM 在 每次 发布时都能看到。而不是每次都用一张临时的表格。当格式随每次发布而改变时，每个检查点都会变成一场关于哪些证据有效的辩论——而重新讨论格式往往是团队在重新论证已经证明过的工作。一个稳定的模板意味着 PM 只需学习一次如何阅读，并可以终生复用这种能力。

其次，阈值必须在评估运行 之前 商定。“我们需要 90% 的意图准确率才能发布”是一个产品决策，而不是技术决策——它体现了用户对缺陷的容忍程度，以及在你的领域中失败的代价。如果在结果出来后再设定这个数字，那它就不是阈值。它是一个为了匹配最强势的人所想要的结果而反向推导出来的辩词。

第三，每个切片都需要一个产品术语命名的名称。“意图分类头的 macro-F1”对 PM 来说毫无意义。“助手正确识别用户需求频率”则很有意义。同样的数字，翻译之后就不同了。

弥合鸿沟的纪律

以下是五个具体的实践，大致按杠杆效应排序。

采用预设阈值的固定模板评估评分卡。 每次发布都使用同一个模板。每个指标在运行 之前 都由工程和产品部门商定好发布（ship）/ 暂缓（hold）/ 升级（escalate）的区间。评分卡的工作是给出建议——绿色、黄色、红色——而不只是数字。绿色：每个维度都达到阈值，相对于基线没有回归，对抗性测试（adversarial pass）高于安全底线。黄色：核心场景通过，部分边缘场景退化，有监控措施。红色：出现任何安全故障，或核心通过率低于阈值，或者在没有补偿性收益的情况下出现重大回归。PM 不需要去 计算 结论。他们需要 理解 结论，并根据需要有意识地否决它。

产品侧对真实案例进行评估审查。 每次发布时，PM 都要实实在在地查看五个失败案例和五个成功案例——真实的输入，真实的模型输出。这是清单上杠杆效应最高的一项实践。数字是抽象的；但助手理直气壮地给客户错误的退款政策的对话记录则不然。经过三次发布后的这种审查，PM 不再会问“87% 好吗？”，而是开始问“那失败的 13% 是我们能承受的失败吗？”——这才是正确的问题。

翻译术语表。 一份鲜活的一页文档，将每个评估切片映射到一句产品语言中。intent_accuracy → “我们理解用户需求的频率”。adversarial_pass → “试图破坏助手的用户失败的频率”。groundedness → “回答在多大程度上得到了我们检索到的文档的支持”。维护起来虽然无聊，但这却能区分出一个能读懂评分卡的 PM 和一个只能察言观色的 PM。

季度校准。 每季度，PM 和工程团队都要重新锚定哪些切片对应哪些用户可见的结果。评估维度会发生偏移——在事故发生后会增加新的切片，而旧的切片会饱和并失去区分度。如果没有定期的重新锚定，PM 的心理模型会在评分卡不断增长的同时悄然失效。

发布会议决策协议。 在众人辩论之前，首先 宣读评估评分卡的建议。这是一个极小的会议设计，却能产生巨大的影响。当数据成为锚点时，讨论会围绕一个共同的参考点进行调整。当讨论先行时，数据就会沦为已经有偏好的一方所利用的弹药。同样的数字，截然不同的认识论——顺序决定了你得到的是哪一种。

为什么这是领导力的问题，而非模板问题

你可以将上面的章节看作一份流程清单，到此为止。但这会错过真正的核心点。

更深层次的失败源于领导层的一个假设：即 AI 质量可以委托给一个指标，而指标本身就能说明一切。事实并非如此。评估分数（eval score）是将混乱且多维的现实压缩成一个数字，而压缩是有损的。会议室里必须有人负责解压这个数字，而这个人既需要具备相关的专业素养（literacy），又需要具备决策权威 —— 或者是在分别持有这两项能力的两人之间搭建一座可靠的桥梁。

当这座桥梁缺失时，组织的失败并不会轰轰烈烈。它会悄无声息地发生：发布决策被层层上报，直到落入那个听起来直觉最笃定的人手中。有时这种直觉是对的。问题在于，这种正确性与证据之间变得不再相关 —— 一个投入重金进行严谨评估，最后却凭直觉拍板的组织，只是买了一个昂贵的道具而已。

相对于其保护的评估基础设施，修复方案的成本非常低廉。一份词汇表、一个固定模板、每次发布查看十份对话记录、每季度一小时，以及重新调整会议议程的优先级。这些都不需要新的工具。所有这一切都要求领导层将跨职能的评估素养视为一项有明确负责人的交付物，而不是一种会自发形成的东西。

在下一次发布之前建立这种素养桥梁，而不是在那个因为“大家感觉良好”就让评估分仅为 87% 的产品上线后的复盘会上再行动。