Anthropic 自己內部是怎麼用 Claude Code Skills 的，這次終於公開了。
他們把內部團隊的用法做了一次完整復盤：Skills 分成那 9 類、那類最值得花力氣、怎麼寫才真的有用。這些經驗之前只在 Anthropic 內部流轉，現在一次講清。
今天把這個經驗帖的核心乾貨給你梳理清楚。
一、先把 Skill 理解對
Anthropic 先糾正了一個很常見的理解。Skill 不只是幾段提示詞，它更接近一個圍繞任務組織起來的資料夾。
這個資料夾裡可以放 SKILL.md，也可以放參考文件、指令碼、範本、示例、hooks，甚至放會被後續任務繼續讀取的資料。Claude 呼叫 Skill 時，拿到的其實是一套完成任務所需的工作材料。
這個定義很重要。因為很多團隊真正缺的，從來不是“再補一段提示詞”，而是把那些已經驗證過的做法、容易錯的細節、常用指令碼和固定流程，一次整理好，後面反覆復用。
二、Anthropic 把內部 Skills 歸成了 9 類
Anthropic 盤了一遍內部的 Skills，最後大致分成了 9 類。這 9 類連起來看，其實很像一條完整的軟體工作流，從補知識到寫程式碼，再到驗證、部署、排障和維運。
前三類：給模型補知識、補驗證、補資料
第一類是 library 和 API reference，給模型解釋某個庫、CLI 或 SDK 在團隊內部到底該怎麼用，把容易用錯的規則和 gotchas 寫清楚。
第二類是 product verification，負責判斷產出有沒有真的工作，比如在無頭瀏覽器裡完整跑一遍註冊和結帳流程。Anthropic 明說這類對輸出質量提升最明顯，值得讓工程師專門花一周打磨。
第三類是 data fetching and analysis，連著資料倉儲和監控系統，把取數方法、欄位約定和常見分析路徑封裝好，模型不用再去猜表結構和欄位名。
中間三類：開始接住團隊裡的日常流程
第四類是 business process and team automation，把重複發生的團隊流程壓成一個命令就能跑的工作流，比如只輸出相對昨天增量的 standup，或固定格式的周報。能看出來，Skill 接住的不只是程式碼任務，也包括協作任務。
第五類是 code scaffolding and templates，生成那些有固定骨架、但又帶著大量自然語言約束的程式碼，比如新 service 或遷移檔案。這正是純範本引擎覆蓋不了的部分。
第六類是 code quality and review，讓程式碼儘量符合團隊的質量標準。典型例子是拉一個“新鮮視角”subagent 來挑錯的 adversarial-review，這類能力還能做成 hook 接進 CI。
後三類：已經連到生產環境了
第七類是 CI/CD and deployment，把程式碼從開發態推到上線態。比如 babysit-pr會盯完一個 PR 的全過程，deploy-<service>會把 build、放量、錯誤率對比和回滾條件串成一條鏈路。
第八類是 runbooks，入口不是“我要寫什麼”，而是“現在出了什麼症狀”。報警、Slack thread、request ID 進來，它負責對應到該用那些工具、查那些路徑，最後給出結構化結論。
第九類是 infrastructure operations，處理資源清理、依賴治理和成本排查這類例行操作。這些動作常帶破壞性，所以 Skill 裡要寫清 guardrail，先通知、再確認，最後才真正執行。
三、Anthropic 真正強調的，不只是“會寫”，更是“寫對”
把 9 類梳理完以後，Anthropic 接著講的，其實是幾條更底層的判斷：什麼樣的 Skill 更穩，那些地方最值得花力氣。
好的 Skill，往往都很聚焦
Anthropic 說得很直接，最好的 Skill 往往都很聚焦。能清楚落進某一類裡的 Skill，通常更穩；試圖同時覆蓋太多目標的 Skill，反而更容易把模型帶亂。
這個判斷很有參考價值。因為很多團隊一開始做 Skill，最容易犯的錯誤就是想“一次做大做全”，結果最後既不好觸發，也不好維護。
所有類型裡，他們最看重「驗證」
在所有類型裡，Anthropic 特別強調 verification。因為模型最容易給人一種“已經做完了”的錯覺，而真正容易掉鏈子的地方，恰恰是最後那一步驗證。
原文甚至建議，值得讓工程師單獨花一周，把驗證類 Skill 做到足夠好。這個投入聽起來很重，但如果它直接影響結果質量，其實很划算。
他們還給了兩個非常實用的建議。一個是讓 Claude 錄下自己測試過程的視訊，這樣你能清楚看到它到底測了什麼。
另一個是在關鍵節點加程序化斷言。狀態有沒有變化，事件有沒有真正落庫，最終頁面是不是到了目標狀態，都儘量不要只靠“看起來差不多”。
真正有價值的內容，往往是 gotchas
Anthropic 對 Skill 裡的內容優先順序也講得很清楚。最有訊號量的部分，通常不是通用步驟，而是 gotchas。
因為 Claude 本來就會寫程式碼，也會讀程式碼庫。那些“默認它也會做”的東西，寫進 Skill 裡只會增加上下文，不一定增加價值。
真正值得寫的，是那些會把模型從默認思路里拽出來的細節。比如 subscriptions表是 append-only，要找最高version，不能只看最新created_at。
再比如同一個欄位，在 API gateway 裡叫@request_id，到了 billing 服務裡叫trace_id。還有 staging 返回 200，也不代表 Stripe webhook 真處理成功了，還得去看payment_events裡的真實狀態。
這類資訊單看都不大，但一旦出錯，最後結果就會偏。Skill 的價值，很多時候就體現在這些“團隊裡人人知道，但模型默認不知道”的地方。
四、Skill 到底該怎麼寫
前面 Anthropic 團隊講完了“先做什麼”，這一段他們共享了“具體怎麼寫，才能讓 Skill 真起作用”的內部經驗。
1. 別把顯而易見的話再寫一遍
第一個細節是別把顯而易見的話再寫一遍。Skill 不是給人看的摘要，它要補的是模型默認拿不到、或者默認容易走偏的資訊。
Anthropic 提到過一個前端設計 Skill 的例子。它的價值不在於教 Claude 怎麼寫前端，而在於補充團隊通過和客戶反覆迭代後沉澱下來的“設計品味”和避坑點，比如少用一些過於套路化的字型和配色選擇。
2. SKILL.md更像目錄，不該寫成大雜燴
第二個細節是SKILL.md不要寫成大雜燴。更好的做法，是讓它做目錄和路標，把具體資料按需分發到別的檔案裡。
比如任務卡住了，再去讀 stuck-jobs.md。API 的函數簽名和用法示例，可以拆進references/api.md。
如果最終要產出一份 markdown 檔案，那範本可以放進 assets/。指令碼、參考資料、例子也都可以分目錄放好，讓 Claude 需要時再去取。
這套做法對應的就是 Anthropic 說的 progressive disclosure。檔案系統本身，也是一種上下文工程。
3. Skill 不要寫得太死
第三個細節是別把 Skill 寫得太死。你需要給 Claude 關鍵規則，但也要給它足夠的適應空間，不然 Skill 一復用，就容易在別的具體情境裡卡住。
4. setup 要提前想好
第四個細節是提前想好 setup。很多 Skill 真跑起來時，會缺一些來自使用者的上下文，比如 Slack 要發到那個頻道。
原文建議把這類配置放進 config.json。如果配置還沒建好，Claude 就先問使用者；如果需要結構化、多選式提問，還可以直接呼叫AskUserQuestion工具。
5. description 要直接服務觸發
第五個細節是 description 要寫給模型看。Claude Code 一開局會先掃描所有 Skill 的名稱和 description，再判斷這次請求有沒有可用 Skill。
所以 description 不是摘要，而是觸發條件說明。使用者可能會說什麼關鍵詞，會上傳什麼檔案，什麼場景下應該啟動這個 Skill，都應該直接寫進去。
原文還舉了一個很小但很典型的點。像 “babysit” 這種觸發詞，就應該直接出現在 description 裡。
五、Skill 用深之後，會先長出記憶、指令碼和 hooks
Anthropic 專門留了一節講這個。很多 Skill 一開始只是幾行說明，越用越多之後，最先長出來的就是記憶、指令碼和 hooks 這三樣。
先說記憶。像 standup-post這種 Skill，可以把每次輸出都記進standups.log，下次執行階段先讀歷史，再判斷今天和昨天相比到底變了什麼。
這種記憶可以很簡單，用 append-only 文字或 JSON 就夠了；也可以複雜一點，直接用 SQLite。原文還提到，可以用 ${CLAUDE_PLUGIN_DATA}這個環境變數，拿到一個穩定的持久化目錄來存這些資料。
再說指令碼。Anthropic 的判斷很明確，能給 Claude 的最強工具之一，其實就是程式碼本身。
如果你把常用的資料抓取函數、分析函數或者操作指令碼預先放進去，Claude 就不用每次從零重寫樣板程式碼，而是把更多回合花在“怎麼編排”和“下一步做什麼”上。
比如資料分析類 Skill 可以直接帶一組 helper functions。這樣當使用者問“周二到底發生了什麼”時，Claude 就能臨時拼出一段更複雜的分析指令碼，而不是先花很多力氣重建基礎設施。
最後是 on-demand hooks。它們只在 Skill 被呼叫時生效，而且只在當前會話裡存在。
原文舉了兩個很典型的例子。/careful會攔住rm -rf、DROP TABLE、force-push、kubectl delete這類高風險操作；/freeze則會阻止對指定目錄之外的 Edit 和 Write，適合排障時防止自己一邊加日誌一邊順手改壞別的地方。
六、當團隊開始大量用 Skill，後面就是分發和治理
這是單個 Skill 長大的下一步。Skill 一旦開始在團隊裡擴散，問題就不只是“怎麼寫”，還會變成“怎麼發給別人用、怎麼持續管理”。
兩條主路線：repo 內 check-in 和外掛 marketplace
一種是直接把 Skill check in 到 repo 裡的 ./.claude/skills。對於規模不大的團隊、或者只在少數程式碼庫協作的團隊，這已經很好用。
另一種是做成外掛，用內部的 Claude Code Plugin marketplace 來上傳和安裝。團隊一變大，這種方式的優勢會更明顯。
原因很簡單。每多 check-in 一個 Skill，模型可見的上下文負擔就會多一點；而 marketplace 可以把安裝權交給團隊成員自己，也方便順手做 setup 流程。
Anthropic 在治理上也沒有一上來就搞中央審批。更常見的方式，是誰有 Skill 想給大家試，就先傳到 GitHub 裡的 sandbox 資料夾，再發到 Slack 或別的管道讓別人試用。
等這個 Skill 真有了 traction，再由 Skill owner 提 PR，把它正式移進 marketplace。這個流程很輕，但很符合 Skills 這種靠真實使用慢慢長出來的東西。
Skills 之間也可以互相組合
原文還提到一個很有意思的方向，就是 skill composition。比如你可以有一個檔案上傳 Skill，再有一個 CSV 生成 Skill，後者生成完檔案後，再去呼叫前者完成上傳。
這類依賴管理目前還不是 marketplace 或 Skill 機制裡的原生能力，但只要在 Skill 裡直接引用另一個 Skill 的名字，模型在安裝了它們的前提下，照樣能把鏈路串起來。
還可以做 usage measurement
Anthropic 也提到，他們會用PreToolUse hook 記錄公司內部的 Skill 使用情況。這樣就能看到那些 Skill 很熱門，那些觸發明顯不足。
這類資料其實很有用。因為 Skill 做出來以後，真正的問題常常不是“能不能運行”，而是“會不會在該觸發的時候被想起來”。
寫在最後
Anthropic 在文章結尾提到一個細節：他們內部最好的 Skills，一開始往往只有幾行字和一個 gotcha，用得越多，才補得越完整。
這句話基本可以當成上手指南。寫 Skill 不用追求一步到位，先把驗證方法寫清楚，把真正踩過的坑記下來，指令碼、記憶、hooks 和分發，等用起來之後再慢慢補。
如果你也在用 Claude Code，不妨從手頭最常重複的那個任務開始。先寫幾行說明，加上一個 gotcha，剩下的交給時間和使用頻率。 (Datawhale)