Skill 的正確打開方式：Anthropic 公開內部方法論後的 5 點反思

作者：AI 產品阿穎

看了一篇 Anthropic 團隊寫的博客《Lessons from building Claude Code: How we use skills》。這應該是我目前看到關於 Skill 最深入的一篇實踐總結了。

Skill 這東西其實不復雜，但真正想把 Skill 做好，我覺得也沒那麼容易。

我記得 Skill 剛火的時候，大家特別喜歡做各種文風 Skill、寫作 Skill。好像只要把自己的寫作風格塞進去，模型就能穩定按照這個風格輸出。

但我後來自己試了一圈，發現很多時候根本不可行。

因為一個文風 Skill 可能就塞進去幾千字甚至上萬字內容。Skill 一加載，上下文就佔掉很大一塊。上下文一重，模型的思考能力反而容易下降。

最後經常出現一種情況：風格倒是學到了，但內容變淺了，分析能力也變弱了。

還有一種常見情況。

很多人寫 Skill 的時候，喜歡往裡面塞各種操作說明。第一步做什麼，第二步做什麼，第三步做什麼。結果跑起來會發現，模型執行並不穩定。

後來我才慢慢理解，很多這種重複執行的工作，其實更適合沉澱成 Script，而不是寫成長長的 Instructions。

看完 Anthropic 這篇文章之後，我最大的感受是，很多人其實都在用 Skill，但未必真正理解 Skill。

Skill 本質上是在做 Context Engineering。什麼時候應該把知識放進 Skill，什麼時候應該拆成 References，什麼時候應該寫成 Script，什麼時候應該用 Gotchas 去約束模型，這裡面其實有很多經驗。

理解了 Skill 的運行原理之後，再回頭看那些優秀的 Skill，會發現它們解決的從來都不是提示詞的問題，而是在解決上下文、經驗沉澱以及能力複用的問題。

如果大家想深度研究 Skill，特別推薦看兩篇文章：

https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills

https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity

#01 不要寫廢話

Skill 本質上是在沉澱組織裡的「隱性知識」。所以，Skill 裡不要重複它已經知道的常識。真正有價值的是其實是那些模型根本不知道的信息。

Anthropic 內部經常強調，Skill 真正要寫的是 Gotchas，也就是常踩的坑。

比如：

1、這個表不能按 created_at 排序

2、staging 返回 200 不代表成功

3、request_id 和 trace_id 是同一個東西

因為這些信息往往存在於員工的經驗裡。所以一定要記住 Skill 本質是什麼。

Skill = 把老師傅經驗寫下來。

通過 Skill，把原來散落在不同人腦子裡的經驗沉澱下來。

#02 Skill 其實是 Context Engineering

這可能是 Anthropic 最深刻的觀點之一。

Skill 不是一個 markdown 文件，而是一個文件夾。對用過 Skill 的人來說，這話聽上去像廢話。

但我這兩天反覆琢磨，慢慢意識到：他們正是想用文件夾這個形式，來表達 Context Engineering 的理念。

我們再重新看一下典型的 Skill 結構：

skill/  ├── SKILL.md  ├── references/ 放詳細說明、API 參考、邊界條件  ├── scripts/ 放可執行腳本  ├── examples/ 放示例  ├── assets/ 放模板、圖片、固定素材

當調用某個 Skill 的時候，模型首先讀取的是 SKILL.md。如果我們把所有的信息都塞進這個文件裡，那很快就會上下文爆炸。

假設這是一個支付排障 Skill，裡面既有 Stripe 的錯誤碼說明，也有歷史故障案例，還有排查腳本和最終報告模板。

如果這些內容全部堆進 SKILL.md，每次調用 Skill 的時候，Claude 都得重新讀一遍。

哪怕用戶只是想確認一個錯誤碼的含義，哪怕只是想查看某個支付狀態為什麼沒有更新。大量根本用不上的信息，也會被一起塞進上下文。

而 Anthropic 的思路完全不同。

SKILL.md 更像一個導航頁。它的職責是告訴模型，遇到 Stripe 錯誤的時候，去 references 裡找對應說明。

需要參考歷史案例的時候，去 examples 裡查類似問題，需要真正執行排查動作的時候，運行 scripts 裡的腳本，最後生成排障報告時，再使用 assets 裡的模板。

整個過程是漸進的暴露。

下面這張圖，強烈建議大家收藏。

#03 儘量用腳本

不要讓模型把有限的上下文和推理能力浪費在重複勞動上。把這些事情交給腳本。

舉個例子。很多人寫 Skill 的時候，會這樣寫：

1. 查詢註冊數據；2. 查詢付費數據；3. 計算轉化率；4. 分析異常原因。

這種寫法當然沒問題。模型也能完成。但每次執行的時候，它都得從頭把整個分析流程重新走一遍。

查詢數據、整理數據、處理各種邊界情況，這些工作其實都是重複的。

既然這些能力已經被驗證過無數次。為什麼還要讓模型重新發明一次？不如直接提供具體的腳本。

而且通過腳本的方式， Skill 的執行也會更加準確，也更省 Token。

從這個角度看，Skill 裡的 Scripts 其實是在沉澱組織能力。每一個腳本背後，往往都是團隊過去踩過無數坑之後總結出來的最佳實踐。

把這些能力固化下來之後。Claude 每次都能站在這些經驗之上工作，而不是一次又一次從零開始。

所以我越來越覺得，Skill 中，Instructions 和 Scripts 解決的是兩個不同層面的問題。

Instructions 提供的是經驗和判斷，Scripts 提供的是能力和執行。

舉個例子，支付排障 Skill 裡可能有這樣一句：

如果 Stripe 返回 200，不要直接認為支付成功，需要進一步檢查 payment_events 表。

這屬於 Instructions。因為這是經驗，而 check_payment_events() 屬於 Script，因為這是執行能力。

如果只有 Script，模型知道怎麼查，但未必知道為什麼查。

如果只有 Instructions，模型知道應該查。但每次都得重新實現。兩者缺一不可。

#04 Description 更像一個路由規則

很多人寫 Skill Description 的方式天然就是錯的。

因為大家習慣寫成功能介紹。比如：PR Management Skill 幫助用戶監控 PR 狀態，處理 CI 問題，自動完成 Merge。

但問題在於，模型並不是通過功能去尋找 Skill 的，Claude Code 啟動的時候，會先掃描所有 Skill 的名稱和 Description。

然後根據用戶當前的問題，判斷應該加載哪個 Skill。

所以 Description 裡最重要的信息，不是這個 Skill 能幹什麼，而是什麼情況下應該加載它。

Description 其實承擔著整個 Skill 的路由工作。

真實世界裡，很少有人會說幫我調用一個 PR 管理工具。大家更可能說：幫我盯一下這個 PR、CI 又掛了之類。

所以一個好的 Description，應該儘量描述用戶的意圖，而不是羅列功能。

我甚至覺得可以用一個特別簡單的方法檢查。

寫完 Description 之後，把整個 Skill 刪掉，只保留這一行 Description。然後問自己：模型看到用戶的問題之後，能不能知道什麼時候該加載這個 Skill。

如果做不到，那大概率還得繼續改。

#05 Skill 的管理和分發

還有一個是關於 Skill 的管理。

一個人用 Skill 的時候，這事其實很簡單。自己寫幾個 Skill，自己維護，自己升級就行了。但我相信大部分團隊後面都會遇到同一個問題。

當 Skill 從幾個變成幾十個，甚至幾百個的時候，這些 Skill 應該怎麼管理？怎麼升級？怎麼分發給團隊成員？

Anthropic 在這方面的經驗，我覺得挺值得參考。

團隊規模比較小的時候，Skill 直接跟著代碼倉庫走。放在項目裡的 .claude/skills目錄就行。大家共享同一套 Skill，也共享同一套工作方法。

但隨著 Skill 數量越來越多，一個新的問題出現了。

Claude Code 啟動的時候，會掃描所有 Skill 的名稱和 Description，然後判斷當前任務應該調用哪個 Skill。Skill 越多，路由成本就越高。

這也是為什麼 Anthropic 後來開始做 Marketplace。但更有意思的是，他們管理 Marketplace 的方式。

很多公司遇到這種問題，第一反應往往是建立一套審批流程。誰寫了 Skill，先提交申請；審核通過之後，再進入官方 Skill 庫。我們內部之前也這樣做過，但非常重。為了管理而管理

我發現人家 Anthropic 的組織就很輕巧。

讓新的 Skill 先在小範圍傳播，讓同事自己安裝、自己試用。

如果越來越多人開始使用，說明這個 Skill 確實解決了某個真實問題。到了這個階段，作者再提交到正式的 Marketplace。

所以他們沒有先討論 Skill 有沒有價值，而是先讓它接受真實使用場景的檢驗，用的人多了，自然就進入正式體系。這樣留下來的 Skill，基本都是團隊真正需要的 Skill。