如何設計 skill-creator eval 的測試案例
前言
最近在公司分享 skill-creator 驗證功能的重要性時，發現大家可以理解「為什麼需要驗證」，但對於「怎麼設計測試案例」其實很陌生。
當我進一步思考要怎麼解釋時，才發現這件事的難點在於：我們能不能清楚定義，怎樣才算做對？
TL;DR
我後來讀到 Lessons from Building Claude Code: How We Use Skills 這篇貼文，裡面提到 9 種常見的 skill 類型。
我把它們重新整理成 4 種測試設計原型：
- Golden Reference 已知答案比對型：已經知道正確答案，用來驗證 agent 是否答對。
- Rubric + Scenario 主觀品質型：沒有唯一答案，但有明確的品質條件。
- State Transition 前後狀態驗證型：看執行前後狀態是否符合預期。
- Adversarial / Counter-Example 找錯型：測 skill 是否找得到問題，也不會亂誤報。
重點不是把測試寫得很工程化，而是先把「什麼叫好、什麼叫對、什麼叫不該發生」講清楚。
為什麼要有測試
在開始介紹這 4 種測試案例之前，我想先釐清「為什麼要有測試？」
寫程式本身其實是在做一種「知識轉譯」。我們把自己對問題的理解，轉換成機器可以執行的指令。
但這個轉譯過程一定會有落差：
- 我們對問題的理解可能有盲點
- 程式碼可能和開發者的意圖不一致
- 邊界條件可能超出原本想像
- 看似合理的輸出，不一定真的正確
所以我很喜歡這個說法：測試的本質，是在對抗不確定性。
它是用另一套語言，去描述自己對「正確」的理解，然後讓這兩套描述互相驗證。
而放到現在的 AI Coding 驗證 skills 的情境下，同樣存在著一層落差，甚至因為 LLM 的隨機性，導致這層落差被放大得更誇張，所以我們不只要驗證「它有沒有產出」，更要驗證：它是否能在不同情境下，穩定產出符合期待的結果。
4 種「測試設計原型」
原型 A：Golden Reference 已知答案比對型
核心：我已經知道「正確答案」長什麼樣，在不讓 agent 看到答案的情況下，問同樣的問題看它回答得對不對。
對應分類：Library & API Reference、Data Fetching & Analysis、Runbooks（部分）。
- Library & API Reference：餵已知會踩雷的場景，看產出有沒有避開 gotcha
- Data Fetching & Analysis：用「上季營收是多少」這種已知正確值的 KPI 當測試
- Runbooks：用過去已解決的事故當輸入，事後分析報告當答案
友善起手：「列出 5 個你已經知道答案的問題」比「列出 5 個我想問的問題」有用得多。
我自己的工作中比較常遇到資料分析的場景，在建立測試流程時，拿過去的資料作為測試資料，比起直接用模型生成的假測試資料，更能夠模擬實際的分析流程。我的經驗是在設計測試的階段，需要很明確地跟 AI 說明測試資料要用過去真實的資料，以及如何拿到這些資料。
原型 B：Rubric + Scenario 主觀品質型
對應分類：Business Process & Team Automation、Code Scaffolding（部分）。
核心：沒有單一正確答案，但有「必須符合的條件清單」。
- Rubric：可逐項回答 Yes/No 的清單（「有沒有風險章節？」「每個 blocker 有沒有 owner？」）
- Scenario：典型 / 邊界 / 異常各 1～3 個（正常週、放假週、有事故的週）
- 最常見設計失誤：Rubric 寫成形容詞，LLM 評不出來，跑 100 次給 100 種分數。
友善起手：「先各拿 1 個你覺得讚 / 不行的範例，逐項講出差異」，差異即 Rubric。如果這一步偷懶，後面 eval 都是噪音。
我認為這是最難設計的一類，因為它逼我們回答一個很根本的問題：什麼才算是好的內容產物？
也因此，領域專家在這裡非常有價值。因為他們不只是「感覺這個比較好」，而是能具體說出好在哪裡、差在哪裡，並把這些差異轉換成可驗證的標準。
原型 C：State Transition 前後狀態驗證型
對應分類：Product Verification、CI/CD & Deployment、Infrastructure Operations、Business Process（執行層）。
核心：看 agent 執行完之後，系統是否處於預期狀態。
- 前置狀態 → 觸發 → 後置狀態三段式
- 必須在隔離環境跑（test repo、staging、dry-run mode）
- 最常見設計失誤：漏了「不該動的東西沒被動」這類精準度測試，特別是 Infrastructure Operations，模型可能順手刪掉它不該刪的。
原型 D：Adversarial / Counter-Example 找錯型
對應分類：Code Quality & Review、Runbooks（部分）。
核心：Skill 的工作是「找出問題」，所以測試要同時測「找得到」和「不會誤報」。
- Precision 測試：餵乾淨的東西，看它有沒有亂找碴
- Recall 測試：餵已知有問題的東西，看抓到沒
- Trap 測試：餵看起來像問題但其實不是（false positive 誘餌）
- 最常見設計失誤：只測 recall，導致 skill 變得超級多疑、什麼都標紅，最後沒人想用。
結尾
透過這 4 種原型，我們可以把具體測試案例整合進 skill-creator 的驗證流程。
我也整理了這 4 種可以直接拿去用的測試案例 prompt，讓你可以請 agent 依照自己的使用場景，產生對應 skill 的 eval / test cases。
不過我會強烈建議：不要只是把 prompt 丟給 AI 就結束。更好的做法是，用討論的方式跟 AI 一起設計測試案例。
因為真正有價值的，不只是產出 eval，而是透過釐清「什麼叫好、什麼叫對、什麼叫不該發生」的過程，來提升自己在專業領域的敏銳度。