MEMORY.md 只有 25KB，要當目錄用、別當倉庫塞

五月初 MEMORY.md 超出注入上限，CC 的警告訊息說「只載入了一部分」。當時撞牆的完整脈絡在 上一篇 寫過了，這篇直接從解法分析開始。

撞牆當下我查了一圈，發現很多討論把兩件事混在一起：把 25KB 當成資訊總量的上限，結論就只剩「塞不下就刪短」。但這兩件事其實是不同的操作。把它分清楚花了我一段時間，記錄下來。

先講三類解法的框架。

A 類：真的突破上限，讓 CC 載入超過 25KB。這條路不存在。官方文件明寫「超出部分不載入」，設定選項也窮舉過了，沒有任何上限調整的開關（那種叫 autoMemoryMaxSize 的設定根本不存在）。GitHub 上相關 issue（#40614、#41283）也都標了 NOT_PLANNED 關掉。這是刻意設計的常數，不是 bug，等不到官方修。

B 類：旁路注入，上限不變，但透過 SessionStart hook 每次額外塞內容進來。機制確實存在，有人實作過，也有第三方工具走這條路。但它的副作用蠻痛的：

一是靜默截斷：超出旁路上限的部分無聲丟掉，把原本 MEMORY.md 的問題換個地方繼續發生；二是版本耦合，CC 大約每兩天更新一次，hook 走的路徑某個版本可能就靜默失效了；三是失效無守護，hook 掛掉不會大喊「我掛了」，只有第一行 stderr，要自己寫監控。旁路注入的容量也是估計值，沒有官方說明，實際能撐多少沒人確認過。

C 類：縮小需求，同樣 25KB，但改變資訊的組織方式，讓主索引塞得下更多導航入口。

五月七號那次大整理，起點是 34.7KB / 118 條，超過注入上限（24.4KB）大概 42%。

整理分三步走：先刪了 7 筆明確過時的條目，再重寫 28 條太長的描述（冗餘砍掉，資訊錨點留著），最後做群集重組，把平鋪的條目按主題歸群，MEMORY.md 主索引只放群集入口，細節搬到各自的主題檔。條目從 118 條降到 69 條，少掉的大半不是刪除，是併進群集、細節下放到主題檔。

結果是 17.7KB / 69 條 / 83 行，降幅 -49%。

我原本以為降幅主要來自「把描述寫短」，但實際看各階段：刪過時條目省了不到 2KB，重寫過長描述再省 3KB 左右，真正把檔案從 29.8KB 拉下來的是最後那步群集重組，整理完落在 17.7KB。砍字數有用，但對總大小的貢獻遠比重組小。

這才搞清楚「降 size ≠ 縮敘述」是什麼意思。

縮敘述是把每條記錄寫得更短，資訊一起少。降 size 可以透過移位達成：細節搬到主題檔，主索引只留導航指針。25KB 的上限是 session 開頭的自動載入上限，不是資訊總量的上限。你可以用主索引引用的方式，讓 Claude 按需讀主題檔，不是所有東西都要擠在那 25KB 裡。

Anthropic 官方文件其實也這樣說，原文大意是「MEMORY.md 放簡短索引，細節移到主題檔，Claude 需要時再讀」。群集化就是照這個設計意圖走。

決策順序很簡單：C 類先走完，再評估要不要上 B。

C 類「走完」的判準：同主題的條目都已抽成群集、MEMORY.md 裡剩下的都是真的每個 session 開頭都要載入的東西，這時候如果還超，才有理由考慮旁路注入。

真的走到要評估 B 的時候，要先實測旁路的真實容量（那個估計值沒有任何官方來源），設截斷守護，還要限縮適用範圍，不需要脈絡的 headless 執行不應該也觸發注入。

A 類直接跳過，那個路口是封起來的。