寫 Claude Skill 最大的盲區，Anthropic 終於幫你補上了

作者：Feisky

日期：2026年3月5日上午12:18

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

寫Claude Skill最大盲區係無法驗證效果，Anthropic更新skill-creator引入測試框架幫你補返呢個窿。

整理版摘要

作者寫咗幾十個Claude Skill，最大困惑係唔知個Skill到底有冇用。每次寫完放落.claude/skills/目錄，就靠感覺判斷效果，唔確定係Skill起作用定係模型隨機行為。Claude更新之後，原來好用嘅Skill會唔會悄悄失效，完全冇頭緒。呢個困惑應該唔止佢一個人有，寫Skill嘅人大多唔係工程師，清楚流程但缺少工具驗證。

Anthropic最新更新skill-creator，核心係將軟件工程嘅測試、基準評估、迭代改進搬過嚟，但唔需要寫Code。新功能包括用自然語言寫eval、多Agent並行測試、benchmark模式、觸發時機優化。作者認為設計eval嘅過程，本質上係逼你將「期望咩行為」講清楚，好多模糊預期會浮面。結論係：下次寫Skill，少靠感覺，加個eval驗一驗。

Skill寫作最大盲區係無法驗證效果，Anthropic更新skill-creator引入eval測試，將軟件工程方法引入。
用自然語言寫eval，描述期望結果，唔使寫code，直接判斷Skill有冇經得住檢驗。
兩種Skill類型：能力補充型（加新能力）同流程編排型（串流程），測試策略同預期生命週期都唔同。
設計eval倒逼你諗清「期望咩行為」，好多模糊預期會浮面，係提升Skill質量嘅關鍵。
即刻安裝skill-creator，畀你嘅Skill加個eval，一條prompt加一段預期描述就得，跑一次可能發現未意識到嘅問題。

值得記低

工具 github.com

skill-creator 插件

Claude Code用戶可以直接用claude plugin install skill-creator安裝，用於測試、衡量同迭代Skill。

連結 github.com

Anthropic 官方 Skills 倉庫

Anthropic提供嘅公開Skills範例，可以參考同學習。

連結 claude.com

原文連結

Anthropic關於skill-creator更新嘅官方公告。

整理重點

寫Skill嘅困惑終於有解

作者寫咗幾十個Claude Skill，最大困惑係唔知個Skill到底有冇用。每次寫完放落.claude/skills/目錄，就靠感覺判斷效果，唔確定係Skill起作用定係模型隨機行為。Claude更新之後，原來好用嘅Skill會唔會悄悄失效，完全冇頭緒。

呢個困惑應該唔止佢一個人有，寫Skill嘅人大多唔係工程師，清楚流程但缺少工具驗證。

Anthropic最新更新skill-creator，核心係將軟件工程嘅測試、基準評估、迭代改進搬過嚟，但唔需要寫Code。

整理重點

先搞清楚你寫緊邊種Skill

Anthropic將Skill分成兩種：能力補充型同流程編排型。呢個區分對設計Skill好有參考價值。

能力補充型：畀模型添加佢本來做唔好嘅能力，例如官方文檔生成類Skill。風險係隨模型變強，可能變得多餘甚至限制Claude。
流程編排型：模型本身識做每個環節，但Skill將環節按規範串聯，例如NDA審查、每週報告。更耐用，但測試重點係驗證有冇按順序行完。

如果有測試，你能及時發現「呢個Skill已經完成歷史使命了」，而唔係一直帶住個冇用嘅包袱。

流程編排型嘅價值完全依賴於流程嘅嚴格執行，測試重點係驗證有冇按預定順序走完每一步。

整理重點

用eval取代感覺，仲有觸發優化

skill-creator而家可以幫你寫eval，形式好簡單：畀出測試提示詞，描述期望行為，然後判斷Skill有冇經得住檢驗。做過軟件測試嘅人會覺得呢個模式好熟悉，分別係唔使寫code。

1 eval最直接價值係捕捉質量回歸：模型升級或基礎設施變動後，Skill可能行為變化，eval能提前預警。
2 仲有個微妙用途：對於能力補充型Skill，如果基礎模型唔加載Skill就能通過eval，說明技巧已被內化，Skill可以退役。
3 觸發時機優化功能：分析當前Skill描述，對照測試提示詞，推薦修改減少誤觸發同漏觸發。作者認為呢個功能最實用。

如果冇eval，呢個bug可能就一直隱藏，每次遇到不可填寫嘅表單就悄悄出問題。

多Agent並行跑eval，每個Agent獨立上下文，仲有comparator agent做A/B對比，盡量排除評估偏差。

整理重點

總結：畀你嘅Skill加個eval

作者認為下次寫Skill，少靠感覺，加個eval驗一驗。唔需要多複雜，一條提示詞、一段預期描述就夠。跑一次，可能會發現啲你冇意識到嘅問題。

Eval框架恰好在往what描述方向走，呢個描述本身可能就係未來形態嘅Skill。

能力補充型Skill要留意隨模型升級變得多餘；流程編排型要驗證步驟執行。
設計eval係將期望講清楚嘅過程，幫助釐清模糊預期。

寫咗幾十個Claude Skill之後，我最大嘅困惑唔係點樣寫，而係佢到底有冇用。每次寫完一個Skill，就掟咗入 .claude/skills/ 目錄度，然後就開始憑感覺判斷效果。有時覺得有用，過兩日再睇結果又好似變差咗，唔肯定係Skill起作用定係模型本來嘅隨機行為搞成咁。仲煩嘅係，Claude每次更新之後，原本好用嘅Skill會唔會靜靜雞失效，完全唔知。

呢個困惑應該唔止我一個人有。寫Skill嘅人多數唔係工程師，清楚自己嘅工作流程，但欠缺工具去驗證Skill到底有冇起作用。尋日Anthropic更新咗skill-creator（《Improving skill-creator: Test, measure, and refine Agent Skills》），核心思路係將軟件工程嗰套搬過嚟，測試、基準評估、迭代改進，但唔需要寫code。

Claude Code用家可以直接執行下面嘅命令安裝：

claude plugin install skill-creator

喺Claude.ai同Cowork入面直接同Claude講話用skill-creator創建想要嘅Skill就得。

先搞清楚你寫緊邊種Skill

未講測試之前，有一個框架我覺得幾有參考價值，可以幫你喺落筆之前諗清楚一件事。

Anthropic將Skill分成兩種，諗返轉頭，的確係咁樣。

第一種係能力補充型，俾模型添加佢本來做唔好嘅能力。Claude官方提供嘅文檔生成類Skill係個典型例子，入面編碼咗一套技巧同模式，生成結果比直接畀提示詞好得多。模型冇呢個Skill，就達唔到呢個效果。

第二種係流程編排型，模型原本就能處理每個環節，但Skill將呢啲環節按照團隊規範串聯埋一齊，畀嘅係「用咩順序做咩事」呢類嘅約束。NDA審查、每週報告生成呢類Skill屬於呢種。

呢個區分對設計Skill好有參考價值：能力補充型有個隱患，隨住模型變強，佢可能會慢慢變得多餘，甚至限制Claude嘅能力。有啲似你精心寫咗本新員工培訓手冊，結果新嚟嘅人仲熟手過舊員工，手冊自然就冇人睇。如果有測試，你能夠及時發現「呢個Skill已經完成歷史使命」，而唔係一直帶住個冇用嘅包袱。

流程編排型更耐用，但價值完全取決於流程嘅嚴格執行，測試嘅重點係驗證佢有冇按預定順序行完每一步。

寫之前先諗清楚自己寫緊邊種，測試策略同預期生命週期都唔一樣。

用eval取代感覺

skill-creator而家可以幫你寫eval。形式都好簡單，你畀出測試提示詞，描述期望嘅行為，然後叫skill-creator判斷你嘅Skill係咪經得住考驗。做過軟件測試嘅人會覺得呢個模式好熟面口，分別係唔使寫code，用自然語言描述預期結果就得。

例如PDF Skill，以前處理唔可以填寫嘅表單時經常出錯，原因係Claude需要喺冇字段定義嘅情況下精確定位文字放置位置。寫咗eval之後，先定位到呢個具體失敗點，最後透過將定位錨定到提取出嚟嘅文字座標解決咗問題。如果冇eval，呢個bug可能就一直隱藏住，每次遇到唔可以填寫嘅表單就靜靜雞出問題。

eval最直接嘅價值係捕捉質量回歸（quality regression）。模型升級或周邊基礎設施變動之後，原本好用嘅Skill可能行為發生變化。喺變化影響到實際工作流程之前，eval可以提前給你預警。

不過仲有一個更微妙嘅用途，就係判斷Skill仲有冇存在嘅必要。對於能力補充型Skill嚟講，如果基礎模型唔加載Skill就能通過eval，即係呢啲技巧已經被模型內化咗，Skill唔係壞咗，只係完成咗使命。呢個訊號你只能靠測試發現，靠感覺永遠睇唔出。

更新入面仲加咗benchmark模式，可以跑標準化評估，追蹤eval通過率、耗時同token用量。數據儲存喺本地，可以整合到dashboard或CI系統。

多Agent並行

之前eval係順序執行，速度慢唔在講，測試之間嘅上下文仲會互相污染。前一個測試嘅內容可能影響到後一個嘅判斷。而家skill-creator支援多Agent並行跑eval，每個Agent喺獨立嘅上下文入面運行，有各自嘅token同耗時統計，互唔幹擾。

另外仲加咗comparator agent，用嚟做A/B對比：兩個版本嘅Skill對比，或者Skill vs 唔加Skill。有啲似雙盲實驗，負責評判嘅Agent唔知自己睇緊邊個版本嘅輸出，盡量排除評估偏差。呢個設計基本解決咗「我覺得改好咗，但其實唔知」嘅問題。

觸發時機最容易被忽略

輸出質量測完，係咪就夠呢？未必。Skill首先要喺啱嘅時候觸發先有意義。呢個係我自己寫Skill時踩得最多嘅地方：描述寫得太闊，每次少少相關嘅請求都會觸發；描述寫得太窄，得完全匹配嘅詞先會觸發，平時根本用唔上。兩種情況都令人頭痛。

skill-creator而家可以分析當前嘅Skill描述，對照一組測試提示詞，推薦修改嚟減少誤觸發同漏觸發。Anthropic測試咗6個公共文檔創建類Skill，有5個嘅觸發精度透過呢個方法得到改善。

老實講，呢個功能我覺得係今次更新入面最實用嘅，因為觸發問題係最隱蔽。你寫嘅邏輯完全正確，但描述冇匹配到用戶嘅表達方式，Skill就等於白寫。

設計eval其實係將期望講清楚

睇完今次更新，我對Skill寫作有咗個新理解：設計eval嘅過程，本質上係逼你將「期望咩行為」講清楚。好多時Skill效果差，唔係因為提示詞寫得唔好，而係作者自己都冇諗清楚咩叫成功。當你要被迫用語言描述「喺呢個輸入之下，Claude應該做到啲咩」，好多模糊嘅預期就會浮出水面。

Anthropic仲提到咗一個有趣嘅預測：隨住模型越來越強，Skill同spec之間嘅界線可能會模糊。而家嘅SKILL.md本質上係實現計劃，喺度教Claude點樣做事。將來可能只需要描述你想要啲咩，模型自己搞掂點樣做。eval框架啱啱好喺呢個方向行，eval描述嘅係what，即係期望嘅結果。某程度上，呢個描述本身可能就係未來形態嘅Skill。

如果你都喺度寫Skill，下次不妨少啲靠感覺，畀佢加個eval驗一驗。唔使咁複雜，一條提示詞、一段預期描述就夠。行一次，可能會發現一啲你冇意識到嘅問題。

相關資源

•

skill-creator插件：https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator

•

Anthropic官方Skills倉庫：https://github.com/anthropics/skills

•

原文連結：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

好啦，今日就傾到呢度。如果你都喺度探索同使用AI，歡迎關注Feisky公眾號，我會持續分享實踐中嘅發現同踩坑經驗。

寫了幾十個 Claude Skill 之後，我最大的困惑不是怎麼寫，而是它到底有沒有用。每次寫完一個 Skill，扔到 .claude/skills/ 目錄裏，然後就開始憑感覺判斷效果了。有時候覺得有用，過兩天再看結果好像又變差了，不確定是 Skill 在起作用，還是模型本來的隨機行為導致的。更麻煩的是，Claude 每次更新之後，原來好用的 Skill 會不會悄悄失效，完全不知道。

這個困惑應該不只我一個人有。寫 Skill 的人大多不是工程師，清楚自己的工作流程，但缺少工具來驗證 Skill 到底有沒有在起作用。昨天 Anthropic 更新了 skill-creator（《Improving skill-creator: Test, measure, and refine Agent Skills》），核心思路是把軟件工程那套東西搬過來，測試、基準評估、迭代改進，但不需要寫代碼。

Claude Code 用戶可以直接執行下面的命令安裝：

claude plugin install skill-creator

Claude.ai 和 Cowork 裏直接跟 Claude 說用 skill-creator 創建想要的 SKILL 就行。

先搞清楚你在寫哪種 Skill

在聊測試之前，有一個框架我覺得挺有價值的，可以幫你在下筆之前想清楚一件事。

Anthropic 把 Skill 分成了兩種，回頭一想，確實是這麼回事。

第一種是能力補充型，給模型添加它本來做不好的能力。Claude 官方提供的文檔生成類 Skill 是個典型的例子，裏面編碼了一套技巧和模式，生成結果比直接提示詞好得多。模型沒有這個 Skill，就達不到這個效果。

第二種是流程編排型，模型原本就能處理每個環節，但 Skill 把這些環節按照團隊規範串聯起來，給的是“用什麼順序做什麼事”這樣的約束。NDA 審查、每週報告生成這類 Skill 屬於這種。

這個區分對設計 Skill 很有參考價值：能力補充型有個隱患，隨着模型變強，它可能會慢慢變得多餘，甚至是限制 Claude 的能力。這有點像你精心寫了一本新員工培訓手冊，結果新來的人比老員工還熟練，手冊自然就沒人翻了。如果有測試，你能及時發現“這個 Skill 已經完成歷史使命了”，而不是一直帶着一個沒用的包袱。

流程編排型更耐用，但價值完全依賴於流程的嚴格執行，測試的重點是驗證它有沒有按預定順序走完每一步。

寫之前先想清楚自己在寫哪種，測試策略和預期生命週期都不一樣。

用 eval 取代感覺

skill-creator 現在可以幫你寫 eval。形式也很簡單，你給出測試提示詞，描述期望的行為，然後讓 skill-creator 判斷你的 Skill 是否經得住檢驗。做過軟件測試的人會覺得這個模式很熟悉，區別是不用寫代碼，用自然語言描述預期結果就夠了。

比如 PDF Skill，以前處理不可填寫的表單時經常出錯，原因是 Claude 需要在沒有字段定義的情況下精確定位文字放置位置。寫了 eval 之後，才定位到這個具體失敗點，最後通過把定位錨定到提取出來的文字座標解決了問題。如果沒有 eval，這個 bug 可能就一直隱藏着，每次遇到不可填寫的表單就悄悄出問題。

eval 最直接的價值是捕捉質量回歸。模型升級或周邊基礎設施變動之後，原本好用的 Skill 可能行為發生變化。在變化影響到實際工作流之前，eval 能提前給你預警。

不過還有一個更微妙的用途，即判斷 Skill 是否還有存在的必要。對於能力補充型 Skill 來說，如果基礎模型不加載 Skill 就能通過 eval，說明這些技巧已經被模型內化了，Skill 不是壞了，只是完成使命了。這個信號你只能靠測試發現，靠感覺永遠看不出來。

更新裏還加了 benchmark 模式，可以跑標準化評估，跟蹤 eval 通過率、耗時和 token 用量。數據保存在本地，可以集成到 dashboard 或 CI 系統裏。

多 Agent 並行

之前 eval 是順序執行的，速度慢不說，測試之間上下文還會互相污染。前一個測試的內容可能影響到後一個的判斷。現在 skill-creator 支持多 Agent 並行跑 eval，每個 Agent 在獨立的上下文裏運行，有各自的 token 和耗時統計，互不干擾。

另外還加了 comparator agent，用來做 A/B 對比：兩個版本的 Skill 對比，或者 Skill vs 不加 Skill。有點像雙盲實驗，負責評判的 Agent 不知道自己看的是哪個版本的輸出，儘量排除評估偏差。這個設計基本解決了“我覺得改好了，但其實不知道”的問題。

觸發時機最容易被忽略

輸出質量測完了，是不是就夠了？不一定。Skill 首先得在對的時候觸發才有意義。這是我自己寫 Skill 時踩得最多的地方：描述寫得太寬，每次稍微相關的請求都會觸發；描述寫得太窄，只有完全匹配的詞才會觸發，平時根本用不上。兩種情況都讓人頭疼。

skill-creator 現在能分析當前的 Skill 描述，對照一組測試提示詞，推薦修改來減少誤觸發和漏觸發。Anthropic 測試了 6 個公共文檔創建類 Skill，有 5 個的觸發精度通過這個方法得到了改善。

說實話，這個功能我覺得是這次更新裏最實用的，因為觸發問題是最隱蔽的。你寫的邏輯完全正確，但描述沒有匹配到用戶的表達方式，Skill 就等於白寫了。

設計 eval 其實是在把期望說清楚

看完這次更新，我對 Skill 寫作有了一個新認識：設計 eval 的過程，本質上是在逼你把“期望什麼行為”說清楚。很多時候 Skill 效果差，不是因為提示詞寫得不好，而是作者自己也沒想清楚什麼叫成功。當你被迫用語言描述“在這個輸入下，Claude 應該做到什麼”，很多模糊的預期就會浮出水面。

Anthropic 還提到了一個有意思的預判：隨着模型越來越強，Skill 和 spec 之間的邊界可能會模糊。現在的 SKILL.md 本質上是實現計劃，在告訴 Claude 怎麼做事。以後也許只需要描述你想要什麼，模型自己搞清楚怎麼做。eval 框架恰好在往這個方向走，eval 描述的是 what，也就是期望的結果。某種程度上，這個描述本身可能就是未來形態的 Skill。

如果你也在寫 Skill，下次不妨少靠感覺，給它加個 eval 驗一驗。不需要多複雜，一條提示詞、一段預期描述就夠了。跑一遍，可能會發現一些你沒意識到的問題。

相關資源

•

skill-creator 插件：https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator

•

Anthropic 官方 Skills 倉庫：https://github.com/anthropics/skills

•

原文連結：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

好了，今天就聊到這兒。如果你也在探索和使用 AI，歡迎關注 Feisky 公眾號，我會持續分享實踐中的發現和踩坑經驗。