前言：反正都是「給 AI 讀的規則」，分那麼細幹嘛？

「Skill 不就是一份寫給 AI 看的說明文件嗎？裡面寫規則也好、寫步驟也好，AI 都看得懂，有必要分成兩種類型嗎？」

昨天講完「Skill 的本質是把一次性經驗提煉成可重複套用的規則」，今天要拆解得更細一點：同樣是「規則」，但**「這裡的規矩是什麼」跟「這件事該怎麼一步步做」是兩種完全不同的問題，寫法也該完全不同**。混在一起寫，兩種效果都會打折。

今日目標

• 分清楚 Reference 型（知識型）跟 Task 型（動作型）skill 的本質差異
• 理解判斷依據：這個 skill 要回答的問題是什麼
• 看一組對照，感受用錯類型設計 skill 的具體後果
• 建立「動筆寫 skill 前先問一句」的習慣

兩種類型，回答兩種不同的問題

Reference 型 skill 補充的是慣例、模式、領域知識——它回答的問題是「這裡的規矩是什麼」。內容通常沒有明確的執行順序，讀完之後，AI 知道的是一套判斷標準，不是一串動作清單。例如「API 要用 RESTful 命名、錯誤格式要一致」這類，讀者（不管是人還是 AI）看完就能拿去套用在各種不同情境，不需要照著特定步驟走。

Task 型 skill 給的是逐步操作指令——它回答的問題是「這件事該怎麼一步步做」。內容通常有明確的順序、每一步做完該檢查什麼，甚至可以搭配 disable-model-invocation: true 這種設定，只能被明確叫出來執行，不會在對話裡被自動觸發。例如「部署到正式環境：先跑測試、再打包、再推到目標環境」這種，重點是「照著這個順序做」，不是「理解某個判斷標準」。

判斷依據很單純：如果 AI 讀完這份 skill 之後，該做的事是『套用一個判斷標準到眼前的情境』，這是 Reference 型；如果該做的事是『照著一串步驟執行到底』，這是 Task 型。

用錯類型的具體後果

把 Task 型的內容硬塞進 Reference 型的寫法裡，最常見的後果是步驟被拆散成一堆各自獨立的規則片段，AI 讀完知道每一步該注意什麼，卻抓不到「這些步驟有先後順序、缺一步會出事」。反過來，把 Reference 型的內容硬寫成 Task 型的逐步指令，則容易變成一份看起來很嚴謹、實際上處處是例外的清單——因為知識型的判斷標準本來就不是線性的，硬要編號成「第一步、第二步」，遇到不屬於清單裡任何一種情境的案例，反而讓 AI 不知道該怎麼辦。

用一組對照來看這個差異：

❌ 把「部署流程」寫成 Reference 型：
---
name: deploy-conventions
description: 部署相關的注意事項
---
- 部署前記得跑測試
- 記得先打包
- 記得推到正式環境
- 記得檢查有沒有漏掉環境變數

→ AI 讀完知道有這四件事要注意，
  但抓不到「跑測試沒過，後面幾步就不該做」這種順序依賴，
  也沒有「這是一個完整流程,不是四條各自獨立的提醒」這個框架

✅ 把「部署流程」寫成 Task 型：
---
name: deploy
description: 部署應用程式到正式環境
disable-model-invocation: true
---
部署到正式環境：
1. 跑完整測試套件，全部通過才能繼續
2. 打包應用程式
3. 推到目標環境
4. 確認環境變數是否齊全

→ AI 讀完知道這是一個有先後順序、
  中途卡關就該停下來的流程，
  而且明確標記「只能被明確呼叫，不會自己跳出來執行」，
  避免 AI 在不該部署的時候把這個流程當成參考規則套用

這兩種寫法的差別，不是格式上的美觀問題，是「AI 讀完會不會誤判這份 skill 該怎麼被使用」的實質問題。 Reference 型被誤寫成一串步驟，AI 可能會機械式地照著跑，即使當下情境根本不需要走完整套流程；Task 型被拆成零散的判斷提醒，AI 可能會漏掉步驟間的依賴關係，跳著做、做一半就停。

一個容易被忽略的訊號：這個 skill 要不要限制觸發方式

判斷完類型之後，還有一個實務上的訊號值得留意：Task 型 skill 涉及有副作用、不可逆、或代價高的動作（部署、發版、刪除資料）時，通常該加上 disable-model-invocation: true，只允許使用者明確呼叫，不讓 AI 自己判斷「現在該執行了」就跳出來做。 Reference 型因為本質上是「補充判斷標準」而不是「觸發動作」，反而希望 AI 能在相關情境下自動套用，通常不需要這個限制。

這條經驗法則不是絕對規則——如果一份 Task 型 skill 涉及的動作低風險、可逆，讓 AI 自動判斷是否呼叫也沒問題。但寫 skill 的時候先問一句「這件事做錯了，代價是什麼」，會比單純套用「Task 型就一定要限制觸發」這種機械式規則更準確。

今日思考題

回想你手上寫過（或想寫）的一份給 AI 用的規則文件：它現在的寫法比較接近「一套判斷標準」，還是「一串該照做的步驟」？如果兩種內容混在同一份文件裡，你有沒有想過拆開來寫，會不會讓 AI 用得更準？

今日重點回顧

• Reference 型 skill 回答「這裡的規矩是什麼」，補充慣例/模式/判斷標準，沒有明確執行順序
• Task 型 skill 回答「這件事該怎麼一步步做」，給的是有先後順序的逐步指令
• 用錯類型會讓 AI 誤判這份 skill 該怎麼被使用——步驟被拆散成零散提醒，或判斷標準被硬套成看似嚴謹實則處處例外的清單
• 涉及有副作用、代價高的動作，考慮用 disable-model-invocation: true 限制只能被明確呼叫，不讓 AI 自己判斷要不要觸發

明日預告

明天要用一個具體案例，走一次一支 skill 從無到有的誕生過程——一次真實犯過的錯，怎麼變成一支能被下次任務直接讀取、避免重蹈覆轍的規則文件。