為什麼你的 Skill 庫越堆越亂：用「Diff 筆記法」給存量做減法

適用場景： 你已經收藏或寫了不少 skill（提示詞、工作流程、腳本），但經常記不清哪個版本能用、哪個早就過期了，翻找一次要花十分鐘以上。

---

問題：Skill 庫的「只進不出」

大多數人管理 skill 的方式是單向的：

1. 遇到好用法 → 存一份
2. 用法升級 → 再存一份（舊的懶得刪）
3. 三個月後 → 同名檔案 3 個，版本全靠檔名猜

結果就是：skill 庫名義上是「資產」，實際上是「垃圾場」。真正動手用之前，你得先做考古——翻目錄、打開比對、回憶當時為什麼改過，一回合下來十分鐘就沒了。更要命的是「不敢刪」：萬一哪天又用上了呢？於是廢棄版本永久駐紮在你的庫裡。

什麼是 Diff 筆記法

每兩週（或每次大版本更新時）對 skill 庫做一次「差量盤點」，只記錄變化，不重寫全庫。每次盤點產出一篇不超過 20 行的 diff 筆記，固定四段：

• 新增：本週加了什麼 skill，一句話說清觸發條件（什麼情況下該用它）
• 替換：哪個舊 skill 被新版取代，舊版標記 deprecated 並寫明「什麼時候別再用」
• 刪除：直接移除，只留一行「刪了什麼 + 為什麼刪」
• 不變：什麼都不寫

筆記歸檔在 skill 庫根目錄，可以是一篇滾動 CHANGELOG.md，也可以按月一篇（diff-2026-08.md）。關鍵規則：只記差量。三個月後的你（或同事）翻筆記，應該能在 30 秒內看懂「這段時間庫變成了什麼樣」。

何時該用

• 你的 skill 超過 15 個，且存在同名或近名檔案（prompt-v2-final-實際是v3.md 這類）
• 你發現自己在「找對版本」上花的時間，已經超過「用 skill」本身
• 多人共用一個 skill 庫——這時 diff 筆記同時充當版本說明和交接文件
• skill 依賴外部工具，而工具升級會悄悄讓舊寫法失效

何時不該用

• 庫只有 5 個以內 skill —— 一張清單就夠了，別上流程
• 你的 skill 已在嚴格版本化的 git 倉庫裡 —— 用 git log、tag 和 PR 更專業，diff 筆記是重複造輪子
• 還在「野蠻生長期」—— 先跑兩三個月積累真實痛點，再引入方法；太早引入只會製造儀式感

操作清單（單次盤點，15 分鐘內）

1. 列出全庫 skill 清單（檔名即可，別打開內容）
2. 逐個問三個問題：最近一次用是什麼時候？現在有沒有替代品？下次會用哪個版本？
3. 把答案歸類到 新增 / 替換 / 刪除 / 不變
4. 寫 diff 筆記；給被替換的舊檔案在檔案頭加標記：⚠️ DEPRECATED: 已被 xxx 替代，2026-08-16
5. 儲存/提交。deprecated 滿兩週無人申訴，直接刪除

常見坑

• 寫成流水帳：diff 筆記不是日誌。「不變」的絕對不要寫，否則下次盤點沒法讀，筆記本身變成新的垃圾
• 只替換不刪除：廢棄檔案留在原地才是混亂之源。標記是第一步，刪除才是目的
• 頻率太高：每週做會變成新的負擔。雙週或月度是合理節奏，太勤說明庫本身還沒穩定
• 團隊共用庫但只有一個人盤點：diff 要進共享倉庫並走 review，否則等於沒做——別人不知道你的 diff，就會基於舊版本繼續堆新檔案
• 筆記和庫不同步：刪檔案時忘了同步 diff 筆記（或反過來）。兩者同一次提交完成，是最省事的紀律

一句話總結

Skill 庫的價值不在數量，在「打開就能用對的那個」。Diff 筆記法讓你每次花 15 分鐘維護這件事，而不是每次用的時候花 15 分鐘考古。