要知道模型裁判判得準不準，先由人確認判斷依據，分開檢查兩類誤判，修改規則後再用保留資料驗證。

需求釐清 agent 整理 ticket 時，會用一句 Goal 摘要目標。優惠碼卡在同一批紀錄裡執行三次，第二次寫下這句話：

提供可在結帳時套用的優惠碼功能，並支援後台設定折扣與到期控管。

這句可以讀成後台只設定折扣，也可以讀成後台連到期日都能設定。模型裁判 judge 若直接回覆滿足或不滿足，還看不出它採用哪種解讀，可能放過新增功能，也可能把合理內容判錯。

同次 score.json 的 Goal 通過只代表非空，接下來要檢查的是每項功能是否都有需求原文支持。

先找出分歧出在哪項功能

把 Goal 與原始需求中的 description、7 條驗收條件 AC 逐項對照，可以先整理成下表。這是解讀示例，尚未經人工確認為校準標籤：

第 6 條 AC 的完整內容是：

活動結束後過期的碼不能用，但已套用的訂單不受影響

這條支持到期限制，沒有指定由誰設定到期日、使用什麼介面。如果 Goal 只是在摘要到期限制，這部分有依據；如果它承諾後台設定到期日，就需要額外的需求支持。

因此，這筆資料要先處理修飾範圍的歧義，再確認整句的人工標籤。若兩位檢查者採用不同解讀，應先約定這類句子如何判定，保留分歧與理由；尚未解決的例子另列數量，不硬算成 judge 判錯。

這也是 Airbnb 校準流程要求先處理人工分歧的原因。確認答案後，人工與 judge 都要逐項保存對應原文與理由，整句只有在所有功能都有支持時才算滿足。

人要在讀 judge 答案前先完成判定，人工標籤另存，不放進 judge 的輸入。紀錄還要包含原始需求、Goal 全文、判斷標準，以及模型與 prompt 版本，才知道兩邊判的是不是同一份資料。

一致率很高，也可能完全沒抓到新增需求

假如大多數人工標籤都是滿足，一個永遠回答滿足的 judge，也可能得到很高的一致率。因此要分開看兩類例子，不能只看總共對上幾筆。

Hamel 與 Shreya 的 judge 驗證方法使用 TPR（true positive rate）與 TNR（true negative rate），分開檢查兩類例子的判定。這裡把滿足設為 positive，以每份 Goal 對這條標準的整體判定為單位：

比例要連同各類樣本數一起看，某類沒有例子時，對應比例就無法計算。人工仍有疑義、judge 呼叫失敗或回覆無法解析的紀錄，要另外列出，不納入這兩個比例的計算。

這條檢查主要防止新增需求被接受，因此要優先檢查假通過，同時保留 TPR，避免一律拒絕也看似有效。假通過可能讓團隊多做功能；誤拒的代價則取決於後續動作，是多一次複查，還是直接刪掉內容。

這份設計會把不滿足的判定送人工複查，保留原本的 Goal。決定門檻前，要先約定哪些誤判需要人介入，再用兩類誤判的代價與驗證結果決定可接受的範圍。

依 ticket 分組，再保留驗證資料

這批執行紀錄涵蓋 16 張 ticket，共留下 45 份最終產出。其中 13 張各有三份，另外三張各有兩份，可以從這些產出挑選待評 Goal，建立人工基準。

同一張 ticket 的重跑要放在同一組，近似變體也一起分。若拿優惠碼卡的前兩次產出修改規則，再用第三次確認效果，驗證時仍然見過同一份需求，無法代表對新 ticket 的表現。

分組後，要確認修改規則與驗證用的資料都包含滿足和不滿足的例子。若自然產出缺少反例，就刻意改寫補足，例如在 Goal 加入「結帳同時累積會員點數」。

原始需求沒有點數功能，這份改寫可以用來檢查 judge 會不會放過新增需求。改寫的例子要經人工確認，與原 ticket 放同一組，並記下它是刻意加入的反例；這裡沒有把它當成實跑產出。

一組資料用來分析分歧、修改規則與例子，另一組預先保留。固定 judge 的模型、prompt 與規則後，才用保留資料驗證；若看過結果又據此修改，下一次就需要新的保留資料。

總結

優惠碼 Goal 的到期限制有原文支持，後台設定到期日卻沒有明示依據，要先釐清句子的含義，再確認人工答案。逐項記錄能找出分歧，TPR 與 TNR 則分開檢查合理內容被拒與新增功能被放過的情況。

現有 45 份產出提供了校準素材，仍需人工標籤與 judge 判定才能得到驗證結果。同一張 ticket 和近似變體要放同一組，保留未用於改規則的資料，並依誤判後的實際代價決定何時轉人工。