Anthropic工程師踩坑1500次：AI記憶不是越大越好

我見過太多人試圖用「堆量」解決AI失憶問題。500行、1000行、2000行的CLAUDE.md（或.cursorrules），文件越膨脹，AI越糊涂。研究早就證實：上下文過長時準確率暴跌，大文件中間的指令會被直接忽略。你還沒提問，上下文窗口已經被塞爆了。

真正有效的方案完全相反：小文件、分層加載、按需喚醒。

1500次對話后的實戰結構

這位工程師在60多個項目、1500多場對話后，摸索出一套四層架構。核心邏輯像圖書館索引——不是把書全堆在桌上，而是告訴AI「某本書在第幾排」。每層都有嚴格的字數預算，超了就強制遷移，絕不姑息。

Tier 1 憲法層（約200行，始終加載）

這是你的「 standing orders」。偏好設置、硬性規則、以及指向其他層的路由表。「永遠用TypeScript嚴格模式。」「測試里不許mock數據庫。」就這些。如果這層超過200行，說明你把東西放錯地方了。

路由表是整套系統的樞紐。它不存儲知識，只存儲知識的位置。Tier 1從不回答「怎么做」，只回答「去哪里找」。這種設計把上下文窗口從「倉庫」變成了「調度中心」。

Tier 2 活記憶層（約50行，始終加載）

一個簡短的糾錯清單——AI反復踩坑的地方。「這張表存的是增量，不是累計值。」「VS Code插件不會觸發CLI鉤子。」每條記錄都直接阻止一次重復錯誤。這層見效最快，因為痛點就在眼前。

50行的限制極其苛刻。工程師發現，約束倒逼質量。當你不能再隨手塞內容時，被迫思考：這件事真的需要永遠在線嗎？還是該下沉到項目層？

Tier 3 項目腦（按項目加載）

每個項目一個文件，深度上下文：業務規則、數據schema、關鍵文件、決策日志、變更記錄。只在進入該目錄時加載。5個項目的話，80%的知識只對一個項目有用——何必每次都全量加載？

這層解決了跨項目污染。你在A項目積累的約定，不會干擾B項目的對話。AI看到的永遠是當前項目的「專屬記憶」，而非一鍋亂燉的全局配置。

Tier 4 知識庫（按需查詢）

可搜索的數據庫（SQLite + FTS5，或純markdown文件）存放參考資料：完整schema、API文檔、術語表。AI需要時主動搜索，而非被硬塞進指令文件。

這層的關鍵是「拉取」而非「推送」。傳統做法是把文檔切片塞進上下文，現在反過來——AI先判斷需要什么，再精準調取。上下文窗口的壓力驟減。

會話記憶（連續性層）

SQLite數據庫記錄每場對話的摘要。新會話啟動時，AI查詢項目簡報：最近做了什么、做了哪些決策、還有哪些開放問題。再也不用玩「我們上次聊到哪兒了」的猜謎游戲。

血淚教訓：預算必須硬

每層都要嚴格預算。Tier 1限200行，Tier 2限50行。工程師強調：「約束強制質量。」 hitting the limit forces you to move things to the right tier instead of dumping them in the always-loaded file.

另一個反直覺原則：別存AI能推導的東西。文件結構、源碼里可見的代碼模式、git歷史——AI都能自己讀。只存那些「沒有提示就會出錯」的信息。這是區分「必要知識」和「冗余噪音」的試金石。

如果要用AI總結會話，務必加防護。他們曾有一個 summarizer 沒有批量限制，試圖一次性處理50場會話，遇到API錯誤后循環重試整批任務，燒掉了周token預算的三分之一。Batch cap，這是用真金白銀換來的教訓。

這套架構的本質是「認知卸載」。人類工作記憶有限，所以我們用便簽、日歷、書簽。AI的上下文窗口就是它的工作記憶—— Tier 1到Tier 4 相當于給AI配了一套外部存儲系統。區別只在于，AI可以毫秒級檢索，而我們需要翻找。

200行憲法 + 50行糾錯 + 按需加載的項目腦 + 主動查詢的知識庫。這個數字組合，是1500次對話后的收斂解。不是越大越好，而是越準越好。你的CLAUDE.md今天多少行了？