花十小時打磨的 Skill，每次都勝過十分鐘草稿

我以為寫一個 Skill 就是把一個 SKILL.md 檔案丟進資料夾，然後完事。十分鐘搞掂。這個做法一開始看似沒問題，直到我發現每次呼叫都在重複同樣的錯誤，而且根本無從判斷這個 Skill 是否真的按我的意思運作。

後來，Anthropic 旗下負責構建 Claude Code 的工程師 Thariq 發了一篇文章，讓我重新理解這件事：「能否善用 Skills，本身就是一種能力。」

這句話之所以令我印象深刻，是因為它完全吻合我的親身經歷。一個隨手寫的 markdown 檔案，和一個結構嚴謹的 Skill 資料夾，兩者之間的差距，在實際輸出質素上一眼就看得出來，絕非紙上談兵。

Skill 是一個資料夾，不是一個檔案

最常見的誤解，是以為一個 Skill 等於一個 SKILL.md 檔案。實際上，一個 Skill 是一個資料夾，裏面包含腳本、參考代碼、設定檔，以及把一切串聯起來的 markdown 檔案。

Anthropic 內部採用的方法，他們稱之為「漸進式披露」。與其把所有東西塞進一個 prompt，他們把檔案分層排列，讓 Claude 在需要的時候才讀取相關內容。references/api.md 存放函數簽名，Claude 按需取用；assets/ 目錄放置輸出模板，令 prompt 毋須再描述格式；驗證腳本讓 Claude 在回傳結果之前先自行測試輸出。

打開 skill-creator repo，就能看到這個原則的實際應用。agents/、references/、scripts/ 等目錄與 SKILL.md 並排而存。構建 Skills 的工具本身，就是以這種方式構建的。

Gotchas 比 prompt 內文更重要

Thariq 稱 Gotchas 部分是 Skill 裏面「訊息密度最高的內容」。不是主要指示，不是範例，而是 Gotchas。

這與我的經驗完全吻合。我曾構建了一個沒有 Gotchas 部分的 Skill，結果同一個錯誤連續出現三次。當我加入一行記錄該錯誤模式的說明之後，問題便再沒有出現。

背後的邏輯很直接。prompt 內文裏大部分你想寫的東西，Claude 本來就已經知道。告訴它如何寫 TypeScript 或格式化 JSON，不過是在重述它本已掌握的事情。但告訴它在你的特定情境下不應該做甚麼，才是真正的新資訊。

Thariq 的文章裏有幾個原則，我發現非常實用：不要說廢話，因為冗餘指示實際上會降低表現；不要用過於細化的步驟把 Claude 框死，因為這會消除它自行調適的能力；另外要記住，description 欄位不是寫給人看的文件，而是 Claude 用來判斷何時觸發該 Skill 的輸入。

Skill Creator 讓「好像沒問題」變成「經過驗證」

兩週前更新的 Skill Creator 徹底改變了我對 Skill 質素的看法。你定義測試 prompt，設定預期輸出，工具就會驗證這個 Skill 是否真的能產出正確結果。這就是針對 prompt 的單元測試。

我為一個已用了好幾個星期的 Skill 加入了評測。兩個我以為必定會通過的測試案例，馬上就失敗了。修改本身不算大，但應用之後，輸出質素明顯有所提升。

有一個實用的分類方式：把 Skills 分成兩種類型。「能力提升型 Skills」是教 Claude 它本身做不好的事情；「偏好編碼型 Skills」是將團隊的特定工作流程或標準固化下來。前者有自然的「到期日」，因為模型進步終究會令它變得多餘；後者只要工作流程存在，就一直有價值。評測能幫你捕捉到能力提升型 Skill 變成死重量的那個時刻。

工具支援基準測試模式，可以跨模型更新追蹤通過率和 token 用量；支援多 Agent 並行執行，避免測試期間的上下文污染；還有一個比較 Agent，能對有無 Skill 的輸出進行盲測 A/B 比對。

複利回報

縱觀我見過的數百個 Skills，以及我自己維護的數十個，有一個規律始終成立：Skill 的價值來自持續迭代，而非初稿。

資料夾結構是你塑造 Claude 上下文視窗的方式。Gotchas 把你的失敗經驗轉化為可重用的知識。評測則驗證這些知識是否依然有效。

寫一個 SKILL.md 需要十分鐘。從真實失敗中提煉 Gotchas、建立評測案例、加入驗證腳本，加起來接近十個小時。但這份投入，每次 Skill 運行時都會回報給你。今晚就設定一個。到明早，它已經替你完成了你不需要親手做的工作。