judge

judge skill 概觀

judge 是做什麼的

judge skill 會啟動一個雙階段評估流程：先由 meta-judge 為任務定義合適的評分規準，再由 judge 子代理在隔離的上下文與證據下對作品打分。它特別適合需要有紀律地審查程式碼、分析、寫作或 agent 輸出的人，而不是只想要一個隨性的意見。

誰適合使用 judge

當你需要的是只輸出報告、標準清楚、帶有引用與可執行回饋的評估時，就適合用 judge skill。它很適合用在 Skill Authoring 審查、repo 變更審查，以及任何可能受到確認偏誤或對話延續效應干擾判斷的情境。

judge 有什麼不同

和那種只是泛泛要求「給我回饋」的提示詞不同，judge 會先建立評估標準，再開始打分。這讓 judge skill 在「產出類型還不確定」、「需要多維度評分」或「審查結果必須能對另一位人類交代」時更有優勢。

如何使用 judge skill

安裝 judge 並檢查入口檔

使用 npx skills add NeoLabHQ/context-engineering-kit --skill judge 安裝。先從 plugins/sadd/skills/judge/SKILL.md 看起，因為那裡包含定義 judge 安裝行為的工作流程、輸入內容與評估限制。

為 judge 提供明確的評估目標

這個 skill 最好在你清楚指定工作內容與評估角度時使用。好的提示會像這樣：Judge the last draft of the launch page for clarity, SEO fit, and factual accuracy.；像 Review this 這種模糊提示，會讓 meta-judge 需要自己猜太多。

為 judge pipeline 提供正確脈絡

請包含要評估的產物、成功標準，以及任何硬性限制，例如語氣、受眾、評分規準優先順序或禁止修改的內容。如果你是拿 judge 來做 Skill Authoring，請明講並指出目標 skill，因為評分規準應該會因安裝清晰度、可發現性與教學品質而改變。

先讀這些檔案

若是要安裝或改寫，先讀 SKILL.md，再讀 repo 內其他工作流程或政策檔。在這個 repo 裡，skill 本體就是主要依據，所以最快的做法，是先看提示詞結構、工作流程階段與證據要求，再把模式複製到你自己的系統。

judge skill 常見問題

judge 只適合做程式碼審查嗎？

不是。judge skill 的用途是評估任何能用規準來檢視的產出：提示詞、文件、分析、agent 輸出，或設計決策都可以。重點是結果必須能依明確標準與證據來判定。

什麼時候不該用 judge？

如果你只需要快速的主觀反應、如果產物還沒完成，或如果任務無法依證據評估，就不該用 judge。這些情況下，較簡單的提示詞通常更快，也比較不脆弱。

judge 適合新手嗎？

可以，只要使用者能說清楚產物是什麼、成功標準是什麼。新手通常會卡在沒有脈絡就要求判斷。這個 skill 透過強制先做 meta-judge 步驟來降低這類問題，但它仍然需要明確目標。

judge 跟一般提示詞有什麼不同？

一般提示詞常常是讓同一個模型在一次流程裡同時發明規準、又對結果打分。judge skill 會把這兩個角色拆開，通常能提升一致性、降低偏差，也讓最後報告更容易被信任。

如何改進 judge skill

把評估目標講清楚

judge 最好的輸入會明確寫出產物是什麼、目標受眾是誰，以及你想支援哪個決策。例如：Evaluate the new onboarding doc for first-time contributors, with emphasis on setup clarity and missing prerequisites. 這比 Check my doc 更好，因為評分規準可以對準真實的使用者風險。

加入會影響評分規準的限制

如果你在意逐行證據、引用需求，或特定的分數尺度，請一開始就說明。當 judge 知道要優先看正確性、完整性、UX 清晰度或政策合規時，表現會更好，而不是把它們在背後自動平均。

第一次報告之後再迭代

先用第一份 judge 報告來收斂下一輪提示詞：補上缺少的脈絡、釐清取捨，並指出哪個區段覺得分數給得太低。對 Skill Authoring 來說，最有用的迭代通常是把安裝清晰度、實際使用情境與邊界案例分開請 judge 重新評估。

留意常見失敗模式

當原始內容本身很模糊、產物還不完整，或評估焦點塞了太多目標時，judge 的表現可能會變差。如果發生這種情況，就把任務拆成更窄的幾輪，只把目前決策真正需要的材料餵給 judge。