請(qǐng)立刻升級(jí)你的所有Skills

我所有的 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 不再只是一個(gè)小功能，而是在被當(dāng)成 Claude 的核心能力層來建設(shè)。

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

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

https://anthropic.skilljar.com/

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

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

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

3. 如果你正在做個(gè)人工作流、團(tuán)隊(duì)知識(shí)沉淀、或者 Agent 自動(dòng)化，現(xiàn)在就是認(rèn)真做 Skills 的好時(shí)機(jī)。

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

然后我讓最新的 skill-creator 重新設(shè)計(jì)了這個(gè) svg skills

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

真誠(chéng)建議：你的所有 Skills 都需要重新做一遍！至少我會(huì)逐步全部?jī)?yōu)化一遍

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

1. 官方集合頁(yè)：Features and capabilities

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

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

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

2.公開課

https://anthropic.skilljar.com/

看前幾個(gè)就行了

3. GitHub 官方 skill-creator（重點(diǎn)推薦！）

這個(gè)版本給我的最大感受是：

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

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

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

2. 再寫草稿

3. 準(zhǔn)備測(cè)試 prompt

4. 跑"帶 Skill"和"不帶 Skill"的基線對(duì)比

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

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

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

skill-creator 里最讓我震撼的是它的評(píng)測(cè)體系。

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

第一步：基線對(duì)比（A/B Test）

對(duì)每一個(gè)測(cè)試用例，同時(shí)跑兩個(gè)版本：

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

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

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

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

第二步：量化斷言（Assertions）

在測(cè)試跑著的同時(shí)，給每個(gè)用例寫量化斷言——這些斷言是可編程驗(yàn)證的。比如：

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

• 圖表是否有坐標(biāo)軸標(biāo)簽

• 格式是否符合模板

好的斷言有兩個(gè)特點(diǎn)：客觀可驗(yàn)證+描述性命名（一眼能看懂在檢查什么）。

對(duì)于那些主觀性強(qiáng)的維度（寫作風(fēng)格、設(shè)計(jì)美感），skill-creator 明確說了：不要硬塞斷言，用人工評(píng)審。

第三步：Eval Viewer 可視化評(píng)審

skill-creator 自帶了一個(gè)瀏覽器評(píng)審工具（eval-viewer/generate_review.py），打開后有兩個(gè)標(biāo)簽頁(yè)：

• Outputs 標(biāo)簽：逐個(gè)展示測(cè)試用例的輸入和輸出，你可以直接在里面寫反饋

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

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

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

第四步：迭代改進(jìn)

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

• 用戶滿意

• 反饋全部為空

• 改進(jìn)幅度不再明顯

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

然后再用analyzerAgent 分析贏的那個(gè)為什么贏。

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

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

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

這可能是 skill-creator 里價(jià)值最高的一個(gè)功能。

它的原理是：

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

2. 這些查詢不是"讀取 PDF"這種簡(jiǎn)單的，而是模擬真實(shí)用戶的具體描述（帶文件名、帶背景、帶口語(yǔ)化表達(dá)、甚至帶錯(cuò)別字）

3. 60/40 拆分：60% 用于訓(xùn)練，40% 用于驗(yàn)證（防過擬合）

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

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

6. 重新評(píng)估新 description，最多迭代 5 輪

7. 最終按驗(yàn)證集分?jǐn)?shù)（不是訓(xùn)練集）選出最佳 description

這整個(gè)流程和機(jī)器學(xué)習(xí)的超參數(shù)調(diào)優(yōu)一模一樣。

迭代改進(jìn)的四條心法

skill-creator 里還給出了改進(jìn) Skill 時(shí)的思維方式，非常值得分享：

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

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

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

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

但這次官方文檔反復(fù)在強(qiáng)調(diào)一個(gè)更準(zhǔn)確的視角：

Skill 是把你的流程、標(biāo)準(zhǔn)、語(yǔ)氣、工具使用方式，封裝成 Claude 在合適時(shí)機(jī)主動(dòng)調(diào)用的能力。

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

觸發(fā)。

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

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

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

因?yàn)楝F(xiàn)實(shí)里最好用的 Skill，往往不是寫得最長(zhǎng)的那個(gè)，而是觸發(fā)最準(zhǔn)的那個(gè)。

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

2. 官方開始鼓勵(lì)"小而專"的 Skill 設(shè)計(jì)

幫助中心里有一句我很認(rèn)同，大意是：

不要把所有東西都塞進(jìn)一個(gè)大 Skill 里，多個(gè)聚焦的小 Skill，組合起來反而更強(qiáng)。

這個(gè)思路和寫程序很像。

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

Skill 也是一樣。

比如你可以拆成：

• 一個(gè)負(fù)責(zé)"技術(shù)文章撰寫"

• 一個(gè)負(fù)責(zé)"PDF 翻譯"

• 一個(gè)負(fù)責(zé)"本地視頻轉(zhuǎn)錄"

• 一個(gè)負(fù)責(zé)"Obsidian 筆記歸檔"

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

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

這次官方文檔還專門單獨(dú)列了安全注意事項(xiàng)。

比如：

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

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

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

比如這些就很適合：

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

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

• 讀取 Obsidian 某類筆記并輸出周報(bào)

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

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

這些任務(wù)有一個(gè)共同點(diǎn)：

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

這類任務(wù)最值得先做成 Skill。

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

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

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

1. 它解決什么問題

2. 用戶在什么語(yǔ)境下提到它時(shí)應(yīng)該觸發(fā)

3. 最終輸出大概是什么

如果這三點(diǎn)寫不清楚，Claude 很可能就"知道有這個(gè) Skill，但就是不用"。

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

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

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

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

• SKILL.md負(fù)責(zé)規(guī)則和入口

• scripts/負(fù)責(zé)確定性執(zhí)行

• references/負(fù)責(zé)大塊知識(shí)

• assets/負(fù)責(zé)模板和素材

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

第四步：一定要做基線對(duì)比

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

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

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

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

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

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

• 準(zhǔn)備 2-3 個(gè)真實(shí)場(chǎng)景的 prompt——不是"幫我寫個(gè)報(bào)告"這種籠統(tǒng)的，而是帶有具體背景、具體文件、具體要求的

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

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

• 用 eval viewer 可視化對(duì)比：通過率、Token 用量、耗時(shí)一目了然

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

聽起來麻煩？其實(shí)不用自己折騰。直接在 Claude Code 里用 skill-creator，它會(huì)自動(dòng)幫你跑完這一套。

最后一句

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

而是你有沒有能力把自己的工作流，沉淀成一套可以復(fù)用、可以組合、可以迭代的 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.

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

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

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