我所有的 skills 都是與 Agent 溝通清楚需求之后由 Anthropic 的 skill-creator 創(chuàng)建的

最近 anthropic 官方更新了skill-creator模板

https://github.com/anthropics/skills/tree/main/skills/skill-creator

這兩天我重新刷了一遍 Anthropic 的 Skills 相關(guān)文檔（居然有中文版），明顯感覺：Skills 不再只是一個小功能，而是在被當成 Claude 的核心能力層來建設。

https://code.claude.com/docs/

Anthropic 還有一個公開課，可以說把 Agent 相關(guān)內(nèi)容事無巨細將透徹了（本身很多 AI Agent 概念就是 A 社發(fā)明的），市面上沒有比這個更好的素材了

https://anthropic.skilljar.com/

我先把結(jié)論放前面：

1. Anthropic 已經(jīng)把 Skills 講得越來越"工程化"了，不再停留在概念層。

2. GitHub 上的官方skill-creator模板，也已經(jīng)從"教你怎么寫"升級成"教你怎么評測、迭代、優(yōu)化觸發(fā)效果"。

3. 如果你正在做個人工作流、團隊知識沉淀、或者 Agent 自動化，現(xiàn)在就是認真做 Skills 的好時機。

做了一下測試，我常用的文章核心內(nèi)容設計成高密度 svg 的 skills，本來也在逐步優(yōu)化，但是依然不穩(wěn)定，時常頁面顯示有 bug

然后我讓最新的 skill-creator 重新設計了這個 svg skills

同樣輸入，得到的結(jié)果就改善不少

真誠建議：你的所有 Skills 都需要重新做一遍！至少我會逐步全部優(yōu)化一遍

前面推薦的材料，如果你時間不多，我建議按這個順序看：

1. 官方集合頁：Features and capabilities

這是我這次最想推薦的入口頁，集合頁里已經(jīng)收錄了26 篇能力說明文章，里面不光有 Skills，還有 Artifacts、Web Search、Research、Projects、Memory、Cowork、Excel、PowerPoint 等等。

最關(guān)鍵的是，這個集合頁已經(jīng)明確提供了簡體中文入口 https://support.claude.com/zh-CN/collections/18031719-%E5%8A%9F%E8%83%BD%E4%B8%8E%E8%83%BD%E5%8A%9B

尤其不能錯過這一篇：：如何創(chuàng)建自定義技能

2.公開課

https://anthropic.skilljar.com/

看前幾個就行了

3. GitHub 官方 skill-creator（重點推薦?。?br/>

這個版本給我的最大感受是：

Anthropic 已經(jīng)默認你做 Skill，不是一次性寫完，而是要反復迭代。

它里面強調(diào)的流程非常像正經(jīng)產(chǎn)品開發(fā)：

1. 先定義 Skill 想解決什么問題

2. 再寫草稿

3. 準備測試 prompt

4. 跑"帶 Skill"和"不帶 Skill"的基線對比

5. 看結(jié)果、做評估

6. 改描述、改內(nèi)容、繼續(xù)迭代

7. 最后還要做Description 觸發(fā)優(yōu)化

skill-creator 里最讓我震撼的是它的評測體系。

不是讓你"看看感覺對不對"，而是一套非常工程化的系統(tǒng)：

第一步：基線對比（A/B Test）

對每一個測試用例，同時跑兩個版本：

• With-skill：帶著你的 Skill 執(zhí)行

• Without-skill（或舊版 Skill）：不用 / 用舊版執(zhí)行

兩組任務同時起跑（用 subagent 并行），結(jié)果分別存進with_skill/和without_skill/目錄。

這是真正的 A/B Test 思維——不是"我覺得好了"，而是"有沒有帶來可量化的提升"。

第二步：量化斷言（Assertions）

在測試跑著的同時，給每個用例寫量化斷言——這些斷言是可編程驗證的。比如：

• 輸出文件里是否包含目錄結(jié)構(gòu)

• 圖表是否有坐標軸標簽

• 格式是否符合模板

好的斷言有兩個特點：客觀可驗證+描述性命名（一眼能看懂在檢查什么）。

對于那些主觀性強的維度（寫作風格、設計美感），skill-creator 明確說了：不要硬塞斷言，用人工評審。

第三步：Eval Viewer 可視化評審

skill-creator 自帶了一個瀏覽器評審工具（eval-viewer/generate_review.py），打開后有兩個標簽頁：

• Outputs 標簽：逐個展示測試用例的輸入和輸出，你可以直接在里面寫反饋

• Benchmark 標簽：展示量化數(shù)據(jù)——通過率、用時、Token 消耗，帶均值和標準差

迭代到第二輪以后，還能看到和上一輪的對比。

這套評審界面做得真的很用心。Anthropic 在 SKILL.md 里反復強調(diào)（甚至用了大寫字母強調(diào)）：一定要先讓人看結(jié)果，再改 Skill！

第四步：迭代改進

讀完用戶反饋后，改 Skill，重新跑所有測試用例到新的iteration-N/目錄，再次評審。循環(huán)往復，直到：

• 用戶滿意

• 反饋全部為空

• 改進幅度不再明顯

skill-creator 甚至還提供了盲評機制——把兩個版本的輸出交給一個獨立的 Agent，不告訴它哪個是新版、哪個是舊版，讓它獨立判斷哪個更好。

然后再用analyzerAgent 分析贏的那個為什么贏。

這是不是很像學術(shù)論文里的"雙盲評審"？

Anthropic 把這套方法論塞進了一個 Skill 的創(chuàng)建工具里，格局之大，可見他們對 Skills 生態(tài)的重視程度。

核心：Description 觸發(fā)優(yōu)化

這可能是 skill-creator 里價值最高的一個功能。

它的原理是：

1. 生成 20 條測試查詢——一半應該觸發(fā) Skill，一半不應該觸發(fā)

2. 這些查詢不是"讀取 PDF"這種簡單的，而是模擬真實用戶的具體描述（帶文件名、帶背景、帶口語化表達、甚至帶錯別字）

3. 60/40 拆分：60% 用于訓練，40% 用于驗證（防過擬合）

4. 每條查詢跑 3 次取穩(wěn)定觸發(fā)率

5. Claude 根據(jù)觸發(fā)失敗的 case 提出 description 改進建議

6. 重新評估新 description，最多迭代 5 輪

7. 最終按驗證集分數(shù)（不是訓練集）選出最佳 description

這整個流程和機器學習的超參數(shù)調(diào)優(yōu)一模一樣。

迭代改進的四條心法

skill-creator 里還給出了改進 Skill 時的思維方式，非常值得分享：

1. 從反饋中泛化：你只在幾個測試用例上迭代，但 Skill 未來要用無數(shù)次。不要過擬合到特定例子上，不要寫死板的 MUST/NEVER，而是用不同思路去解決頑固問題

2. 保持 Skill 精簡：去掉沒起作用的部分，讀測試過程的完整日志（不只看最終輸出），看看 Skill 有沒有讓 Claude 做了很多無用功

3. **解釋"為什么"**：不要只告訴 Claude "必須這樣做"，而是解釋為什么要這樣做。今天的 LLM 很聰明，理解了 why 比記住 what 更有效

4. 發(fā)現(xiàn)重復模式：如果多個測試用例中 Claude 都獨立寫了類似的輔助腳本，那就說明這個腳本應該被打包進 Skill 的scripts/目錄，省得每次重新發(fā)明輪子

但這次官方文檔反復在強調(diào)一個更準確的視角：

Skill 是把你的流程、標準、語氣、工具使用方式，封裝成 Claude 在合適時機主動調(diào)用的能力。

這里最重要的不是"內(nèi)容多不多"，而是兩個字：

觸發(fā)。

官方文檔這次明確強調(diào)，description不是裝飾字段，而是 Claude 判斷"什么時候該用這個 Skill"的核心依據(jù)。

GitHub 上的skill-creator甚至直接建議：描述要寫得更明確、更主動一點，避免 Skill 該觸發(fā)的時候不觸發(fā)。并且它還給出了一套完整的Description 優(yōu)化流程——自動生成測試查詢、拆分訓練集和驗證集、跑 3 次取穩(wěn)定觸發(fā)率、迭代 5 輪找最優(yōu) description，這和機器學習調(diào)參一個思路。

這個細節(jié)非常關(guān)鍵。

因為現(xiàn)實里最好用的 Skill，往往不是寫得最長的那個，而是觸發(fā)最準的那個。

skill-creator 還揭示了一個很多人不知道的觸發(fā)機制：Claude 對簡單任務不會觸發(fā) Skill。如果它自己就能處理（比如"讀這個 PDF"），它不會去查 Skill。只有復雜的、多步驟的任務才會激活觸發(fā)邏輯。這意味著你測試 Skill 的時候，用過于簡單的 prompt 是測不出來的。

2. 官方開始鼓勵"小而專"的 Skill 設計

幫助中心里有一句我很認同，大意是：

不要把所有東西都塞進一個大 Skill 里，多個聚焦的小 Skill，組合起來反而更強。

這個思路和寫程序很像。

函數(shù)越單一，越容易復用，越容易測，越不容易崩。

Skill 也是一樣。

比如你可以拆成：

• 一個負責"技術(shù)文章撰寫"

• 一個負責"PDF 翻譯"

• 一個負責"本地視頻轉(zhuǎn)錄"

• 一個負責"Obsidian 筆記歸檔"

這些 Skill 單獨看都不復雜，但一旦 Claude 能根據(jù)場景自動組合，威力就很大。

3. 安全被提到了正式位置

這次官方文檔還專門單獨列了安全注意事項。

比如：

• 不要把 API Key、密碼之類敏感信息硬編碼到 Skill 里

• 下載別人的 Skill 之前先審查內(nèi)容

• 如果要訪問外部服務，優(yōu)先走合適的 MCP 連接

比如這些就很適合：

• 根據(jù)幾個固定鏈接寫技術(shù)文章

• 固定格式總結(jié)會議紀要

• 讀取 Obsidian 某類筆記并輸出周報

• 把一份 PDF 翻成中文并保留版式

• 根據(jù)一篇文章生成短視頻口播稿

這些任務有一個共同點：

步驟清楚，產(chǎn)出穩(wěn)定，重復率高。

這類任務最值得先做成 Skill。

第二步：先把觸發(fā)描述寫對

這是很多人最容易忽略的地方。

一個好 Skill 的描述，至少要說清楚三件事：

1. 它解決什么問題

2. 用戶在什么語境下提到它時應該觸發(fā)

3. 最終輸出大概是什么

如果這三點寫不清楚，Claude 很可能就"知道有這個 Skill，但就是不用"。

第三步：資源外置，不要把所有東西都堆在 SKILL.md 里

官方現(xiàn)在推薦的結(jié)構(gòu)已經(jīng)很清楚了：

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

這個結(jié)構(gòu)的好處非常直接：

• SKILL.md負責規(guī)則和入口

• scripts/負責確定性執(zhí)行

• references/負責大塊知識

• assets/負責模板和素材

說白了，就是讓 Skill 既能"會說"，也能"會干活"。

第四步：一定要做基線對比

這點是 GitHub 官方skill-creator給我的最大啟發(fā)。

很多人做完 Skill，你至少要看兩件事：

1. 帶 Skill 和不帶 Skill，輸出到底差了什么

2. Skill 觸發(fā)率、穩(wěn)定性、結(jié)構(gòu)一致性有沒有提升

如果沒有明顯提升，那這個 Skill 可能只是讓你心理安慰更強了，并沒有真正提升生產(chǎn)力。

具體怎么做？skill-creator 給出了一套可操作的方法：

• 準備 2-3 個真實場景的 prompt——不是"幫我寫個報告"這種籠統(tǒng)的，而是帶有具體背景、具體文件、具體要求的

• 同時執(zhí)行帶 Skill 和不帶 Skill 的兩組任務

• 寫量化斷言：輸出里是否包含某個結(jié)構(gòu)、格式是否一致、關(guān)鍵信息有沒有遺漏

• 用 eval viewer 可視化對比：通過率、Token 用量、耗時一目了然

• 記錄每一輪迭代：存到iteration-1/、iteration-2/目錄，跟蹤改進趨勢

聽起來麻煩？其實不用自己折騰。直接在 Claude Code 里用 skill-creator，它會自動幫你跑完這一套。

最后一句

我越來越覺得，2026 年做 AI 提效，真正的分水嶺已經(jīng)不是"會不會寫 Prompt"了。

而是你有沒有能力把自己的工作流，沉淀成一套可以復用、可以組合、可以迭代的 Skills。

Prompt 是一次性的。

Skill 才是資產(chǎn)。

skill-creator 的 SKILL.md 里有一句話讓我印象很深：

This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over.

"思考時間不是瓶頸，認真想清楚才是關(guān)鍵。"

這句話不只是說給創(chuàng)建 Skill 的 Claude 聽的，也是說給我們每一個用 AI 的人聽的。

制作不易，如果這篇文章覺得對你有用，可否點個關(guān)注。給我個三連擊：點贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！