AI 做出来的东西，你怎么验证 — 遮住答案，再数错的

能不能做出来，已经不是问题。 做出来的东西是否正确，由谁、用什么方法确认，才是问题。

制作速度早已不是瓶颈

最近的 AI 导入咨询里，几乎没有人再问"这个能不能做"。多半都能做出来。剩下的只有一个问题：怎么知道做出来的东西是对的。

这项确认工作不会自动发生。看起来合理和实际正确是两回事，尤其是报告、分析、判定这类形式固定的成果，错了也看不出来。

我们最近做了一件必须正面回答这个问题的工作。把一套沉淀已久的知识体系搬到 AI 上生成解读文本，完成的那一刻就撞上了墙。收集一百条"很准"的反馈，也不构成证据。因为人只会记住说中的部分。

下面是我们当时建立的验证流程，写成可以直接搬到业务上的形式。

一、选择答案已知的案例

验证的起点是你已经知道正确答案的问题。

在公司里，就是已经有结论的历史案件：去年批准或驳回的申请、结果已定的报价、最终引发投诉的订单。要从结果明确、样本足够的领域入手，验证才成立。

反过来说，无法准备答案的工作，现在还不是动手的时候。结果几年后才出现的工作、不同人判断不一致的工作都属于此类。

二、遮住答案再让它作答

这一步是多数团队会漏掉的。

如果在给出案例的同时，把能推测结论的线索也一并给了 AI，那么它答对时我们什么也学不到。因为无法区分它是判断出来的，还是把已知的东西抄了一遍。

所以我们删掉了所有可能通向结论的信息，没有留下任何能识别对象、时间和地点的值。然后用机器确认它确实被删掉了 — 对送入 AI 的全部文本做关键词扫描，只要命中一处就中止验证。

没有这一步，"盲测"就只是一句声明。实务中同样如此：投入历史案例时，只清空了结果列，却把暗示结果的备注原样留着，这个错误极为常见。

三、先写下判定标准

看了结果再定标准，什么都会像是答对了。

什么算"命中"、什么算"未中"，必须在跑第一个案例之前用文字写下来。我们还加了一条：判定为命中的每一处，都要附上作为依据的记录。拿不出依据的，从判定中剔除。

仅这一条规则就改变了验证的性质。它不再是印象，而是可以计数的东西。

解读结果 — 怎么数占一半

比流程更难的是结果解读。给出四点建议。

第一，答对和答错一起数。在我们的案例中，两份报告分别有 22 处和 31 处与文献记录吻合，3 处和 6 处未中。只写前一个数字的报告是宣传材料，不是验证结果。在公司内部听取 AI 成果汇报时，要问的也正是这句 — 有多少件是错的？

第二，把错误分类。它们不是同一种失败。

• 完全相反 — 给出了相反的答案，直接暴露工具的边界。
• 只对一半 — 方向对了，结论错了。多半是抓住了依据却在最后一步判断上偏离，这正是需要人介入一步的位置。
• 前提不同，不适用 — 答案本身说得通，但不适用于这个案例。

第三，最该盯住第三类。这里会显露出工具默认假设了什么。在我们的案例中，完全不知道对象是谁的 AI，给出了以某个特定国家制度为前提的答案。这不是偶发失误，而是被学习进去的默认值 — 而这个默认值同样混在那些答对的内容里。是错误答案让它变得可见。

搬到业务上就是：它是不是在用行业惯例而不是我们公司的规程作答？是不是在用修订前的标准作答？验证的错题清单会给出线索。

第四，答对的也要再分一层。放在谁身上都成立的话和只在这个案例成立的话是两回事。"细致，但有时会着急"这样的句子永远都对。验证中真正该给分的，只有本可能出错却答对了的部分。

验证顺带告诉你的事

这项工作带来了一个计划外的收获：跑验证的过程中，暴露出既有系统的多处缺陷。

原因很简单。要把人做的判断交给机器，就必须把过去默默处理掉的例外和边界值，全部用语言写出来。在这个过程中，原本就存在的错误会一起浮上来。

边界值尤其如此。人眼扫过去毫不在意的地方，一旦落成计算，就成了决定结果的那条线。我们的案例中，一个输入只偏了一点，结果的一整条轴就翻了过来。验证之前没有人知道这件事。

AI 项目的第一份成果，常常不是新的自动化，而是发现了旧流程里的错误。

事后比对不是预测

最后是最重要的区分。

在历史案例上通过，意味着这个工具在与历史案例相似的工作上可用，并不意味着它能预测未来。我们也在报告里用粗体写了一句 — 这是事后比对，不是预测。

在公司内部分享验证结果时，请把这一行一并附上。少了它，一份漂亮的验证结果反而会成为过度自信的依据。

归纳起来

选答案已知的案例，遮住答案，先写标准，把错的也数上。然后按类型去读那些错误。这个工具能信到什么程度，答案就写在那里。

如果制作花了半天、验证花得更久，那不是做砸了，而是做对了。

本文案例所用的报告，可以在 Orienteller 上以同样的方式确认与验证。