告別Flaky Tests：AI測試中的評分卡實戰技巧

在AI測試中使用評分卡沒你想的那么糟

誰不喜歡斷言（asserts）呢？

我們有個壞習慣，把"簡單"和"容易"混為一談。在傳統自動化中，定義質量很簡單。它是二元的。要么匹配，要么不匹配。綠色或紅色。

`Assert.AreEqual(expected, actual)`

但在AI領域，"好"不是二元的。它很復雜。有五十種正確說"你好"的方式，也有五十種粗魯說它的方式。作為人類，我們憑直覺處理這種復雜性。我們讀到一個不完美但抓住了主要思想的輸出，會想："嗯，夠好了。"

但當我們試圖自動化這種感覺時，問題就開始了。自動化討厭"差不多對"。自動化想要精確。而當我們試圖將一個非確定性的、創造性的AI塞進一個僵化的、二元的盒子里時，我們得到的不是質量。相反，我們得到的是不穩定的測試（flaky tests）。

僵化數學的問題

讓我們看一個真實世界的例子：我的API 分析智能體（An API Analysis Agent）。

這是一個設計用來分析API端點的AI智能體。你給它一個提示詞："分析這個端點，給我3個有效輸入的建議、3個無效輸入的建議，以及3個邊界情況的建議。"

在傳統測試中，你的斷言邏輯大概長這樣：

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

現在，假設 AI 返回了：

● 3個有效建議。

● 3個無效建議。

● 2個邊界情況。

總計：完成了9個請求中的8個。

在傳統自動化的二元世界里，這個測試失敗了。報告變紅。流水線停止。你在Slack上收到告警。你看著失敗說："蠢 AI。"（當然，別在麥克風附近說，它可能會聽見）。

但等等，看看數據。它給了你 8 個扎實的建議。它找到了有效輸入和無效輸入。它甚至找到了兩個棘手的邊界情況。它只是漏了一個邊界情況。這是一個"失敗"的結果嗎？還是這是一個非常有用的結果，只是沒達到一個arbitrary（隨意設定）的計數？

通過把這個標記為失敗，你在扔掉價值。你在用一個二元的"壞"標簽，掩蓋一個"夠好"的結果。

解決方案：評分卡

為了解決這個問題，我們必須停止測試相等性（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（艦長橋）的用武之地。讓我們停止與我們的工具對抗，開始領導我們的質量——來自戰壕的戰略原則或實踐。

??轉崗軟件測試/野路子技能提升

??想了解更多漲薪技能提升方法

??可以到我的個人號：atstudy-js

即可加入領取 ??????

轉行、入門、提升、需要的各種干貨資料

內含AI測試、 車載測試、AI大模型開發、BI數據分析、銀行測試、游戲測試、AIGC