Claude Skills 完整指南：打造專屬 AI 工作流

每天打開 Claude，前十分鐘往往都在「重新教它一次」：重新貼品牌語氣、重新交代輸出格式、重新解釋你這次的目標讀者是誰。不少內容團隊都把這段重複勞動當成「必要的暖機」，撐一下就過去了。但換句話說，這十分鐘從來都非必要，真正的問題在於你還沒把一次性的提示詞，升級成可重用的「能力」。

核心重點：Claude Skill 是一個包含指令、腳本與參考資源的資料夾，用來封裝可重複使用的工作方法。支援 Skills 的 Claude 介面會依名稱與 description 判斷何時載入。它不是模型或獨立 App，也不只是加長版提示詞；可把它理解成一份帶工具與素材的操作手冊（見 Anthropic 的〈What are Skills?〉說明）。

要解決的並非「Claude Skill 是什麼」這個入門問題，而是一個更實務的問題：怎麼從零開始，把 Skill 做成一項可用、穩定、能交給團隊的資產，再讓多個 Skill 串成真正跑得動的工作流程。如果完全沒聽過 Claude Skills，可以先把它想成「可重用的進階版提示詞」，再往下讀會順很多。

你每天在浪費的，是「設定成本」

常見的重複設定有三類：語氣、輸出格式與任務脈絡。不同 Claude 產品可能提供 Projects、偏好或其他持續性設定，但不應假設先前對話一定會把完整工作程序帶進每個新任務；Skill 的價值在於把程序明確版本化並重複使用。

問題不在 Claude 笨，問題在於你把「知識」當成「對話」在處理。知識應該被儲存、被版本管理、被團隊共用；對話則是用完即丟。當你把該儲存的知識塞進對話裡，就會陷入一個死循環：同一套品牌語氣，你講了五十次，每個同事又各自講了五十次，而且每個人講的版本都不一樣。結果產出的內容風格百家爭鳴，你還得回頭逐一校稿。

Skill 要解的，就是這個「設定成本不斷歸零」的問題。你把那三類設定寫進一支 Skill 裡一次，之後只要跟 Claude 說「用我們品牌的語氣寫一篇關於 OLED 電視的開箱」，它就會自動把對應的能力載入。換個比喻：沒有 Skill 的時候，你每次都得把新員工從頭訓練一遍；有了 Skill，等於你把訓練手冊寫好放在架上，新人上工第一天就能照手冊執行。

Skill、Subagent、MCP、Project，四個最容易搞混的東西

這四個名詞在 AI 工具圈被混用得很嚴重，每次討論到 AI 工具，總有人把它們拿來問。先把話說在前面：它們解決的是不同層的問題，混在一起用才會亂。用一張表把它們拆開，你之後判斷「這件事該用哪個」會快很多。

名稱	本質上是什麼	解決的問題	一句話分辨
Skill	一份打包好的「怎麼做」的操作手冊	重複性的設定與流程，每次都要重講	它在教 Claude「做事的方法」
Subagent	一個使用獨立任務脈絡與工具的代理執行單元	複雜任務需要分工或隔離上下文	它不等同於擁有永久記憶
MCP	一個連接外部資料與工具的協定	Claude 需要讀外部系統、呼叫外部功能	它是一條「對外的線」，接資料用的
Project	一個帶知識庫與固定設定的工件區	把某個專案的資料與偏好綁在一起	它是一個「工作專案」，有專屬檔案櫃

Project 通常把特定專案的檔案與指令放在一起；Skill 則把可重複的方法與資源封裝成技能模組，並在支援的介面中按需載入。能否跨專案或跨產品使用，取決於該介面的安裝與權限，不應假設自動可攜。對 MCP 還不熟的人，可以回頭看MCP 入門指南。

這四者並不互斥；在介面支援且權限允許時，Skill 可以搭配 MCP 工具、代理分工與 Project 資料。實際可用組合依產品表面與管理設定而異。

一支 Skill 的解剖圖：那顆決定生死的 description

一支 Skill 是一個資料夾，至少包含 SKILL.md。檔案開頭以 YAML frontmatter 定義 name 與 description，正文則是 Markdown 指令；資料夾也可包含腳本與參考資源（見 Anthropic 官方文件）。

常見問題是正文寫得很細，description 卻過於模糊。Claude 會先載入 Skill 的名稱與 description，判斷相關時才讀取完整 SKILL.md，之後再按需讀取其他資源；這就是漸進式揭露（progressive disclosure），機制細節見 Anthropic 官方文件。

換句話說，description 就是這支 Skill 的「履歷自傳」，Claude 是面試官，它只看自傳決定要不要約你來面試。自傳寫得模糊，正文再精彩也沒人看得到。實務上的判斷標準很簡單：把 description 拿給一個完全不懂這個專案的同事看，如果他看完講不出「這支 Skill 大概會在什麼時候被叫出來」，那就是不及格。一份好的 description，至少要回答三件事：它能做什麼、它在什麼情境下該被觸發、它不處理哪些事（這點很多人漏掉，但它正是防止誤觸發的關鍵）。

正文的部分，建議用「條件式的指令」來寫，別用「敘述式的說明」。差別在哪？敘述式會寫「我們的品牌語氣是親切專業」，條件式會寫「如果使用者要你寫社群短文，語氣要比部落格文章再活潑一點；如果是要寫產品頁文案，語氣要收斂、少用語助詞」。後者告訴 Claude「在什麼條件下做什麼」，前者只是給了一段背景知識，Claude 不知道怎麼把知識對應到動作。

從零打造第一支 Skill：實用的六步流程

實務上常看到很多人一上來就想寫一支「無所不能」的 Skill，結果寫了三百行沒人敢改。把流程拆成六步，每一步都有一個明確的產出，照著走可以避開九成的過度設計。

1. 先觀察，不要急著寫。連續兩週，把你每次手動重打的設定記下來，不管是貼在備忘錄還是截圖。你會發現真正高頻的其實就那三到五個場景，其他都是偶發。Skill 是給高頻場景用的，偶發的不要做。
2. 挑一個最痛的場景，把那一次的完整對話存下來。這份「黃金對話」就是你的草稿來源，因為它已經被你反覆修正到能用了，比從空白開始寫可靠得多。
3. 把對話拆成三塊：前置知識、判斷規則、輸出規範。前置知識是品牌資產（語氣、禁用詞、目標讀者）；判斷規則是「遇到什麼情況走什麼路線」；輸出規範是格式、長度、結構。這三塊的邊界清楚，之後要改才不會牽一髮動全身。
4. 先寫 description，再寫正文。這個順序很重要。先把「這支 Skill 什麼時候被觸發」講清楚，你才知道正文該放什麼、不該放什麼。先寫正文的人，到頭來都會回頭把正文砍掉一半。
5. 用正例、反例與邊界案例做盲測。不要明說「用那支 Skill」，記錄是否正確觸發與是否誤觸。三個案例只能當起點，沒有「三次中兩次」的官方及格線。
6. 命名要讓半年後的你還看得懂。命名建議用「動詞＋物件」的結構，例如 write-blog-post、check-seo-meta。看著名字就知道它在做什麼，比 helper-v2 這種命名好維護一百倍。

這六步看起來很保守，但它背後的精神是：一支 Skill 的價值，關鍵在於它多久會被正確地用到一次，至於寫得精不精巧，反倒不重要。寧可你做一支很樸素但天天被叫到的 Skill，也不要你做十支華麗但半年沒人碰的。前者是資產，後者是債。

description 寫壞了，整支就廢了：收窄還是擴寫？

Skill 有時不觸發或叫錯支，description 是優先檢查項目之一，但不是唯一原因；產品介面、可用工具、上下文、正文衝突與安裝狀態也可能影響結果。

典型的過寬寫法，是把觸發條件寫成「所有跟內容有關的事都交給我」。它可能與其他 Skill 重疊，也可能把不相關任務套進錯誤流程。修法是補上明確觸發情境與邊界；排除情境是實務上的好做法，但不是 SKILL.md frontmatter 的必填欄位。

那什麼時候反而該擴寫呢？當一支 Skill「從來不被觸發」的時候。這通常是 description 只寫了它能做什麼，卻沒寫它在哪些情境下會被需要。Claude 是看著 description 跟你的任務做比對的，你只說「會寫文案」，但它不知道你現在這個「幫我把這段技術規格翻成消費者語言」的任務跟寫文案有關。擴寫的方向是補上「使用時機」這一塊，把幾個典型的觸發情境具體寫出來。

症狀	大概率的病因	該做的動作
該觸發卻沒觸發	description 只寫能力，沒寫時機	擴寫，補上典型觸發情境
該用 A 卻用 B	兩支 description 重疊度太高	收窄，各自寫清邊界
什麼都被它攔走	description 範圍太貪心	收窄，明列排除情境
觸發了但產出不對	description 沒問題，是正文條件不足	不要動 description，去補正文規則

這張表可以當作一份急救手冊，排查 Skill 失靈的時候，都從這四個症狀開始問起。九成的狀況都在這張表裡，剩下的一成通常是 Skill 之間互相打架，那就要動到下一節會講的「編排」問題了。

五支 Skill 串成內容流程：一個示意佈局

單支 Skill 解決重複設定；多支 Skill 也可組成內容流程。以下用一個內容團隊作為示意：分別用 Skill 處理部落格、社群短文、EDM、客服回覆與產品頁文案。是否真的自動串接，仍取決於你使用的介面、工具與編排方式。

這個佈局最關鍵的設計，是「共用一組品牌資產，但各自有獨立的輸出規範」。五支 Skill 共享同一份品牌語氣設定、同一份禁用詞清單、同一份目標讀者輪廓，所以不管產出什麼形式，品牌一致性都不會跑掉。但每一支對「長度、結構、語氣強度」的要求完全不同：部落格要深度、社群要鉤子、EDM 要行動呼籲、客服要安撫、產品頁要轉換。這種「共用核心、各自變形」的結構，是內容團隊用 Skill 擴大產量又不失格的關鍵。

用一張表把這條產線的上下游關係畫出來，你可以把它當成自己團隊佈局的參考：

Skill	主要任務	輸入從哪來	產出給誰
部落格文章	把一個主題寫成深度長文	主題清單、關鍵字研究	社群短文（拆點）
社群短文	把長文拆成三到五則鉤子	部落格文章產出	EDM（挑一則當主題）
EDM	把一個主題包成信件版的行動呼籲	社群短文、活動資訊	訂閱名單
客服回覆	用品牌語氣回覆常見問題	FAQ 知識庫	顧客
產品頁文案	把服務規格轉成消費者語言	服務清單、價格	官網訪客

你會發現，這條產線最上面的「部落格文章」是源頭，它餵養了下游的社群與 EDM。這就是為什麼要強調把 Skill 當資產管（後面會講），因為只要源頭那一支的品質控管好，下游的社群與 EDM 幾乎是自動化的。一個觀念釐清：這裡講的「產線」跟 內容行銷策略 裡談的「內容引擎」是同一件事的兩個層次，策略層決定要生產什麼、給誰看，Skill 層負責把策略落地成可重複執行的產出流程，兩者缺一不可。

什麼該寫進 Skill，什麼該餵給它讀：知識的兩種邊界

很多人做 Skill 的第一個大失誤，是把它當成「什麼都能塞」的垃圾桶：品牌故事塞進去、產品規格塞進去、客戶問答塞進去、上個月的活動記錄也塞進去。結果一支 Skill 越長越肥，改一個價格要在三個地方同步，token 越吃越兇，Claude 還常常讀到一半就漏掉關鍵規則。要避開這個陷阱，你得先分清楚兩種知識的邊界。

第一種是「程序性知識」，回答的是「怎麼做」。例如品牌語氣該怎麼拿捏、一篇開箱文的結構怎麼排、遇到客訴要按什麼順序回應。這類知識的特徵是：變動頻率低、具有判斷性、需要 Claude 去理解後靈活運用。這種東西就該寫進 Skill，因為它是「能力」的一部分，寫進去之後 Claude 才會帶著這個能力去做事。

第二種是「陳述性知識」，回答「是什麼」。穩定、非機密的參考資料可以直接放在 Skill 資料夾中，讓 Claude 按需載入；價格、庫存、促銷或其他經常變動的事實，則適合放在受管理的外部來源，執行時讀取。機密資訊不應明寫在 Skill 或一般參考檔中。想了解動態檢索，可讀RAG 背後意義與 SEO 應用。

判斷維度	程序性知識（寫進 Skill）	陳述性知識（外部檔案，執行時讀取）
回答的問題	怎麼做	是什麼
變動頻率	低（語氣、結構、流程）	高（價格、活動、名單）
Claude 的角色	理解後靈活運用	查到後如實引用
改錯的代價	改一支 Skill 就好	若寫死，要逐支翻找同步

把這條邊界想清楚，你的 Skill 會瘦下來、穩下來、好維護。一個簡單的檢查法：把 Skill 裡每一句話問自己「這句話三個月後還會一樣嗎？」。答得出「會」的，留著；答「不一定」的，搬到外部檔案。這個動作建議每季做一次，就像幫 Skill 做健康檢查，把悄悄混進來的陳述性知識清出去，讓 Skill 回到它「純粹的能力」本質。

讓 Skill 帶腳本：把 AI 不擅長的事交給程式碼

很多人以為 Skill 只能寫文字指令，其實一支 Skill 可以附帶腳本（script），也就是一小段程式碼。這件事的價值不在「讓 Skill 更酷」，而在於它解決了一個根本矛盾：語言模型是機率性的，它擅長理解、判斷、生成，但它不擅長需要百分之百確定的事，例如算數字、做格式轉換、查一個固定不變的對照表。

例如「檢查 SEO 中繼資料」的 Skill，可以讓文字指令負責判斷與建議，腳本負責按明確規則計算字元或解析欄位。腳本通常較可重現、可測試，但仍可能有程式錯誤、編碼差異或規則過時，不能宣稱零誤差；要準備測試案例與錯誤處理。

這個分工帶出一個重要的判斷原則：當一個步驟的「正確性」比「靈活性」重要，就應該考慮用腳本；當一個步驟需要的是「判斷」而非「計算」，就留在文字指令裡。反過來說，如果你發現自己在 Skill 的正文裡寫了一堆「如果等於 A 就輸出 B、如果等於 C 就輸出 D」的硬對照，那通常是一個訊號：這部分其實更適合用腳本來做。想深入理解模型能力的邊界，可以回頭看這篇談 AI 幻覺成因與避免技巧的解析，弄清楚哪些錯誤是模型結構性的限制，哪些是你可以靠設計繞開的。

簡單腳本可由 Claude 協助起草，但使用者仍要看懂權限、輸入輸出、依賴與失敗情境，並在隔離環境測試後再納入 Skill。若工作會碰到命令列工具，可先讀CLI 命令列入門。想把帶腳本的 Skill 放進真實的開發環境執行，可以再搭配Claude Code 中文教學，從終端機的安裝與專案設定開始熟悉。

Skill 為什麼會失靈？五個最常見的故障點

Skill 不像傳統軟體會直接報錯，它的失靈往往很安靜：沒有彈窗、沒有錯誤碼，就是靜靜地給你一個「差一點但不對」的結果。這種安靜的失敗最危險，因為你會以為它在正常運作，直到累積出一堆要回頭改的內容。把最常見的五個故障點整理出來，每個都附上判斷方法與修復方向。

故障點	你會看到的現象	判斷方法	修復方向
description 過窄	明明該觸發卻不觸發	換三種說法描述同一任務，看是否都不觸發	擴寫時機欄位
正文規則互相矛盾	產出時好時壞，找不到規律	逐一停用規則測試，找出打架的那條	合併或排序規則，標明優先級
前置知識過時	用了已經淘汰的產品資訊或價格	檢查 Skill 內嵌的事實型內容	把會變動的事實移到外部檔案
Skill 之間搶觸發	同一個任務每次叫到不同的 Skill	列出所有相關 Skill 的 description 比對	收窄重疊處，畫清邊界
上下文被塞爆	Skill 產出變短、開始省略步驟	檢查是否一次載入太多 Skill	拆任務，分次處理

這五個裡面，最陰險的是第三個「前置知識過時」。一支 Skill 往往會內嵌一些事實型內容，例如「我們目前主打的方案有三個」或「客服信箱是某某」。這些資訊一旦變動，Skill 不會自己更新，它會繼續用舊的事實產出，而且語氣依然流暢自然，你根本察覺不到它在過時。實務上的習慣是把所有「會變動的事實」從正文裡抽出去，改放在一個獨立的參考檔案，Skill 在執行時再去讀那個檔。這樣一來，價格調了、方案改了，你只要改一個檔案，所有 Skill 同步更新，不必逐支翻找。這跟前面談的「知識兩種邊界」是同一件事的兩面：把陳述性知識移出 Skill，故障點自然就少一個。

把 Skill 當資產管：版本、命名、團隊協作

一支兩支 Skill 的時候，你怎麼管都行，放在桌面也無所謂。但當你的團隊累積到十幾支，問題就會一一浮現：誰改了什麼、為什麼改、現在用的是哪一版、新同事要怎麼知道有這些 Skill 存在。這時候如果你還把 Skill 當成一堆散落的檔案，遲早會亂成一鍋粥。正確的態度是：把 Skill 當成內容資產來管，跟你的品牌識別手冊、SOP 文件放在同一個位階。

第一件該建立的是「命名規範」。前面提過用「動詞＋物件」的結構，這裡再補一層：跨團隊共用的時候，前面加上團隊或職能的前綴，例如 content-write-blog、cs-reply-faq。這樣一來，看檔名就知道它屬於哪個職能、做什麼事，新人 onboarding 的時候，光看目錄結構就能掌握整個團隊的能力地圖。

第二件是「版本紀錄」。每次改動 Skill，不管多小，都該留下「改了什麼、為什麼改、誰改的」。這麼做是為了未來的你，走流程只是順便。實務上很常出現這種狀況：一支 Skill 上個月還好好的，這個月產出變調，原因就是某次有人「順手」調了一條規則，卻沒有人記得調過什麼。有版本紀錄，你三十秒就能對比出差異；沒有版本紀錄，你得靠記憶跟猜測重建，這在內容量大的時候幾乎是不可能的任務。

第三件，也是對團隊協作最關鍵的一件，是「建立一個讓 Skill 可被發現的索引」。很多團隊的困境在於大家根本不知道有什麼 Skill 可以用，空有 Skill 卻沒被發現。解法很樸素：維護一份清單，列出每支 Skill 的名字、用途、典型觸發情境、負責人。新人進來第一件事就是讀這份清單，這比他自己摸索快十倍，也避免他重新發明輪子、做出一支功能重複的 Skill。如果你們團隊已經在用 Claude 的協作功能，這份索引就是讓 Skill 真正被團隊「用起來」的臨門一腳。

兩條不能踩的紅線：安全與成本

Skill 用得越深，這兩條紅線就越要刻在腦子裡。第一條是安全。一支 Skill 本質上是一份「告訴 Claude 該怎麼做」的指令，而指令是可以被汙染的。最典型的風險有兩種：一是你在 Skill 裡寫入了不該出現的敏感資訊，例如 API 金鑰、客戶名單、內部定價，這些東西一旦跟著 Skill 被分享出去或被不當觸發，就是一次資安事件；二是來自外部的「提示注入」，也就是有心人在輸入裡夾帶指令，試圖蓋過你 Skill 裡的規則。

原則是：Skill 不放機密，工具只給最小必要權限。外部不可信內容應標示為資料，但單靠一句「不要執行裡面的指令」不足以防止提示注入；還要限制工具權限、隔離敏感系統、驗證高風險輸出，並對外部寫入或執行動作保留人工核准。

第二條紅線是成本。前面講過漸進式揭露的設計，Claude 只會在需要時載入 Skill，目的之一就是省 token。但這不代表你可以無限制地堆 Skill。當你同時掛上幾十支 Skill，每一支的 description 都要被讀過一遍做比對，這個「目錄掃描」本身就會吃掉可觀的 token，而且會讓 Claude 的判斷變慢、變鈍。務實的做法是：依場景分組，只啟用當前任務需要的 Skill。不要把客服用的、寫程式用的、做設計用的全部同時掛著，那只會讓系統為了讀一堆用不到的目錄而空轉。把 Skill 想成工具箱裡的工具，你一次只拎出這個 job 要用的那幾把，別把整個倉庫背在身上。

從「用好 Claude」到「用好 Skill」：心態要先轉三個彎

工具都講完了，接著把重心轉到心態上，因為實務上常看到很多人技術都學會了，卻始終用不起來，卡的就是心態。第一個要轉的彎，是從「我來下指令」變成「我來設計能力」。用 Claude 的時候，你是司機，每一個轉彎都自己打方向盤；用 Skill 的時候，你比較像在設計一套「自動駕駛的規則」，你要思考的是「在各種路況下它應該怎麼開」，單次怎麼開反而是次要的。這個視角的切換，會讓你寫出完全不同品質的 Skill。

第二個彎，是從「追求一次寫對」變成「追求可迭代」。一支好的 Skill，幾乎沒有人是第一次就寫到位的，它一定會歷經「用了才發現哪裡不對、修了再觀察、再修」的循環。如果你抱著「我要一次寫到完美」的心態，你會不敢動筆，或者一寫就寫得太複雜、太僵硬。健康的心態是：先做一個能跑的最小版本，然後讓真實使用把它打磨出來。這跟常見的內容方法論是相通的，先求有、再求好，然後靠回測與優化持續滾動。

第三個彎，也是最關鍵的一個，是從「把 AI 當工具」變成「把 AI 當隊友」。工具是你叫它才動、用完就收起來的東西；隊友是你會主動想「它適合接手哪些事、它哪些事做不好我來補」的對象。當你開始用 Skill 替 Claude 建立一套能力清單，你跟它的關係就從「每次重新交代」升級成「長期培養默契」。這聽起來有點玄，但實際的效益非常具體：產出更穩定、品質更一致、你從重複勞動裡被釋放出來，去做只有人能做的判斷與創造。想再往上一層，把這種「隊友關係」發展成會自己規劃、自己執行的代理人，可以參考這篇 AI Agent 運作原理與工具推薦的指南，那是 Skill 之上更進一步的境界。

怎麼知道一支 Skill 真的成功了？三個夠用的指標

另一個很多人沒想清楚的問題：一支 Skill 做完之後，你怎麼知道它「成功了」？很多人的直覺是「產出看起來不錯就算成功」，但這個標準太主觀，也很容易自我欺騙。實務上用三個樸素但夠用的指標來判斷，三者都成立，這支 Skill 才算真的活下來。

第一個指標是觸發準確率。用真實任務、應觸發案例與不應觸發案例計算 precision／recall，再由團隊依風險設定門檻；七成不是通用及格線。測試句要貼近日常說法，並保留固定回歸案例。

第二個指標是事後修改率。一支真正好用的 Skill，它產出的東西你應該只需要微調就能用，而不是整段重寫。如果連續三次你都得把它寫的東西砍掉超過一半重來，那代表正文裡的判斷規則或輸出規範有問題，不是 description 的鍋。事後修改率是品質的試金石，它直接反映「Claude 帶著這份能力，究竟能不能產出堪用的東西」。

第三個指標，也是最容易被漏看的，是採用頻率。一支 Skill 裝上去之後，一個月內被你或團隊實際用過幾次。如果答案是零或一次，不管它寫得多漂亮，它在你這個工作流裡就是失敗的，因為它沒有解決真正的痛點，只是解決了一個你想像出來的痛點。採用頻率低的 Skill，建議直接停用，把心力省下來做別支。資產的定義是「會被用到的東西」，放在架上生灰塵的不是資產，是庫存。

指標	測量方式	及格線	不及格代表什麼
觸發準確率	十個真實任務，自動叫對幾次	由團隊依風險自訂	description 寫不到位
事後修改率	產出要砍掉多少才能用	微調即可，非整段重寫	正文規則有缺陷
採用頻率	一個月實際被用幾次	至少數次	解決的是假痛點，停用

這三個指標的好處是它們都能量化、都能追蹤，而且彼此獨立。一支 Skill 可能觸發很準、但產出不能看（準確率高、修改率也高）；也可能產出漂亮、但根本沒人用（修改率低、採用頻率也低）。三個維度交叉看，你才能誠實地判斷一支 Skill 的健康狀況，而不是靠「感覺還不錯」這種含糊的感覺在自欺。養成這個測量習慣，你做的每一支 Skill 都會比上一支更貼近真實需求。

現在就能做的三個起步動作

講了一整篇方法論，如果你不知道從哪裡下手，就照著這三步走，今天就能把它做完。

1. 花十分鐘，把過去一週你重複貼給 Claude 的內容全部抓出來。品牌語氣、輸出格式、目標讀者設定，這些就是你的第一批 Skill 候選。不用挑選，全列出來，頻率自然會告訴你優先順序。
2. 挑出現最高頻的那一個，照六步流程做一支最小版本的 Skill。不要貪心，就做一支，而且只處理一個場景。做完裝上去，用三天觀察它被觸發的準確度，有問題就用前面那張急救表修。
3. 為這支 Skill 寫一行 description，然後拿給一個不懂這專案的人看。他講得出「這什麼時候會被用到」才算及格，講不出來就回去收窄或擴寫。這個動作看似簡單，卻是一支 Skill 能不能活下來的分水嶺。

Claude Skill 不是一個你學會了就突然爆發生產力的開關，它更像是一份你慢慢累積、越用越順的能力地圖。第一支可能笨拙，但第十支的時候，你會回頭感謝自己當初把那十分鐘的暖機，存成了一份資產。如果你還在摸索 Claude 本身的基本功，這篇 Claude 完整使用指南可以幫你把地基打好；想更全面地比較各種 AI 工具的定位，這份 AI 工具總整理會給你一張清楚的全景圖。地基穩了，Skill 才有地方扎根。

動手吧。先做一支，哪怕它很粗糙。真正會用 Skill 的人，沒有一個是從完美開始的，他們只是比你早開始而已。