既然系統都幫我跑了測試、算了通過率，是不是看 benchmark.json 的數字就夠了，不需要再自己看輸出內容？
不夠。這正是這套系統設計時特別提醒的地方——analyst pass 存在的理由，就是因為通過率數字本身可能是假象：如果某個斷言不管有沒有用 Skill 都通過，這個「100% 通過」看起來很漂亮，但完全不能證明 Skill 有發揮作用，因為它對「有沒有 Skill」這個差異沒有辨別力。
真正該養成的習慣是，看 benchmark 數字之前，先看 analyst pass 有沒有標記出「不會辨別」的斷言跟「變異過大」的測試——如果有，那些測試案例對應的通過率數字應該直接打折扣看待，甚至整個案例都該重新設計。數字永遠要搭配這層分析一起讀，單獨看通過率百分之多少，很容易被一個設計不良的斷言誤導。
description 優化那個流程，用 60/40 的訓練/測試分割，跟簡單地多跑幾次取平均有什麼不同？
差別在於要防範的問題不一樣。單純多跑幾次取平均，解決的是「單次結果不穩定」的問題；但 description 優化面臨的是另一種風險——過度配適（overfitting）：如果你拿同一批查詢既用來改進描述、又用來評分這個描述好不好，很容易改出一個「剛好能通過這批查詢」但換一批新查詢就不準的描述，因為優化過程會不自覺地針對這批特定查詢的用詞去調整。
60% 訓練、40% 保留測試的分割，解決的正是這個問題：改進描述的過程只能看訓練集，最終選哪個版本的描述當作 best_description，依據的是它在「沒看過」的測試集上的分數，而不是訓練集分數。文件裡講得很直接，這麼做是為了「避免過度配適」——如果你只看訓練分數去挑最終版本，很可能選出一個只是「背熟了這批題目」、換一批新使用者的實際用詞就打回原形的描述。
官方文件說「簡單的查詢，像『讀取檔案 X』，即使描述完全匹配，也不會可靠地觸發 Skill」，這代表什麼？
這代表 trigger 這個機制本身有個隱藏的門檻——不是「描述寫得夠精準」就保證會觸發，還要看這個請求本身是不是「複雜到值得去諮詢一個 Skill」。如果一個請求單純到幾句話就能處理完，Claude 的判斷機制可能直接選擇不觸發任何 Skill，即使那個 Skill 的 description 跟這個請求的關鍵字對得完全準確。
這對設計評測用的查詢有直接影響：如果你拿「讀取檔案 X」這種過於簡單的查詢去測試一個 Skill 該不該觸發，得到的結果可能本來就不可靠，不是因為 description 寫得不好，而是這個查詢本身不夠有「值得觸發 Skill」的份量。官方文件也直接點出這個因果關係：「設計不良的評測查詢，會導出設計不良的 description」——如果你一開始餵進去的測試案例本身就選錯了難度，不管後面的優化流程跑幾輪，產出的描述也不會真正可靠。
我在 Claude.ai 裡用 skill-creator，為什麼有些評測功能完全跑不起來？
因為 Claude.ai 環境本身就不具備某些功能所需要的能力，官方文件明確列出了對應限制：Claude.ai 沒有 subagent，所以測試案例只能序列執行（嚴謹度低於平行執行），也沒有辦法做基準比較（baseline run），量化 benchmark 跟盲測比較都需要獨立 baseline 才有意義，所以這兩項直接被跳過；description 優化需要用到 claude -p 這個指令列介面，只有 Claude Code 才有，Claude.ai 一樣跳過。
換句話說，在 Claude.ai 裡，你能用到的其實是精簡版——跑測試案例、產出質性回饋，直接在對話裡呈現結果，而不是透過瀏覽器檢視器。如果你需要完整的量化 benchmark、A/B 盲測或 description 自動優化，這些功能明確要求 Claude Code 環境跟 subagent 能力，不是 skill-creator 哪裡設定錯了，是環境本身的能力邊界。
在 skill-creator 加入評測功能之前，判斷一個 Skill 到底有沒有讓 Claude 表現更好，基本上只能靠試用跟直覺。官方的 skill-creator SKILL.md 現在內建了一整套評測流程——跑測試案例、產出量化指標、做盲測 A/B 比較、甚至自動優化 Skill 的 description 欄位。這篇文章把這套系統實際拆開來看，它真正能告訴你什麼，又在哪些地方需要你自己補足判斷。
核心邏輯並不複雜：針對同一個任務提示，同時啟動兩個 subagent，一個帶著你的 Skill 執行，一個完全不用（或者如果是改進既有 Skill，則是跑舊版本），兩邊的輸出都存到各自獨立的資料夾。接著官方文件要求「在跑的過程中就先把斷言（assertion）寫好」——針對每個測試案例，先定義好可以被客觀驗證的檢查項目，而不是等結果出來才回頭想該怎麼評分。
這裡有個官方文件特別強調的分界線：斷言必須是「可被客觀驗證」的東西，像寫作風格、設計美感這類主觀輸出，建議改用質性回饋去評估，不要硬套量化斷言——勉強量化一個本質上主觀的產出，得到的分數反而會造成誤導。
跑完測試後，scripts.aggregate_benchmark 會把結果整理成 benchmark.json 跟 benchmark.md，列出每個版本的通過率、耗時、token 用量，含平均值、標準差跟差異量。真正有意思的是接下來的 analyst pass——官方文件要求做一次分析，去找出「總是通過、不管有沒有 Skill 都一樣」的斷言（代表這個斷言沒有辨別力，看不出 Skill 到底有沒有造成差異），以及「變異量異常大」的測試案例（代表這個測試可能本身就不穩定，結果不可靠）。這一步算是整套系統裡最誠實的部分：它主動幫你把「這個指標其實沒告訴你任何事」的情況標記出來，而不是讓一堆漂亮的通過率數字誤導你。
如果想更嚴謹地比較兩個版本到底哪個更好，系統提供盲測比較——找一個獨立的 agent，不告訴它哪個輸出來自哪個版本，讓它單純就品質判斷，再回頭分析勝出的原因。官方文件對這個功能的定位講得很保守：「這是可選的，需要 subagent，大多數使用者不會需要它，人工審查迴圈通常就已經足夠」。這個誠實的自我定位值得注意——系統設計者自己都認為，多數情境下不需要動用到這麼重的驗證流程，單靠人看輸出結果、給回饋就夠了。