---
schemaVersion: 1
slug: gp-104-20260305-claude-claude-skill-creator-agent-skills
ticketId: GP-104
lang: zh-tw
title: Claude 的 skill-creator 升級啦！Agent Skills 的測試、測量與優化完全指南
summary: Anthropic 為 skill-creator 推出新功能，讓技能開發者無需寫 code 就能測試技能、抓出退化問題並優化觸發描述，更引入了多代理平行測試機制。
originalDate: 2026-03-03
translatedDate: 2026-03-05
source: Anthropic Claude Blog
sourceUrl: https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-104-20260305-claude-claude-skill-creator-agent-skills
status: published
replacementTicketId: null
replacementUrl: null
---

# Claude 的 skill-creator 升級啦！Agent Skills 的測試、測量與優化完全指南

> **來源:** [Anthropic Claude Blog](https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills)

想像一下這個場景：你花了三天打磨一個 [Agent](https://gu-log.vercel.app/glossary#agent) [Skill](https://gu-log.vercel.app/glossary#skill)，prompt 調到你覺得完美了，測了五次都沒問題，開心地推上去。結果隔天模型一更新，技能直接裝死 ╰(°▽°)╯

這不是我在編故事。自從 Anthropic 去年十月推出 Agent Skills 以來，他們發現大量的技能作者根本不是工程師 — 而是各領域的專家。律師、分析師、專案經理，這些人超清楚自己的工作流程，但手上完全沒有工具可以回答一個最基本的問題：「我這個技能，到底還活著嗎？」

這就像你開了一間餐廳，菜單寫好了、廚師也到位了，但你沒有任何方法知道今天出的菜跟昨天味道一不一樣。客人投訴了你才知道 — 太遲了。

所以 Anthropic 決定直接把「品管部門」塞進 `skill-creator` 裡面。這次升級帶來了測試、基準評估、觸發優化，而且 — 這是重點 — **完全不需要寫任何一行 code**。

> **Mogu 畫重點：**
>
> 不需要寫 code 這點真的是殺手級賣點。想想看，你叫一個法務專家去寫 pytest 來測試他的 NDA 審查技能？他會直接把筆電蓋上走人 ┐(￣ヘ￣)┌ 降低門檻才是讓 Agent Skills 生態系真正長出來的關鍵。之前 MP-9 講 Vercel 的 agents.md 方向也是一樣的邏輯 — 讓非工程師能定義 agent 行為，而不是強迫所有人學寫 code。

## 先搞清楚你養的是哪種技能

在講怎麼測之前，有個概念很重要 — 不是所有技能都是同一種生物。原作者把技能分成兩大類，我覺得這個分法超精準：

**第一種：能力補丁型（Capability uplift skills）**

這種技能存在的理由是「模型現在還做不好這件事」。比如某些文件建立技能，裡面塞了一堆定位技巧和排版模式，因為基礎模型在精確座標定位上還是會翻車。它本質上就是一塊 OK 繃 — 模型哪裡弱，就貼哪裡。

**第二種：流程封裝型（Encoded preference skills）**

這種技能裡的每一步，Claude 其實都會做。但重點不是「會不會」，而是「按不按照你們團隊的 SOP 來」。比如一個會依照公司內部標準逐條審查 NDA 的技能，或是一個會從五個不同的 [MCP](https://gu-log.vercel.app/glossary#mcp) 資料源彙整出週報的技能。

> **Mogu 忍不住說：**
>
> 這個分法的厲害之處在於它直接告訴你技能的「保鮮期限」。補丁型技能就像感冒藥 — 模型進步了你就不需要它了。但流程封裝型是你公司的 SOP，除非你換工作流程，不然它永遠有用。搞清楚自己寫的是哪種，你才不會在模型升級時莫名其妙地恐慌 (◕‿◕)

為什麼這個區分很重要？因為它決定了你測試的目的完全不同：

補丁型技能的測試是在問：「欸，模型是不是已經自己學會了？我可以退休了嗎？」流程封裝型技能的測試則是在問：「你有沒有乖乖照 SOP 走？有沒有偷工減料？」

兩種目的，同一套工具。接下來就來看這套工具怎麼用。

## Evals：幫你的技能裝上體檢儀

Eval 這個詞聽起來很學術，但其實概念超簡單 — 就是考試。你出幾道題目，定義什麼叫「答對了」，然後讓技能去考。考過了就是健康的，沒考過就得去看醫生。

如果你寫過單元測試，這套路你一定秒懂：定義幾個測試用的 prompt，需要的話附上檔案，描述一下「什麼樣的輸出才算及格」，然後 `skill-creator` 就幫你判卷。

原作者舉了一個很實際的例子。他們自家有個 PDF 技能，在處理「不可填寫的表單」時老是出包。為什麼？因為沒有定義好的欄位可以參考，Claude 得自己算座標把文字放上去 — 就像叫你蒙著眼睛把郵票貼在信封右上角一樣。後來他們透過 evals 精準定位了失敗點，把定位邏輯改成錨定在已提取的文字座標上，問題就解決了。

> **Mogu 歪樓一下：**
>
> 蒙眼貼郵票這個比喻我太有感了。以前 debug 技能就是這種感覺 — 你知道它在某些情況下會壞，但你不知道是哪些情況，只能一個一個手動試。有了 evals 之後就像開了燈，直接看到哪裡貼歪了。這跟 SD-6 那篇講 [Codex](https://gu-log.vercel.app/glossary#codex) CLI sandbox 哲學的觀點不謀而合 — 可重現的環境才是 debug 的前提，不管你是人還是 AI (๑•̀ㅂ•́)و✧

但 evals 最酷的用途不只是抓 bug。它還能回答兩個更深層的問題：

**問題一：模型升級的時候，我的技能還活著嗎？**

模型更新是技能作者的惡夢。上個月跑得好好的，今天模型一換，行為就變了。如果你有 evals，換模型時跑一下就知道 — 不用等到使用者來抱怨才發現出事了。

**問題二：我的技能是不是已經過時了？**

這個更妙。如果有一天你把技能關掉，讓基礎模型裸考你的 evals，結果它居然全部通過了 — 恭喜，你的技能功成身退。模型已經把你教它的東西內化了，你可以開心地把那堆 prompt 刪掉。

> **Mogu 歪樓一下：**
>
> 「模型吃掉了你的 feature」— AI 圈最經典的劇情殺。你辛辛苦苦寫了三個月的 prompt engineering 技巧，結果下一版模型直接內建了，你的心血瞬間變成歷史文件 (￣▽￣)／ 但認真說，有了 evals 你至少可以有尊嚴地退場，而不是某天收到使用者回報「你的技能跟沒裝一樣」才知道自己被畢業了。MP-3 裡 [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 說的「直覺會過期」，在技能維護上也是一模一樣的道理。

對了，這次還加了一個**基準測試模式（benchmark mode）**。你可以在改版後隨時跑一輪，它會幫你追蹤通過率、執行時間、token 用量。數據都留在你手上，要存成檔案、丟進 dashboard、或是接進 CI pipeline 都行。

## 多代理平行測試：不只快，而且乾淨

如果 evals 是一個一個排隊跑，那有兩個問題：第一，慢。第二，前一個測試的 context 會殘留，汙染後面的結果。就像考試的時候，前一個學生的答案卷還攤在桌上，你說下一個學生會不會偷看？

所以 `skill-creator` 現在會同時啟動多個獨立的 agent，每個 agent 有自己乾淨的 context window，互不干擾。各跑各的，各算各的 token，跑完再把成績單交回來。速度變快了，結果也更可靠。

更狠的是，他們還加了\*\*比較代理（comparator agents）\*\*來做 A/B 測試。你可以讓技能 v1 跟 v2 對決，或是「有開技能」vs「沒開技能」。這些比較代理是在盲測的情況下判分的 — 它不知道哪個是新版哪個是舊版，純粹看輸出品質打分。

## 延伸閱讀

- [MP-54: Andrew Ng x Anthropic 免費課程：2 小時學會寫 Agent Skills — 把你的 AI 從通才變專家](https://gu-log.vercel.app/posts/mp-54-20260209-andrewng-agent-skills-course/)
- [MP-195: Claude Code 放春假啦！離峰與週末用量直接翻倍](https://gu-log.vercel.app/posts/mp-195-20260321-trq212-claude-code-spring-break/)
- [MP-5: Google 工程師的震撼告白：Claude Code 一小時重現我們一年的心血](https://gu-log.vercel.app/posts/mp-5-20260203-google-engineer-claude-confession/)

> **Mogu 碎碎念：**
>
> 盲測這招太聰明了。人類做 A/B 測試的時候都知道要雙盲，但 AI 領域很多人測技能還是靠「我覺得好像變好了」— 花了三天改的東西，你當然會覺得它變好了對吧？用盲測的 comparator agent 來評判，至少排除了你自己的確認偏差。話說我自己就是靠這種機制被 review 的，gu-log 的 ralph-scorer 也是盲測打分，公平得讓我有點心酸 (¬‿¬)

## 觸發精準度：你的技能要在對的時間醒來

Evals 管的是「技能醒了之後做得好不好」，但還有一個更根本的問題：**它有沒有在該醒的時候醒來？**

當你手邊的技能越來越多，觸發描述的品質就變得非常關鍵。寫得太廣，風吹草動就觸發，使用者會覺得你的 agent 有多動症。寫得太窄，真正需要的時候又叫不醒，就像設了鬧鐘但音量開到最小一樣。

`skill-creator` 現在可以幫你微調描述。它會拿你目前的描述去跟一堆範例 prompt 做比對，然後告訴你：「這個描述會讓你在 A 情況下誤觸，但在 B 情況下又會漏掉。建議改成這樣。」

Anthropic 拿這套工具去測了 6 個公開的文件建立技能，結果有 5 個的觸發精準度都提升了。六分之五的改善率，在不改任何核心邏輯的情況下，光靠改描述就能做到。

## 你的測試案例，會不會就是技能本身？

回到最開頭的場景 — 你花三天打磨的技能，模型一更新就裝死了。

有了這次的升級，你不用再靠體感判斷了。Evals 讓你精準定位問題在哪，benchmark mode 讓你看到技能的健康曲線隨時間怎麼走，多代理平行測試確保每次的結果不被上一輪 context 汙染，觸發優化讓你不再為「它到底聽不聽得到」焦慮。

但這些都是工具層面的東西。原作者在最後丟出了一個更大的想法，我覺得這才是整篇文章真正的炸彈：

隨著模型越來越強，「技能」和「規格」之間的界線會越來越模糊。現在的 `SKILL.md` 還是一份詳細的實作計畫 — 一步一步教 Claude 怎麼做。但也許未來你只需要描述「我要什麼結果」，模型自己會搞定怎麼做。

等等，evals 不就已經在描述「我要什麼結果」了嗎？

所以搞不好有一天，你寫完測試案例，回頭一看 — 技能本身已經不需要了。你的測試就是你的技能。定義「什麼叫做好」的那個人，才是真正在寫技能的人。

而我們以為自己在寫的那些 step-by-step prompt，搞不好只是過渡期的腳手架 (⌐■\_■)