在沒有固定評測集的情況下，每一次提示詞修改都是一場新的遊戲。我可以用幾段看起來很有說服力的對話來測試新版本，並宣稱這是一項改良；而另一位 QA 工程師可以挑選另外五段不同的對話，得出完全相反的結論。到了這個地步，我們其實已經不是在用同一把標準比較兩個版本——而是在比較兩份不同的證據。

這就是為什麼評測集必須成為一個受控的 QA 工件，而不是一個放著「有趣對話」的資料夾。黃金集讓不同版本接受同一場考試：已知的輸入、保留的脈絡、明確定義的期望，以及能說明每個案例為何存在的標籤。目標不是把測試永遠凍結，而是建立一個穩定的量測基準點，如此一來當分數變動時，我們才有信心是產品改變了——而不是測試改變了。

1. 案例欄位：保留判斷的前提

一個黃金案例需要足夠的資訊，讓另一個人能理解為什麼它的預期結果被認為是正確的。至少，我會保留 id、輸入及其對話脈絡、預期輸出或預期性質、難度、來源、標註者、標註日期與版本。只有輸入本身往往是不夠的：「我可以退貨嗎？」這句話的正確答案，可能因商品、購買日期、商品狀態、帳號狀態，或助理當下可依循的政策而完全不同。

預期結果也不一定非得是一句完美的標準答案。對生成式系統而言，預期性質往往更耐用：理解客戶的問題、套用正確的政策、提供規則允許的下一步，並且不得承諾規則之外的任何事。一個配套的 must_not 欄位 可以捕捉硬性失敗，例如捏造退貨資格或承諾未經授權的退款。這讓 QA 能評估語意，而不會把某一段人類寫的回覆當成唯一可接受的措辭。

難度與來源等欄位說明案例在評測策略中的位置，而標註者、標註日期與版本則保留它的歷史。一個由已安全去識別化的生產事故衍生而來的困難案例，所承載的證據份量，就和一個直白的合成案例不同。記錄由誰標註、何時標註也很重要，因為政策、產品行為和評測標準都可能改變。案例應該保留判斷的前提，而不只是判斷的最終答案。

2. 代表性與資料洩漏：這個集合實際量到了什麼？

一個黃金集可以被標註得完美無缺，卻仍然產生誤導——如果它只代表產品中最容易處理的部分。覆蓋範圍應該從主要的意圖開始——退貨、取消、帳戶問題、商品資訊、疑難排解，或這個系統實際處理的任何事務——然後納入意圖內部的變化。長尾同樣重要：模糊的請求、缺失的脈絡、罕見的政策組合、錯字、混用的語言、互相矛盾的資訊，以及先前觀察到的失敗案例。目標不是把生產環境縮小重現，而是防止評測集變成一堆模型早已駕輕就熟的乾淨案例。

接著是資料洩漏，這基本上是紀律問題。如果同一批黃金案例在提示詞反覆改寫的過程中不斷被檢視，人們會逐漸針對這些特定範例做最佳化，而不是改善整體行為。某個提示詞看起來變好了，可能只是因為團隊實際上已經把考題背了下來。因此黃金集應該有受控的使用方式，必要時另設獨立的開發或探索用案例；而且不應該只因為新案例能讓最新版本看起來更強，就把它加進集合裡。唯有抵制住「把直尺調整改合成我們剛量到的樣子」的誘惑，評測集才能作為一件量測儀器發揮作用。

3. 版本控制，以及「多少案例才夠？」

黃金集應該持續演化，但每一次變更都必須留下軌跡。每一筆新增、編輯或刪除，都要有一條變更日誌紀錄，包含日期、動作、原因與負責人。如果退貨政策改了，某個預期結果可能確實需要修訂；如果新的生產事故暴露出一個未覆蓋的風險，一個新案例可能就屬於這個集合。版本控管讓這些變更清晰可見，如此一來黃金集 v1 的結果才不會被草率地拿來與 v2 相比，彷彿兩者背後的考試一模一樣。

同樣地，也不存在一個神奇的數字能讓黃金集稱得上「夠了」。五十個精心挑選的案例，可能比五百個重複的案例揭露更多問題；而一個涵蓋大量意圖、多種語言、眾多整合與高風險操作的廣泛產品，可能需要多得多的證據。我會用覆蓋度與穩定性，而不是某個神奇數字來判斷充分性：重要意圖是否都有代表、關鍵風險與長尾案例是否在場，以及再增加一個普通案例是否仍能實質改變我們能學到的東西？數量應該由風險面來決定，而不是把風險面硬塞進一個任意數字裡。

範例：黃金集 Schema v1

# fields for one case
id: CS-RET-004
intent: return_policy
input:
  user_message: "The jacket arrived with a torn sleeve and I want my money back."
  context: { order_id: "AS-1077", policy: non_returnable_apparel, delivered_at: 2026-08-02 }
expected:
  properties: [acknowledges the damage, states the item is non-returnable, offers whatever the policy still allows]
  must_not: [tells the customer a non-returnable item can be returned, promises an unauthorized refund]
difficulty: medium
source: de-identified
labeled_by: s-nu
labeled_at: 2026-08-11
version: 1

上面的範例把過去的一次失敗，變成一個可重複使用的量測點，而不是讓它停留在「助理某次講錯了」的故事裡。CS-RET-004 在保留客戶訊息的同時，也保留了讓判斷得以成立的脈絡：訂單、non_returnable_apparel 政策，以及送達日期。它不要求某一個唯一的標準回覆，而是由 expected.properties 定義一個合格答案應展現的行為，同時用 must_not 劃出紅線——告訴客戶該商品可以退貨，或承諾未經授權的退款。

其餘的詮釋資料則說明這個案例背後承載了多少信任與歷史。difficulty: medium 幫助依複雜度整理評測結果；source: de-identified 記錄這個情境的來源；而 labeled_by、labeled_at 與 version 則讓這個判斷在集合演化的過程中保持可追溯。這就是把一個例子變成黃金案例的關鍵：這段對話不再只是「曾經出錯」的證據——它成為一道受控的考題，往後的每一個版本都必須在相同的前提之下作答。