要用模型判斷 Goal 的內容，先提供原始需求與一條具體標準，讓它回傳判定及依據；欄位非空的通過結果，不能代替這項檢查。

需求釐清 agent 會把雜亂的 ticket 整理成目標與範圍，其中 Goal 用一句話說明要做什麼。即使已確認 agent 不會自行覆寫需求方的驗收條件 AC，整理出的這句話是否符合需求，仍要另外檢查。

優惠碼功能的 ticket 在 Day 14 用相同模型、prompt 與輸入執行三次，最終卡片裡的 Goal 分別是：

1. 新增可由後台設定的優惠碼功能，供使用者在結帳時使用並影響金額
2. 提供可在結帳時套用的優惠碼功能，並支援後台設定折扣與到期控管。
3. 提供可由後台設定、可在結帳時套用的優惠碼功能，並支援手機版使用。

三份評分紀錄的 goal 都是 pass: true，但三句內容並不相同。第二句提到到期控管，第三句提到手機版，這些差異還不足以決定哪句比較好，得先說清楚 Goal 必須保留哪些內容。

而且第三次的到期規則仍在 Scope in，也就是要做的範圍裡。Goal 沒寫到，不等於整張卡漏掉；判斷前要先確定評的是摘要，還是完整的整理結果。

通過的條件只有非空

這個版本的 16 筆 case，都把驗收依據寫在 goal state 裡。goal 雖然設成 must_include，但關鍵詞清單 keywords 是空陣列，判定程式 scorer 因此會走進這段非空檢查：

if (spec.mode === 'must_include') {
  const got = actual.map(normalize).filter((v) => v.length > 0);
  if (spec.keywords.length === 0) {
    return { field, mode: 'must_include', pass: got.length > 0, missing: [], unexpected: [] };
  }

這段節錄先把文字正規化、排除空字串，再檢查是否還有內容。假設把 Goal 換成與優惠碼無關的一句話，這條檢查仍會通過。

另外預留的 goal_wording 設成 ignore，回傳 pass: null，代表不評分。因此這三次只通過 Goal 的非空檢查，內容品質還未評估，整筆 case 也都沒有通過。

要補上內容檢查，可以考慮再呼叫模型擔任 judge。Goal 已有欄位可以讀取，真正需要補的是語意判斷的條件，不能把目前 scorer 沒做的檢查，說成所有程式都做不到。

一次判定一條要求

直接問 judge「Goal 寫得好不好」，它可能自行偏好比較短的句子，也可能認為細節越多越好。先把問題縮小，這次要檢查的是 Goal 有沒有擅自新增需求。

judge 的輸入要包含原始 ticket 的 description、全部 AC，以及從最終卡片讀回的 Goal。一次呼叫只放一條判斷標準，這份設計要這樣使用：

例如第二次 Goal 的到期控管，可以對照第 6 條 AC：

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

只提供 description，卻沒提供 AC，judge 就可能把原本有依據的功能當成自行添加。要求回傳兩邊的文字，才能在複查時看出它有沒有漏讀資料，或引用不相干的段落。

這條標準檢查新增需求；要檢查遺漏，則得另外列出 Goal 必須保留的內容。原文有衝突時如何處理，也需要另外定義，不能期待一條檢查同時回答所有品質問題。

若改成檢查手機版的需求有沒有保留，就要先決定一定得出現在 Goal，還是 Scope in 有寫也接受。前者只看 Goal，後者要連同 Scope in 一起提供給 judge，受評資料必須配合判斷範圍。

RuVerBench 採用的也是逐條驗證形式，讓 judge 根據任務資料與一條 rubric 判定是否滿足，再與人工標籤對照。研究也排除了缺少判斷資料、混合多項獨立條件等 rubric（論文 §3.2、§4.1）。這裡借用的是問題的拆法，沒有據此假定這隻 judge 已經可靠。

固定產出，才看得出 judge 是否改判

前面三次執行改變的是 agent 產出，要觀察 judge 的一致性，則要固定同一份 Goal、原始需求與判斷標準，重複請它判定。如果連 Goal 都重新產生，就無法分辨差異來自哪一邊。

Anthropic 將 model-based grader 的非決定性與人工校準列為使用時要處理的限制（grader 分類）。因此設計上要保留每次判定、引用片段、模型與規則版本，不能只存最後一次結果。

回傳的憑證方便人核對，卻不保證判定正確。judge 可能引用了相關文字，仍誤解其中的限制；重複得到相同答案，也可能只是反覆犯同一個錯。

接入報表時，要逐條列出 judge 的判定，與 scorer 的欄位檢查並列。原本能直接比對的 AC 問題標註集合仍由程式處理；呼叫失敗或回覆無法解析，要記成評估未完成，不能當成 agent 已通過或失敗。

總結

Goal 非空只證明卡片寫了內容，要檢查內容是否有原始需求支持，可以設計 model-based judge，每次給一條明確標準、完整依據與待評文字，並保存可供核對的判定。

這份設計還需要用人工判定確認準確度。固定產出後重複判定能觀察一致性，但多次答案相同，仍不足以證明這項檢查值得信任。