前言：規則講過一次，AI 下次還會忘記嗎？

「昨天才糾正過 AI 一個錯誤判斷，今天換個任務，它是不是又會犯一樣的錯？」

會的——如果那個教訓只留在昨天那次對話裡。這正是為什麼「把一次性踩坑經驗變成可重複套用的規則」這件事，值得認真對待。今天不講「skill 是什麼」這種概論，而是老實走一遍：一支 skill 是怎麼從一次真實犯錯，一步步變成之後每次任務都會自動套用的規則。

今日目標

• 看一次完整的敘事弧：一次性錯誤 → 被糾正 → 寫進記憶 → 提煉進 skill → 下次任務直接避開同一個坑
• 理解「定位」段落為什麼是一支 skill 最重要的開頭
• 認識 skill 裡也要明講「不要做的事」，而不是只寫「該做的事」
• 知道 skill 不是只能寫規則，也可以包裝成半自動化工具

一次真實犯錯，怎麼變成一支 skill

有一次，我請 AI 清理一段程式碼裡過時的說明性註解。這段程式碼裡有一整段夾帶著具體斷言邏輯的多行註解——不是單純的說明文字，而是描述了某個特殊情境該怎麼驗證的邏輯。AI 把這整段當成「不可測試化的根因說明」保留了下來，理由是「這段話看起來在解釋為什麼這裡沒辦法寫測試」。

我看過之後糾正了它：那段話裡藏著的其實是一個具體、可以直接寫成斷言的驗證邏輯,不是「不可測試化」的說明,是被遺忘的待辦。AI 把「看起來像說明文字」跟「真的只是說明文字」混為一談，漏掉了裡面真正該做的事。

這次糾正沒有停在「這次改對了就好」。我把這個錯誤模式（多行註解裡混雜著可執行的驗證邏輯，容易被誤判成純粹的背景說明）寫進記憶，再進一步提煉成清理註解這支 skill 裡的一條具體規則，附帶當初那次誤判的案例當教材。

這正是一支好用的 skill 誕生的完整路徑：不是先坐下來想「這個領域應該有哪些規則」，而是先讓錯誤真的發生一次，再把那次錯誤的具體樣貌，變成下一次能被自動避開的規則。

用一組對照看這個差異：

❌ 只停在「這次改對了」：
AI 這次被糾正，改對了這段程式碼。
→ 下一次遇到類似情境（不同檔案、不同註解），完全沒有任何機制
  提醒 AI「這種模式要小心」，同樣的錯誤會再發生一次

✅ 把這次犯錯提煉進 skill：
AI 被糾正後，把「多行註解可能夾帶可執行邏輯，
不要直接當成純說明文字保留」寫進對應 skill 的規則，
並附上這次真實的錯誤案例當教材
→ 下一次任何情境套用到這支 skill，AI 會先看過這條規則
  跟這個案例，同一類錯誤被提前擋下

「定位」段落先劃邊界，比規則本身更重要

這裡要先分清楚兩層不同的東西：skill 檔頭 frontmatter 裡的 description 決定的是「這支 skill 會不會在當下這個情境被載入」；而內文一開頭的「定位」段落，決定的是「載入之後,這條規則的細節該怎麼套用、邊界在哪裡」——description 沒寫好，skill 可能根本不會被觸發；description 寫對了、但內文沒有「定位」段落，skill 觸發之後還是可能被套用過頭。兩層都要顧到，這裡先講第二層。

一支 skill 內文寫得再詳細，如果沒有先講清楚「這支管什麼、不管什麼」，很容易被套用到不該套用的地方，或者跟另一支 skill 的規則互相打架。所以每支 skill 內文開頭都要有一段「定位」，明講適用範圍——例如某支處理外部廠商接線的 skill，會先講「這支只適用某一類特定廠商家族的接線細節，通用的廠商整合原則見另一支 skill」，把「這個規則多廣」的邊界先劃清楚，而不是讓 AI 自己猜這條規則能不能套用到眼前這個情境。

另一個常見的邊界劃法，是明確排除掉「看起來像、但其實不算」的情況——例如某支管理環境設定的 skill，會明講「只有換環境（開發/測試/正式）會不一樣的值才夠格搬進環境變數，單純的業務常數不算」，避免 AI 把規則過度套用，把不該搬的東西也一起搬了。「定位」段落做的事情，其實跟 Day 01 那句話是同一件事——逼 AI 誠實標注這條規則的查證範圍/適用範圍，而不是含糊地「感覺應該可以套用」。

Skill 裡也要藏著「不要做的事」

大部分 skill 讀起來像是「該怎麼做」的清單，但真正防住 AI 犯錯的，往往是那些明講「不要這樣做」的條目——尤其是牽涉到安全邊界的地方。

有一次，在設計某個簽章驗證機制的白名單時，曾經考慮過一個看起來更省事的做法：用反射自動掃描某個類別裡的所有公開方法，自動產生白名單，不用每次新增功能都手動維護清單。這個方向後來被否決了，理由很直接——白名單本身就是一道安全邊界，改成反射自動探索，等於任何新增的公開方法都會自動變成可以被觸發的入口，隱性擴大了攻擊面,而且擴大的過程完全不會被察覺，因為「自動」正是問題所在。

這件事後來被明確記錄下來，成為對應 skill 裡的一條「不要做的事」。AI 覺得「更自動化、更省事」的做法，不一定是對的方向——特別是牽涉到安全邊界的時候，手動維護的麻煩，其實就是那道邊界本身的價值。

Skill 不只是文字規則，也可以是半自動化工具

有些 skill 除了寫規則，還會附帶一支可以直接執行的腳本——例如比對「程式碼裡實際用到的欄位清單」跟「測試覆蓋率報告」，自動列出差異；或是從資料庫結構定義自動產生型別宣告的草稿。這些腳本做的是「機械式比對」這一類重複、容易看漏、但邏輯本身很明確的工作，跑完之後把結果攤開給人看，但**「這份草稿裡的判斷是不是正確、要不要照著套用」，仍然要求人工核對，不會自動套用**。

這跟這個系列反覆出現的分界是同一件事：把機械式、可以窮舉的工作自動化，把真正需要判斷的部分留給人（或更上層的判斷）。「自動化到草稿為止」這句話，值得寫在每一支附帶腳本的 skill 開頭。

今日思考題

回想你上一次被 AI 的某個判斷坑過的經驗：那次教訓後來去哪了？只留在那次對話紀錄裡，還是變成了一條下次會自動生效的規則？

今日重點回顧

• 一支好用的 skill 通常不是先設計出來的，而是從一次真實犯錯 → 被糾正 → 寫進記憶 → 提煉進規則這條路徑走出來的
• 「定位」段落（這支管什麼、不管什麼）比規則本身更重要，能防止規則被套用到不該套用的地方
• Skill 裡要明講「不要做的事」，尤其是安全邊界相關的地方——AI 覺得更自動化的方向不一定是對的
• Skill 可以附帶半自動化工具，但只做到「產生草稿」，最終判斷仍然留給人

明日預告

明天要從「怎麼把經驗寫進 skill」，轉到「AI 本身怎麼記住東西」——持久記憶系統的四種類型：user、feedback、project、reference，各自解決什麼問題、什麼時候該用哪一種。