在專案中使用 Claude Code 時，通常會出現兩種需求：「這項規則每次都要遵守」以及「記住上次找出的結果」。
前者由規則檔 CLAUDE.md 負責，後者則由記憶功能負責。兩者都是「工作階段結束後仍會保留的指示」，因此容易混淆，但管理主體與性質不同。
本文整理 CLAUDE.md 的階層結構、記憶功能的運作方式，以及判斷內容應放在哪裡的標準。
先看看重點摘要。
- CLAUDE.md 是每個工作階段自動載入的規則檔，分為全域與專案層級。
- 記憶功能會讓 Claude 將工作中得知的事實自行記錄並取回至各專案的資料夾。
- 人定義的規則放在 CLAUDE.md，代理程式累積的經驗則放在記憶體。
- 兩者都會消耗上下文，因此應以「是否總是需要」為標準，維持精簡。
CLAUDE.md：位置就是適用範圍
CLAUDE.md 是在工作階段開始時完整載入提示詞的 Markdown 檔案，用來記錄程式碼慣例、禁止事項、專案背景等「必須永遠成立的規則」。
即使檔案名稱相同，位置不同也會有不同的適用範圍。
| 位置 | 範圍 | 共用 |
|---|---|---|
| ~/.claude/CLAUDE.md | 所有專案 | 僅限個人 |
| project/CLAUDE.md | 該專案 | 透過 Git 與團隊共用 |
| subfolder/CLAUDE.md | 在該資料夾工作時 | 透過 Git 與團隊共用 |
全域檔案放置與專案無關的個人偏好，例如提交風格與回應語言；專案檔案則放置儲存庫特有的規則。兩個層級衝突時，明確指定較具體的專案規則優先，通常最安全。
檔案變長時，也可以使用 @경로/파일.md 格式匯入其他文件來拆分。不過匯入的文件同樣會進入上下文，因此應將它視為方便管理的功能，而非節省篇幅的方法。
記憶體：代理程式自行撰寫的筆記
如果說 CLAUDE.md 是人撰寫的由上而下規則，記憶體就是相反方向。Claude 會把工作中得知的事實以檔案形式記錄在專案專用的記憶資料夾，並在下一個工作階段再次取出使用。
運作結構很簡單：一個記憶對應一個檔案，索引檔 MEMORY.md 則會累積每行摘要。工作階段開始時只有索引會進入上下文，個別記憶的本文則在進行相關工作時讀取。
記錄內容的性質也與規則不同，例如「這個 DB 在批次處理後需要進行型別檢查」或「必須在這個工作樹啟動 dev 伺服器才會套用」。這些不是文件中寫明、而是必須親身經歷才知道的事實，也就是在人將其明文化為規則前累積的經驗知識。
對話中也可以傳送以 # 開頭的訊息，直接指示「把這件事記住」。此時 Claude 可能會詢問要儲存在哪個檔案，或自行分類。
判斷應放在哪裡的標準
當兩者的角色看似重疊時，可以用三個問題來判斷。
第一，這是誰決定的？團隊或自己訂定的規則放在 CLAUDE.md，工作中發現的事實則放在記憶體。
第二，違反時會造成問題嗎？禁止提交金鑰、部署流程等違反就會導致事故的規則，務必放在 CLAUDE.md。因為記憶體比較像參考筆記，不是能保證取回的強制機制。
第三，是否已能從程式碼或文件得知？只要閱讀儲存庫就能知道的內容，原則上不應放入任何一方。這只會浪費上下文，程式碼一變也會成為錯誤資訊。
維運時應遵守的兩件事
第一，定期清理。CLAUDE.md 往往只會累積規則而不會刪除。發現已失效的規則或一次性指示後，應立即刪除，避免每個工作階段浪費上下文。記憶體也一樣，程式碼變更後已不再正確的項目，刪除比保留更好。
第二，規則要簡短且明確。相較於「如果可以，最好～」這類句子，「～」「禁止～」這類短句更容易遵守。加上一行範例，遵守率會明顯提升。
總結
CLAUDE.md 是憲法，記憶體是工作日誌。人訂定的不變規則由上而下傳遞，現場取得的經驗則由下而上累積。
開始區分管理兩者後，就能減少每個工作階段重複相同說明，也能避免再次踩上前一個工作階段的坑。