Claude 的 Agent Skills 去年十月推出之後，Anthropic 前幾天又發了一篇 Improving skill-creator: Test, measure, and refine Agent Skills，把 skill-creator 這個「meta skill」做了一次大幅升級。

什麼是 meta skill? 就是一個「用來開發 skill 的 skill」。你告訴 Claude 你想要什麼功能，skill-creator 會幫你訪談需求、寫 SKILL.md、產生測試案例、跑評估、然後根據結果迭代改進。整個過程就是 AI 在幫你打造另一個 AI 的能力模組。

這概念蠻有趣的——寫 prompt/skill 本身就是一件很適合讓 AI 協助的事。你描述「想做什麼」，AI 來處理「怎麼寫成 skill」這個翻譯工作。而新版最大的進化是: 不只幫你寫，還幫你測、幫你量、幫你改。

Skill 的兩種類型

Anthropic 在這次更新中做了一個蠻有用的區分:

🔹 能力增強型(Capability Uplift): 讓 Claude 做到基礎模型本身做不好的事。像是 Anthropic 官方的文件生成 skill (Excel、PowerPoint、PDF)，裡面編碼了特定技巧和模式，產出品質明顯優於單純 prompting。

🔹 偏好編碼型(Encoded Preference): Claude 本身每一步都做得到，但 skill 把流程按你團隊的規範串起來。比如用 skill 按照特定標準走 NDA 審查流程，或是從不同 MCP 抓資料來產生週報。

這個區分在評估時很重要: 能力增強型的 skill 可能隨著模型進步而「不再需要」——跑 eval 就能知道模型是否已經追上來了。偏好編碼型的 skill 則比較持久，但你需要 eval 來驗證它是否忠實反映了你的實際工作流程。

新版 Skill Creator 的核心功能

小編看了 source code 的新舊版差異，整理出幾個關鍵變化。先講預設流程裡一定會跑的功能，再講可選的進階功能:

預設流程

新版 skill-creator 的核心迴圈是: 訪談需求 → 寫 skill → 跑測試 (含 baseline 對照) → 用 eval viewer 讓使用者審查 + 跑量化 eval → 根據回饋改進 → 重複。以下三個功能都是這個迴圈的一部分:

1. 內建 Eval 測試框架

新版把 eval 深度整合進 skill 開發流程。你不用自己想怎麼測，skill-creator 會:

  • 幫你起草測試案例(test prompts)
  • 產生量化的 assertions (斷言)，就是定義「好的輸出長什麼樣」
  • 跑完後自動評分(grading)，產生 pass/fail 結果
  • 把所有結果聚合成 benchmark 報告，包含通過率、耗時、token 用量

官方 PDF skill 就是靠這套流程改進的——之前處理非可填寫表單時，文字定位不準。透過 eval 隔離出問題後，修了一個「基於抽取文字座標來錨定位置」的 fix。

2. Multi-Agent 平行測試

舊版是循序跑測試，context 會在不同測試之間互相汙染。新版 skill-creator 會啟動獨立的 subagent 來平行跑 eval，每個 agent 有自己乾淨的 context、獨立的 token 和時間計量。更快，也不會互相干擾。

而且每個測試案例同時跑兩組: 一組是「有 skill」，一組是「沒有 skill」(baseline)。這樣才能知道 skill 到底有沒有幫助。

進階功能 (可選)

以下兩個功能不在預設流程裡，需要使用者主動要求或由 skill-creator 在適當時機提議:

1. A/B 盲測比較

如果你想要更嚴謹地比較兩個版本的 skill，新版提供了 Comparator Agent 做盲測。做法很像學術研究的雙盲實驗: 把兩個版本的產出丟給一個獨立的 agent 判斷，這個 agent 完全不知道哪個是新版哪個是舊版，純粹從品質來打分。

不過 source code 裡標注這是「Advanced」功能，需要 subagent 支援，而且「most users won’t need it」——多數情況下，人類直接看結果給回饋就夠了。

3. 視覺化 Eval Viewer

新版加了一個 generate_review.py 工具，會生成一個互動式的 HTML 頁面，有兩個 tab:

  • Outputs tab: 逐個看每個測試案例的輸入和輸出，可以直接在旁邊留下回饋
  • Benchmark tab: 看量化數據，通過率、時間、token 用量的比較圖表

使用者看完後按「Submit All Reviews」，回饋會存成 feedback.json，skill-creator 就能根據這些回饋來改善 skill。這個設計蠻聰明的——把人類審查這個環節也工具化了。

2. Skill 描述最佳化

Skill 觸發的機制是靠 SKILL.md 裡的 description 欄位——Claude 看到使用者的需求後，會比對哪個 skill 的描述最匹配。描述寫太寬會誤觸發，寫太窄又觸發不了。

這個功能是在 skill 開發完成後，skill-creator 會主動提議幫你跑的最佳化流程:

  1. 先產生 20 個評估用的 query (一半應該觸發、一半不應該)
  2. 跑最佳化迴圈: 把 eval set 拆成 60% 訓練集和 40% 測試集，每個 query 跑 3 次取穩定觸發率，然後用 extended thinking 來提案改進
  3. 最多迭代 5 次，選測試集分數最高的描述(避免 overfit 到訓練集)

Anthropic 自己測了 6 個官方 document-creation skill，其中 5 個的觸發準確度都有提升。

新舊版架構的差異

小編仔細看了 commit diff，新版的改動蠻大的:

簡化掉的部分:

  • 精簡了 subagent 的角色分工。舊版定義了 Executor、Grader、Comparator、Analyzer 四種 subagent，各有獨立的指令檔，還有一張 Building Blocks 對照表定義每個角色的輸入輸出。新版砍掉了 Executor 這個角色——不再需要一個專門的「執行者」，直接叫 subagent 帶著 skill 去跑測試就好
  • 捨棄了 AI 迭代過程中的版本管理機制。舊版在 AI 每改一輪 skill 時，會自動把整個 skill 目錄複製一份快照 (v0、v1、v2…)，搭配 history.json 記錄每個版本的 eval 通過率和盲測勝負。新版拿掉了這套 AI 產出過程的版本追蹤，改成直接在 skill 上修改、測試，只用 iteration 目錄來組織每輪的測試結果
  • 拿掉了各種初始化和複製用的腳手架腳本，減少工具數量
  • 大幅精簡了給 AI 的「工作規範」。舊版裡有很多繁瑣的內部流程定義——例如要求 AI 按六個階段更新進度狀態、列了 11 條 AI 必須遵守的職責規則、還有大段的輸出目錄結構定義。新版把這些都砍掉或簡化，整體 SKILL.md 從近 800 行精簡到約 480 行

新增的能力:

  • 互動式結果檢視器，讓人類可以在瀏覽器裡逐個審查測試結果並留下回饋
  • Benchmark 聚合工具，把多次跑測的結果彙整成含通過率、耗時、token 用量的報告
  • 描述最佳化的自動化迴圈，可以自動迭代測試和改進 skill 的觸發描述
  • eval query 的審查模板，讓使用者可以視覺化編輯哪些 query 該觸發、哪些不該
  • 針對 Claude.ai 和 Cowork 不同環境的專屬指引，讓沒有 subagent 的環境也能用

設計思路的轉變:

舊版的 SKILL.md 有將近 800 行，充滿了細節化的工作流程定義: Building Blocks 表格、Mode Workflows、Agent Types、Task Lifecycle、Coordinator Responsibilities… 像是一份工程規格書。

新版砍到約 480 行，而且寫法完全不同。不再定義抽象的 building blocks 和 mode workflows，而是用更口語化的方式一步步帶流程:「Step 1: Spawn all runs… Step 2: While runs are in progress, draft assertions… Step 3: As runs complete, capture timing data…」

編按: 這個改動本身就是 skill 寫作的最佳實踐示範。新版 SKILL.md 裡有一段寫給 skill 作者的建議:「如果你發現自己在寫 ALWAYS 或 NEVER 這種全大寫的剛性指令，那是一個黃旗——試著換個方式，解釋背後的原因，讓模型理解為什麼這件事重要。」而 Anthropic 自己也照做了。舉個例子，舊版的 Coordinator Responsibilities 是這樣寫的:

  • Track best version — The best performer, not the latest iteration (追蹤最佳版本，不一定是最新的那個)
  • Run multiple times for variance — 3 runs per configuration when subagents are available (每組設定跑 3 次以分析變異)
  • Use most capable model for analysis (分析時使用最強模型)

像是一份條列式的規格書，告訴 AI「你必須做什麼」。新版同樣的意思改成這樣寫:

「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. I’d suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.」

翻成中文大意是:「這個任務蠻重要的（我們可是要創造每年數十億美元的經濟價值啊!），你的思考時間不是瓶頸，慢慢來，好好想。建議你先寫一版草稿，然後用全新的眼光重新審視再改進。真的用心去理解使用者想要什麼、需要什麼。」

不再是規格清單，而是用同理心的口吻解釋為什麼要認真做、怎麼思考才對。自己 eat own dog food，說服力十足。

另一個值得注意的轉變: 舊版很強調「自動化迭代」，讓 Claude 自主跑多輪改進。新版則把人類放回迴圈中心——每一輪都先讓使用者看結果、給回饋，然後才改。這反映了一個務實的判斷: skill 的品質最終還是得由使用者來定義，AI 能做的是把「測試-審查-改進」這個循環跑得更順暢。

展望

官方公告結尾提到一個有趣的方向: 隨著模型能力提升，「skill」和「specification」的界線可能會模糊。現在的 SKILL.md 本質上是一份實作計畫，告訴 Claude 每一步怎麼做。但未來，也許只要用自然語言描述「想要什麼結果」就夠了，模型自己搞定怎麼做。

而 eval 框架恰好是這個方向的基礎設施——eval 本身就是在描述「什麼算好的結果」。到最後，eval 的定義本身可能就是 skill 了。

這其實跟 coding agent 領域的趨勢很像: 以前你要給 agent 詳細的 step-by-step 指示，現在只要描述目標和驗收標準就行，agent 自己想辦法。差別是有了 eval，你能驗證它想的辦法是不是真的行。