「這條規則我明明寫進 CLAUDE.md 了，AI 怎麼還是沒照著做？」
如果你也問過這句話，先別急著懷疑是 AI 不夠聰明。更常見的原因很無聊：那份 CLAUDE.md 已經長到連你自己都記不清楚裡面寫了什麼，AI 每次要在幾千行規則裡找到那一條真正相關的，跟大海撈針沒有太大差別。今天用一個通用情境案例，具體看清楚「CLAUDE.md 太長」這件事，會怎麼一步步把一份原本救命的文件，變成沒人真正記得住的雜訊堆。
假設有一個團隊，一開始的 CLAUDE.md 只有 50 行——commit 訊息格式、程式碼縮排慣例、幾條最重要的架構限制。這份文件輕薄短小，每個人都讀得完，AI 每次載入也幾乎不花時間。
半年後，情況變了。每次 AI 犯了一個錯，團隊的直覺反應是「把這件事寫進 CLAUDE.md，下次就不會再犯了」——某個資料庫欄位的命名慣例、某個第三方套件的已知版本陷阱、某次專案 review 時對某段特定程式碼的處理方式、某個只在特定情境才會用到的效能優化技巧。半年下來，這份文件累積到三千行，涵蓋了團隊踩過的幾乎每一個坑。
問題是：**這三千行裡，真正「幾乎每次任務都會用到」的規則，可能不到一百行；剩下的兩千九百行，是只有碰到特定情境才相關的細節。**但因為全部混在同一份文件裡，AI 每次執行任何任務，都得把這三千行全部讀過一遍。
第一種傷害：權重稀釋。 想像規則文件是一份「這個專案最重要的事」清單。當清單只有 50 條時，每一條都很顯眼，AI（跟人）很容易记住並且真的照著做。但清單膨脹到三千條之後，最重要的那幾條規則被淹沒在大量低頻使用的細節裡——不是這些細節不重要，是它們稀釋了真正該優先遵守的那幾條規則的存在感。這就是為什麼團隊常常發現：明明某條核心規則寫在 CLAUDE.md 裡，AI 卻好像沒看到一樣，不是 AI 沒讀到,是這條規則被淹沒在其他 2999 行裡,沒有被賦予應有的權重。
第二種傷害：載入成本。 每一次執行任務，不管任務跟這三千行規則裡的哪一小部分相關，AI 都得把整份文件讀過一遍才能開始工作。文件越長，這個固定成本就越高——不只是拖慢每次任務啟動的速度,也代表每次任務的 context 有相當大一部分，被跟這次任務完全無關的規則佔掉了。
用一組對照來看這個差異：
❌ 把所有規則塞進同一份 CLAUDE.md：
「這個資料庫欄位的命名要用某種特定慣例（某個子系統才會用到）」
「某個第三方套件在某個版本有個已知的效能陷阱（半年前踩過一次）」
「commit 訊息要用 Conventional Commits 格式」（幾乎每次都用得到）
→ 全部混在同一份文件裡，AI 每次都要通讀三千行，
真正常用的那幾條規則被淹沒在大量低頻細節裡
✅ 只留「幾乎每次都適用」的規則在 CLAUDE.md，其他按需載入：
CLAUDE.md 只留：commit 訊息格式、核心架構限制、去識別化這類全站規則
低頻細節搬進對應的 skill，用觸發範圍限定（例如只在碰到
特定資料夾/特定情境時才載入）
→ CLAUDE.md 保持精簡，AI 每次都能完整記住這份核心清單；
低頻細節只在真的用得到的時候才被載入進 context
這正是這個系列會反覆回到的主題句在文件設計上的具體樣貌：CLAUDE.md、skill、memory 這些協作工具本身，跟你平常在寫的程式碼一樣，需要被設計——沒有清楚的分工，它們就會用最省事的方式（全部塞進同一份文件）累積成一堆彼此稀釋權重的雜訊。
一個實用的判斷問題是：這條規則，在這個專案裡「幾乎每次任務」都適用，還是只在「特定情境」才適用？ 如果答案是前者（例如全站的編碼規範、commit 慣例、匿名化原則），留在 CLAUDE.md；如果答案是後者（例如某個特定目錄的資料存取慣例、某支第三方套件的整合細節），該搬進一支按觸發範圍限定的 skill，讓它只在真的碰到那個情境時才被載入。
這個判斷不是一次性的——一條規則今天可能是「特定情境」，隨著專案演進變成「幾乎每次都會用到」，這時候就該考慮把它從 skill 挪回 CLAUDE.md。反過來，CLAUDE.md 裡如果有一條規則你發現自己已經很久沒真的用到，也該考慮把它搬進 skill，替 CLAUDE.md 騰出空間。
翻開你自己專案的 CLAUDE.md（如果有的話），數一數裡面有幾條規則是「幾乎每次任務都用得到」的，又有幾條是「只在特定情境才相關」的。這個比例，跟你直覺想像的一樣嗎？
明天要講「特定情境才適用」的規則該搬去哪裡——Skill 的本質：把一次性經驗提煉成可重複套用的規則。
iThome鐵人賽
看影片追技術