告別Flaky Tests：AI測(cè)試中的評(píng)分卡實(shí)戰(zhàn)技巧

在AI測(cè)試中使用評(píng)分卡沒你想的那么糟

誰不喜歡斷言（asserts）呢？

我們有個(gè)壞習(xí)慣，把"簡單"和"容易"混為一談。在傳統(tǒng)自動(dòng)化中，定義質(zhì)量很簡單。它是二元的。要么匹配，要么不匹配。綠色或紅色。

`Assert.AreEqual(expected, actual)`

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

但當(dāng)我們?cè)噲D自動(dòng)化這種感覺時(shí)，問題就開始了。自動(dòng)化討厭"差不多對(duì)"。自動(dòng)化想要精確。而當(dāng)我們?cè)噲D將一個(gè)非確定性的、創(chuàng)造性的AI塞進(jìn)一個(gè)僵化的、二元的盒子里時(shí)，我們得到的不是質(zhì)量。相反，我們得到的是不穩(wěn)定的測(cè)試（flaky tests）。

僵化數(shù)學(xué)的問題

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

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

在傳統(tǒng)測(cè)試中，你的斷言邏輯大概長這樣：

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

現(xiàn)在，假設(shè) AI 返回了：

● 3個(gè)有效建議。

● 3個(gè)無效建議。

● 2個(gè)邊界情況。

總計(jì)：完成了9個(gè)請(qǐng)求中的8個(gè)。

在傳統(tǒng)自動(dòng)化的二元世界里，這個(gè)測(cè)試失敗了。報(bào)告變紅。流水線停止。你在Slack上收到告警。你看著失敗說："蠢 AI。"（當(dāng)然，別在麥克風(fēng)附近說，它可能會(huì)聽見）。

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

通過把這個(gè)標(biāo)記為失敗，你在扔掉價(jià)值。你在用一個(gè)二元的"壞"標(biāo)簽，掩蓋一個(gè)"夠好"的結(jié)果。

解決方案：評(píng)分卡

為了解決這個(gè)問題，我們必須停止測(cè)試相等性（Equality），開始測(cè)試實(shí)用性（Utility）。我們需要從二元斷言轉(zhuǎn)向評(píng)分卡（Scorecard）。

評(píng)分卡將"夠好"量化。它將結(jié)果分解成加權(quán)的概念并把它們加起來。

讓我們把我們之前的API結(jié)果翻譯成使用評(píng)分卡的方法：

評(píng)分標(biāo)準(zhǔn)：

● 有效輸入：每個(gè) 1 分（最多 3 分）

● 無效輸入：每個(gè) 1 分（最多 3 分）

● 邊界情況：每個(gè) 1 分（最多 3 分）

通過閾值：

● 及格分?jǐn)?shù)：> 6

執(zhí)行過程：AI 返回了 3 個(gè)有效、3 個(gè)無效和 2 個(gè)邊界情況。

● 分?jǐn)?shù)：3 + 3 + 2 = 8

● 閾值：6

● 結(jié)果：通過

突然之間，你的測(cè)試套件不是紅的了。它是綠的。為什么？因?yàn)楫a(chǎn)品完成了它的工作。它提供了價(jià)值。評(píng)分卡反映的是質(zhì)量的現(xiàn)實(shí)，而不僅僅是提示詞的嚴(yán)格性。

進(jìn)化：評(píng)分卡是活的代碼

關(guān)鍵來了：這個(gè)評(píng)分卡不是靜態(tài)的。今天6分的閾值可能是可接受的。但隨著你的模型改進(jìn)，或者你優(yōu)化提示詞工程，你可能會(huì)把閾值提高到8。或者你可能給"有效案例"加個(gè)乘數(shù)，因?yàn)樗鼈兏匾?/p>

這不是"維護(hù)負(fù)擔(dān)"，這是質(zhì)量工程（Quality Engineering）。你在主動(dòng)決定"夠好"長什么樣，并把它編碼進(jìn)你的套件。

結(jié)論

測(cè)試基于AI的產(chǎn)品或智能體，需要我們?cè)谌绾慰创詣?dòng)化上進(jìn)行根本性轉(zhuǎn)變。我們正在從檢查字符串轉(zhuǎn)向評(píng)分行為。我們正在從"通過/失敗"轉(zhuǎn)向"夠好"。

如果你還在試圖對(duì)LLM 輸出使用`Assert.Equals`，那你將會(huì)在 2026 年和你自己的測(cè)試套件打架。而且你會(huì)輸。

`Assert.Equals`

這種從二元到評(píng)分的轉(zhuǎn)變，正是我們想鼓勵(lì)人們開始使用的戰(zhàn)略性思考。這就是我的Captain's Bridge（艦長橋）的用武之地。讓我們停止與我們的工具對(duì)抗，開始領(lǐng)導(dǎo)我們的質(zhì)量——來自戰(zhàn)壕的戰(zhàn)略原則或?qū)嵺`。

??轉(zhuǎn)崗軟件測(cè)試/野路子技能提升

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

??可以到我的個(gè)人號(hào)：atstudy-js

即可加入領(lǐng)取 ??????

轉(zhuǎn)行、入門、提升、需要的各種干貨資料

內(nèi)含AI測(cè)試、 車載測(cè)試、AI大模型開發(fā)、BI數(shù)據(jù)分析、銀行測(cè)試、游戲測(cè)試、AIGC