Claude Skills 是什麼？把工作習慣變成 AI 能重複執行的流程

上一篇文章，我整理了如何把一次成功的 AI 對話拆成可重複 Workflow。

當時我回頭整理了這次提供哪些資料、AI 經過哪些步驟、哪裡需要人工判斷，以及什麼結果才算完成，最後才把有效的 Prompt 留進流程。

但 Workflow 整理好之後，還會遇到下一個問題。

每次開啟新的對話，還是要重新告訴 AI：

請先讀哪些文件、按照什麼順序執行、哪些地方不要自己決定、完成後要檢查哪些項目。

流程雖然已經存在，但仍然要靠人記得把它叫出來。

如果每次都要重新交代這些內容，這套 Workflow 可能已經值得升級成 Skill。

Claude Skills 是什麼？

這篇沿用大家常說的「Claude Skills」，正式的規格名稱是 Agent Skills。這套格式最早由 Anthropic 開發，現在已成為開放規格，也能用在其他支援 Agent Skills 的工具。

Skill 可以理解成一套讓 AI 按需載入的工作能力。

除了告訴 AI「這次要做什麼」，它還可以包含：

• 什麼情況應該使用這套流程
• 什麼情況不應該使用
• 任務要經過哪些步驟
• 執行時需要讀取哪些資料
• 產出要符合什麼格式
• 哪些結果需要檢查
• 哪些決定必須留給人

依照 Agent Skills 規格，一個 Skill 是一個資料夾，裡面至少要有一份 SKILL.md。

除了主要指令，也可以加入 scripts、references、assets、模板或其他任務需要的資源。Agent 會先讀取 Skill 的名稱與描述，等任務符合使用條件時，再載入完整指令與需要的檔案。

最簡單的結構大概會長這樣：

article-publishing-check/
├── SKILL.md
├── references/
│   ├── seo-aeo-geo-spec.md
│   └── brand-writing-style.md
├── assets/
│   └── review-report-template.md
└── scripts/
    └── validate-frontmatter.js

資料夾只是外殼。你仍要先把工作整理成一套步驟清楚、能重複執行，也能檢查結果的流程。

Prompt、Workflow、CLAUDE.md 和 Skill 差在哪？

這幾個名詞很容易混在一起，但它們處理的是不同層級的問題。

例如，我請 AI 檢查一篇 Level UP 專欄文。

Prompt 可能是：

請檢查這篇文章是否適合上稿，並找出需要修改的地方。

Workflow 則會把檢查流程整理出來：

讀取文章
→ 判斷文章類型
→ 檢查 Frontmatter
→ 檢查內容結構
→ 檢查資料來源
→ 檢查圖片與內部連結
→ 輸出修改清單

CLAUDE.md 可能會放整個網站長期適用的規則：

不要自行建立新的文章分類。
不要更改與任務無關的頁面。
修改後必須執行網站建置檢查。

Skill 則會進一步定義：

什麼時候啟動文章上稿檢查
需要讀取哪些品牌與上稿規格
不同文章類型應該檢查哪些內容
輸出要分成哪些層級
哪些地方只能提出建議，不能直接修改

所以，Workflow 和 Skill 最大的差別是：

Workflow 描述一件事應該怎麼做，Skill 則讓 AI 知道什麼時候要使用這套做法，以及執行時要搭配哪些資料、工具與限制。

Skill 比長 Prompt 多了什麼？

剛開始接觸 Skill 時，很容易把自己常用的長 Prompt 貼進 SKILL.md，然後就認為已經建立完成。

這樣確實可以減少複製貼上，但觸發條件、參考資料和驗證方式仍然缺了一塊。

一套比較完整的 Skill，至少要補上四個部分。

1. 觸發條件

AI 要知道哪些任務符合這個 Skill。

例如：

檢查 Level UP 官網文章上稿品質時使用。

但只寫到這裡還不夠。

比較清楚的寫法會包含：

檢查 Level UP 官網文章的 Frontmatter、SEO、AEO、GEO、來源、圖片、FAQ 與內部連結時使用。

不要在撰寫初稿、一般文字潤飾或 Threads 文案任務中使用。

Skill 的 description 很重要，因為 Agent 通常會先依靠名稱與 description 判斷是否需要載入完整內容。描述太廣，可能在不相關的任務中被啟動；描述太窄，真正需要時又可能找不到。

2. 執行流程

Skill 要把真正重要的步驟寫清楚。

哪些事情一定要先做，哪些事情可以依照情境判斷，不能全部只寫成模糊建議。

例如：

1. 先讀完整文章，不要看到開頭就開始修改。
2. 判斷文章屬於工具教學、工作流、觀念拆解、比較、避坑或實作紀錄。
3. 依文章類型選擇需要的檢查模組。
4. 檢查固定 Frontmatter 與事實來源。
5. 輸出必改、建議修改與已通過項目。
6. 未經使用者要求，不要直接重寫整篇文章。

3. 參考資料

很多工作除了流程，還需要背景資料。

例如檢查 Level UP 的文章時，AI 還需要知道：

• 官網文章的 SEO、AEO、GEO 規格
• 品牌定位與目標受眾
• 文章分類與欄位規則
• Level UP 的寫作語氣
• 封面與內文圖片規格

這些資料可以分開存放，不必全部塞進 SKILL.md。

Agent Skills 採用漸進式載入。Skill 的名稱與 description 會先被讀取，完整指令只在 Skill 啟動後載入，references、scripts 或 assets 則在執行到需要的階段時再使用。

這樣可以避免每次任務都把大量不相關資料放進 Context。

4. 驗證方式

一次成功不足以證明 Skill 已經穩定。

你還需要知道：

• AI 有沒有真的按照步驟執行
• 哪些檢查項目經常被漏掉
• 輸出格式是否穩定
• 任務不符合時，Skill 會不會被錯誤觸發
• 加入 Skill 後，結果是否真的比原本好

可以程式化驗證的項目，盡量不要只靠 AI 自己判斷。

例如：

• Frontmatter 是否缺少欄位
• slug 是否符合格式
• 圖片路徑是否存在
• FAQ 數量是否正確
• 內部連結是否失效
• 建置指令是否通過

依照 Agent Skills 的腳本使用指南，能固定重複執行的檢查可以整理到 scripts，減少每次重新生成相同的驗證邏輯。

什麼樣的 Workflow 值得做成 Skill？

只有一部分 Workflow 值得繼續升級。

我會先確認五件事。

1. 這項工作會不會重複出現？

只執行一次的任務，通常直接使用 Prompt 就夠了。

例如臨時整理一份旅行清單、替一次活動想名稱，沒有必要特別建立 Skill。

2. 每次是否都經過相似步驟？

Skill 適合處理「每次情境不同，但做事方法相似」的任務。

例如：

• 每次寫的文章主題不同，但上稿檢查流程相似
• 每次 Review 的程式碼不同，但安全與品質檢查項目相似
• 每次分析的公司不同，但資料來源與報告結構相似

3. 是否經常重複提供同一批資料？

每次都要重新上傳品牌文件、檢查清單、報告模板或技術規格，代表這些內容可能適合整理到 Skill 的 references 或 assets。

4. 產出是否有完成標準？

例如：

• 所有必要欄位都存在
• 測試與型別檢查通過
• 報告包含固定段落
• 所有數字附上資料來源
• 高風險項目被標示出來

沒有完成標準，AI 很難判斷什麼時候應該停止。

5. AI 做錯時能不能被發現？

這是我覺得最重要的一點。

Skill 可以讓一套流程執行得更頻繁，但也可能讓錯誤被更頻繁地複製。

如果結果沒有辦法被檢查，或錯誤發生後很難發現，就不適合直接交給 AI 自動執行。

可以先用這張表判斷：

怎麼從 Workflow 升級成 Skill？

我會把這個過程拆成六個階段。

第一步：找到一直重複的工作

不要先從「我要做一個 Skill」開始。

先回頭看自己實際使用 AI 的過程：

• 哪些指令每次都要重新貼
• 哪些背景資料每次都要重新提供
• 哪些錯誤一直提醒 AI 不要再犯
• 哪些檢查清單每次都相同
• 哪些輸出格式每次都要重新說明

我會優先處理自己已經重複做過很多次的工作，不會從網路上最熱門的題目開始。

第二步：先把它整理成 Workflow

先寫出：

輸入是什麼
→ 經過哪些步驟
→ 哪裡需要判斷
→ 會得到什麼輸出
→ 如何確認完成

這一步說不清楚時，先繼續整理 Workflow，再考慮寫 SKILL.md。

Skill 適合承接已經逐漸穩定的做法，再把它整理成 AI 能理解與重複使用的形式。

第三步：先手動跑幾次

先用一般 Prompt 或 Workflow 實際執行。

每次完成後記錄：

• AI 最常漏掉哪個步驟
• 哪些規則根本沒有被遵守
• 哪些步驟其實不需要
• 哪些情況需要另外分支
• 哪些地方一定要人工判斷

不要把只成功過一次的做法，立刻當成穩定流程。

一次成功可能只是當下提供的資料、對話脈絡與模型剛好配合。

重複跑過幾次後，才比較看得出真正有效的是哪一部分。

第四步：定義使用時機

接著要回答兩個問題：

什麼時候使用這個 Skill？
什麼時候不要使用？

例如 Level UP 上稿檢查 Skill：

---
name: levelup-article-review
description: >
  Review completed Level UP blog drafts before publishing.
  Use when checking frontmatter, SEO, AEO, GEO, sources,
  images, FAQ, internal links, and publishing readiness.
  Do not use for writing first drafts, Threads posts,
  or general sentence-level proofreading.
---

description 決定了 Skill 的任務入口與觸發範圍。

它需要讓 Agent 知道：

• 任務要出現哪些特徵
• 哪些相似任務不屬於它
• 這套 Skill 能提供什麼額外能力

第五步：拆分指令與資源

核心流程放在 SKILL.md，詳細資料放到 references，固定格式放到 assets，可以程式化的檢查則交給 scripts。

例如：

levelup-article-review/
├── SKILL.md
├── references/
│   ├── publishing-checklist.md
│   ├── seo-aeo-geo-spec.md
│   ├── brand-background.md
│   └── writing-style.md
├── assets/
│   └── review-output-template.md
└── scripts/
    └── validate-frontmatter.js

SKILL.md 應該保持聚焦。

它只要負責告訴 Agent：

• 任務如何開始
• 依什麼條件選擇資料
• 執行順序是什麼
• 哪些規則不能省略
• 最後怎麼輸出結果

Agent Skills 的建立建議也提到，SKILL.md 應保持聚焦，詳細內容可以移到個別參考檔案，並清楚說明什麼情況需要讀取。

第六步：用失敗結果修改 Skill

Skill 建立後，仍要繼續觀察流程是否穩定。

實際使用時，可能會發現：

• 需要使用時沒有被觸發
• 不相關任務反而被觸發
• AI 沒有讀取指定的參考資料
• 執行到一半跳過檢查
• 輸出格式每次都不一樣
• AI 擅自做了應該留給人的決定

遇到這些情況時，要先判斷問題發生在哪一層：

觸發錯誤
→ 修改 name 或 description

步驟被跳過
→ 調整 SKILL.md 的流程與優先級

資料沒有被讀取
→ 明確寫出讀取時機與檔案路徑

結果無法檢查
→ 加入完成標準或驗證 script

需要太多例外
→ 拆成兩個不同 Skill

每次流程失敗後，都把原因整理成下一版更清楚的工作規則，Skill 才會逐漸穩定。

實際案例：Level UP 專欄上稿檢查 Skill

以我目前寫 Level UP 專欄的流程來說，文章完成後不會直接上稿。

我還需要檢查：

• Frontmatter 是否完整
• 標題、摘要與 slug 是否一致
• 文章類型需要哪些內容模組
• 時效性資料是否查過原始來源
• 比較表、流程與案例是否對得上
• 圖片檔名、alt 與插入位置是否正確
• FAQ 是否重複正文
• 是否有適合的站內延伸閱讀
• 語氣是否像實作者，避免寫成百科或產品廣告

原本我可以把這些內容整理成一份 Workflow：

完成初稿
→ 判斷文章類型
→ 檢查固定欄位
→ 選擇內容模組
→ 驗證資料與連結
→ 檢查圖片
→ 檢查語氣
→ 輸出上稿報告

但升級成 Skill 之後，還會多出幾個能力。

Skill 知道什麼時候啟動

它只在檢查已完成的 Level UP 官網文章時使用，不會在寫 Threads、想標題或撰寫第一版初稿時啟動。

Skill 知道要讀哪些資料

它會依照任務讀取上稿檢查表、SEO 規格、品牌背景、寫作風格與網站欄位規則。

Skill 知道怎麼判斷文章

工具教學、工作流教學、觀念拆解、比較文、避坑文與實作紀錄，需要的段落並不相同。

它不會為了套模板，強迫每篇文章都加入相同的比較表、FAQ 或操作步驟。

Skill 知道輸出格式

最後可以固定整理成：

一、必須修改
二、建議調整
三、資料或來源待確認
四、圖片與上稿設定
五、已通過項目

Skill 知道哪些事情不能直接做

例如：

• 不自行建立文章分類
• 不把作者經驗改寫成沒有來源的普遍結論
• 不直接刪除有個人風格的段落
• 不在未確認的情況下更改文章立場
• 不為了 SEO 重複堆疊關鍵字

做到這裡，Skill 已經包含使用時機、執行流程、參考資料、判斷方式、輸出格式與修改邊界。

Skill 建好之後，怎麼知道它真的有效？

Skill 仍可能讓結果變差。

SkillsBench 在多領域任務中發現，人工整理的 Skills 平均提升了 16.2 個百分點的任務通過率，但不同領域與任務差異很大，部分任務加入 Skill 後反而表現下降；由模型自行生成的 Skills，也沒有帶來穩定改善。

SWE-Skills-Bench 針對真實軟體工程任務測試後也發現，多數受測 Skills 沒有提高通過率，過時或與專案不相容的指引甚至可能降低表現。

Skill 的數量不是品質指標。

我會檢查：

最簡單的測試方式，是準備幾個固定任務：

應該觸發的任務
不應該觸發的相似任務
正常案例
缺少資料的案例
容易出錯的邊界案例

固定任務要重複測試，單次成功還不夠。

建立 Skill 時常見的錯誤

把所有規則都塞進同一個 Skill

文章撰寫、文章檢查、封面規劃、Threads 改寫與網站上稿，雖然都和內容有關，但不一定需要放在同一套 Skill。

範圍太大，會讓觸發條件變得模糊，執行時也更容易混用規則。

一個 Skill 先處理一類清楚的任務，通常比較容易測試與維護。

流程還沒跑順就急著封裝

如果每次執行時都需要大幅改變步驟，代表這套 Workflow 還在探索階段。

這個階段先記錄實際做法與失敗原因，等步驟穩定後再整理成固定規則。

只寫操作步驟，沒有完成標準

操作步驟和完成標準需要分開寫清楚。

每套 Skill 最好都要說清楚：

• 哪些條件必須通過
• 哪些問題可以保留
• 哪些情況要停止並詢問
• 哪些結果需要人工確認

直接安裝沒有檢查的外部 Skill

Skill 可能包含 scripts、外部指令、檔案操作與環境存取。

加入陌生 Skill 前，至少應該：

1. 讀完整的 SKILL.md
2. 檢查 scripts 裡的程式
3. 確認它會讀取或修改哪些檔案
4. 查看發布者與更新紀錄
5. 先在低風險或可丟棄的專案測試

不要只因為 Skill 名稱看起來符合需求，就直接放進正式專案。

參考資料

• Agent Skills 規格
• Agent Skills 建立建議
• SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks
• SWE-Skills-Bench: Do Agent Skills Actually Help in Real-World Software Engineering?

總結：先把流程跑順，再把工作方式交給 AI

如果只記得一件事：

Workflow 是把工作步驟整理清楚，Skill 則是把一套已經跑順的 Workflow，加上觸發條件、參考資料、驗證方式與執行邊界，變成 AI 能在正確情境重複使用的能力。

剛開始不需要急著建立很多 Skill。

先觀察自己每次使用 AI 時，哪些規則一直重複、哪些資料一直重新提供、哪些錯誤一直發生。

挑一項低風險、會重複、結果能檢查的工作，先把它跑成穩定 Workflow，再整理成第一個 Skill。

當這些流程逐漸被保留下來，你會累積出一套可以持續修改、重複使用，也能交給不同 AI Agent 執行的工作方式。

不過，把流程做成 Skill，只代表 AI 更容易照著同一套方法執行。

AI 仍可能選錯流程、漏掉規則，或產出不能直接使用的結果。

下一步要處理的是：

Coding Agent 為什麼會在執行過程中逐漸失控？我們又該怎麼透過指令、權限、測試與人工檢查點，把風險限制在可控範圍內？