Claude Code Projects 的共享記憶怎麼運作?一個 MEMORY.md,決定所有並行 thread 知道什麼

MEMORY.md 裡寫的內容,是 Claude 自動決定要記什麼,還是我可以主動要求它記住特定事項?

從官方給的例子來看(「發布時程改到週五了」「動帳務程式碼前要先問誰」),這類資訊聽起來像是在對話過程中自然浮現、Claude 判斷屬於「決策性、規則性」的內容,主動寫進索引裡——這代表機制本身傾向於自動化,不完全是你每次都要明確下指令「幫我記住這件事」才會運作。

但反過來說,如果某件事對你來說很重要,比較保守的做法還是直接在對話裡明確講出來,而不是假設 Claude 一定會自己判斷出這件事的重要性、主動寫進 MEMORY.md——畢竟這是一份 Claude 主動維護的索引,你目前沒有辦法在文件裡直接看到它的完整判斷邏輯,與其事後才發現某個關鍵決策沒被記住,不如在當下就明確說出來,降低漏記的風險。

為什麼「記憶」跟「程式碼脈絡」要走兩條不同的繼承路徑,不乾脆全部放進同一份索引裡?

這兩者的性質本來就不一樣。程式碼脈絡(repository 本身、CLAUDE.md、skills、plugins)是每個 thread 執行工作時,實際需要拿來操作、編輯、測試的素材本身——這類內容體積可能很大,而且每個 thread 通常需要一份完整、獨立的複本,才不會在並行執行時彼此干擾。如果把這些內容也塞進 MEMORY.md 這種索引檔案裡,索引本身會變得龐大而低效,而且失去「每個 thread 有自己獨立工作副本」這個並行執行的基本前提。

記憶(MEMORY.md 索引裡的內容)則相反,它的價值恰恰在於「輕量、跨 thread 共享、持續累積」——這類決策性資訊通常很短,但需要被所有後續的 thread 看到,不需要、也不應該像程式碼那樣被每個 thread 複製一份獨立副本(複製多份反而會造成資訊不同步的風險)。把兩者拆成不同機制,是因為它們對「要不要共享」「要不要獨立複本」這兩個問題的答案剛好相反。

如果我的 project 橫跨多個 repository,權限規則只在啟動目錄裡生效這件事,實際上會造成什麼具體影響?

實際影響是:你在其中一個 repository 底下設定的權限規則(例如某條 deny 規則、某個 hook),不會自動延伸到 project 裡的其他 repository——如果一個 thread 是從另一個 repository 的目錄啟動,它不會受到你在第一個 repository 裡設定的那套規則約束,除非你在那個 repository 底下也各自設定了對應的規則。這代表在多 repository 的 project 裡,權限規則的把關程度,取決於你有沒有在「每一個」repository 底下都個別做好設定,而不是設定一次就能保護整個 project。

實務上比較保險的做法,是先盤點你的 project 裡涵蓋幾個 repository,針對每一個都個別檢查權限規則、hooks、env 是否符合你的預期,而不是因為在其中一個 repository 裡設好了規則,就假設整個 project 都已經套用了同一套防護——這個假設在單一 repository 的 project 裡是成立的,但一旦 project 橫跨多個 repository,就不再成立。

協調者看不到 thread 執行過程的每一步,只看得到回報結果,這對我實際監督工作進度會不會造成問題?

這代表你如果只盯著 project 對話本身,能掌握的是「這個 thread 現在到哪個階段了、最後回報了什麼」這種高層次的進度,而不是「它剛才試了三種方法,前兩種失敗了」這種執行細節。對於大部分只需要知道結果的情境,這個層級的資訊已經夠用,不需要每一步都盯著看。

但如果某個 thread 的結果不如預期,或是你需要理解它為什麼做出某個特定選擇,單靠協調者這一層的資訊會不夠——這時候需要主動打開那個 thread,才能看到完整的執行過程跟中間嘗試。所以比較實際的監督習慣,是把協調者對話當成「巡視進度用的儀表板」,只有在儀表板顯示的結果讓你有疑問、或是結果本身需要更仔細審查時,才進一步點開個別 thread 去看細節——不需要、也不太可能對每個並行執行的 thread 都全程緊盯。