Skill 不是文檔，是容器——結構設計決定 AI 輔助的天花板
Skill 不是文檔，而是資料夾結構；有效的內容應該是差異和例外，而非基礎知識；價值來自持續的反饋迴圈，而非一次性寫入。
容器 vs 文檔的認知差
大多數人寫 Skill 時，心裡想的是 markdown 文件。條理清楚，分類完整，像在寫一份知識手冊。但這個前提就錯了。
Skill 本質上是一個資料夾結構——可以容納腳本、代碼片段、模板、設定檔、甚至資料庫連線。它不是「記錄知識」，而是「組織資源」。這個差異看起來細微，實際上決定了整個 Skill 的效能天花板。
善用資料夾結構的 Skill 往往最有效。不是因為它更完整，而是因為它讓 Claude 能夠精準定位和調用。反過來，再漂亮的 markdown 文檔，如果沒有結構化的資源組織，Claude 看到的就是一堆文本噪音。
從「完整性」到「差異性」
傳統知識管理的直覺是「記錄基礎概念」。假設 Claude 不知道，所以要把什麼都寫進去。但這對 AI 輔助開發無效。
Claude 對通用概念已經掌握得很好。重複記錄基礎知識只會造成 token 浪費和上下文污染。有效的 Skill 應該是例外集合——你的專案特定的邊界案例、常見陷阱、與官方文檔的偏差、團隊約定俗成的做法。
換句話說，寫 Claude 會搞錯的，而非它已知的。這是一個從「完整性思維」到「差異性思維」的轉變。前者試圖自給自足，後者承認 Claude 的基礎知識，只補充它缺少的部分。
靜態文檔 vs 動態反饋迴圈
傳統知識庫的用法是一次性寫入，然後就放著。Skill 應該是相反的——持續演進。
關鍵是建立「根據 Claude 實際犯的錯持續更新」的工作流。不是在開發過程中發現一個問題、記下來、然後忘記。而是有人定期檢視 Claude 的失誤模式，判斷是否需要在 Skill 中補充新的例外或澄清。
這要求一套監測和更新的機制。可能很簡單——比如團隊 Slack 有一個 #claude-failures 頻道，每週檢視一次，決定哪些值得寫進 Skill。也可能更系統化——用測試集來驗證 Skill 的有效性。
Skill 的價值不在初版，而在於能否快速捕捉和修正 AI 的失誤模式。靜態文檔做不到這一點。
實踐上的一個轉變
如果你現在的 Skill 還是按「完整教程」的方式寫，可以考慮一次重構：
- 把資料夾結構化，而不只是文件內容
- 刪掉 Claude 已知的基礎概念，保留你的特殊情況
- 建立一個簡單的反饋迴圈，定期更新失誤案例
不需要一次全改。可以從下一個新 Skill 開始試。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。