判定程式也要被驗收，拿已知正確與錯誤的產出分別測試，確認該通過的會過、該擋下的會被擋下，才有依據相信它給的分數。

前一篇用 precision 跟 recall 區分 agent 多標與漏標的問題，但不論看哪個數字，還得確認計算分數的程式檢查了規範真正要求的內容。有一份 Trello 卡片的實驗，就發生過產出違規、檢查卻回報通過的情況。

一條回報通過的檢查，產出其實違規

Trello 卡片實驗的驗收依據是一份寫作規範，其中禁止把尚未釐清的問題留在卡片上。agent 的產出存成檔案後，由另一支程式逐條檢查。

其中一條檢查是 section-absent: Open Questions，這條 assertion 只確認產出有沒有名為 Open Questions 的標題。

偏偏有一份產出把未答的問題放在 ## Unknowns to resolve before implementation 底下。問題還在，只是標題不同，這條 assertion 就回報 PASS。程式照條件執行了，但「沒有某個標題」無法證明「沒有未答的問題」。

產出違反規範，檢查卻回報通過，這裡稱為假通過，是本系列使用的名稱。

那次另一條 assertion 發現標題不在規範允許的清單裡，因此整筆仍判定失敗。可是，如果把未答的問題放進規範允許的標題底下，這兩條檢查都擋不住。

把正確產出判成失敗，會讓開 PR 的人停下來查原因；把錯誤產出判成通過，則不會阻止下一步，比較容易被忽略。要找出後一種錯，不能只追失敗的 case。

用一份正確產出，再拿掉一個必要標註

需求釐清 agent 整理 ticket 時，會檢查需求方寫的驗收條件，也就是 AC，並標出有問題的項目。以優惠碼功能的 ticket 為例，人工確認的答案共有 4 個標註，第 3 條有「彼此衝突」與「與描述不符」，第 4、7 條各有一個「不可驗證」。

這組答案放在 goal state，作為判定程式 scorer 的比對依據。ac_flags 要求集合完全相同，順序和重複項目不影響判定，比對前也會統一全半形與空白；但少了或多了任何一個標註都不能過。

要驗收 scorer，可以先給它一份符合全部條件的產出，要求判定通過，再從同一份產出拿掉 3:mismatch，也就是第 3 條的「與描述不符」，要求它判定失敗，而且列出少了哪個標註。

repo 的 scorer 測試 先確認完整產出會通過，再測少掉一個標註的情況。下方的 promoActual 是測試檔預先寫好的正確產出，promoGoalState 是測試用的期望值，這段只拿掉一個標註：

test('Day 3 的掉法：少掉 3:mismatch 必須紅，且 diff 指得出來', () => {
  const dropped = {
    ...promoActual,
    ac_flags: ['3:conflict', '4:unverifiable', '7:unverifiable'],
  };
  const score = scoreCase('ac-conflict-001', promoGoalState, dropped);
  assert.equal(score.pass, false);
  const flags = score.fields.find((f) => f.field === 'ac_flags')!;
  assert.deepEqual(flags.missing, ['3:mismatch']);
  assert.deepEqual(flags.unexpected, []);
});

這是刻意製作的錯誤產出，用來測 scorer 能否抓到漏標，不代表改 prompt 後實際漏掉的是這一個。正確產出也要測，否則一支永遠回傳失敗的 scorer，同樣能通過上面這條測試。

scorer 的測試不會自動保護 dataset 設定

上面的 promoGoalState 寫在測試檔裡，沒有從 dataset 載入。如果只把 dataset 的 AC 標註欄位改成「存在且非空」，scorer 的這條測試仍然會過，因為它收到的期望值沒有變。

因此 repo 另外在 dataset/case.test.ts 載入真正的 case 檔，確認 AC 標註仍使用 exact_set，期望集合也仍是那 4 個標註。放鬆 dataset 設定時，會失敗的是這條檢查。

寫測試時得確認資料從哪裡讀進來，才知道哪一種改動會被發現。scorer 的比對邏輯和 dataset 裡的通過條件，都會影響最後的分數。

判不到的 assertion，要與產品失敗分開

Trello 實驗的舊版判定程式還有三個問題，新版分別做了修正：

• 靠 assertion 的文字選檢查函式。 改掉比對用的關鍵詞，就可能找不到函式。新版改用固定的 id。
• 找不到檢查函式就記成失敗。 這只代表檢查沒執行，不能推論產出做錯或做對。新版把它列為判定程式的錯誤，與產品分數分開記錄。
• 每筆 case 的期望值寫在判定程式裡。 新版移回 case 的 metadata，修改條件時可以直接看見改了哪一筆、哪個值。

不過，改成 id 或搬動期望值，都補不了「只查標題、沒查內容」的缺口。每條檢查仍得對照規範，確認通過時究竟能證明什麼。

通過的產出也要抽查

滿分本身不代表判定程式有錯。Anthropic 談 eval 飽和時，區分了兩種用途，100% 已無法顯示新的能力進步，但仍能追蹤原本做對的任務有沒有變差（Demystifying evals for AI agents）。

同一篇也建議閱讀多次執行的紀錄與評分，確認 grader 的判定是否正確。對這份 Trello 實驗而言，抽查時就要打開卡片，逐段找未答的問題，不能只看標題檢查的 PASS。發現漏判後，把那份錯誤產出留下來，補成判定程式的測試案例。

總結

假通過是產出違反規範，檢查卻給了通過。驗收 scorer 時，要同時確認正確產出能過、已知錯誤會被擋下，並另外檢查 dataset 的通過條件，避免只測到測試檔裡的設定。

這些測試只能涵蓋已知的錯誤。規範中還有哪些要求沒被檢查到，仍要靠抽查產出找出來，再把漏判的例子加進測試。