每周30次對話，每次開頭重復(fù)同樣的上下文——這不是職場PUA，是AI編程助手的日常。一位開發(fā)者統(tǒng)計：每月5-8小時浪費在"教AI它本該記得的事"上。

「你的AI能思考，但不能記憶?！?/b>這句話讓他決定自己動手。

四層記憶：把冰箱改成檔案柜

多數(shù)人把記憶當(dāng)成一個桶，塞滿日志、偏好、過時的項目信息，最后全在爭搶有限的上下文窗口。他的解法：按用途分類，而非按時間堆放。

第一層，情景記憶（Episodic）——發(fā)生了什么。會話日志、事件、時間戳，會衰減。

第二層，語義記憶（Semantic）——知道什么。實體、關(guān)系、事實，相對穩(wěn)定。

第三層，項目記憶（Project）——在做什么。目標(biāo)、決策、狀態(tài)，隨項目演進。

第四層，程序記憶（Procedural）——怎么做。工作流、偏好、規(guī)則，幾乎永久。

每層有不同的保留策略、壓縮方式和檢索模式。這個區(qū)分比選什么嵌入模型重要得多。

為什么選SQLite：拒絕基礎(chǔ)設(shè)施表演

沒選Postgres、Redis或任何向量數(shù)據(jù)庫。理由只有一個：SQLite跟著項目走，零連接字符串、零Docker、零月費。一個.db文件，開箱即用。

表結(jié)構(gòu)很直白：tier字段約束四層類型，metadata存JSON，expires_at控制生命周期，distilled標(biāo)記是否已壓縮，access_count記錄訪問頻率。

187個實體、128條關(guān)系，全塞進這個單文件。沒有外部服務(wù)，賬單為零。

蒸餾管道：6300條噪音變1條上下文

原始記憶會膨脹。他設(shè)計了一條蒸餾流水線：定期把數(shù)千條原始記錄壓縮成緊湊的上下文， fit進單次LLM提示。

具體數(shù)字：約6300條原始記憶被壓縮后，活躍工作集仍能一次性喂給模型。不是RAG那種"先搜再拼"，是直接讓AI帶著精簡后的世界觀進場。

效果？三周前的決策現(xiàn)在能自動影響當(dāng)前行為。顏色方案、模型選擇、團隊術(shù)語——不再重復(fù)解釋。

這套系統(tǒng)現(xiàn)在跑在他的Claude Code環(huán)境里。每月省下的5-8小時，夠?qū)懚嗌俅a？