在AI测试中使用评分卡没你想的那么糟

谁不喜欢断言（asserts）呢？

我们有个坏习惯，把"简单"和"容易"混为一谈。在传统自动化中，定义质量很简单。它是二元的。要么匹配，要么不匹配。绿色或红色。

`Assert.AreEqual(expected, actual)`

但在AI领域，"好"不是二元的。它很复杂。有五十种正确说"你好"的方式，也有五十种粗鲁说它的方式。作为人类，我们凭直觉处理这种复杂性。我们读到一个不完美但抓住了主要思想的输出，会想："嗯，够好了。"

但当我们试图自动化这种感觉时，问题就开始了。自动化讨厌"差不多对"。自动化想要精确。而当我们试图将一个非确定性的、创造性的AI塞进一个僵化的、二元的盒子里时，我们得到的不是质量。相反，我们得到的是不稳定的测试（flaky tests）。

僵化数学的问题

让我们看一个真实世界的例子：我的API 分析智能体（An API Analysis Agent）。

这是一个设计用来分析API端点的AI智能体。你给它一个提示词："分析这个端点，给我3个有效输入的建议、3个无效输入的建议，以及3个边界情况的建议。"

在传统测试中，你的断言逻辑大概长这样：

assert len(suggestions.valid)== 3
assert len(suggestions.invalid) == 3
assert len(suggestions.edge_cases)== 3

现在，假设 AI 返回了：

● 3个有效建议。

● 3个无效建议。

● 2个边界情况。

总计：完成了9个请求中的8个。

在传统自动化的二元世界里，这个测试失败了。报告变红。流水线停止。你在Slack上收到告警。你看着失败说："蠢 AI。"（当然，别在麦克风附近说，它可能会听见）。

但等等，看看数据。它给了你 8 个扎实的建议。它找到了有效输入和无效输入。它甚至找到了两个棘手的边界情况。它只是漏了一个边界情况。这是一个"失败"的结果吗？还是这是一个非常有用的结果，只是没达到一个arbitrary（随意设定）的计数？

可以到我的个人号：annasea0928

即可加入领取【转行、入门、提升、需要的各种干货资料】

内含AI测试、 车载测试、AI大模型开发、银行测试、游戏测试、数据分析、AIGC…

通过把这个标记为失败，你在扔掉价值。你在用一个二元的"坏"标签，掩盖一个"够好"的结果。

解决方案：评分卡

为了解决这个问题，我们必须停止测试相等性（Equality），开始测试实用性（Utility）。我们需要从二元断言转向评分卡（Scorecard）。

评分卡将"够好"量化。它将结果分解成加权的概念并把它们加起来。

让我们把我们之前的API结果翻译成使用评分卡的方法：

评分标准：

● 有效输入：每个 1 分（最多 3 分）

● 无效输入：每个 1 分（最多 3 分）

● 边界情况：每个 1 分（最多 3 分）

通过阈值：

● 及格分数：> 6

执行过程：AI 返回了 3 个有效、3 个无效和 2 个边界情况。

● 分数：3 + 3 + 2 = 8

● 阈值：6

● 结果：通过

突然之间，你的测试套件不是红的了。它是绿的。为什么？因为产品完成了它的工作。它提供了价值。评分卡反映的是质量的现实，而不仅仅是提示词的严格性。

进化：评分卡是活的代码

关键来了：这个评分卡不是静态的。今天6分的阈值可能是可接受的。但随着你的模型改进，或者你优化提示词工程，你可能会把阈值提高到8。或者你可能给"有效案例"加个乘数，因为它们更重要。

这不是"维护负担"，这是质量工程（Quality Engineering）。你在主动决定"够好"长什么样，并把它编码进你的套件。

结论

测试基于AI的产品或智能体，需要我们在如何看待自动化上进行根本性转变。我们正在从检查字符串转向评分行为。我们正在从"通过/失败"转向"够好"。

如果你还在试图对LLM 输出使用`Assert.Equals`，那你将会在 2026 年和你自己的测试套件打架。而且你会输。

`Assert.Equals`

这种从二元到评分的转变，正是我们想鼓励人们开始使用的战略性思考。这就是我的Captain's Bridge（舰长桥）的用武之地。让我们停止与我们的工具对抗，开始领导我们的质量——来自战壕的战略原则或实践。