Agent Skills：用 Markdown 寫一次，30+ AI 工具通用

什麼是 Agent Skill？為什麼突然人人都在寫？

Agent Skill 是一個資料夾，裡面放着一個名為 SKILL.md 的 Markdown 檔案。檔案內只有三樣東西：名稱、描述，以及一段告訴 AI 助手如何完成某項特定工作的純文字指示。沒有程式碼，沒有 API，同一個檔案可在超過 30 款 AI 工具中通用。

Anthropic 於 2025 年 12 月 18 日公布 Agent Skills 規格。48 小時之內，OpenAI 與 Microsoft 已經支援。

真正值得留意的是這個速度。互相競爭的公司極少會如此迅速地就一種檔案格式達成共識。他們願意，是因為問題本身足夠普遍：每個人都有一批每日重複輸入的提示，卻沒有辦法把它們帶到另一個工具。

如果你這星期已經第五次把同一段四百字的簡報貼進 ChatGPT，你其實已經完全理解 Skill 要解決什麼問題。你正在用人手做一件應該由檔案代勞的事。

Skill 與「儲存起來的提示」有什麼分別？

儲存起來的提示要等你去翻出來，Skill 卻會自己載入。助手先讀描述欄位，判斷當前請求是否匹配，然後主動把指示拉進來。你完全不需要記得它存在，而這正是它會被真正使用的原因。

這就是抽屜裡的食譜卡，與一位早已熟悉這道菜的廚師之間的分別。

第二個分別是可攜性。存放在 ChatGPT 自訂指示裡的提示，只能留在 ChatGPT。為 Claude 撰寫的 SKILL.md 檔案，可以原封不動地在 OpenAI Codex、GitHub Copilot、Cursor、Gemini CLI、Goose 中運行。截至 2026 年 6 月，agentskills.io 展示頁上約有 40 款產品支援此標準。

第三個分別是 Skill 可以交給別人。提示留在你的帳戶裡，資料夾卻可以放進共用雲端硬碟、程式碼庫，甚至直接用訊息傳出去。同事把它放進自己的工具，就得到你那一套完整流程。

為什麼描述欄位比指示內容更重要？

描述是助手在決定要否載入 Skill 之前，唯一會讀取的部分。如果它與你實際的說話方式不吻合，Skill 就永遠不會啟動，指示內容也永遠不會被看見。當 Skill 失效，問題幾乎總是出在描述，而不是內文。

大多數人第一次撰寫時，都會用自己的詞彙去描述「這個 Skill 大概是關於什麼」。

失敗的描述例子：「團隊內容指引」。沒有人會這樣輸入，因此它匹配不到任何請求。

有效的描述遵循兩段式結構：先講它做什麼，再加一句「Use when」，列出真實用戶會用的觸發字詞。

--- 用一句話、以具體名詞說明它做什麼

--- 「Use when」後面列出 5 至 10 句你真的會輸入的話，包括那些寫得草率的版本

--- 全長不超過 1,024 字元，這是規格上限

官方規格自己舉的例子刻意寫得極為直白：「Extract PDF text, fill forms, merge files. Use when handling PDFs.」這正是你需要的語氣。不是宣傳文案，而是路由指令。

建議最後才寫描述。等內文完成之後，你才會清楚這個 Skill 實際覆蓋什麼範圍，而那個範圍通常比你最初想像的窄。

如何在 20 分鐘內寫出第一個 Agent Skill？

挑一項你最常重複解釋的工作，把指示寫成向一位能幹的新同事交代任務的樣子，然後存為資料夾內的 SKILL.md。規格只要求兩個 frontmatter 欄位：name 與 description，其餘全部可選。

以下是一個完整可用的 Skill，你可以直接複製、改名、修改。這是真實案例：一份每個客戶經理每逢星期五都要從零重寫的週報。

把以下內容複製到 SKILL.md

---

name: weekly-client-update

description: Draft the Friday client status update from raw notes. Use when writing a weekly update, client status email, Friday report, progress summary, or when the user pastes messy meeting notes and asks for a client-ready version.

---

# 每週客戶更新

把零散筆記整理成可直接發給客戶的更新。絕不虛構任何筆記中沒有的狀態、日期或數字。

## 結構，必須按此順序

1. 一句標題：本週最重要的一件事。

2. 已完成：客戶現在能看見的成果。用點列，過去式。

3. 進行中：正在推進的項目，以及預計完成日期。若我的筆記沒有日期，寫 TBC 並在文末標示。

4. 受阻：需要客戶作決定的事項。寫清楚是什麼決定，以及截止時間。

5. 下週計劃：最多三項。

## 規則

- 全文最多 200 字。

- 不使用「很好」「令人期待」「相當顯著」這類形容詞。

- 不可只寫「我們正在處理」，必須說明下一步是什麼、何時完成。

- 若有進度延誤，必須寫在前兩行，不可埋在中段。

- 文末加一節「MISSING」，列出所有被標為 TBC 的項目。

## 完成前檢查

重讀草稿，刪掉任何刪去之後不會損失資訊的句子。

檔案應該放在哪裡

兩種慣例已經覆蓋大部分情況。放在帳戶層級的資料夾，代表你在任何地方工作都可以用到；放在特定專案內的資料夾，則只在該專案生效，而這正是處理客戶專屬規則時你想要的效果。在 Claude Code 及大部分兼容工具中，這兩個位置分別是個人 skills 資料夾與專案 skills 資料夾。

如果你使用桌面版 AI 應用程式而非終端機，請在設定中尋找 Skills 或 Capabilities 面板。兩者的檔案格式完全相同。

2026 年有哪些 AI 工具真正支援 Agent Skills？

截至 2026 年 3 月，已有 32 款工具支援該規格；到 2026 年 6 月，agentskills.io 展示頁上約有 40 款產品。名單橫跨 Anthropic、OpenAI、Microsoft、Google、JetBrains、AWS、Databricks、Snowflake、字節跳動與 Mistral AI。

已具名支援的包括 Claude 與 Claude Code、OpenAI Codex CLI、GitHub Copilot 與 VS Code、Cursor、Gemini CLI、Block 的 Goose、AWS Kiro、Sourcegraph Amp，以及 JetBrains Junie。

但你必須誠實看待這份名單，因為它會影響你該先寫哪一個 Skill。這 40 款產品中相當大一部分是開發者工具，運行於終端機或 IDE。如果你的日常是試算表、簡報與電郵，真正與你相關的是桌面版與網頁版助手，不是那些命令列工具。

另外兩個里程碑說明這個生態並非停留在公告階段。Vercel 於 2026 年 1 月 20 日推出 skills.sh，一個支援命令列安裝的市集。AWS 則於 2026 年 2 月 5 日在 Kiro IDE 中加入 Agent Skills 支援。

實際結論是：可攜性現在真的有價值。你本月撰寫的 Skill，明年換助手時大概不會被困死在原地，而你過去建立的任何提示庫都沒有這種待遇。

Agent Skills 會在哪些地方失效？

Skill 失效有四種可預測的模式：描述與真實說話方式不符、一個 Skill 想涵蓋太多工作、指示長到擠佔了真正任務的空間，以及沒有人檢查 Skill 究竟有否啟動。四者都可以在幾分鐘內修正，前提是你知道要去看。

一個 Skill，一項工作

一個叫「marketing」的 Skill，同時涵蓋社交貼文、電郵、SEO 大綱與廣告文案，結果是它不斷被觸發，卻對每一項都幫不上忙。四個範圍狹窄的 Skill 永遠優於一個包山包海的版本，因為描述可以寫得精準。

長度不等於質素

指示會佔用上下文視窗中本來應該放你真正文件的空間。SKILL.md 要保持精簡，把參考資料推到附帶檔案，讓它只在需要時載入。如果你的 Skill 在第一條指示之前已經寫了三千字鋪陳，請動手刪。

無聲的未啟動

這一種最浪費時間。你以為 Skill 正在運作，輸出看起來也合理，但 Skill 其實從未載入。直接問：「這個答案你用了哪些 skills？」如果答案是沒有，問題就在描述。

Skill 不會核實事實

Skill 塑造輸出的形態，卻不會驗證內容。一個寫着「絕不虛構數字」的 Skill 能減少虛構數字，卻不能消除。每一項聲稱仍然需要你親自過目，尤其是價格、日期與人名。這與處理任何 AI 草稿的紀律一致，也正是讓 AI 以真實來源文件為依據始終是一個獨立且必要步驟的原因。

怎樣測試一個 Skill 才敢信任它？

做兩個測試：觸發測試與盲測。觸發測試檢查 Skill 是否會在你沒有預設的說法下載入；盲測檢查輸出是否真的比沒有 Skill 時更好。兩者合計不到十分鐘，卻能抓出幾乎所有問題。

立即試試

打開你的助手，把以下內容貼進去，方括號部分換成你自己 Skill 的工作內容：

我已安裝一個負責［撰寫每週客戶更新］的 skill。以下是真實同事可能提出這項請求的五種說法。請對每一句只回答 YES 或 NO：你會否為這個請求載入該 skill？不要解釋，不要放軟語氣，也不要告訴我描述看起來沒問題。

1.「Acme 星期五那份處理好了沒有」

2.「客戶要下午五點前收到進度」

3.「這是我開會的筆記，幫我整理到可以見人」

4.「起草週報」

5.「我們這星期交了什麼」

然後列出這五句之中，所有未出現在我 skill 描述裡的觸發字詞。

強迫二元回答是這個提示能夠奏效的關鍵。你叫助手「幫我檢視描述」，得到的只會是安慰；強迫它對每一種具體說法表態 YES 或 NO，你才會看見缺口。

接着做盲測。同一份輸入，一次啟用 Skill，一次移除。如果你分不出兩者差別，代表你的指示只是在描述一個能幹助手本來就會做的事，這個 Skill 並未賺到它的位置。

這星期應該先寫哪一個？

從你已經解釋超過三次的工作開始，而不是從最亮眼的那個開始。Skill 的價值來自重複，因此那件沉悶但反覆出現的工作，回報比雄心勃勃的項目快得多。一個範圍狹窄、經過測試的 Skill，勝過十個從不啟動的 Skill。

值得各花十分鐘的候選項目：客戶週報、財務同事堅持的報銷備註格式、老闆對內部公告語氣的具體要求、你對外發布任何內容前都會走一遍的檢查清單。

這些全都不吸引，卻全都是你目前需要反覆解釋的事。而每一次重複解釋，都是你為「沒有把那個檔案寫出來」而繳的一筆小額稅款。

這個格式刻意設計得簡單，因為它必須讓不寫程式的人也讀得懂。這正是 Agent Skills 真正的意義所在：配置一件 AI 工具的東西，第一次變成了一份文件，而寫文件是你本來就會做的事。

懂AI的冷，更懂你的難 UD 同行28年，讓科技成為有溫度的陪伴。掌握格式只是容易的那一半，把它變成團隊實際運作的一部分，才是大多數人卡住的地方，而這一段沒有人應該獨自摸索。

把一個 Skill 變成一套真正運作的系統

寫出第一個 SKILL.md 只需二十分鐘，但要把幾個 Skill 整合成全團隊倚賴的流程，是另一回事。UD 陪伴香港企業走過 28 年，最清楚技術要落地才有價值。我們手把手帶你完成每一步，由挑選該封裝哪些工作、測試它是否穩定啟動，到部署至整個團隊。

本文由 UD AI 團隊審閱。