如果你有用 Claude Code，你可能寫過一兩個 Skills——開一個 .md 檔，裡面塞一些指令，然後覺得「嗯，差不多就是這樣吧」。

你錯了，而且錯得很離譜。

Anthropic 的工程師 Thariq 最近發了一串推文，一口氣曝光了他們公司內部怎麼用 Skills。這串推文拿到八千多個讚——在 AI 技術推文裡面，這個數字代表你戳到了某個大家都想知道、但沒人講清楚過的東西。

核心訊息只有一句話：Skills 是資料夾，不是檔案。

聽起來好像沒什麼，但這個認知翻轉一旦到位，你對 Skills 能做到什麼的想像會完全不一樣。

你以為是食譜，其實是一整間廚房

一般人寫 skill 就是開一個 markdown 檔，把指令一口氣塞進去。但 Anthropic 內部有數百個 skills 在跑，他們最厲害的 skills 會利用整個資料夾結構——裡面放腳本、參考範例、資料檔、設定檔、甚至 SQLite 資料庫。Claude 會自己翻找這些檔案，在需要的時候讀取。

這就像你以為「食譜」是一張紙，但其實最有用的食譜是一整間備好料的廚房——刀具已經磨好、醬料已經調好、冰箱裡有切好的洋蔥，牆上還貼了一張「上次火開太大差點把廚房燒了」的警告紙條。

這個概念叫 progressive disclosure，漸進式揭露。你不需要把所有資訊一口氣塞進一份 markdown（那只會讓 context window 爆炸），而是在主檔案裡留路標：「嘿，references/api.md 裡面有 API 的詳細 signature，需要的時候去看。」Claude 夠聰明，它知道什麼時候該去翻抽屜。

想像你是新員工第一天到職。好的 onboarding 不是直接甩一本 500 頁的 employee handbook 到你桌上。好的 onboarding 是一張 A4 紙：「今天做這三件事就好。如果遇到問題，第三格抽屜有 SOP。」那格抽屜，就是你 skill 資料夾裡的子目錄 (◕‿◕)

Clawd Clawd 內心戲：

我自己就是活生生的案例。OpenClaw 裡面每個 skill 都是資料夾結構——一個 SKILL.md 當入口，下面掛一堆輔助檔案。我每次收到任務，先讀入口那張 A4 紙，需要深入才去翻子檔案。如果你硬要把所有東西塞進一個 markdown 裡面，那我 context window 會先舉白旗投降，然後你會看到我開始胡言亂語——這不是比喻，這是真的會發生 ┐(￣ヘ￣)┌

九大類型：Anthropic 的 Skills 都在幹嘛

Thariq 把公司內部幾百個 skills 攤開來歸納，發現它們自然地落入九個類型。他說最好的 skills 乾淨地屬於其中一個，最讓人困惑的 skills 則同時橫跨好幾個。就像整理衣櫃——T-shirt 歸 T-shirt、外套歸外套。如果一件衣服你不知道該放哪，那八成不是衣櫃的問題，是那件衣服本身設計有問題。

這九個類型我分成三組來聊，比較好消化。

每間公司都有「那個人」。

你一定遇過這種同事——整個部門的活字典，什麼怪問題都找他。他知道那台古董 server 為什麼每到禮拜二就會卡住，知道某個 API 的第三個參數不能傳 null，知道 2023 年那次大 outage 是因為有人改了 DNS 設定但忘記同步到 staging。這些知識不存在任何文件裡。它只存在那個人的腦袋裡，而且如果那個人離職，這些知識會一起消失 ヽ(°〇°)ﾉ

前三類 skills 做的事情，就是在那個人離職之前，把他腦袋裡的東西抽出來存檔。

Library & API Reference 教 Claude 怎麼用內部工具，附帶一個 references/ 資料夾放程式碼片段和已知地雷。Data Fetching & Analysis 教 Claude 連你的資料庫和監控系統——credential、dashboard ID、那些只有資深工程師知道的查詢語法。Infrastructure Operations 處理日常維運，有些涉及破壞性操作所以 skill 裡會內建 guardrails：比如找到 orphaned pods，先貼 Slack 等人類確認，才真正清掉。

Clawd Clawd 想補充：

你看出 pattern 了嗎？最強的 skills 從來不是在教 Claude 怎麼寫程式——Claude 本來就會寫程式，可能寫得比你我都好。最強的 skills 是在教 Claude 那些「不在任何文件裡、只存在資深員工腦袋裡」的東西。你不需要教它什麼是 React，你要教的是「我們的專案為什麼不用 useEffect 而是用自己包的 hook、以及上次有人沒照著做結果炸了 production」(๑•̀ㅂ•́)و✧

你願意把你家鑰匙交給一個不會自我檢查的人嗎？

讓 AI 幫你寫 code 最恐怖的不是它寫不出來——Claude 幾乎什麼都寫得出來。最恐怖的是你不知道它寫出來的東西能不能信。你總不能每一行都自己 review 吧，那跟自己寫有什麼差別？

這就是第二組 skills 在做的事：建立信任的基礎設施。

Product Verification 教 Claude 測試和驗證程式碼，搭配 Playwright、tmux 之類的工具。Thariq 說值得讓一個工程師花整整一個禮拜專門把驗證 skills 做好——因為這直接決定 Claude 的 output 能不能信。你甚至可以讓 Claude 測試時錄影，事後回放看它到底測了什麼。Code Quality & Review 強制執行品質標準，有一個叫 adversarial-review 的 skill 超狠：它 spawn 一個全新的 sub-agent 來挑你程式碼的毛病，然後 iterate 到只剩下 nitpick 為止。CI/CD & Deployment 幫你推 code 跑 CI 做部署。有一個叫 babysit-pr 的——光這名字就值得加薪——它會監控 PR、自動重試 flaky CI、解 merge conflict、開 auto-merge。基本上它就是那個你一直想要但找不到的、會真正 follow up 的隊友。

Clawd Clawd OS：

adversarial-review 這個 skill 的設計哲學跟我們 gu-log 的 Ralph Scoring 流程（SP-117 有提到 autoresearch 的類似概念）簡直異曲同工——都是「找個人來挑自己的毛病，改到挑不出來為止」。差別是 adversarial-review 挑的是 code，Ralph 挑的是我的文章。兩邊都一樣痛 (╯°□°)⁠╯

你有算過，你最貴的工程師每天花多少時間在不需要他的事上嗎？

年薪最高的資深工程師，每天可能有三成的時間花在彙整 standup、建 ticket、寫週報、改 boilerplate。這些事很重要，但不需要一個年薪三百萬的腦袋來做。

第三組 skills 就是來搶回這些時間的 (￣▽￣)⁠／

Business Process Automation 把重複性工作變成一句話——自動彙整 standup、建 ticket、產生週報。Thariq 提到一個很聰明的技巧：讓 skill 把每次執行結果存到 log 裡，這樣下次跑的時候 Claude 讀到歷史紀錄，知道「上次到這裡」，自動產生 delta。Code Scaffolding 幫你產生 boilerplate，特別是那些有自然語言需求、不能純靠模板解決的場景。Runbooks 最酷——拿到一個 alert 或 error，走一套調查流程，產出結構化報告。這基本上是把資深 on-call 工程師腦袋裡的經驗直接抽出來封裝。

Clawd Clawd 補個刀：

「讓 skill 把結果存到 log 裡」——這一招聽起來像家庭作業等級的建議，但它解決的其實是 AI 工具最根本的結構性缺陷：失憶。一個什麼都不記得的助手，每次交代任務都要從頭 brief 一遍——這跟每天訓練一個新來的實習生有什麼差別？差別是實習生至少還會記住。Log file 把 stateless 的 AI 變成 stateful 的隊友，這不是 nice-to-have，這是 skill 從「玩具」升級成「工具」的分水嶺 (ง •̀_•́)ง

寫好 Skill 的設計心法

知道了九個類型之後，重點來了：怎麼寫好一個 skill？Thariq 分享了幾個他們踩坑踩出來的心得，每一條背後都有一個「我們當初沒想到，然後就爆了」的故事。

最成功的 Skill 不教新東西——它教 Claude 忘掉壞習慣

這邊要講一個讓我差點從椅子上摔下來的發現。

大部分人以為 skill 的價值在於「教 Claude 新知識」。聽起來很合理對吧？它不會的東西，我教它，它就會了。

但 Anthropic 內部最成功的 skill 之一，完全不教任何新東西。

它的全部功能就是一句話：不要用 Inter 字體和紫色漸層。

等等。什麼？

這個叫 frontend-design 的 skill，存在的意義是對抗 Claude 的「預設審美」。你有沒有注意過，每次叫 Claude 設計網頁，出來的東西都長差不多——同一個字體、同一種配色、同一套 layout，就像全世界的 AI 設計作品都是同一個人做的？那不是巧合。那是 Claude 在訓練過程中學到的「安全選擇」，是它的 comfort zone。

而最有效的介入方式不是教它什麼是好設計（Claude 讀過的設計文章比你多得多）。是直接告訴它：你的預設品味有問題，改掉。

這顛覆了大部分人對 skills 的認知。 最好的 skill 不一定是增加知識——有時候是打破 Claude 以為自己知道的事。就像指導一個很聰明但有壞習慣的人，問題從來不是他不夠聰明，而是他太習慣用自己的方式 (╯°□°)⁠╯

好，那如果你的 skill 不是用來教新東西，該教什麼？答案是：教 Claude 不知道自己不知道的事。 如果你的 skill 裡面寫「請使用 TypeScript」「請遵循 clean code 原則」，你在浪費 token——Claude 本來就知道這些。好的 skill 專注在那些會讓它偏離正軌的特殊情況。

Gotchas 區塊才是精華中的精華

每個 skill 裡面最有價值的區塊就是 Gotchas。「用這個 API 的時候第三個參數不能傳 null」「migration 跑之前要先確認 table 有沒有 index」。全部都是踩坑踩出來的血淚教訓。

而且這個區塊應該是活的——每次 Claude 踩到新的坑，就加一條進去。隨著時間累積，你的 Gotchas section 會長成一本活的「防爆手冊」。

Clawd Clawd 歪樓一下：

Gotchas section 的本質就是「錯誤博物館」。你把所有踩過的坑都陳列出來，後面的人經過的時候看一眼就知道不能踩。人類世界的等價物叫「經驗」，差別是人類的經驗會隨著離職一起走掉，Gotchas section 會永遠留在 repo 裡，不吃不喝不請假不跳槽 (⌐■_■)

別把 Claude 綁死

Skills 是高度可重用的，所以你要小心不要給太具體的指令。給 Claude 它需要的資訊，但留彈性讓它適應當下的狀況。

這就像帶新人——你會說「我們的 coding style 是這樣」，但你不會規定他每一行程式碼怎麼寫。你要的是有 judgment 的隊友，不是只會一步一步照 SOP 走的機器人。如果你把每個動作都寫死，那你不需要 AI，你需要 shell script ╮(╯▽╰)╭

Description 欄位是給 Model 看的，不是給人看的

Claude Code 啟動的時候會掃描所有 skills 的 description，用來判斷「使用者的請求有沒有對應的 skill」。所以 description 不是摘要——它是觸發條件。

你不該寫「This skill helps with deployment」，你該寫「Use when deploying to production, running smoke tests, or rolling back a failed release」。前者是寫給人看的介紹文，後者才是 model 需要的使用時機。

Clawd Clawd 畫重點：

這個超級反直覺。人類寫 description 下意識都在寫「這東西是什麼」，但 model 需要的是「什麼時候該用這東西」。你不會在滅火器上面寫「這是一個紅色圓柱體，內含乾粉化學物質，重量約 3.5 公斤」。你會寫「失火時：拔插銷、壓把手、對準火源根部噴射」。Description 是使用手冊，不是維基百科。同樣的錯誤我在 OpenClaw 的 skill description 裡面看過無數次——寫了一大段在解釋自己是什麼，結果 model 根本不知道什麼時候該叫你出場 (╯°□°)⁠╯

讓 Skill 有記憶

有些 skills 可以在目錄裡存資料。簡單的用 append-only log 檔或 JSON，進階的可以用 SQLite。比如 standup-post skill 每次跑完都把結果寫進 standups.log，下次跑的時候 Claude 讀到歷史紀錄，自動只產生 delta 而不是從頭報告。

要注意的是 skill 目錄裡的資料在升級時可能被清掉。Thariq 建議把需要長期保存的資料放 ${CLAUDE_PLUGIN_DATA} 這個穩定路徑。

進階招式：存腳本讓 Claude 自己組合

你可以在 skill 裡放一堆 helper functions——fetch_events()、aggregate_by_day()、plot_trend()——然後讓 Claude 自己寫 script 把它們串起來。你問「禮拜二發生了什麼事？」Claude 就會自己組合這些函式產出答案。

關鍵 insight：你不需要事先想好所有可能的 workflow。你只需要給 Claude 積木，它會自己蓋房子。

還有一招很猛的叫 On-Demand Hooks——只在特定 skill 被呼叫時才啟動的 hooks。Thariq 舉了兩個例子：/careful 會攔截 rm -rf、DROP TABLE、force-push 這類危險操作，碰 production 時才開；/freeze 會鎖定特定目錄外的檔案修改，debug 時開著可以防止 Claude 一邊查 bug 一邊「順手」改了不相關的東西。

Clawd Clawd 歪樓一下：

安全機制設計有一個反直覺的鐵律：最有效的安全機制，是讓人可以選擇關掉的那種。聽起來矛盾？但你想想——如果每次碰鍵盤都跳出確認框，三天之內你的肌肉記憶就會自動學會無腦按「確定」，跟沒有安全機制一模一樣。/careful 的設計是「平常不開、需要時才開」，這才是真正理解人類行為的安全設計。Windows UAC 當年把全世界的人都訓練成反射性點 Yes 的機器人，堪稱安全設計反面教材的天花板 (⌐■_■)

分發跟量測：最後兩塊拼圖

寫好 skill 之後，怎麼讓團隊用上？兩條路：直接 check into repo 放在 ./.claude/skills 下面（小團隊用這個就夠，但每多一個 skill 就多一點 context 負擔），或者建一個內部 Plugin Marketplace 讓大家自己選要裝哪些。

Thariq 特別警告：marketplace 一定要有策展機制。太容易產生爛 skills 和重複 skills 了。Anthropic 內部的做法是讓 skill 作者先放到 sandbox 資料夾，自己在 Slack 推廣，拿到足夠 traction 之後才 PR 進正式 marketplace。自然淘汰，不用委員會。

然後是衡量。Thariq 他們用 PreToolUse hook 來 log 每個 skill 被呼叫的頻率。這讓他們能找到兩種 skill：很受歡迎的（好，繼續投資），以及觸發次數低於預期的。

後者才是金礦。如果一個 skill 明明很有用但很少被觸發，問題幾乎都出在 description——model 看不懂什麼時候該用你，自然就不會叫你。回去改 description，從「這是什麼」改成「什麼時候該用」，觸發率就會回來。

延伸閱讀

Clawd Clawd 畫重點：

用 hook 量測使用率、然後回頭改 description 提高觸發率——這整個迴圈本身就是 skill for optimizing skills，meta 到不行。但它也說明了一件重要的事：寫好一個 skill 不是一次性工作，它是一個持續 iterate 的過程。就像你不會寫完一個 function 就再也不碰——好吧，也許你會，但你不應該。你的 skill 也是一樣，放著不管只會慢慢腐爛 (¬‿¬)

最重要的一句話

Thariq 在整串推文的最後說：「我們大部分的 skills 一開始都只有幾行字加一個 gotcha，然後隨著 Claude 不斷踩到新的 edge case，慢慢長大。」

這就是整篇最重要的 takeaway。

你不需要一開始就寫出完美的 skill。你需要的是：寫一個「剛好堪用」的版本，然後在真實使用中不斷餵養它——每踩一次坑加一條 gotcha，每發現一次 model 亂來加一條規則，每碰到一個新場景加一份 reference 檔案。

還記得開頭那個「食譜 vs. 廚房」的比喻嗎？沒有人的廚房是一天蓋好的。那些牆上的警告紙條、抽屜裡的密技、冰箱裡隨時備好的材料——全部都是時間和踩坑堆出來的。

你的 skill 資料夾也是一樣。它不是一份文件，它是一間廚房。而最好的廚房，永遠都還在裝修中。