半年前照著教學寫好的 Claude Skill，現在可能有一部分內容根本沒被讀到。Anthropic 在 2026 年更新了 Skill 撰寫的最佳實踐指南，新增的規則不只影響新 Skill，也適用於你已經在用的每一個。這篇文章把更新整理成 8 點檢查清單，每一點都附上「怎麼檢查」和「沒過怎麼修」，最後用我們自己的一個 Skill 實際跑一次給你看。
為什麼 Skill 的規則變了
Skills 在 2026 年初推出時，大家學到的寫法是：描述寫清楚、SKILL.md 控制在 200 行內、細節拆到參考檔、指令寫成一步一步的清單。這些到現在仍然成立，但有兩件事變了。
第一，Claude 讀長檔案的方式。Anthropic 的文件現在明確要求，超過 100 行的參考檔要在開頭放目錄，原因是模型讀取長檔案時可能只先看前段，用目錄判斷整份檔案有沒有它需要的東西。重要規則如果放在後半段又沒有目錄，就有可能被略過。
第二，模型本身變聰明了。半年前的模型會跳步驟，所以大家用編號清單和大寫的「重要」反覆強調。現在的高階推理模型剛好相反，為舊模型寫的 Skill 常常太囉嗦，反而讓結果變差。Anthropic 直接建議：如果模型不照某條指令做得更好，就刪掉那條指令。
這兩個變化合起來的意思是，Skill 的品質越來越取決於檔案怎麼排、檢查怎麼跑，而不是指令寫得多詳細。下面 8 點就是依這個方向整理的。
8 點檢查清單
1. 超過 100 行的參考檔要有目錄
規則：任何超過 100 行的參考檔，開頭放一份對應各節標題的目錄。
怎麼檢查：在 skills 資料夾裡列出每個 .md 檔的行數，超過 100 行的逐一打開看第一屏有沒有目錄。
沒過怎麼修：把檔案裡的 H2、H3 標題抄到最上方做成清單。不用超連結，純文字就夠，重點是讓 Claude 在只讀前段時也能知道整份檔案涵蓋什麼。
2. 依任務的脆弱度決定自由度
規則：不是每一步都要寫得一樣細。Anthropic 把這叫做「設定適當的自由度」，分三級：
- 高自由度：只寫目標。例如審閱一份銷售通話紀錄、起草一篇文章，正確做法本來就不只一種，Claude 自己判斷比你規定還好。
- 中自由度：給範本加幾個可調參數。例如每週客戶報告，格式固定，但要不要附圖、輸出 Markdown 還是 HTML 可以選。
- 低自由度：直接給腳本，不准改指令、不准加參數。碰到金錢、刪除、對外寄送的動作都屬於這類，例如開發票、退款、移除會員。
怎麼檢查：逐步問一個問題，「如果 Claude 這一步的做法跟我想的不一樣，會怎樣？」答案是「沒差」就放寬，答案是「會出事」就收緊。
沒過怎麼修：同一個 Skill 可以混用三種級別。開發票的 Skill 裡，寫備註文字的步驟可以放寬，建立發票的步驟就該改成腳本。低自由度幾乎都等於一段腳本，而不是更多文字說明。
3. 用哪些模型跑，就用哪些模型測
規則：Skill 的結果取決於底下的模型，所以要在每一個打算使用的模型上測過，並把測過的模型寫進 YAML front matter。
怎麼檢查：同一個任務分別用 Haiku、Sonnet、Opus 跑一次你最常用的 Skill，比較結果。Anthropic 的文件給每個模型一個問題：Haiku 得到的指引夠不夠？Sonnet 看來清楚有效率嗎？Opus 有沒有被過度解釋拖累？
沒過怎麼修：Haiku 漏步驟，那一步要寫清楚，或乾脆改成腳本，因為腳本在每個模型上跑出來都一樣。Opus 有 Skill 比沒 Skill 還差，就開始刪指令，刪到它變好。如果 Skill 要分享給別人，front matter 一定要註明測過的模型。
4. SKILL.md 控制在 500 行內，按領域拆檔
規則：SKILL.md 本體不超過 500 行，把它當成其他檔案的目錄頁。涵蓋多個領域的 Skill，參考檔要按領域分開。
怎麼檢查：看 SKILL.md 行數，以及參考檔是不是按「什麼時候需要」切分。Anthropic 的範例是一個資料分析 Skill，財務、業務、產品、行銷各一個檔，問營收的問題就不會載入行銷那份。
沒過怎麼修：接近 500 行就拆。拆的原則是「同一個步驟會一起用到的放同一檔」。做客戶報告的 Skill，就是一個客戶一個檔。
5. 參考檔只能一層深
規則：每個參考檔都要從 SKILL.md 直接連過去，不要 SKILL.md 連到 A、A 再連到 B。
怎麼檢查：列出 SKILL.md 提到的所有檔案，再打開每個參考檔看它們有沒有再指向別的檔。只能透過另一個檔才到得了的，就是問題。這件事可以直接叫 Claude 幫你做。
沒過怎麼修：把第二層的檔案也加進 SKILL.md 的連結清單，並說明什麼時候要讀。原因回到第 1 點：鏈結末端的檔案最容易只被預覽前段。
6. 順序重要的流程，給一份會抄進回覆的檢查清單
規則：多步驟且順序有意義的工作，給 Claude 一份清單，讓它複製到回覆裡逐項打勾。
這聽起來跟近期「給目標、不要給步驟」的提示工程建議相反，其實不衝突。清單是給順序有意義的工作用的，例如先驗證資料再做報表。順序不重要就不要列。
怎麼檢查：Anthropic 的範例是研究整理流程，只有五行，每行仍然只寫目標：讀完所有來源、找出主題、整理成綱要、撰寫、驗證引用。關鍵在最後一步寫了「引用不完整就回到第三步」。你的清單裡有沒有這種「失敗就退回」的指令？
沒過怎麼修：在每個可能失敗的步驟後面加一句退回條件。沒有這句，Claude 可能把沒做好的步驟打勾後繼續往下走。
7. 讓 Skill 檢查自己的輸出
規則：產出、對照標準檢查、修正、再檢查，全部通過才算完成。Anthropic 說這個迴圈對輸出品質的改善很明顯。
怎麼檢查：你的 Skill 在產出之後有沒有一個「對照什麼檢查」的步驟？那個「什麼」不一定是程式碼，可以是一份風格指南、品牌語氣文件、或稽核規範。
沒過怎麼修：加一個檢查步驟，並寫明不通過要回到哪一步。更進一步，當草稿因為某個規則沒寫進文件而被退回時，讓 Claude 在結尾提議新規則，你核准後寫進文件，下一次就會檢查這一條。Skill 會隨著使用慢慢變準。
8. 不要假設套件已經裝好
規則：每一段腳本旁邊都放一行安裝指令，寫明套件名稱。
怎麼檢查：找出 Skill 裡所有「用某個工具處理」的句子，看有沒有說那個工具要怎麼裝。
沒過怎麼修：把「用 PDF 工具處理這個檔案」改成「安裝 X 套件後處理這個檔案」。已經裝過的話 Claude 會自己跳過。這一條在你自己電腦上看不出差別，但同事裝了同一個 Skill，第一天會不會壞，就看這一行。
什麼情況先不要動你的 Skill
不是每個 Skill 都值得立刻重整。以下三種情況建議先放著：
- 只有你一個人用、而且結果一直穩定。這 8 點多數是在解決「規模化之後」的問題：換模型、換電腦、換人用。單人單機跑得好的 Skill，重整的效益不高。
- 參考檔都在 100 行以內、沒有任何腳本。第 1、5、8 點對它幾乎沒有影響，只需要看第 3 點和第 7 點。
- 還沒決定要用哪些模型。第 3 點的測試要花時間，如果公司還在評估方案，等方案定了再做。
反過來說，只要 Skill 會交給同事、會碰到金錢或刪除、或者你發現同一個 Skill 在不同模型上結果差很多，就該排進這週的工作。
實際跑一次：我們自己的 SEO 文章流程 Skill
這篇文章就是用我們公司內部的一個 Skill 寫出來的，它負責帶著使用者從選題、客群、關鍵字一路走到產出與 SEO 收尾。我們拿它對照上面 8 點，結果如下：
- 1. 長檔目錄：通過。6 個參考檔都在 30 到 61 行之間，SKILL.md 140 行。
- 2. 自由度分級：部分。寫作步驟是高自由度，輸出格式有範本屬於中自由度，但沒有任何低自由度的腳本，重新打包 .skill 檔這類固定動作目前靠文字描述。
- 3. 模型測試：未通過。front matter 沒有註明測過哪些模型，也只在一個模型上測過。
- 4. 500 行與拆檔：通過。品牌、客群、SEO 檢查、輸出格式各自獨立。
- 5. 一層深：通過。維護說明檔有再提到其他檔，但那些檔都已經從 SKILL.md 直接連過去。
- 6. 檢查清單：部分。流程有 8 個階段和確認點，但沒有要求 Claude 把清單抄進回覆逐項打勾。
- 7. 自我檢查：部分。有寫作規則和回饋日誌，但產出後沒有明確的「對照規則檢查、不過就重寫」步驟。
- 8. 套件安裝：不適用。目前沒有腳本。
三個「部分」和一個「未通過」，就是我們下個版本要改的地方。最值得做的是第 7 點，因為它讓 Skill 從「寫一次」變成「每次使用都在累積規則」。這份檢查花了大約十五分鐘，而且大部分可以叫 Claude 自己做。如果你公司裡已經有超過三個 Skill 在用，這十五分鐘很划算。
常見問題
這些規則是 Anthropic 官方的，還是社群整理的？
大部分來自 Anthropic 官方的 Skill 撰寫最佳實務文件，有繁體中文版。「只預覽前 100 行」這個現象是社群觀察，官方的說法是長檔案要放目錄以便截斷讀取時仍能看到全貌。本文以官方文件為準。
我的 Skill 只在 Claude Code 用，這些規則也適用嗎？
適用。Skills 在 Claude Code、Claude 應用程式和 API 上都是同一套格式，差別只在腳本能不能執行。Claude Code 和 Cowork 可以執行腳本，所以第 2 點和第 8 點對這兩個環境特別重要。
公司沒有工程師，第 2 點的「腳本」做得到嗎？
做得到，但要分清楚哪些步驟真的需要。多數非技術流程的低自由度步驟其實是「固定格式的文字」，例如一段不准改的免責聲明，這用文字就能鎖。真的需要程式執行的動作，例如呼叫發票系統 API，才需要寫腳本，這部分可以請外部協助一次做好。
檢查這 8 點要花多久？
以一個有 5 到 8 個檔案的 Skill 來說，人工檢查約 15 到 30 分鐘。把這篇文章的 8 點貼給 Claude，請它對照你的 Skill 資料夾逐項回報，會更快。
下一步
如果你公司已經有幾個 Skill 在用，建議這週先做兩件事：找出所有超過 100 行又沒有目錄的參考檔補上目錄，然後挑一個最常用的 Skill 用不同模型各跑一次。這兩件事不需要改任何指令，但會直接影響結果的穩定度。
如果你正在評估把公司流程做成 Skill，或已經做了但同事用起來總是出問題，歡迎跟我們聊聊。我們會先看你現有的流程，再判斷哪些步驟適合放寬、哪些該鎖死。
預約一次流程諮詢參考資料：Anthropic 官方文件：Skill 撰寫最佳實務（繁體中文）。本文整理自該文件與社群對更新內容的解說，自家 Skill 的檢查結果為 2026 年 10 月實際執行。
