歡迎來到 Claude Code Deep Dive。

這一集我們要處理的，不是某一個單獨功能，而是整個專案最容易被弄亂的一件事：記憶與持久規則要怎麼放，才不會讓團隊越做越大，卻越做越難維護。

如果你有看過很多 Claude Code 團隊，會發現一個很典型的現象。剛開始的時候，大家都很有紀律，什麼東西都想寫清楚。可是過了一段時間，根目錄的規則檔越來越厚，import 越來越多，例外越來越長，最後變成一份誰都不想打開的文件。這時候，問題就不是「資訊不夠」，而是「資訊放錯地方」。

所以第二集要建立的模型很簡單。CLAUDE.md 是持久政策面，memory 是續航面。前者管長期規範，後者管 session 之間不要斷線。兩者都重要，但它們不是同一件事。

先講 CLAUDE.md。你可以把它想成這個 repo 的長期入口。它應該放的是 durable policy，也就是長期有效、跨 session 仍然成立的規則。像是這個專案的工作方式、固定流程、誰負責哪一層、什麼事情一定要寫回檔案、什麼事情不能只留在對話裡。這些都屬於 CLAUDE.md 的範圍。

但 CLAUDE.md 有一個很重要的邊界。它不是百科全書，也不是整個專案的手冊。很多人會想把所有細節都塞進 root file，覺得只要這樣最完整。實際上剛好相反。你把越多東西塞進根檔，它就越難掃描，越容易互相衝突，也越容易在 context 壓力下失去作用。

這裡的原則，是短、穩、可掃描。根檔只負責最重要的政策。細節要往 narrower files 移。這就是為什麼我們會有 `.claude/rules/`、topic notes、architecture notes、以及其他專門的檔案。你不是在減少資訊，而是在把資訊分層。

再來講 memory。memory 的角色不是政策，而是續航。session 一長，context 會 compact，對話也會失焦。這時候，memory 的作用是把重要決策、重要偏好、已經定案的結構留住，讓下一次 session 重新進來時，不會像從零開始。

但 memory 不能取代 source of truth。這點要講得很清楚。memory 可以幫你回想，不能幫你定義規則。它可以告訴你「上次我們決定把 settings 和 permissions 分開」，但它不能自己變成 settings 規範。它是續航，不是法條。

這也是第二集最常見的兩個反模式。

第一個反模式，是把 CLAUDE.md 當成垃圾桶。所有例外、所有教學、所有想法、所有討論紀錄，全塞進同一個 root file。最後結果就是，連模型都很難判斷哪些是長期政策，哪些只是某一次的臨時補充。

第二個反模式，是把 memory 當成政策來源。這很危險，因為 memory 的本質是幫你保留上下文，不是幫你做治理。你如果把它當成正式規則，團隊會開始依賴一些沒有明確來源的記憶，久了之後就會出現「大家都記得有寫，但沒人知道寫在哪」的狀況。

所以正確寫法不是「把所有東西記住」，而是「把東西放在對的層」。根檔放永續政策，細節放 narrower files，重要決策寫回檔案，session 中間需要續航的內容才放 memory 或 checkpoint。這樣整個系統才有可預測性。

如果你要把這套結構翻成團隊設計，我會這樣切。

Research 的工作，是確認官方文件怎麼定義 memory、CLAUDE.md、import、nested loading、以及它們的邊界。
Architecture 的工作，是決定 root file、rules、topic notes、checkpoints 各自的用途。
Content 的工作，是把這些規則翻成可以教人的講法。
Instructor 的工作，是把語氣和節奏穩住，讓人聽得懂它們之間的差異。
Distribution 的工作，是確保每一集的講義、逐字稿、show notes 和 RSS 都能對得起這個架構。

你會發現，這不是內容分工而已，這其實是治理分工。因為只要沒有明確責任，規則就會回到對話裡，最後又失去檔案化。

這一集你可以抓三個 takeaways。

第一，CLAUDE.md 是持久政策，不是百科全書。
第二，memory 是續航，不是規則來源。
第三，重要決策一定要回寫到檔案，不要只留在 session 裡。

如果你能把這三句話講清楚，那你就已經知道第二集在做什麼了。不是教你多記一份檔案，而是教你怎麼讓一個團隊在 session 壓力下，還能維持同一套運作方式。

下一集我們就進到 settings。那一集會更直接，因為我們要開始回答一個更實際的問題：哪個設定該放哪裡，誰可以改，改了之後會影響誰。