Claude Code 內部覆盤的Skills實戰經驗公開：好 Skill 的 5 個共性
整理版優先睇
好 Skill 嘅關鍵係高語境知識，唔係寫說明書
Anthropic 工程師 Thariq 公開咗 Claude Code 內部用 Skills 嘅經驗，話佢哋已經有數百個 Skill 活躍使用。作者之前都寫過 Skill 實測，但發現好多人都係「寫出來唔好使」。Thariq 嘅分享令作者意識到，大部分 Skill 寫嘅係低語境知識，例如 API 文檔、操作步驟，呢啲模型本身就識。真正令 Skill 好用嘅，係高語境知識——團隊特有嘅坑、默認規則、邊界條件，呢啲只有你自己先知道嘅嘢。
高低語境係 Edward T. Hall 提出嘅框架：低語境依賴字面信息，高語境依賴共享背景同隱含共識。傳統編程係低語境，但團隊協作充滿高語境。你帶一個新人，唔單止要講任務，重要講邊部機器唔好碰。Skill 就係要將呢啲高語境知識翻譯成 AI 接得住嘅格式。Thariq 總結咗五條經驗：第一，坑點總結信息密度最高；第二，description 要寫成觸發條件，唔係簡介；第三，Skill 可以加記憶（日誌文件）；第四，Skill 嘅威力在於成個文件夾（腳本、模板、參考代碼）；第五，加鈎子做護欄。
最終結論係：寫 Skill 嘅正確順序係先列坑點、再寫精準 description、加工具同模板、加記憶、再加護欄。咁樣先至係一個有知識、有工具、有記憶、有邊界嘅工作環境。模型決定 AI 能想多遠，Skill 決定 AI 能幹多穩，而 Skill 嘅質量取決於你裝咗幾多高語境知識入去。
- 好 Skill 嘅核心係高語境知識，例如團隊特有嘅坑同默認規則，唔係低語境嘅說明書。
- 寫 Skill 第一步係列出你哋踩過嘅 10 個最大嘅坑，放喺 Gotchas 部分。
- Description 要寫成精準嘅 if 條件，等模型喺正確場景自動觸發，唔好亂寫一句簡介。
- 幫 Skill 加記憶（日誌文件），令佢記得上次做到邊，避免每次由零開始。
- 用鈎子設定護欄，限制 AI 嘅危險操作，例如只准編輯指定目錄或攔截 rm -rf。
高低語境啟發：Skill 補嘅係語境，唔係說明書
傳統編程係一種極端嘅低語境溝通：你乜都要寫清楚，少個分號就崩。但團隊入面做嘢完全唔同，老工程師會話「呢個接口唔係唔用得，但線上最好唔好咁叫」，呢啲嘢文檔揾唔到，只係經驗同默契。
學術上叫「高語境溝通」——依賴共享背景、默認規則同隱含共識。
你而家調教嘅 Skill 就係個實習生。API 文檔、技術教程佢都知，甚至比你更熟。但一入真實工作流，卡住佢嘅係高語境信息：團隊真正嘅驗收標準、公認嘅「準口徑」、文檔無寫但必須核嘅步驟。
所以寫 Skill 之前，問自己：呢度有幾多內容係 Claude 自己搜唔到？如果大部分搜得到，呢個 Skill 價值就好有限。
五條實戰經驗：由坑點到護欄
第一：Anthropic 內部最睇重嘅係「坑點總結」，因為呢啲高語境知識查遍全網都揾唔到。
例如你哋審批流程文檔標可選，但實際上一定要行，唔行就卡住。呢啲先係要寫入 Skill 嘅嘢。
第二：Description 字段非常重要，佢唔係畀人睇嘅摘要，係畀模型睇嘅觸發條件。
寫得太窄會錯過場景，寫得太寬成日亂跳。應該精準寫明「當用戶需要翻譯英文文檔（PDF/DOCX/EPUB）為中文時觸發，唔適用於日常短句」。
第三：Skill 可以有自己的記憶，例如喺目錄放一個日誌文件，每次執行完追加記錄。
下次執行先讀日誌，咁就知上次做咗乜。應用喺站會日報，能識別今日新增咗咩、邊啲任務由進行中變完成，而唔係次次由零開始。
第四：Skill 嘅威力唔止喺份 markdown，而係成個文件夾——腳本、模板、參考代碼。
將查詢邏輯封裝成 Python 函數放喺 scripts/ 目錄，AI 只需決定點調用，唔使重建輪子。放模板文件令輸出格式精準，放參考代碼令風格一致。呢個就係「漸進式上下文披露」。
第五：要有邊界同護欄，用 PreToolUse 鈎子攔截危險操作，或者用 /freeze 限制 AI 只編輯指定目錄。
內部管理：自然生長 + 質量戰
Anthropic 將數百個 Skill 歸成 9 類，例如庫同 API 參考、產品驗證、數據分析、業務流程自動化等。但最好嘅 Skill 都只落喺一個類別，唔會又想做教程又想做自動化。
背後判斷標準係：呢個 Skill 到底補「知識差」定「執行差」。
補知識差就重點寫坑、邊界、反例；補執行差就畀腳本、驗證工具、自動化流程。
Thariq 特別提到驗證類 Skill：如果做得好，值得一星期時間打磨。
因為生成能力決定 AI 能做幾多，驗證能力決定你敢畀佢做幾多。佢哋內部用 PreToolUse 鈎子做使用統計，數據驅動淘汰。
Skill 商店已經出現，但質量戰先係重點。創建糟糕 Skill 太容易，要有策展機制先好上架。
寫 Skill 嘅正確順序：五步法
- 1 第一步：列出你哋團隊喺呢類任務上踩過嘅 10 個最大嘅坑，寫入 Gotchas。
- 2 第二步：將 description 當觸發條件寫，想清楚邊啲場景該自動激活、邊啲唔該。
- 3 第三步：畀腳本、畀模板、畀參考代碼，唔好齋畀文字。等 AI 集中精力做判斷同組合。
- 4 第四步：加記憶，哪怕只係一個日誌文件，令 Skill 知道上次做咗乜、今次要做咩唔同。
- 5 第五步：加護欄，唔單止話畀 AI 做乜，重要話畀佢乜嘢絕對唔做得。
做完呢五步，你嘅 Skill 就係一個有知識、有工具、有記憶、有邊界嘅工作環境。模型決定 AI 能想多遠，Skill 決定 AI 能幹多穩，而 Skill 嘅質量取決於你裝咗幾多高語境知識入去。
上個月我寫咗一篇 Skill 嘅實測文章，由翻譯兩本書嘅實戰出發，講咗「做完打包」呢件事有幾重要。
但係仲有啲朋友話，「我寫嘅 Skill 就係唔好用」。
老實講，呢個問題我自己都遇過。有啲 Skill 寫完越用越順，有啲點改都爭啲，一直都講唔出到底衰喺邊。
3 月 18 日，Anthropic 工程師 Thariq 出咗條長推，標題係《Lessons from Building Claude Code: How We Use Skills》。佢哋內部已經有幾百個 Skill 活躍緊用，踩過嘅坑同埋總結出嚟嘅經驗，終於公開咗一次。
我睇完之後有好大觸動。唔係某個具體技巧，而係令我意識到，大部分寫 Skill 嗰陣，寫入去嘅嘢根本唔係 AI 需要你話畀佢知嘅。
Skill 補嘅唔係說明書，係語境
講 Thariq 五條經驗之前，先講一件看似無關但其實好重要嘅事。
你有冇諗過，傳統編程其實係一種好極端嘅溝通方式？你一定要將輸入、輸出、參數、條件、流程全部寫清楚，少寫一個分號個程式都會冧。電腦唔會估你嘅意思，你講乜佢做乜，一個字都唔慳得。
但我哋人同人之間喺團隊做嘢，完全唔係咁。老工程師會同你講：呢個接口唔係唔用得，但係線上最好唔好咁樣 call。產品經理會話：呢份需求文檔寫嘅係 A，但老細真正想要嘅係 B。
呢啲說話你喺任何文檔都揾唔到。佢哋只係存在喺經驗、默契、口頭傳授，同埋一堆做耐咗就知嘅判斷入面。
學術上有個講法叫「高語境溝通」。Edward T. Hall 喺上世紀提出嘅框架：低語境溝通依賴字面信息，高語境溝通依賴共享背景、默認規則同埋隱含共識。你同一個合作咗三年嘅同事講「老規矩處理一下」，佢即刻知道點做。但你同一個新嚟嘅實習生講同一句說話，佢會一頭霧水。
你而家調教緊嘅 Skill，就係嗰個實習生。
API 文檔、代碼示例、技術教程，呢啲寫到明嘅嘢佢都知道，甚至比你記得更清楚。但一入到真實工作流程，卡住佢嘅正正係嗰啲高語境信息：你哋團隊真正嘅驗收標準係咩、邊個圖表先係組織公認嘅「準口徑」、有啲步驟文檔冇寫但一定要額外核對。
所以好多 Skill 之所以唔好用，係因為大家寫入去嘅，仍然係模型本來就知嘅嘢，本質上等於又餵咗佢一份已經食過嘅飯。嗰啲低語境嘅、寫喺明面嘅知識，模型原本就識。你講多次，佢都未必做得更好。
第一：Anthropic 內部最睇重嘅，係「坑」
咁應該寫啲咩？
Thariq 喺推文入面講咗一句說話，我覺得含金量好高：「一個 Skill 裏面信息密度最高嘅部分係坑點總結。」
因為 Claude 本身已經知道好多嘢。你寫一個 Skill 話畀佢知「呢個 SDK 嘅 init 方法接收三個參數」，好大機會佢已經知，呢類情報喺預訓練數據入面見過無數次。
但如果你話畀佢知：「我哋呢個審批流程，文檔標咗係可選，但實際上一定要做。唔做呢步，後面嘅權限審核會直接卡住。」——呢啲情報佢爆曬成個網絡都揾唔到。因為呢個根本係你哋自己定嘅規矩，唔喺任何公開文檔入面。
呢啲就係坑。呢啲就係高語境知識。
返轉頭睇我哋之前翻書嗰個案例，翻譯 Skill 裏面最有用嘅部分係咩？唔係「點樣 call LinguaGacha」呢啲流程說明，而係「50 併發會炸 API」，呢啲踩過先知嘅坑。
所以寫 Skill 之前，先問自己一個問題：呢度有幾多內容係 Claude 自己揾唔到嘅？
如果答案係大部分都揾到，咁呢個 Skill 嘅價值好大機會好有限。說明書係低語境知識，邊個都查到；Gotchas 係高語境知識，只有你自己最清楚。Skill 真正嘅價值，就係將後者由你個腦度拎出嚟，變成 AI 可以讀取嘅格式。
第二：Description 字段非常重要
淨係將經驗寫入去仲唔夠。一個 Skill 再有價值，如果佢唔能夠喺正確嘅場景被叫出嚟，效果都會打折。
呢個亦都係點解 Thariq 特別強調：description 字段非常重要。
好多人寫 Skill，花咗好多心機喺正文內容。流程寫得好詳細，步驟列得好清楚，參考文檔都有附上。但 description 字段求其寫一句「呢個係一個翻譯工具」就算數。
問題係，description 字段唔係畀人睇嘅摘要，係畀模型睇嘅觸發條件。Claude Code 啟動嘅時候，會掃描所有可用嘅 Skill，讀嘅就係呢個 ，然後根據用戶當前嘅請求，決定會唔會激活某個 Skill。
所以，Description 寫得好唔好，直接決定呢個 Skill 會唔會喺應該出現嘅時候出現。
你寫「呢個係一個翻譯工具」，模型見到用戶話「幫我翻譯呢篇文章」嘅時候可能會激活。但用戶話「將呢個英文 PDF 轉做中文」呢？話「呢篇論文可唔可以出個中文版」呢？
呢啲都係翻譯場景，但如果 description 寫得太窄，模型就配對唔到。
相反，如果 description 寫得太闊，例如「處理各種文本任務」，咁用戶隨便講句說話佢都可能走嚟搞亂檔。
好嘅 description 應該似一個精準嘅 if 條件：
當用戶需要翻譯英文文檔（PDF/DOCX/EPUB/網頁文章）做中文，包括學術論文、書籍、長文翻譯、術語密集型內容時觸發。唔適用於日常短句翻譯或口語化翻譯。
你睇，應該觸發嘅場景列清楚咗，唔應該觸發嘅場景都排除咗。
呢個細節睇落好細，但當你手上有十幾個 Skill 嘅時候，分別會好明顯：description 寫得好嘅 Skill，你提出需求佢就自動走嚟做嘢；寫得差嘅，你每次都要手動指定。
第三：等 Skill 自己記住上次做咗啲咩
不過，能夠喺啱嘅時候被觸發，仍然只係第一步。
一個助手真正開始「順手」，唔只係因為佢知道你哋點做嘢，仲因為佢記得上一次已經做到邊一步。
呢個亦係 Thariq 嗰條推入面我覺得最被低估嘅一點：Skill 可以有自己的記憶。
最簡單嘅做法：就係喺 Skill 目錄下面放一個日誌檔案，每次執行完就喺入面追加一條記錄。下次執行嘅時候，AI 先讀一次日誌，就知上次做咗啲咩。
複雜少少：放一個 JSON 檔案，記錄結構化數據。再複雜啲：放一個 SQLite 數據庫。
呢件事點解重要？因為好多傳統 AI 助手最令人躁底嘅問題就係：每次都好似第一次見你。你琴日叫佢寫過日報，今日佢又由零開始估你嘅格式。你上個禮拜叫佢行過一套數據分析，呢個禮拜佢又好似失憶咁問你「數據喺邊」。
有咗 Skill 內部記憶，情況就唔同咗。
Thariq 舉咗個例：一個 standup-post Skill，每日幫你寫站會日報。如果佢保留咗之前每日嘅日報內容，咁第二日佢運行嘅時候就唔只係「生成一份新日報」，而係能夠知道：今日同昨日相比，真正新增咗啲咩、有咩任務由「進行中」變咗「已完成」、有邊啲卡咗兩日都未鬱。
呢啲先係有用嘅日報，只係寫發生咗咩變化。
我哋自己做新聞選題系統嘅時候都有類似體會。如果選題 Skill 唔記得昨日推薦過啲咩，今日就有可能推薦一模一樣嘅選題。但如果佢讀到自己嘅歷史記錄，就會自動跳過已推薦嘅，只推新嘅。
呢種「記憶」唔需要好高級。一個 append-only 嘅文字檔案就夠。關鍵係要意識到：Skill 唔只係一次性嘅指令集，佢可以係一個有狀態嘅工作助手。
每次執行完，叫佢將關鍵信息寫入日誌。下次執行前，叫佢先讀日誌。就係咁簡單一個循環，效果天差地別。
第四：Skill 嘅威力唔係喺嗰份 markdown，而係成個文件夾
呢一條係我自己體會最深嘅。
你用過一段時間 Skill 就會發現，一份 markdown 寫得再好，能夠承載嘅嘢都有限。你冇辦法喺一段文字描述入面將一個查詢邏輯講清楚，亦冇辦法用文字精確定義一份報告應該係點樣。
Thariq 舉咗個例。假設你做數據分析，成日需要由公司嘅事件系統度拉數據。每次你都要話畀 AI 知：「先連呢個數據庫，用呢句查詢陳述式，然後按呢個格式輸出。」煩唔煩？煩。而且 AI 每次重新寫查詢，寫出嚟嘅仲未必啱。
但如果你將呢啲操作封裝成幾個 Python 函數，放喺 Skill 嘅 scripts/ 目錄下面。咁 AI 喺執行嘅時候就唔需要由頭寫查詢邏輯。佢只需要決定：先 call 邊個函數、傳啲咩參數、結果點組合。
等 Claude 將精力放喺決策上，而唔係重新發明輪子。
同樣道理，如果你嘅 Skill 最終輸出係一份特定格式嘅報告，你可以喺 assets/ 目錄下面放一個模板檔案。AI 見到模板，就知應該喺度填啲咩、格式係點。比你喺 markdown 用文字描述格式準確十倍。
仲有一種更高級嘅用法：放參考代碼。例如你哋團隊有一套代碼風格，淨係靠文字描述好難講清楚，但放三個寫得靚嘅檔案入去，AI 一睇就明。
呢個思路其實就係 Thariq 講嘅「漸進式上下文披露」。你唔需要將所有資訊塞入主提示詞，咁樣又長又亂。將詳細內容拆到唔同檔案，話畀 AI 知呢啲檔案喺邊、分別做乜。佢會喺需要嘅時候自己去讀。
用高低語境嘅框架嚟睇，呢個其實就係幫 AI 建立「共享背景」。
就好似一個成熟團隊唔會將所有規範寫入一封超級長嘅電郵。而係有文檔庫、有腳本、有模板、有 checklist。Skill 本質上就係將呢套嘢做成 AI 可以直接 call 嘅工作環境。
第五：但係得能力唔夠，仲要有邊界同護欄
不過，一個真正可用嘅工作環境，唔可以得能力，冇約束。
如果 scripts、模板、參考代碼解決嘅係「AI 做唔做到」，咁鈎子機制解決嘅就係「AI 會唔會亂嚟」。
Thariq 提到，Claude Code 嘅 Skill 可以註冊「on-demand hooks」，即係臨時鈎子。呢啲鈎子只係喺 Skill 被激活嘅時候生效，Skill 結束就自動關閉。
例如你有一個叫 /careful 嘅 Skill。激活之後，佢會掛一個 PreToolUse 鈎子，攔截所有危險操作：rm -rf、DROP TABLE、force-push、kubectl delete。你掂生產環境嘅時候開一開，佢就好似一個安全鎖，AI 想執行危險指令嘅時候就會被截住。平時唔開，唔影響正常運作。
再例如一個叫 /freeze 嘅 Skill。激活之後，AI 只可以編輯指定目錄下面嘅檔案，其他地方掂都唔畀掂。你喺偵錯嘅時候特別有用。你想加幾行 log，但唔想 AI 順便「修」咗其他檔案。開咗 /freeze，佢就只能夠喺你指定嘅範圍內活動。
呢個設計特別巧妙。因為大多數人寫 Skill 嘅思路係「話畀 AI 知應該做啲咩」。但臨時鈎子反過嚟，係「話畀 AI 知有啲嘢絕對唔可以做」。
前者係引導，後者係護欄。兩個都有，先算一個完整嘅工作環境。
諗下你帶一個新人。你唔只要話畀佢知「你嘅任務係咩」，仲要話畀佢知「呢幾部機千萬唔好掂」。Skill 加埋鈎子，就係做緊同一件事。
9 類 Skill，背後只有一個判斷標準
除咗呢啲實用技巧，Thariq 仲透露咗 Anthropic 內部管理 Skill 嘅方式。Thariq 仲分享到，Anthropic 內部將幾百個 Skill 歸成 9 類：
庫同 API 參考——教 AI 用你哋內部嘅 SDK 產品驗證——等 AI 自己測試自己寫嘅代碼 數據獲取與分析——連接你哋嘅數據同監控系統 業務流程自動化——將重複嘅團隊流程一鍵化 代碼腳手架——生成符合你哋規範嘅項目模板 代碼質量與審查——自動化 code review CI/CD 與部署——由構建到發佈到回滾 Runbook——由警報訊號到排查到出報告 基礎設施運維——清理、成本分析、依賴管理
類別好多，但最好嘅 Skill 都只係屬於一個類別。如果一個 Skill 又想教人，又想自動化，又想審查，最後通常做乜都做唔好。
背後其實只有一個判斷標準：呢個 Skill 到底係補「知識差」，定係補「執行差」。
補知識差嘅，重點寫坑、寫邊界、寫反例；補執行差嘅，重點畀腳本、畀驗證工具、畀自動化流程。搞清楚呢點，你就知自己嘅 Skill 入面應該寫咩、唔應該寫咩。
特別值得一提嘅係驗證類 Skill。Thariq 都着重重申一句話：如果驗證 Skill 做得好，值得一個工程師花一個星期時間專門打磨。
一個好嘅驗證 Skill 可能包括：瀏覽器自動化腳本、測試帳號、狀態斷言規則、甚至等 AI 錄一段操作影片方便你事後檢查。生成能力決定 AI 做到幾多嘢，驗證能力決定你敢唔敢畀佢做咁多嘢。分別就喺度。
Skill 商店已經開始出現，但質量戰先係重點
Thariq 仲透露咗 Anthropic 內部管理 Skill 嘅方式。
佢哋冇一個中央團隊嚟審批。而係等 Skill 自然生長。
你覺得好用，先放去 GitHub 嘅沙盒文件夾，喺 Slack 話畀同事知。有人用過覺得好，口碑傳開咗，再開 PR 進入正式嘅 Skill marketplace。
呢個模式好早期 App Store。先等數量爆發，再靠口碑同使用數據淘汰。
但 Thariq 都提咗一句警告：創建差劣或冗餘嘅 Skill 太容易。確保你有某種策展機制先上架。
呢個同我哋之前篇文章觀察到嘅一模一樣。SkillsMP 上面嘅 Skill 數量增長得好快，但質量參差。有啲 Skill 就係將官方文檔複製貼上，description 寫得含糊不清，根本用唔到。
數量先爆、質量後補、適者生存。呢條路 App Store 行過，小程序行過，而家 Skill 生態都係咁行。
佢哋內部仲用 PreToolUse 鈎子做咗使用統計，睇到邊啲 Skill 被 call 得最多、邊啲 Skill 觸發率低過預期。即係話 Skill 好壞唔再靠感覺判斷，而係有數據可以查。
對普通開發者嚟講，呢條信息嘅意義係：如果你做咗一個 Skill 放上 GitHub，人哋用唔用、好唔好用，將來係可以被量化嘅。呢個都代表，做 Skill 嘅門檻雖然低，但做好 Skill 嘅標準正在提高。
返到最初嘅問題：點解你嘅 Skill 唔好用？
將 Thariq 嘅經驗總結同高低語境嘅框架擺埋一齊，答案其實好清楚。
唔好用嘅 Skill，寫嘅係低語境信息。功能介紹、API 文檔、操作步驟。呢啲嘢模型本來就知，你寫多次佢都唔會做得更好。
真正令 Skill 好用嘅，係高語境信息：你哋團隊特有嘅坑、你哋自己嘅驗收標準、嗰啲「做耐咗就知」嘅默認規則、「呢個指令千祈唔好喺生產環境執行」之類嘅護欄。
呢啲嘢冇辦法由預訓練學到，冇辦法由官方文檔抄到，只有你自己最清楚。
Claude Code 之所以會令人覺得越用越順手，就係因為 Skill 開始承載越來越多團隊自己嘅語境、經驗、工具同邊界。
所以寫 Skill 嘅正確順序應該係：
第一步，唔好急住寫說明書。先列出你哋團隊喺呢類任務上踩過嘅 10 個最大嘅坑，寫入 Gotchas。
第二步，將 description 當觸發條件嚟寫，而唔係當簡介。諗清楚呢個 Skill 應該喺咩場景下被自動叫出嚟，咩場景下唔應該出現。
第三步，畀腳本、畀模板、畀參考代碼，而唔係淨係畀文字。等 AI 將精力放喺判斷同組合上，而唔係重新發明輪子。
第四步，加記憶。哪怕只係一個日誌檔案，等 Skill 知道上次做咗咩，今次應該做啲咩唔同嘅。
第五步，加護欄。唔只話畀 AI 知應該做咩，仲要話畀佢知有啲嘢絕對唔可以做。
呢五步做完，你嘅 Skill 就係一個有知識、有工具、有記憶、有邊界嘅工作環境。
講到尾，你喺做緊嘅事，係將你個腦入面嗰啲高語境嘅、只可意會嘅工作經驗，翻譯成一種 AI 接得住嘅格式。
模型決定 AI 可以諗幾遠。Skill 決定 AI 可以做幾穩。而 Skill 嘅質量，取決於你入面裝咗幾多隻有你先知嘅嘢。
上個月我寫過一篇 Skill 的實測文章，從翻譯兩本書的實戰出發，講了“做完打包”這件事有多重要。
但依舊有小夥伴反饋，“我寫出來的 Skill 就是不好使”。
說實話，這個問題我自己也遇到過。有的 Skill 寫完就是越用越順，有的怎麼調都差點意思，一直說不上來到底差在哪。
3 月 18 日，Anthropic 工程師 Thariq 發了一條長推，標題就叫_《Lessons from Building Claude Code: How We Use Skills》_。他們內部已經有數百個 Skill 在活躍使用，踩過的坑和總結出來的經驗，終於公開講了一次。
我看完之後有一個很大的觸動。不是某個具體技巧，而是讓我意識到，大部分寫 Skill 的時候，寫進去的東西壓根就不是 AI 需要你告訴它的。
Skill 補的不是說明書，是語境
在講 Thariq 的五條經驗之前，先說一個看似無關但其實特別重要的事。
你有沒有想過，傳統編程其實是一種非常極端的溝通方式？你必須把輸入、輸出、參數、條件、流程全部寫清楚，少寫一個分號程序都會崩。計算機不猜你的意思，你說什麼它做什麼，一個字都不能省。
但我們人和人之間在團隊裏幹活，完全不是這樣的。老工程師會跟你說：這個接口不是不能用，但線上最好別這麼調。產品經理會說：這個需求文檔寫的是 A，但老闆真正想要的是 B。
這些話你在任何文檔裏都找不到。它們只存在於經驗、默契、口頭傳授，和一堆做久了就知道的判斷裏。
學術上有個說法叫“高語境溝通”。Edward T. Hall 在上世紀提出的框架：低語境溝通依賴字面信息，高語境溝通依賴共享背景、默認規則和隱含共識。你跟一個合作了三年的同事說老規矩處理一下，他立刻知道該怎麼做。但你跟一個新來的實習生說同樣的話，他會一臉懵。
你現在調教的 Skill，就是那個實習生。
API 文檔、代碼示例、技術教程，這些寫得明明白白的東西它都知道，甚至比你記得還清楚。但一旦進入真實工作流，卡住它的恰恰是那些高語境信息：你們團隊真正的驗收標準是什麼、哪個圖表才是組織裏公認的“準口徑”、哪些步驟文檔上沒寫但必須額外核驗。
所以很多 Skill 之所以不好用，是因為大家寫進去的，仍然是模型本來就知道的東西，本質上等於又餵了它一份已經吃過的飯。那些低語境的、寫在明面上的知識，模型原本就會。你多說一遍，它也未必做得更好。
第一：Anthropic 內部最看重的，是“坑”
那應該寫什麼？
Thariq 在推文裏說了一句話，我覺得含金量很高：“一個 Skill 裏信息密度最高的部分是坑點總結。”
因為 Claude 本身已經知道很多東西了。你寫一個 Skill 告訴它“這個 SDK 的 init 方法接收三個參數”，大概率它已經知道了，這種信息它在預訓練數據裏見過無數遍。
但如果你告訴它：“我們這個審批流程，文檔裏標的是可選，但實際上必須走。不走這一步，後面的權限審核會直接卡住。”——這種信息它查遍全網也查不到。因為這根本就是你們自己定的規矩，不在任何公開文檔裏。
這就是坑。這就是高語境知識。
回頭看我們之前翻書那個案例，翻譯 Skill 裏最有用的部分是什麼？不是“怎麼調用 LinguaGacha”這種流程說明，而是“50 併發會炸 API”，這些踩過之後才知道的坑。
所以寫 Skill 之前，先問自己一個問題：這裏面有多少內容是 Claude 自己搜不到的？
如果答案是大部分都搜得到，那這個 Skill 的價值大概率就很有限。說明書是低語境知識，誰都能查到；Gotchas 是高語境知識，只有你自己最清楚。Skill 真正的價值，就是把後者從你腦子裏掏出來，變成 AI 能讀取的格式。
第二：Description 字段非常重要
只把經驗寫進去還不夠。一個 Skill 再有價值，如果它不能在正確的場景裏被調出來，效果還是會打折。
這也是為什麼 Thariq 特別強調：description 字段非常重要。
很多人寫 Skill，花了很多心思在正文內容上。流程寫得很詳細，步驟列得很清楚，參考文檔也附上了。但 description 字段隨手寫了一句“這是一個翻譯工具”就完事了。
問題是，description 字段不是給人看的摘要，是給模型看的觸發條件。Claude Code 啓動的時候，會掃描所有可用的 Skill，讀的就是這個 ，然後根據用戶當前的請求，判斷要不要激活某個 Skill。
所以，Description 寫得好不好，直接決定了這個 Skill 會不會在該出現的時候出現。
你寫“這是一個翻譯工具”，模型看到用戶說“幫我翻譯這篇文章”的時候可能會激活。但用戶說“把這個英文 PDF 轉成中文”呢？說“這個論文能不能出個中文版”呢？
這些都是翻譯場景，但如果 description 寫得太窄，模型就匹配不上。
反過來，如果 description 寫得太寬，比如“處理各種文本任務”，那用戶隨便說句話它都可能跳出來搗亂。
好的 description 應該像一個精準的 if 條件：
當用戶需要翻譯英文文檔（PDF/DOCX/EPUB/網頁文章）為中文，包括學術論文、書籍、長文翻譯、術語密集型內容時觸發。不適用於日常短句翻譯或口語化翻譯。
你看，該觸發的場景列清楚了，不該觸發的場景也排除了。
這個細節看起來小，但當你手上有十幾個 Skill 的時候，差別會非常明顯：description 寫得好的 Skill，你提需求它就自動出來幹活；寫得差的，你每次都得手動指定。
第三：讓 Skill 自己記住上次幹了什麼
不過，能在對的時候被觸發，仍然只是第一步。
一個助手真正開始“順手”，不只是因為它知道你們怎麼做事，還因為它記得上一次已經做到哪一步。
這也是 Thariq 那條推裏我覺得最被低估的一點：Skill 可以有自己的記憶。
最簡單的做法：就是在 Skill 目錄下放一個日誌文件，每次執行完往裏面追加一條記錄。下次執行的時候，AI 先讀一遍日誌，就知道上次做了什麼。
複雜一點：放一個 JSON 文件，記錄結構化數據。再複雜一點：放一個 SQLite 數據庫。
這件事為什麼重要？因為很多傳統 AI 助手最讓人抓狂的問題就是：每次都像第一次見你。你昨天讓它寫過日報，今天它又從零開始猜你的格式。你上週讓它跑過一套數據分析，這周它又像失憶了一樣問你“數據在哪”。
有了 Skill 內記憶，情況就變了。
Thariq 舉了個例子：一個 standup-post Skill，每天幫你寫站會日報。如果它保留了之前每天的日報內容，那第二天它運行的時候就不只是“生成一份新日報”，而是能知道：今天和昨天相比，真正新增了什麼、哪些任務從“進行中”變成了“已完成”、哪些卡了兩天還沒動。
這才是有用的日報，只寫發生了什麼變化。
我們自己做新聞選題系統的時候也有類似體會。如果選題 Skill 不記得昨天推薦過什麼，今天就可能推薦一模一樣的選題。但如果它能讀到自己的歷史記錄，就會自動跳過已推薦的，只推新的。
這種“記憶”不需要多高級。一個 append-only 的文本文件就夠了。關鍵是意識到：Skill 不只是一次性的指令集，它可以是一個有狀態的工作助手。
每次執行完，讓它把關鍵信息寫進日誌。下次執行前，讓它先讀日誌。就這麼簡單的一個循環，效果天差地別。
第四：Skill 的威力不在那份 markdown，在於整個文件夾
這一條是我自己體會最深的。
你用過一段時間 Skill 就會發現，一份 markdown 寫得再好，能承載的東西也有限。你沒法在一段文字描述裏把一個查詢邏輯說清楚，也沒法用文字精確定義一份報告該長什麼樣。
Thariq 舉了個例子。假設你做數據分析，經常需要從公司的事件系統里拉數據。每次你都要告訴 AI：“先連這個數據庫，用這個查詢語句，然後按這個格式輸出。”累不累？累。而且 AI 每次重新寫查詢，寫出來的還不一定對。
但如果你把這些操作封裝成幾個 Python 函數，放在 Skill 的 scripts/ 目錄下。那 AI 在執行的時候就不需要從頭寫查詢邏輯了。它只需要決定：先調哪個函數、傳什麼參數、結果怎麼組合。
讓 Claude 把精力花在決策上，而不是重建輪子上。
同樣的道理，如果你的 Skill 最終輸出是一份特定格式的報告，你可以在 assets/ 目錄下放一個模板文件。AI 看到模板，就知道該往裏填什麼、格式長什麼樣。比你在 markdown 裏用文字描述格式要準確十倍。
還有一種更高級的用法：放參考代碼。比如你們團隊有一套代碼風格，光靠文字描述很難說清楚，但放三個寫得好的文件進去，AI 一看就懂。
這個思路其實就是 Thariq 說的“漸進式上下文披露”。你不需要把所有信息都塞進主提示詞裏，那樣又長又亂。把詳細內容拆到不同文件裏，告訴 AI 這些文件在哪、分別是幹什麼的。它會在需要的時候自己去讀。
用高低語境的框架來看，這其實就是在幫 AI 建立“共享背景”。
就像一個成熟團隊不會把所有規範寫進一封超級長的郵件裏。而是有文檔庫、有腳本、有模板、有 checklist。Skill 本質上就是把這套東西做成 AI 能直接調用的工作環境。
第五：但只有能力還不夠，還要有邊界和護欄
不過，一個真正可用的工作環境，不能只有能力，沒有約束。
如果 scripts、模板、參考代碼解決的是“AI 能不能做”，那鈎子機制解決的就是“AI 會不會亂做”。
Thariq 提到，Claude Code 的 Skill 可以註冊“on-demand hooks”，也就是臨時鈎子。這些鈎子只在 Skill 被激活的時候生效，Skill 結束就自動關閉。
比如你有一個叫 /careful 的 Skill。激活之後，它會掛一個 PreToolUse 鈎子，攔截所有危險操作：rm -rf、DROP TABLE、force-push、kubectl delete。你碰生產環境的時候開一下，它就像一個安全鎖，AI 想執行危險命令的時候會被攔住。平時不開，不影響正常工作。
再比如一個叫 /freeze 的 Skill。激活之後，AI 只能編輯指定目錄下的文件，其他地方碰都不讓碰。你在調試的時候特別有用。你想加幾行 log，但不想 AI 順手"修"了別的文件。開了 /freeze，它就只能在你指定的範圍內活動。
這個設計特別巧妙。因為大多數人寫 Skill 的思路是“告訴 AI 該做什麼”。但臨時鈎子反過來，是“告訴 AI 什麼絕對不能做”。
前者是引導，後者是護欄。兩個都有，才算一個完整的工作環境。
想想你帶一個新人。你不光要告訴他“你的任務是什麼”，還要告訴他“這幾台機器千萬別碰”。Skill 加上鈎子，就是在做同樣的事情。
9 類 Skill，背後只有一個判斷標準
除了這些實用技巧，Thariq 還透露了 Anthropic 內部管理 Skill 的方式。Thariq 還分享到，Anthropic 內部把幾百個 Skill 歸成了 9 類：
庫和 API 參考——教 AI 用你們內部的 SDK 產品驗證——讓 AI 自己測試自己寫的代碼 數據獲取與分析——連接你們的數據和監控系統 業務流程自動化——把重複的團隊流程一鍵化 代碼腳手架——生成符合你們規範的項目模板 代碼質量與審查——自動化 code review CI/CD 與部署——從構建到發佈到回滾 Runbook——從報警信號到排查到出報告 基礎設施運維——清理、成本分析、依賴管理
類別很多，但最好的 Skill 都只落在一個類別裏。如果一個 Skill 既想當教程，又想當自動化工具，還想當審查員，最後往往什麼都做不好。
背後其實只有一個判斷標準：這個 Skill 到底是在補“知識差”，還是在補“執行差”。
補知識差的，重點寫坑、寫邊界、寫反例；補執行差的，重點給腳本、給驗證工具、給自動化流程。搞清楚這一點，你就知道自己的 Skill 裏該寫什麼、不該寫什麼。
特別值得一提的是驗證類 Skill。Thariq 也着重強調了一句話：如果驗證 Skill 做得好，值得一個工程師花一週時間專門打磨。
一個好的驗證 Skill 可能包括：瀏覽器自動化腳本、測試賬號、狀態斷言規則、甚至讓 AI 錄一段操作視頻以便你事後檢查。生成能力決定 AI 能做多少事，驗證能力決定你敢讓它做多少事。差距就在這。
Skill 商店已經開始出現了，但質量戰才是重點
Thariq 還透露了 Anthropic 內部管理 Skill 的方式。
他們沒有一箇中央團隊來審批。而是讓 Skill 自然生長。
你覺得好用，先放到 GitHub 的沙盒文件夾裏，在 Slack 裏告訴同事。有人用了覺得好，口碑傳開了，再提 PR 進入正式的 Skill marketplace。
這個模式特別像早期 App Store。先讓數量爆發，再靠口碑和使用數據做淘汰。
但 Thariq 也提了一句警告：創建糟糕或冗餘的 Skill 太容易了。確保你有某種策展機制再上架。
這跟我們之前文章裏觀察到的一模一樣。SkillsMP 上的 Skill 數量增長很快，但質量參差不齊。有些 Skill 就是把官方文檔複製粘貼進去，description 寫得模糊不清，根本不可用。
數量先爆、質量後補、優勝劣汰。這條路 App Store 走過，小程序走過，現在 Skill 生態也在走。
他們內部還用 PreToolUse 鈎子做了使用統計，能看到哪些 Skill 被調用得最多、哪些 Skill 觸發率低於預期。這意味着 Skill 的好壞不再靠感覺判斷，而是有數據可查。
對普通開發者來說，這條信息的意義是：如果你做了一個 Skill 放到 GitHub 上，別人用不用、好不好用，將來是可以被量化的。這也意味着，做 Skill 的門檻雖然低，但做好 Skill 的標準正在變高。
回到最初的問題：為什麼你的 Skill 不好使？
把 Thariq 的經驗總結和高低語境的框架放在一起，答案其實很清楚了。
不好用的 Skill，寫的是低語境信息。功能介紹、API 文檔、操作步驟。這些東西模型本來就知道，你多寫一遍它也不會做得更好。
真正讓 Skill 好使的，是高語境信息：你們團隊特有的坑、你們自己的驗收標準、那些“做久了就知道”的默認規則、“這個命令千萬別在生產環境跑”之類的護欄。
這些東西沒法從預訓練裏學到，沒法從官方文檔裏抄到，只有你自己最清楚。
Claude Code 之所以會讓人覺得越用越順手，就是因為 Skill 開始承載越來越多團隊自己的語境、經驗、工具和邊界。
所以寫 Skill 的正確順序應該是：
第一步，別急着寫說明書。先列出你們團隊在這類任務上踩過的 10 個最大的坑，寫進 Gotchas。
第二步，把 description 當觸發條件寫，而不是當簡介寫。想清楚這個 Skill 該在什麼場景下被自動調出來，什麼場景下不該出現。
第三步，給腳本、給模板、給參考代碼，而不只是給文字。讓 AI 把精力花在判斷和組合上，而不是花在重建輪子上。
第四步，加記憶。哪怕只是一個日誌文件，讓 Skill 知道上次做了什麼，這次該做什麼不一樣的。
第五步，加護欄。不光告訴 AI 該做什麼，還要告訴它什麼絕對不能做。
這五步做完，你的 Skill 就是一個有知識、有工具、有記憶、有邊界的工作環境。
說白了，你在做的事情，是把你腦子裏那些高語境的、只可意會的工作經驗，翻譯成一種 AI 能接住的格式。
模型決定 AI 能想多遠。Skill 決定 AI 能幹多穩。而 Skill 的質量，取決於你往裏面裝了多少隻有你才知道的東西。