前言：寫一份文件，跟寫一支 Skill，差在哪裡？

「不就是把規則寫成一份文件嗎？跟寫在 README 或內部 wiki 有什麼不一樣？」

這是我剛開始用 Skill 這個機制時,最直覺的疑問。表面上看確實很像——都是一段文字,都在講「這件事該怎麼做」。但用了一陣子之後,我發現真正的差別不在格式,而在這份東西被寫出來的動機。一份文件,通常是「我覺得這件事應該被記錄下來」;一支好的 Skill,幾乎都是從「AI 剛剛犯了一個錯,我不想再解釋第二次」這個具體時刻長出來的。

昨天講到 CLAUDE.md 太長會發生什麼事——每一條規則的權重被稀釋、每次任務都要付出載入成本。今天要講的 Skill,正是解決這個問題的另一半答案:不是把所有規則塞進同一份文件,而是把「這件事」拆成一個獨立、可以按需載入的單位。但拆分本身不是重點,這個單位裡裝的到底是什麼,才是今天真正要講的。

今日目標

• 理解 Skill 的本質是「循環的產物」,不是「文件的產物」
• 認識這個循環具體長什麼樣:犯錯、被糾正、記住教訓、提煉成規則
• 學會判斷什麼樣的經驗值得寫成 Skill,什麼不值得
• 看一組對照,體會「憑空寫規則」跟「從真實教訓提煉規則」的差異
• 建立「先讓錯誤發生過一次,再決定要不要寫成 Skill」的耐心

Skill 不是被「想出來」的,是被「逼出來」的

一份好的 Skill,幾乎不會是坐下來憑空想出「這個專案應該要有什麼規則」寫出來的。真正的起點,通常是一個具體到有點狼狽的時刻:AI 做了某件事,你發現不對,你糾正它,它照做了——然後你意識到,如果不把這次的糾正記下來,下一次遇到類似情境,同樣的錯誤大概率會重演。

這個循環拆開來看是四個步驟:AI 依照自己的預設判斷做了一件事 → 這件事被證明是錯的（或至少不夠好）→ 你糾正它,講清楚為什麼錯、正確的做法是什麼 → 這次糾正被提煉成一條可以獨立套用的規則。Skill 做的事,就是把最後這一步,從「留在你自己的記憶裡」變成「寫成一份 AI 下次可以主動讀到的文件」。

這代表一件事:如果你還沒有真的被 AI 的某個判斷絆倒過,你大概率還沒有資格寫出一支真正有用的 Skill。 那些看起來面面俱到、卻沒有踩過任何具體的坑就寫出來的規則文件,讀起來像是抄了一份最佳實踐清單——沒有錯,但也沒有真正回答「AI 在這個專案裡會犯的那個特定的錯是什麼」。

什麼經驗值得提煉,什麼不值得

不是每一次犯錯都值得寫成 Skill。判斷的標準大致有三個:

第一,會不會重複出現。 如果這個錯誤的情境非常特殊、機率極低,寫成 Skill 的維護成本可能高過它省下來的時間——這種情況,記在個人的長期記憶裡就夠了,不必獨立成一個文件單位。

第二,影響範圍夠不夠廣。 一個只會在某個檔案的某一行出現的邊界情況,通常不值得寫成獨立規則;但如果這個判斷邏輯會反覆套用到一整類任務(例如「任何涉及外部依賴的程式碼都該怎麼組織」),就值得。

第三,有沒有明確的觸發情境。 一支 Skill 最終要能回答「我什麼時候該被讀到」——如果連這一點都講不清楚,寫出來的東西再詳細,AI 也不知道什麼時候該套用它,等於白寫。

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

❌ 憑空想出來的規則:
「所有的函式命名都應該清楚、有意義,
 避免使用模糊的縮寫。」
→ 誰都同意這句話,但它沒有回答任何具體情境,
  AI 讀了也不知道下次遇到什麼狀況該怎麼做

✅ 從真實糾正提煉出來的規則:
「AI 曾經把一個查詢函式命名為 `getData()`,
 這個名字在被要求『這個函式回傳的是使用者的
 訂單清單還是訂單摘要』時完全答不出來——
 之後這類查詢函式一律要求命名反映回傳的具體內容,
 例如 `getOrderSummaries()` 而不是 `getData()`,
 這條規則的觸發時機是任何新增查詢類函式的時候。」
→ 有具體的犯錯情境、有具體的糾正結果、
  有明確的觸發時機,AI 讀到之後知道
  「這條規則什麼時候該被套用」

第一種寫法讀起來完全正確,卻沒有任何實際作用——它太抽象,抽象到沒有辦法在下一次類似情境出現時,讓 AI 意識到「這裡就是那條規則該套用的地方」。第二種寫法看起來瑣碎,卻因為綁著一個具體的犯錯場景,反而更容易在下次類似情境出現時被正確觸發。

「這值得寫成 Skill 嗎」不是一次判斷,是累積判斷

還有一個容易被忽略的細節:第一次犯錯的時候,通常還看不出這件事值不值得寫成 Skill。真正值得動手的時機,往往是同一類錯誤第二次、第三次出現的時候——這時候你才能確定,這不是一次性的意外,而是一個會反覆發生、值得投資時間提煉成規則的模式。

太早把每一次糾正都寫成獨立 Skill,反而會製造出一堆內容重疊、彼此打架的小文件,回到昨天講過的「規則太多、互相稀釋」的老問題,只是換了一個地方發生。耐心讓同一類錯誤真的重複出現,再動手提煉,比每次犯錯就急著寫一份新規則,產出的 Skill 品質更高。

今日思考題

回想你最近一次糾正 AI 的經驗:那個糾正,是第一次發生,還是你已經隱約覺得「這好像不是第一次了」?如果是後者,這條教訓現在被寫下來了嗎,還是只存在你自己的記憶裡?

今日重點回顧

• Skill 的本質是「犯錯 → 糾正 → 提煉」這個循環的產物,不是憑空寫出來的文件
• 判斷值不值得提煉成 Skill 的三個標準:會不會重複出現、影響範圍夠不夠廣、有沒有明確的觸發情境
• 憑空寫出來的抽象規則,即使正確,也常常因為沒有綁著具體情境而失去實際作用
• 不用第一次犯錯就急著寫 Skill,讓同一類問題真的重複出現,再動手提煉

明日預告

明天要拆開 Skill 本身的兩種基本形態:Reference 型跟 Task 型——一種是「知識/慣例」,一種是「逐步操作指令」,什麼情境該用哪一種,寫錯類型會踩到什麼坑。