寫了個Skill，怎麼評測它效果好不好
整理版優先睇
評測Skill效果，係將「感覺還行」變成「可復現穩定」嘅必經一步，用測試用例、斷言同對比基線嚟量化增量價值。
呢篇文章出自賈傑嘅《AI編程秘籍》付費合集，講嘅係點樣科學噉評測一個AI Skill嘅效果。作者指出，寫咗個「好似識行」嘅Skill，但佢穩定唔穩定、邊界會唔會塌、係咪比裸模型強，好容易俾錯覺呃到。佢提出評測就似俾Skill做體檢同碰撞測試，痛但真有用。
作者先釐清概念：可用性同可靠性係兩回事。可用性係「出唔出到嘢」，可靠性係「奇怪輸入嚟一輪仲識唔識穩定出嘢」。評測基本單位係測試用例，有三件套：真實用戶Prompt、清楚期望結果、可選輸入文件。佢建議最小可行方案係先寫2-3個用例，放喺Skill目錄嘅evals/evals.json，然後跑一輪睇下吐出咩。
結論係：評測唔係添麻煩，而係慳時間嘅早診斷。佢幫我哋將「感覺」變成數據，將「可能更好」變成「數據支持嘅更好」。當寫Skill變成「寫—測—改—再測」嘅細循環，輸出質量會上一個好踏實嘅台階，仲可以向老闆彙報。
- 評測核心係「增量對比」：同一個用例，帶Skill跑一次，唔帶Skill跑一次，睇下個Skill到底貢獻咗幾多。
- 好用例嘅四原則：真實（似用戶會講嘅嘢）、多樣（唔同語氣同細節）、邊界（刁鑽情況）、可驗證（期望要具體到可以核對）。
- 斷言要由「產物」倒推：先跑一輪先，睇下實際輸出，再補斷言，避免寫啲太天真或太脆弱嘅判斷。
- 打分要證據為本：每條斷言PASS/FAIL都要引用實際輸出片段，機械化嘅檢查（如檔案存在、JSON可parse）用腳本更可靠。
- 模式分析三步曲：刪兩邊都pass嘅廢斷言、優先救兩邊都fail嘅斷言、捉實「帶Skill先pass」嘅增量點嚟做厚做穩。
最小可行評測循環
1. 寫2-3個真實多樣用例（暫唔寫斷言） 2. 乾淨上下文下，帶Skill跑一次，唔帶Skill跑一次，記錄輸出、時間、Token 3. 基於產物補斷言，再跑評分，出grading.json 4. 聚合統計到benchmark.json，睇delta判斷「值唔值」 5. 按「刪易過、救常敗、放大增量」順序優化Skill 6. 每2-3輪做盲比對同人工覆盤
Evaluating skill output quality
agentskills.io 官方文檔，提供評測Skill嘅詳細指引同JSON結構範例。
點解要評測？評測係Skill嘅體檢
寫咗個「好似識行」嘅Skill，但佢穩定唔穩定、邊界會唔會塌、係咪比裸模型強，呢啲好易俾錯覺呃到。評測就似俾Skill做體檢同碰撞測試，痛但真有用。
可用性同可靠性係兩回事：可用性係「出唔出到嘢」，可靠性係「奇怪輸入嚟一輪仲識唔識穩定出嘢」。
作者一開始就點出，好多人都靠「感覺」去判斷Skill好唔好，但呢個感覺好易呃人。評測就係要將呢種感覺變成可量化嘅數據。
測試用例點寫？真實、多樣、邊界、可驗證
每條測試用例有三件套：一個真實嘅用戶Prompt，一句用人話寫清楚嘅期望結果，同可選嘅輸入檔案（例如CSV、圖片）。最小可行方案係先寫2-3個用例，放喺Skill目錄嘅evals/evals.json。
好用例嘅四原則：真實、多樣、邊界、可驗證。
- 1 真實：用戶會講嘅話，會提到檔案路徑、欄位名、場景，唔係「幫我處理呢個數據」咁籠統。
- 2 多樣：同一個目標用唔同語氣同細節表達，又有「隨便清理下」嘅口語，又有「對data/input.csv做A→B→C」嘅精準指令。
- 3 邊界：至少放一個「刁鑽」例子，例如欄位缺失、檔案半壞、需求有歧義。
- 4 可驗證：期望要寫到可以落地核對，例如「導出PNG柱狀圖，座標軸有標籤，標題提到Revenue」，唔好寫「有條理、要優雅」。
作者仲俾咗一個最小用例示範，直接抄agentskills.io嘅官方結構，將skill_name、prompt、expected_output同files寫清楚。佢強調：呢個結構唔係定義「點判分」，而係聲明「成功長咩樣」。
{
"skill_name": "csv-analyzer",
"evals": [
{
"id": 1,
"prompt": "I have a CSV of monthly sales data in data/sales_2025.csv. Can you find the top 3 months by revenue and make a bar chart?",
"expected_output": "A bar chart image showing the top 3 months by revenue, with labeled axes and values.",
"files": ["evals/files/sales_2025.csv"]
}
]
}點樣跑評測？帶Skill vs 唔帶Skill
核心玩法好樸素：每個用例跑兩遍，一次帶Skill，一次唔帶Skill（或帶舊版本）。每次運行要「乾淨啟動」，隔離任何先驗狀態，例如換會話或者用Claude Code嘅subagent。
執行時要講清楚Skill路徑、用例Prompt、輸入檔案同輸出目錄，唔帶Skill嗰次就刪走Skill path。
目錄結構建議用獨立workspace，每次完整循環一個iteration-N，每個用例一個eval目錄，分with_skill同without_skill兩邊輸出。最終會有outputs、timing.json、grading.json，最外層benchmark.json做彙總。呢個結構帶嚟嘅好處係「可復現、可對比、可回溯」。
- 每次運行後即刻記錄total_tokens同duration_ms，唔好拖到後面先翻日誌。
- 對比基線時，如果Token貴咗三倍，要衡量值唔值，結合業務場景算賬。
斷言同打分：將「感覺」變成「數據」
斷言係可驗證嘅「應該滿足嘅事實」，例如「輸出檔案係合法JSON」「圖表有座標軸標籤」。弱斷言會自欺欺人，例如「輸出係好嘅」或者「必須出現固定短語」，前者不可判，後者太脆弱。
先跑一輪睇下產物，再補斷言，因為「好」嘅樣往往要睇一次真輸出先敢落筆。
打分明確要求每條斷言PASS/FAIL並提供確鑿證據，引用輸出片段或檔案清單。能夠腳本化嘅機械檢查（如檔案存在、JSON可parse）就用腳本，比LLM判分更可靠。
{
"assertion_results": [
{ "text": "The output includes a bar chart image file", "passed": true, "evidence": "Found chart.png (45KB) in outputs directory" },
{ "text": "The chart shows exactly 3 months", "passed": true, "evidence": "Chart displays bars for March, July, and November" },
{ "text": "Both axes are labeled", "passed": false, "evidence": "Y-axis is labeled 'Revenue ($)' but X-axis has no label" },
{ "text": "The chart title or caption mentions revenue", "passed": true, "evidence": "Chart title reads 'Top 3 Months by Revenue'" }
],
"summary": { "passed": 3, "failed": 1, "total": 4, "pass_rate": 0.75 }
}所有用例評分完成後，做一份benchmark.json，統計with_skill同without_skill嘅平均通過率、時間同Token，並給出delta。呢張成本—收益對照表係判斷Skill性價比嘅關鍵。
模式分析同最小可行循環
- 1 刪喺兩邊都「總是通過」嘅斷言，佢哋只係虛高通過率，冇信息增量。
- 2 優先排查兩邊都「總是失敗」嘅斷言，可能斷言寫壞咗、題太難或者檢查點唔啱。
- 3 捉實「帶Skill先通過」嘅斷言，呢啲就係Skill真正創造價值嘅位，回溯係邊條指令或腳本起咗決定性作用，然後做厚做穩。
最後作者整合出一套最小可行循環，佢自己而家都用緊：
- 1 第一步：寫2-3個真實多樣用例，準備好檔案，暫唔寫斷言。
- 2 第二步：乾淨上下文下跑一次帶Skill，再跑一次唔帶Skill，儲存輸出、時間、Token。
- 3 第三步：基於產物補斷言，再跑評分，輸出grading.json。
- 4 第四步：聚合統計到benchmark.json，讀delta做一次「值唔值」判斷。
- 5 第五步：按「刪易過、救常敗、放大增量」順序優化Skill指令或腳本，再下一輪迭代。
- 6 第六步：每2-3輪做一次盲比對同人工覆盤，防止KPI式過斷言。
🌟星標 + 👆關注，第一時間知道最新、最有用的AI編程姿勢
《賈傑的AI編程秘籍》付費合集，共10篇，現已完結。30元交個朋友，學唔到真嘢揾我退錢；）
寫在前面
我哋寫咗個睇落「識行」嘅 Skill，但佢到底穩唔穩定、邊界會唔會塌、係咪比「乜都唔加嘅裸模型」更加勁，呢啲都好容易俾錯覺呃到。
評測（eval）就好似幫 Skill 做體檢同碰撞測試，係痛啲，但真係有用。
我哋要測啲乜，點樣測
「可用性」同「可靠性」係兩回事，可用性係做唔做到嘢，可靠性係各種奇怪輸入都仲可以穩定做到嘢。
評測嘅基本單位係測試用例，佢有三件套：一個真實啲嘅用戶 Prompt，一個用人話寫清楚嘅預期結果，同埋可選嘅輸入文件（例如 CSV、圖片之類）。
最簡單可行嘅方案係，先寫 2～3 個用例就得（唔好一嚟就重本投資），將佢哋放喺你個 Skill 目錄嘅 evals/evals.json 入面，然後跑一輪睇下會出啲乜鬼嘢。
測試用例點樣寫，唔好「自說自話」
定義先來一句：好用例=真實+多樣+帶邊界+可驗證。
真實，係用戶會講嘅嘢，會提到檔案路徑、字段名、場景背景，唔係「幫我處理呢個數據」呢啲含糊其辭。
多樣，係同一個目標用唔同語氣同細節表達，既有「隨便幫我清理下」嘅大白話，都有「對 data/input.csv 做 A→B→C」嘅精準指令。
邊界，係至少放一個「刁鑽」嘅例子，例如字段缺失、檔案格式半壞、需求本身容易有歧義。
可驗證，係預期唔好寫「要有條理、要優雅」呢啲唔落地嘅嘢，先寫成「導出 PNG 柱狀圖，座標軸有標籤，標題提到 Revenue」呢種可以落地核實嘅描述。
一個最細嘅用例示範（定義之後即刻上例子）
下面呢段就係官方推薦結構，我直接照抄改咗啲詞（引自 agentskills.io）：
{
"skill_name": "csv-analyzer",
"evals": [
{
"id": 1,
"prompt": "I have a CSV of monthly sales data in data/sales_2025.csv. Can you find the top 3 months by revenue and make a bar chart?",
"expected_output": "A bar chart image showing the top 3 months by revenue, with labeled axes and values.",
"files": ["evals/files/sales_2025.csv"]
}
]
}佢唔係定義「點樣俾分」，而係聲明「成功係點樣」，俾分我哋之後用斷言嚟做。
跑評測：有 Skill 一次，冇 Skill 再一次
核心玩法好樸素：每個用例跑兩次，一次帶 Skill，一次唔帶 Skill（或者帶舊版本 Skill），咁就有「增量」嘅可比性。
每次執行都要「乾淨啟動」，盡量隔離所有先驗狀態（換會話，或者用支援子代理嘅環境，例如 Claude Code 嘅 subagent，每個子任務都係全新上下文）。
執行嘅時候將 Skill 路徑、用例 Prompt、輸入檔案同輸出目錄都講清楚，好似咁樣（引自 agentskills.io）：
- Skill path: /path/to/csv-analyzer
- Task: I have a CSV of monthly sales data in data/sales_2025.csv. Can you find the top 3 months by revenue and make a bar chart?
- Input files: evals/files/sales_2025.csv
- Save outputs to: csv-analyzer-workspace/iteration-1/eval-top-months-chart/with_skill/outputs/基線嗰次就將 Skill path 拎走，輸出改到 without_skill/outputs/ 就得，做舊版對比嘅話用快照做基線存到 old_skill/outputs/。
目錄點樣擺，唔好將啲嘢塞埋一齊
建議將評測結果放喺一個獨立 workspace 裏面，每次完整循環一個 iteration-N，然後每個用例一個 eval 目錄，再分 with_skill 同 without_skill 兩邊輸出，跑完之後會有 outputs、timing.json、grading.json，最外面有個 benchmark.json 匯總統計（結構見原文示意）。
呢套結構帶嚟嘅爽快感係可復現、可對比、可回溯（唔係「咦我上次改咗啲乜嚟着」）。
計時同計數：時間同 Token 都係錢
一次執行完就將 total_tokens 同 duration_ms 記低，唔好拖到後面先翻日誌（好多環境唔會幫你存檔）。
示例係咁樣（引自 agentskills.io）：
{ "total_tokens": 84852, "duration_ms": 23332 }結論好現實：更好嘅輸出如果貴三倍 Token，佢值唔值得，要結合業務場景計數。
斷言：令「好唔好」變成「啱唔啱」
斷言係可驗證嘅「應該滿足嘅事實」，例如「輸出檔案係合法 JSON」「圖表有座標軸標籤」「報告至少包含 3 條建議」。
弱斷言會令你自欺欺人，例如「輸出係好嘅」，或者「必須出現固定短語」，前者唔可以判斷，後者太脆弱。
將斷言補返落 evals.json，好似咁樣（引自 agentskills.io）：
{
"assertions": [
"The output includes a bar chart image file",
"The chart shows exactly 3 months",
"Both axes are labeled",
"The chart title or caption mentions revenue"
]
}留意順序係先跑一輪睇下產物，再補斷言，因為「好」嘅樣往往要睇一次真實輸出先敢落筆。
俾分：要證據，唔好「主觀感覺良好」
對每條斷言做 PASS/FAIL，並俾出確鑿證據，最好引用輸出裏面嘅具體片段或檔案清單。
可以寫腳本核驗嘅盡量腳本化（例如檔案係咪存在、維度係咪正確、JSON 係咪可以 parse），腳本比 LLM 俾分喺呢啲機械問題上更加可靠，亦更加可複用。
評分記錄可以係咁樣（引自 agentskills.io）：
{
"assertion_results": [
{ "text": "The output includes a bar chart image file", "passed": true, "evidence": "Found chart.png (45KB) in outputs directory" },
{ "text": "The chart shows exactly 3 months", "passed": true, "evidence": "Chart displays bars for March, July, and November" },
{ "text": "Both axes are labeled", "passed": false, "evidence": "Y-axis is labeled 'Revenue ($)' but X-axis has no label" },
{ "text": "The chart title or caption mentions revenue", "passed": true, "evidence": "Chart title reads 'Top 3 Months by Revenue'" }
],
"summary": { "passed": 3, "failed": 1, "total": 4, "pass_rate": 0.75 }
}俾分嘅原則係「嚴格但公平」，有標籤但冇內容算失敗，該挑剔就挑剔。
聚合：將分數變成決策
所有用例評分完成之後，做一份 benchmark.json，統計 with_skill 同 without_skill 嘅平均通過率、時間同 Token，並俾出 delta。
示意數據係咁樣（引自 agentskills.io）：
{
"run_summary": {
"with_skill": { "pass_rate": { "mean": 0.83, "stddev": 0.06 }, "time_seconds": { "mean": 45.0, "stddev": 12.0 }, "tokens": { "mean": 3800, "stddev": 400 } },
"without_skill": { "pass_rate": { "mean": 0.33, "stddev": 0.10 }, "time_seconds": { "mean": 32.0, "stddev": 8.0 }, "tokens": { "mean": 2100, "stddev": 300 } },
"delta": { "pass_rate": 0.50, "time_seconds": 13.0, "tokens": 1700 }
}
}呢張「成本—收益」對照表好關鍵，佢話俾我哋知呢項 Skill 嘅性價比到底點樣。
模式分析：刪「假功勞」，修「真頑疾」，放大「亮點」
有三件事我覺得特別有用。
第一，刪除喺兩邊都「總是通過」嘅斷言，佢哋只係幫你虛高通過率，但冇信息增量。
第二，優先排查兩邊都「總是失敗」嘅斷言，要唔係斷言寫錯，要唔係題太難，要唔係檢查嘅點唔啱路，盡快修正。
第三，揾出「帶 Skill 先通過」嘅斷言，呢度就係 Skill 真正創造價值嘅地方，回溯一下係邊條指令或邊個腳本起到決定性作用，然後將佢做厚做穩。
如果有某個用例波動好大（stddev 高），通常係指令有歧義或者任務太依賴隨機性，俾更多示例、約束格式、減少自由度，可以明顯降低抖動。
仲有個好招叫「盲比對」，將兩個版本嘅輸出喺唔標註來源嘅情況下交俾 LLM 做整體評分（組織、可用性、排版、打磨度），佢同斷言互補，可以捉到嗰啲「過咗斷言但整體質感差距明顯」嘅情況。
人類覆盤：機器俾分之外嘅「味道」
有啲嘢機器好難判斷，例如寫作風格、可讀性、視覺層次、係咪「似人寫俾人睇嘅」，呢啲最好做一輪人手檢查。
我嘅實踐入面會將「斷言評分」同「人工短評」並排擺喺同一條用例下面，下一輪改進就有明確抓手。
一套最小可行循環，我而家就會用佢
第一步，寫 2～3 個真實且多樣嘅用例，準備好必要檔案，先唔寫斷言。
第二步，乾淨上下文下跑一次帶 Skill，再跑一次唔帶 Skill，儲存輸出、時間、Token。
第三步，基於產物補上斷言，再跑一次評分，輸出 grading.json。
第四步，聚合統計到 benchmark.json，睇 delta 做一次「值唔值」嘅判斷。
第五步，按「刪易過、救常敗、放大增量」嘅順序優化 Skill 指令或腳本，再來下一輪迭代。
第六步，每 2～3 輪做一次盲比對同人工覆盤，防止「KPI 式過斷言」。
總結
評測唔係添麻煩，而係慳時間嘅「早診斷」，佢幫我哋將「感覺還可以」變成「可復現嘅穩」，將「可能更好」變成「數據支持嘅更好」。
當我哋將「寫 Skill」變成「寫—測—改—再測」嘅細循環，輸出質量會上一個非常紮實嘅台階（而且可以同老細匯報，嘿嘿）。
參考資料
Evaluating skill output quality（摘自 agentskills.io）： https://agentskills.io/skill-creation/evaluating-skills
Documentation Index（摘自 agentskills.io）： https://agentskills.io/llms.txt
堅持創作唔容易，求個一鍵三連，多謝你～❤️
以及「AI Coding技術交流羣」，聯絡 ayqywx 我拉你入羣，一齊交流學習～
訂閲連結 https://note.mowen.cn/detail/OLPEp7HzeB0EXJOLe7mM4
🌟星標 + 👆關注，第一時間知道最新、最有用的AI編程姿勢
《賈傑的AI編程秘籍》付費合集，共10篇，現已完結。30元交個朋友，學不到真東西找我退錢；）
寫在前面
我們寫了個看起來“能跑”的 Skill，但它到底穩不穩定、邊界會不會塌、是不是比“什麼都不加的裸模型”更強，這些都很容易被錯覺迷惑。
評測（eval）這事就像給 Skill 做體檢和碰撞測試，痛一點，但真有用。
我們要測什麼，怎麼測
“可用性”和“可靠性”是兩件事，可用性是能不能出活，可靠性是各種奇怪輸入來一遍還能不能穩定出活。
評測的基本單位是測試用例，它有三件套：一個真實點的用戶 Prompt，一個用人話寫清楚的期望結果，還有可選的輸入文件（比如 CSV、圖片之類）。
最小可行方案很簡單，先寫 2～3 個用例就好（別一上來重金投入），把它們放進你的 Skill 目錄的 evals/evals.json 裏，然後先跑一輪看看會吐出什麼鬼。
測試用例怎麼寫，別“自說自話”
定義先來一句：好用例=真實+多樣+帶邊界+可驗證。
真實，是用戶會說的話，會提到文件路徑、字段名、場景背景，不是“幫我處理這個數據”這種含糊其辭。
多樣，是同一個目標用不同語氣和細節表達，既有“隨便幫我清理下”的大白話，也有“對 data/input.csv 做 A→B→C”的精準指令。
邊界，是至少放一個“刁鑽”的例子，比如字段缺失、文件格式半壞、需求本身容易歧義。
可驗證，是期望別寫“要有條理、要優雅”這種不可落地的東西，先寫成“導出 PNG 柱狀圖，座標軸有標籤，標題提到 Revenue”這種能落地核驗的描述。
一個最小用例示範（定義之後立刻上例子）
下面這段就是官方推薦結構，我直接照抄改了些詞（引自 agentskills.io）：
{
"skill_name": "csv-analyzer",
"evals": [
{
"id": 1,
"prompt": "I have a CSV of monthly sales data in data/sales_2025.csv. Can you find the top 3 months by revenue and make a bar chart?",
"expected_output": "A bar chart image showing the top 3 months by revenue, with labeled axes and values.",
"files": ["evals/files/sales_2025.csv"]
}
]
}它不是在定義“怎麼判分”，而是在聲明“成功長啥樣”，判分我們之後用斷言來做。
跑評測：有 Skill 一次，沒 Skill 再一次
核心玩法很樸素：每個用例跑兩遍，一遍帶 Skill，一遍不帶 Skill（或者帶舊版本 Skill），這樣就有了“增量”的可比性。
每次運行都要“乾淨啓動”，儘量隔離任何先驗狀態（換會話，或者用支持子代理的環境，比如 Claude Code 的 subagent，每個子任務都是全新上下文）。
執行時把 Skill 路徑、用例 Prompt、輸入文件和輸出目錄都說清楚，像這樣（引自 agentskills.io）：
- Skill path: /path/to/csv-analyzer
- Task: I have a CSV of monthly sales data in data/sales_2025.csv. Can you find the top 3 months by revenue and make a bar chart?
- Input files: evals/files/sales_2025.csv
- Save outputs to: csv-analyzer-workspace/iteration-1/eval-top-months-chart/with_skill/outputs/基線那次就把 Skill path 去掉，輸出改到 without_skill/outputs/ 即可，做舊版對比的話用快照當基線存到 old_skill/outputs/。
目錄怎麼擺，別把東西塞一團
建議把評測結果放在一個獨立 workspace 裏，每次完整循環一個 iteration-N，然後每個用例一個 eval 目錄，再分 with_skill 和 without_skill 兩邊輸出，跑完會有 outputs、timing.json、grading.json，最外層有個 benchmark.json 彙總統計（結構見原文示意）。
這套結構帶來的爽感是可復現、可對比、可回溯（而不是“咦我上次改了啥來着”）。
計時與算賬：時間和 Token 都是錢
一次運行結束就把 total_tokens 和 duration_ms 記下來，別拖到後面再翻日誌（很多環境不會幫你存檔）。
示例長這樣（引自 agentskills.io）：
{ "total_tokens": 84852, "duration_ms": 23332 }結論很現實：更好的輸出如果貴了三倍 Token，它是不是值得，要結合業務場景算賬。
斷言：讓“好不好”變成“對不對”
斷言是可驗證的“應該滿足的事實”，比如“輸出文件是合法 JSON”“圖表有座標軸標籤”“報告至少包含 3 條建議”。
弱斷言會讓你自欺欺人，比如“輸出是好的”，或者“必須出現固定短語”，前者不可判，後者太脆弱。
把斷言補回 evals.json，像這樣（引自 agentskills.io）：
{
"assertions": [
"The output includes a bar chart image file",
"The chart shows exactly 3 months",
"Both axes are labeled",
"The chart title or caption mentions revenue"
]
}注意順序是先跑一輪看看產物，再補斷言，因為“好”的樣子往往得看一次真輸出才敢落筆。
打分：要證據，不要“主觀感覺良好”
對每條斷言做 PASS/FAIL，並給出確鑿證據，最好引用輸出裏的具體片段或文件清單。
能寫腳本核驗的儘量腳本化（比如文件是否存在、維度是否正確、JSON 是否可 parse），腳本比 LLM 判分在這些機械問題上更靠譜，也更可複用。
評分記錄可以是這樣（引自 agentskills.io）：
{
"assertion_results": [
{ "text": "The output includes a bar chart image file", "passed": true, "evidence": "Found chart.png (45KB) in outputs directory" },
{ "text": "The chart shows exactly 3 months", "passed": true, "evidence": "Chart displays bars for March, July, and November" },
{ "text": "Both axes are labeled", "passed": false, "evidence": "Y-axis is labeled 'Revenue ($)' but X-axis has no label" },
{ "text": "The chart title or caption mentions revenue", "passed": true, "evidence": "Chart title reads 'Top 3 Months by Revenue'" }
],
"summary": { "passed": 3, "failed": 1, "total": 4, "pass_rate": 0.75 }
}打分的原則很“嚴格但公平”，有標籤但沒內容算失敗，該挑剔就挑剔。
聚合：把分數變成決策
所有用例評分完成後，做一份 benchmark.json，統計 with_skill 和 without_skill 的平均通過率、時間和 Token，並給出 delta。
示意數據長這樣（引自 agentskills.io）：
{
"run_summary": {
"with_skill": { "pass_rate": { "mean": 0.83, "stddev": 0.06 }, "time_seconds": { "mean": 45.0, "stddev": 12.0 }, "tokens": { "mean": 3800, "stddev": 400 } },
"without_skill": { "pass_rate": { "mean": 0.33, "stddev": 0.10 }, "time_seconds": { "mean": 32.0, "stddev": 8.0 }, "tokens": { "mean": 2100, "stddev": 300 } },
"delta": { "pass_rate": 0.50, "time_seconds": 13.0, "tokens": 1700 }
}
}這張“成本—收益”對照表很關鍵，它告訴我們這項 Skill 的性價比到底咋樣。
模式分析：刪“假功勞”，修“真頑疾”，放大“亮點”
有三件事我覺得特別有用。
第一，刪掉在兩邊都“總是通過”的斷言，它們只是幫你虛高了通過率，卻沒有信息增量。
第二，優先排查兩邊都“總是失敗”的斷言，要麼斷言寫壞了，要麼題太難，要麼檢查的點不對路，儘快修正。
第三，找出“帶 Skill 才通過”的斷言，這裏就是 Skill 真正創造價值的地方，回溯一下是哪條指令或哪個腳本起了決定性作用，然後把它做厚做穩。
如果某個用例波動很大（stddev 高），往往是指令有歧義或任務太依賴隨機性，給更多示例、約束格式、減少自由度，能明顯降低抖動。
還有個好招叫“盲比對”，把兩個版本的輸出在不標註來源的情況下交給 LLM 做整體評分（組織、可用性、排版、打磨度），它和斷言互補，能抓到那些“過了斷言但整體質感差距明顯”的情況。
人類覆盤：機器判分之外的“味道”
有些東西機器很難判，比如寫作風格、可讀性、視覺層次、是否“像人寫給人看的”，這些最好來一輪人工走查。
我的實踐裏會把“斷言評分”和“人工短評”並排放在同一條用例下，下一輪改進就有明確抓手。
一套最小可行循環，我現在就會用它
第一步，寫 2～3 個真實且多樣的用例，準備好必要文件，先不寫斷言。
第二步，乾淨上下文下跑一遍帶 Skill，再跑一遍不帶 Skill，存儲輸出、時間、Token。
第三步，基於產物補上斷言，再跑一次評分，輸出 grading.json。
第四步，聚合統計到 benchmark.json，讀 delta 做一次“值不值”的判斷。
第五步，按“刪易過、救常敗、放大增量”的順序優化 Skill 指令或腳本，再來下一輪迭代。
第六步，每 2～3 輪做一次盲比對和人工覆盤，防止“KPI 式過斷言”。
總結
評測不是添麻煩，而是省時間的“早診斷”，它幫我們把“感覺還行”變成“可復現的穩”，把“可能更好”變成“數據支持的更好”。
當我們把“寫 Skill”變成“寫—測—改—再測”的小循環，輸出質量會上一個非常踏實的台階（而且可向老闆彙報，嘿嘿）。
參考資料
Evaluating skill output quality（摘自 agentskills.io）： https://agentskills.io/skill-creation/evaluating-skills
Documentation Index（摘自 agentskills.io）： https://agentskills.io/llms.txt
堅持創作不易，求個一鍵三連，謝謝你～❤️
以及「AI Coding技術交流羣」，聯繫 ayqywx 我拉你進羣，共同交流學習～
訂閲連結 https://note.mowen.cn/detail/OLPEp7HzeB0EXJOLe7mM4