DevPawDEVPAW · GROUND-UP DEV NOTES
搜尋
選單
ZH-HANT
한국어English日本語繁體中文EspañolPortuguês简体中文
AI 程式開發與代理

[AI 內容 #4] CLAUDE.md 為什麼應該簡短？AI 代理程式常駐載入內容的設計方法

第 3 篇介紹了如何用 /clear 清除對話記錄。但在 /clear 後立即查看剩餘內容，會發現並不是 100%。在 Claude Code 執行 /context，就能看出原因：系統提示、工具定義、CLAUDE.md，以及 MCP 伺服器註冊的工具，早已佔用數萬個權杖…

閱讀 5 分鐘
[AI 內容 #4] CLAUDE.md 為什麼應該簡短？AI 代理程式常駐載入內容的設計方法 封面圖

第 3 篇介紹了如何用 /clear 清除對話記錄。但在 /clear 後立即查看剩餘內容，會發現並不是 100%。在 Claude Code 執行 /context，就能看出原因。系統提示、工具定義、CLAUDE.md，以及 MCP 伺服器註冊的工具，早已佔用數萬個權杖。甚至在對話開始之前。

本篇討論「常駐載入的內容」。如果對話記錄是變動成本，這部分就是固定成本。它每回合都會完整帶上，/clear 也不會消失，並在整個工作階段持續佔用模型的一部分注意力。固定成本設計不佳，任何工作階段都等於一開始就處於劣勢，因此應該優先於對話管理進行改善。

工作階段開始前就已載入的內容

代理程式的內容視窗並不是從一張白紙開始。第一個使用者輸入抵達前，裡面就已經鋪了好幾層內容。

最底層是系統提示。代理程式執行環境（例如 Claude Code）注入基本指示，包含工具使用規則與回應格式等內容，規模達數千個權杖。這是使用者無法修改的區域。

其上是工具定義。模型要使用工具，就必須知道每個工具的名稱、說明與參數結構，而這些內容都會以文字形式進入內容視窗。只有基本工具時負擔不大，但一旦連接 MCP 伺服器，情況就不同了。一個伺服器註冊數十個工具很常見，連接幾個伺服器後，光是工具定義就會消耗數萬個權杖。從未使用的工具也會在每回合往返。

最後是 CLAUDE.md 之類的專案指示檔。全域設定、專案設定與子目錄設定都會自動載入，而這是唯一能由使用者直接設計的層。

CLAUDE.md 的原則：只簡短保留永遠成立的內容

判斷 CLAUDE.md 該放什麼，只有一個標準：「這項內容是否在此專案的所有工作中永遠成立？」這個檔案每回合、每項工作都會載入，因此只適用於部分工作的內容不值得佔用空間。

建置與測試指令、程式碼庫的整體結構，以及少數不可違反的規則，符合標準。相反地，特定功能的詳細規格、完整的函式庫使用方式、過去工作的記錄，只在特定工作中需要，因此不適合放入。

長度存在一個矛盾。指示寫得越多，似乎越容易被遵守，但實際上往往相反。第 2 篇提過，內容變長後，分配給個別項目的注意力會變少；在數百行的指示檔中，真正重要的規則會埋沒在 lost in the middle 裡。寫 50 條規則，50 條都只會被模糊地遵守；寫 10 條，則更接近清楚遵守這 10 條。如果代理程式總是違反 CLAUDE.md 的規則，在增加規則之前，先縮短檔案可能才是正確順序。

常駐載入的 3 層中，只有 CLAUDE.md 可以由你直接設計
常駐載入的 3 層中，只有 CLAUDE.md 可以由你直接設計

不要全部載入，只載入指標

那麼，未達標的資訊，也就是偶爾需要的詳細文件，應該放在哪裡？答案是：「放在內容視窗外，只告訴代理程式位置。」

不要把完整的資料庫移轉流程放進 CLAUDE.md，而是只寫一行：「移轉流程請參考 docs/migration.md」。代理程式只有在進行移轉工作時才會讀取該檔案。詳細內容只會進入需要它的工作階段，無關的工作階段只需負擔一行指標的成本。

Claude Code 的 skill 就是將相同原則系統化。skill 是特定工作的流程文件；平時只有名稱與一行說明會載入內容視窗，工作開始時才載入本文。與其讓「部署流程」常駐在 CLAUDE.md，不如做成 skill，如此一來，不進行部署的 99% 回合都能省下那些權杖。

工具本身也需要整理。如果有已連接但未使用的 MCP 伺服器，只要關閉它，就能消除數萬個權杖的固定成本。現在也有越來越多執行環境支援延遲載入：平時只保留工具名稱，需要時才載入完整結構。方向是一樣的：不要永遠載入所有內容，而是在需要時載入需要的內容。

牆上只放幾行永遠成立的規則；詳細手冊放在架上，需要時再取出
牆上只放幾行永遠成立的規則；詳細手冊放在架上，需要時再取出

固定成本檢查例行流程

常駐載入的內容一旦膨脹，就很難察覺。因為每個工作階段都會產生相同成本，沒有比較對象。因此，偶爾有意識地檢查很有價值。

在 Claude Code 中，可以用 /context 拆解查看目前內容視窗的使用位置與用量。它會顯示系統提示、工具、MCP 與記憶體檔案各自使用的權杖數；如果發現工具定義異常地比對話還大，就先整理 MCP 伺服器。每季至少打開一次 CLAUDE.md，以「上個月這一行是否真的派上用場？」為標準刪除內容。指示檔放著不管只會不斷成長，因此必須把修剪變成例行工作，才能維持精簡。

總結

  • 系統提示、工具定義與 CLAUDE.md 是每回合都會載入的固定成本。它們不會因 /clear 消失，因此必須在對話管理之前先設計好。
  • CLAUDE.md 的標準是「是否在所有工作中永遠成立？」檔案越長，個別規則越模糊；如果規則沒有被遵守，應該先縮短檔案。
  • 詳細文件只載入指標，不載入本文；重複流程拆成 skill；未使用的 MCP 伺服器則關閉。原則是只在需要時載入需要的內容。

做到這裡，一個工作階段的內容視窗就會相當乾淨。然而，即使再節省，也總會遇到一項大型工作無法放進單一工作階段的時刻。下一篇將介紹此時使用的結構化解法：子代理程式。我們會看看讓其他內容視窗負責探索、只帶回結論的隔離模式，如何保護內容視窗。

延伸閱讀