Agent Skill 怎麼寫？把 AI 的個性、工作步驟與驗收放進範本

第一個 Skill 該做什麼？先選一件反覆修正的工作

先挑你已做過、也知道怎樣算好的任務。例如每次請 AI 整理商品介紹，都要提醒先核對資料、缺規格不能補猜、交付前列出待確認項目。這種重複提醒，才有整理成固定方法的價值。

只發生一次的特殊要求先留在當次對話。不要把某一位客戶喜歡的語氣，直接升成所有工作的永久規則。還不清楚三種資訊怎麼分，可以先讀Prompt、Skill 與知識庫的差別。

本篇用虛構的「商品草稿檢查」示範 Skill 內容設計與驗收。完成後，你會有一份可交給支援工具載入的範本；不同工具的安裝位置與載入操作，需依該工具文件處理，本文不提供通用安裝命令。

AI 的個性怎麼寫，才不只是「專業、主動、細心」？

我們設計日常協作方式時，會把抽象形容詞改成可觀察的動作。例如「主動」不是自行發布，而是在已有資料足夠時完成草稿；「細心」則是指出沒有來源的規格，而非在文末說自己已仔細檢查。這是我們的設計經驗，沒有據此量測通用的效率提升。

手機可左右滑動查看完整表格。

這些是範例，不是每個職位都套用的標準答案。研究助理可能需要展開證據，客服回覆可能需要短句；語氣服務工作目的，不能反過來刪掉必要限制。

什麼時候先問，什麼時候可以直接做？

判斷缺少的資訊會不會改變成果。商品名稱與規格都在附件裡，就先讀資料；受眾未指定而且會影響文案方向，才提出一個關鍵問題。不要因為「需求不完整」就讓使用者重新填一整張表。

可以在草稿中明標的非關鍵假設，不一定需要先停下來；但價格、核准狀態或對外承諾不能靠假設補齊。當使用者只在討論方向時，先提供判斷，不把討論當成執行授權。

我們曾把「自然短句、沿用已核准版本、只問影響結果的缺口」整理進協作偏好。這段描述個人的工作選擇；多人公司仍須由負責人界定哪些工作可自行完成、哪些需要確認。

SKILL.md 範本要包含哪些內容？

Agent Skills 規格以資料夾中的 SKILL.md 為核心，檔案前方需要名稱與用途描述，後方以 Markdown 寫工作方法。資料夾名稱須與 name 一致。以下格式依官方規格整理，工作內容是本文原創教學範本。

---
name: product-draft-check
description: 檢查商品介紹草稿與使用者提供的規格是否一致。用於發布前的文案核對，不負責自動發布或補造商品資料。
---

# 商品草稿檢查

## 輸入
商品草稿，以及使用者確認有效的商品資料。

## 工作方式
1. 先列出實際讀到的來源；讀不到就說明。
2. 逐項核對規格、功效、保固與使用限制。
3. 資料沒有支持的說法，標為待確認，不補猜。
4. 來源衝突時列出各自內容，不按檔案新舊自行裁決。
5. 提供最小修改建議，保留原本受眾與語氣。

## 提問與權限
資料已提供就先檢查，不要求重填。
缺少會影響結論的資料時，指出最關鍵的缺口。
只交付檢查報告，不發布、不覆蓋來源檔案。

## 輸出
原句｜判定｜資料依據｜建議修改或待確認事項。
最後分開列出已核對內容與尚未核對內容。

先保留一個用途，不把寫作、發布、回覆客人全部塞進同一份。會變動的商品規格另存為資料，避免換商品時還沿用前一份數字。

怎麼測試 Skill？正常、缺資料與不該啟用都要看

不要只問 AI「你理解了嗎」。先準備幾個你知道預期行為的例子，再檢查它的實際輸出。下表是待執行的測試設計，不是已跑過的成績。

手機可左右滑動查看完整表格。

先確認工具真的載入該 Skill，再看輸出是否符合預期。能載入但做錯，回查步驟或例外規則；根本沒載入，先查工具支援、入口與用途描述。改一項後重跑原本失敗的例子，也保留一個正常例子，避免修好缺漏卻破壞原本能做的事。

同一套方法在新商品上也可用，才值得擴大。如果你還不容易判斷一份交付是否完成，先看AI 回答不符合需求時，如何補齊任務與驗收。

想依自己的狀況選下一篇，可返回AI 協作入門總覽。