Skill 設計方法論

概要

從零開始設計 Claude Code Skill 的五步方法，適用於任何領域的工作流程封裝。

步驟

第一步：分析現有實踐

• 不要憑感覺直接寫，先分析你或團隊現有的工作產出
• 寫作 Skill：讀三篇不同類型的自家文章，歸納共同特徵
• 審查 Skill：翻一遍框架的官方文件，特別是 production / security / performance 章節
• 參考開源社群的現有 Skill（如 humanizer-tw），取其精華但調整定位

第二步：定義品質標準

• 用三欄對照表（太保守 / 適當 / 太激進）明確劃定邊界
• 抽象描述（「專業但不僵硬」）無效，需要具體的樣本點
• 建立分級制度（嚴重程度或品質維度），不分級等於沒有標準
• 為每條規則附上「正確 vs 錯誤」的具體範例

第三步：用多種案例交叉測試

• 覆蓋不同類型的輸入（寫作：踩坑紀錄 / 工具比較 / 觀點反思；審查：安全 / 效能 / migration）
• 如果只測一種類型，會漏掉其他類型的特有問題
• 語氣在反思型文章中過於隨性的問題，在踩坑紀錄測試中不會浮現

第四步：系統化分類

• 將規則按類別整理，不要把所有規則混在一起
• AI 寫作問題：八大類、19 個具體問題
• 程式碼審查：CRITICAL / HIGH / MEDIUM / LOW 四級
• 有分類才有逐項檢查的依據

第五步：分離知識與流程

• 如果 Skill 會隨外部因素更新（框架版本、API 變更），將知識（Skill）和流程（Agent）分開
• 更新知識時不需要改流程邏輯
• 日常用快速指令（只跑相關檢查），定期用全面審計
• 加入噪音過濾機制（信心度門檻、同類合併）

適用場景

• 技術寫作風格規範
• 框架特定的程式碼審查
• 資料分析報告模板
• 客戶溝通回覆模板
• 任何需要「一致性和品質控制」的重複性工作

不適用場景

• 高度創意性的工作（腦力激盪、概念探索）
• 一次性任務（封裝的投入回報比低）
• 規則快速變動的領域（維護成本高於收益）

關聯概念

• [[Claude Code Skill 系統]]
• [[品質評分機制]]
• [[去除 AI 味寫作]]
• [[AI 程式碼審查]]