Claude Code 用久了很多人都會遇到一個特別擰巴的場景上午剛讓 AI 梳理完整個項目的模塊劃分下午新開一個會話它又一臉茫然地問你這個項目的技術(shù)棧是什么。你甚至懶得解釋只能把需求重新貼一遍再附上一句之前不是說過了嗎。claude-mem 這個工具就是專門來解決這種AI 失憶癥的。它本身不改變模型能力而是在模型之外加了一層長期記憶。核心思路非常樸素把你在 Claude Code 里每一輪有價值的對話、決策、項目約定自動抽取出來存到本地 SQLite 數(shù)據(jù)庫里下一次新會話啟動時再根據(jù)當(dāng)前上下文把相關(guān)的記憶重新注入給模型。這樣 AI 雖然本質(zhì)上還是那個每次都是新面孔的模型但它的記憶卻被你留在了本地。這篇文章我會從機制到實操把 claude-mem 的完整用法拆一遍重點講清楚它背后的記憶提取邏輯、安裝配置的細(xì)節(jié)、日常使用中容易踩的坑以及我自己的幾個進(jìn)階玩法。適合正在使用 Claude Code、被重復(fù)上下文折磨得不耐煩的開發(fā)者。1. 項目概述claude-mem 是什么解決的到底是什么問題1.1 用過 Claude Code 的人都懂上下文斷裂有多痛Claude Code 的會話機制本質(zhì)上是一次性的。你每開一個新會話模型拿到的上下文就是當(dāng)前對話窗口里的內(nèi)容外加你手動寫在配置文件里的那點東西。上一條會話里討論過的架構(gòu)方案、踩過的坑、最后拍板的接口設(shè)計通通不會自動帶過來。以前大家是怎么解決這個問題的最常見的是維護(hù)一個 CLAUDE.md 或者項目說明文檔把本項目的重要約定一股腦寫進(jìn)去。但這里有個天然缺點這玩意兒是靜態(tài)的、手寫的。你得自己記得去更新它而且更新時機往往滯后。AI 在會話中自己做出的決策、你對方案的反駁和修正、以及那些試了 A 方案不行改走 B 方案的隱性經(jīng)驗都不會自動沉淀下來。我統(tǒng)計過自己的使用情況在沒引入 claude-mem 之前每次新開會話光復(fù)述背景信息就要花掉三四輪對話。多人協(xié)作時更痛苦同事問你這個模塊當(dāng)時為什么用 PostgreSQL 不用 MySQL你只能回去翻聊天記錄。上下文斷裂不只是一個便利性問題它直接拉低了 AI 編程工具的實際產(chǎn)出效率。1.2 claude-mem 的定位與核心價值claude-mem 瞄準(zhǔn)的就是這個空白。它做的事情簡單說就是會話記憶的自動抽取、結(jié)構(gòu)化存儲、按需回填。你可以把它理解成給 Claude Code 裝了一個外掛的海馬體模型本身沒有變記憶能力但每次會話開始時它能把之前沉淀下來的相關(guān)經(jīng)驗重新喂給模型讓 AI 看起來好像一直記得你。跟傳統(tǒng) RAG檢索增強生成方案比claude-mem 輕量得多。它不需要向量數(shù)據(jù)庫不需要搭服務(wù)甚至不需要配置嵌入模型一條 sqlite3 命令就能管理全部數(shù)據(jù)。對于個人開發(fā)者和三五人的小團(tuán)隊來說這比搭建一套知識庫系統(tǒng)劃算太多了。它解決的也不是單次會話的效果而是跨會話的連續(xù)性問題這兩者對 AI 編程體驗的影響是量級上的差別。方案維護(hù)成本自動程度上下文連續(xù)性適用場景CLAUDE.md低但全靠手動低弱穩(wěn)定的項目約定人工筆記高容易遺忘低弱臨時性備忘claude-mem安裝后幾乎零干預(yù)高強頻繁使用 Claude Code 的日常開發(fā)2. 核心機制拆解記憶是怎么被提取、存儲和回填的2.1 三層記憶模型我第一次用 claude-mem 的時候以為它就是一個簡單的記錄對話日志工具用了幾天才發(fā)現(xiàn)它的記憶結(jié)構(gòu)分了三層不同層級的記憶有不同的生命周期和召回方式。第一層是核心記憶Core Memory對應(yīng)的是跨項目通用的個人偏好。比如你習(xí)慣用 Python 3.11、提交信息必須按 Angular 規(guī)范寫、前端組件庫統(tǒng)一用 Ant Design。這些屬于這個人做事的方式適用于所有項目提取后會長期保留。第二層是項目記憶Project Memory綁定某個具體項目目錄的知識比如這個倉庫的支付模塊用的是狀態(tài)機模式生產(chǎn)環(huán)境數(shù)據(jù)庫連的是主從架構(gòu)只在該項目的新會話中召回。第三層是會話記憶Session Memory這是最細(xì)粒度的記憶記錄一次會話里產(chǎn)生的具體事實比如剛才把接口超時時間從 2 秒改成了 5 秒。這個分層設(shè)計相當(dāng)聰明。如果所有記憶混在一起跨項目召回時就會污染上下文反而降低模型判斷的準(zhǔn)確性。分開存儲之后召回范圍可以通過項目路徑自動圈定相關(guān)度會好很多。用生活中的例子類比核心記憶是你的職業(yè)習(xí)慣項目記憶是某個客戶項目的規(guī)矩會話事實是前兩天剛討論過的具體安排三者的保鮮期和適用范圍完全不一樣。2.2 存儲引擎為什么選 SQLiteclaude-mem 把記憶數(shù)據(jù)放在本地 SQLite 數(shù)據(jù)庫文件里而不是用 MySQL 或者 MongoDB更不是向量數(shù)據(jù)庫。我一開始也覺得奇怪按說記憶檢索應(yīng)該用向量比較才算智能后來實際用起來才明白這個選擇的合理性。對于個人工具場景記憶條目的量級也就是幾千到幾萬條SQLite 的 FTS5 全文搜索在這個量級下響應(yīng)速度快得根本感知不到延遲。SQLite 是單文件數(shù)據(jù)庫備份就是把.db文件拷貝走同步到新機器也是拷過去就行完全不需要運維。最實用的一點是你可以用系統(tǒng)自帶的 sqlite3 命令直接在終端里查記憶數(shù)據(jù)排查問題的時候特別方便。向量檢索當(dāng)然也可以插進(jìn)來做語義匹配但大多數(shù)場景下用關(guān)鍵詞精確匹配已經(jīng)足夠。畢竟記憶通常是你自己寫的或者 AI 從對話里提取的術(shù)語本身就比較準(zhǔn)確這時候全文搜索命中率并不差。工具設(shè)計者沒有為了顯得高級而引入重依賴這個克制我覺得是對的。2.3 自動提取與回填的工作流程claude-mem 的完整工作流程可以拆成四步每一步我都在實際使用中驗證過。第一步是監(jiān)聽會話。它通過 MCP 協(xié)議跟 Claude Code 通信MCPModel Context Protocol模型上下文協(xié)議本質(zhì)上是一個標(biāo)準(zhǔn)接口讓模型可以調(diào)用外部工具。claude-mem 作為 MCP 服務(wù)端能拿到當(dāng)前會話的元數(shù)據(jù)包括項目路徑、會話 ID 等。第二步是候選記憶采集在會話進(jìn)行過程中它會根據(jù)啟發(fā)式規(guī)則識別可能值得記住的片段。第三步是會話結(jié)束后的提取這個階段會調(diào)用模型對候選片段做一次過濾和精簡把口語化的對話整理成結(jié)構(gòu)化的記憶條目再寫入 SQLite。第四步是召回與注入下次新會話啟動時claude-mem 根據(jù)當(dāng)前項目路徑做相關(guān)性匹配把最相關(guān)的記憶插入到系統(tǒng)提示詞里讓模型在回答問題之前就已經(jīng)知道了歷史背景。階段觸發(fā)時機核心動作產(chǎn)出監(jiān)聽會話持續(xù)中收集對話上下文原始片段采集會話進(jìn)行時啟發(fā)式規(guī)則篩選候選候選記憶提取會話結(jié)束后模型整理與精煉結(jié)構(gòu)化記憶條目回填新會話啟動時相關(guān)性匹配與注入注入后的系統(tǒng)提示詞這里面最關(guān)鍵的環(huán)節(jié)其實是第四步的回填。記憶存了不用就是死數(shù)據(jù)回填做得好不好取決于相關(guān)度匹配的算法和一整套過濾邏輯。實操中你會發(fā)現(xiàn)回填的記憶需要控制數(shù)量如果一股腦把所有歷史記憶全塞給模型上下文窗口會爆而且雜音會干擾模型判斷。默認(rèn)配置下只會注入最相關(guān)的幾條這個度需要根據(jù)自己的項目復(fù)雜度來調(diào)。2.4 過濾和去重邏輯記憶系統(tǒng)做不好很容易變成垃圾場填滿垃圾。claude-mem 在這塊做了兩層處理。第一層是價值過濾謝謝好的可以這類寒暄和確認(rèn)性話語會在采集階段就被拋掉。第二層是語義去重同一個決策如果在多個會話里被反復(fù)提到系統(tǒng)會保留信息量最完整的那條并合并其它條目里的補充信息。從我自己的使用經(jīng)驗看這兩層過濾在 80% 的場景下是夠用的。但因為它本質(zhì)上還是依賴模型判斷偶爾也會出現(xiàn)誤殺或者漏網(wǎng)。我遇到過把一次重要架構(gòu)討論的片段當(dāng)成噪音丟掉的情況也遇到過把兩個相似但不同的 Bug 修復(fù)記錄合并成一條的情況。這類問題后面在第 5 節(jié)會專門講排查和處理辦法。3. 安裝配置全流程從零到一跑起來3.1 環(huán)境準(zhǔn)備安裝 claude-mem 之前我建議你先確認(rèn)自己的環(huán)境滿足四個條件。第一電腦上得有 Node.js 運行時版本建議 18 以上。因為 Claude Code 本身就是 Node.js 生態(tài)的工具claude-mem 作為它的擴展同樣跑在 Node 環(huán)境里你機器上既然能跑 Claude CodeNode 環(huán)境基本就有了。第二需要 npm 或 pnpm 包管理器用于安裝 claude-mem 本體。第三要裝好 git這不是安裝 claude-mem 的硬性要求但后面如果你想從源碼構(gòu)建或者參與二次開發(fā)沒有 git 會很不方便。第四提前裝好并至少跑通過一次 Claude Codeclaude-mem 是在它的基礎(chǔ)上做增強不會替你解決 Claude Code 本身的安裝問題。操作系統(tǒng)方面macOS 和 Linux 用起來最順手Windows 在 WSL 2 環(huán)境下也沒問題。我的建議是如果你的主力環(huán)境是原生 Windows優(yōu)先開一個 WSL 2之后所有環(huán)節(jié)都會順暢很多。3.2 安裝與初始化安裝過程并不復(fù)雜核心命令就兩條。如果你通過 npm 安裝執(zhí)行npm install -g claude-mem如果你想用最新源碼或者對項目做二次開發(fā)可以走 git 路線git clone https://github.com/yourfork/claude-mem.git cd claude-mem npm install npm run build npm link安裝完成之后進(jìn)入一個你已經(jīng)用 Claude Code 跑過的項目目錄執(zhí)行初始化claude-mem init這一步它會做三件事在用戶主目錄下創(chuàng)建~/.claude-mem/文件夾生成配置文件config.json和 SQLite 數(shù)據(jù)庫文件memories.db然后嘗試在當(dāng)前項目里注冊 MCP 服務(wù)。初始化完成后需要重啟 Claude Code 才能讓 MCP 生效。驗證是否裝好可以跑一下狀態(tài)命令claude-mem status看到類似Database OK的提示就說明數(shù)據(jù)層沒問題。我再提醒一句init是在項目目錄級別執(zhí)行的如果你在另一個項目目錄下也要用 claude-mem需要重新在那個目錄里執(zhí)行一次claude-mem init來注冊 MCP 服務(wù)否則 Claude Code 不會在那個項目里加載記憶工具。3.3 核心配置參數(shù)說明配置文件默認(rèn)路徑是~/.claude-mem/config.json。我用文本編輯器打開后的默認(rèn)內(nèi)容大概是這樣的{ memoryDir: ~/.claude-mem, autoMemorize: true, maxMemoryContext: 5, minSimilarity: 0.4, projectScope: auto }這四個配置項是日常起作用的我一個個說。memoryDir是記憶數(shù)據(jù)的存放目錄默認(rèn)在用戶主目錄下。如果你有多個工作目錄且想讓它們共享同一套記憶可以把多個項目的配置都指向同一個目錄。autoMemorize控制是否自動提取記憶默認(rèn)是 true。開著省心但如果你發(fā)現(xiàn)提取出來的東西質(zhì)量太低可以先關(guān)掉自動提取只用手動方式記重點。maxMemoryContext控制每次新會話最多注入幾條歷史記憶默認(rèn)是 5。項目復(fù)雜度高、上下文需求多的時候可以調(diào)到 8 或 10但別貪多超過這個數(shù)值模型處理起來會明顯變慢還容易分心。minSimilarity是召回相關(guān)度的最低閾值默認(rèn) 0.4數(shù)值越高召回越嚴(yán)格越不容易混入不相關(guān)的記憶。注意不要在主目錄下直接改完配置就開始用。改完配置以后在各個項目目錄里重新跑一次claude-mem init讓新的配置值真正同步到各項目的 MCP 服務(wù)配置里去這一步漏掉的話改了半天也可能不生效。4. 日常使用操作手冊讓記憶在項目里流動起來4.1 常用命令速查claude-mem 的命令設(shè)計得很直觀第一次用基本不用翻文檔。我整理了一份高頻速查表按我的使用頻率排的命令作用claude-mem status查看數(shù)據(jù)庫狀態(tài)、記憶條數(shù)、最近提取時間claude-mem recall以時間倒序瀏覽最近的記憶claude-mem search 關(guān)鍵詞全文搜索記憶內(nèi)容claude-mem remember 內(nèi)容手動寫入一條記憶claude-mem delete id按 ID 刪除一條記憶claude-mem stats統(tǒng)計各類型記憶的數(shù)量分布recall和search是我用得最多的兩個。每天下班前我會用recall掃一遍今天沉淀了什么發(fā)現(xiàn)明顯過時的就刪掉。search更像一個針對性拉取比如遇到一個 Bug 想確認(rèn)之前是不是修過類似的直接搜關(guān)鍵詞比翻聊天記錄快得多。4.2 接入 Claude Code 的 MCP 配置claude-mem 能跟 Clude Code 深度協(xié)作靠的是 MCP 協(xié)議。正常執(zhí)行claude-mem init之后它會自動在當(dāng)前項目的.mcp.json文件里寫入服務(wù)配置。這個文件在項目根目錄下內(nèi)容大體會是這樣{ mcpServers: { claude-mem: { command: claude-mem, args: [serve] } } }配置寫進(jìn)去以后重啟 Claude Code模型就具備了調(diào)用 claude-mem 工具的能力。這時候你可以在對話里直接問檢索一下我們之前關(guān)于支付超時的結(jié)論Claude 會自動調(diào)用記憶工具并把結(jié)果作為上下文來回答。如果發(fā)現(xiàn).mcp.json里沒有自動寫入也有一個通用的手動添加辦法在 Claude Code 的設(shè)置界面里添加一個 MCP 服務(wù)命令填claude-mem參數(shù)填serve。不同版本的入口位置會有點差別但 MCP 服務(wù)的字段結(jié)構(gòu)是通用的。每次改完.mcp.json記得重啟 Claude Code我吃了好幾次沒重啟導(dǎo)致工具不生效的虧。4.3 記憶管理的日常工作流工具裝上只是開始真正讓記憶系統(tǒng)產(chǎn)生價值靠的是日常使用中形成流程。我自己跑了幾個月之后固定下來一套三步操作節(jié)奏。第一步是會話結(jié)束時的自動沉淀。這是 claude-mem 自動幫我完成的我的做法是確保autoMemorize開著并定期抽查提取質(zhì)量。第二步是每周的記憶巡檢。周末我會花十分鐘跑一遍claude-mem recall把已經(jīng)失效的條目刪掉比如已經(jīng)上線的臨時方案、已經(jīng)廢棄的接口約定。這一步很重要記憶系統(tǒng)最大的敵人不是記不住而是記住太多過期的東西。第三步是關(guān)鍵的主動寫入。有些重要約定如果對話中沒有被自動捕捉到我會在會話里直接說一句請把以下內(nèi)容記入記憶XX 接口的連接超時調(diào)整為 5 秒這樣觸發(fā) claude-mem 的手動寫入路徑。4.4 與 claude-mem 協(xié)同時的提示詞技巧還有一個細(xì)節(jié)值得專門寫一段。即便 claude-mem 在會話啟動時會自動注入相關(guān)記憶我仍然會在任務(wù)開始前主動跟 Claude 確認(rèn)一遍背景。比如說先不要動手改代碼。請用記憶工具搜索一下我們在支付模塊歷史上做過哪些決策重點看超時時間和冪等方案然后總結(jié)給我。這樣做有兩個好處。第一它把記憶內(nèi)容顯式地放進(jìn)當(dāng)前上下文中模型在后續(xù)處理中引用這些信息的準(zhǔn)確度會更高。第二如果你發(fā)現(xiàn)它搜出來的東西跟實際情況對不上說明記憶提取或召回的環(huán)節(jié)出了問題可以及時排查。記憶系統(tǒng)的質(zhì)量是需要校準(zhǔn)的校準(zhǔn)方式就是定期在對話里主動測試召回結(jié)果。5. 常見問題與排查技巧實錄5.1 安裝和初始化階段的坑這個工具整體裝起來不復(fù)雜但我在早期踩過幾個很典型的坑在這里一并列出來。第一個坑是claude-mem命令找不到。表現(xiàn)是執(zhí)行命令時提示command not found。原因基本是 npm 的全局 bin 目錄沒有加進(jìn) PATH。解決方法是先找到 npm 全局目錄執(zhí)行npm config get prefix然后把$(npm config get prefix)/bin加進(jìn)系統(tǒng) PATH。第二個坑是 MCP 服務(wù)沒有生效。我一度以為是 claude-mem 沒裝好折騰半天才發(fā)現(xiàn)是完全忘了重啟 Claude Code。MCP 配置是啟動時加載的不重啟就不會加載新注冊的工具。第三個坑是初始化之后memories.db文件沒有生成。先檢查配置文件目錄的寫權(quán)限再確認(rèn) Node 版本是不是太老這兩個問題會在信息提示里被掩蓋排查時優(yōu)先排除。如果實在排查不出來我建議用最笨也最有效的辦法把~/.claude-mem/目錄備份后整個刪掉重新執(zhí)行claude-mem init。反正數(shù)據(jù)庫里存的只是記憶不會有代碼文件初始化失敗不會造成業(yè)務(wù)損失。5.2 記憶不生效和噪聲過多記憶不生效就是明明存了但新會話就是記不起來。這種問題我遇到過三次每次原因都不一樣。第一次是autoMemorize被我不小心改成了 false導(dǎo)致新會話不再注入記憶。第二次是minSimilarity設(shè)得過高新會話的內(nèi)容跟歷史記憶之間的相似度評分達(dá)不到閾值記憶就召不回來。第三次是項目路徑不匹配我在 A 目錄初始化的 claude-mem跑到 B 目錄去開會話B 目錄沒有注冊 MCP 服務(wù)自然就完全沒有記憶能力。檢查路徑時記住一個原則記憶是按項目路徑隔離的哪個目錄 init 了哪個目錄才有記憶。相反的極端問題是噪聲過多。如果你發(fā)現(xiàn)新會話里注入的記憶經(jīng)常跟當(dāng)前任務(wù)八竿子打不著那就是過濾邏輯沒有生效。優(yōu)先確認(rèn)maxMemoryContext是不是設(shè)得太高了默認(rèn) 5 條雖然看起來少但每條都是精挑的。其次是調(diào)高minSimilarity把它從 0.4 往上拉比如 0.6召回的召回精度會明顯提升代價是會丟掉一些邊界相關(guān)度不夠高的記憶。我的習(xí)慣是寧可少召回不要假召回。5.3 隱私與數(shù)據(jù)安全要注意的事claude-mem 的所有記憶數(shù)據(jù)都存儲在本地 SQLite 文件里這個設(shè)計帶來了很大的隱私優(yōu)勢你的對話內(nèi)容和項目決策不會被上傳到任何第三方服務(wù)器。但本地存儲不等于絕對安全有幾個使用習(xí)慣需要特別注意。第一~/.claude-mem/memories.db里存的都是明文如果這個文件落在別人手里對方能直接看到你所有項目的技術(shù)決策和代碼片段。不要把~/.claude-mem整個目錄提交到 git 倉庫里哪怕是私有倉庫也要養(yǎng)成習(xí)慣忽略它。第二如果你有多個項目同時使用注意記憶查詢時的路徑隔離。claude-mem 是按項目路徑區(qū)分記憶范圍的但如果兩個項目不小心配了同一個memoryDir記憶就會串味這不僅是管理混亂的問題還可能導(dǎo)致 A 項目的敏感信息在 B 項目的會話中出現(xiàn)。第三如果你的電腦設(shè)置了自動備份到云盤~/.claude-mem目錄會跟著備份里面的記憶內(nèi)容也就跟著上了云。對保密要求高的項目這種自動同步之前先想想能不能接受。提示針對最敏感的項目可以給 claude-mem 單獨設(shè)置一個獨立的memoryDir比如/path/to/secret-project/.claude-mem。用完之后整目錄清掉數(shù)據(jù)完全不落盤。這是最干凈的做法。6. 進(jìn)階玩法與個人心得6.1 多項目記憶隔離與共享如果你跟一樣同時維護(hù)好幾個項目你會發(fā)現(xiàn) claude-mem 默認(rèn)的按項目路徑隔離既是優(yōu)點也是限制。優(yōu)點是每個項目獨立A 項目的記憶絕不會跑到 B 項目去互不干擾。但缺點是我在 A 項目里踩過的這個 SDK 的 v3 版本有大坑別用這種經(jīng)驗B 項目完全不知道。為此我摸索出的折中方案是在 A 和 B 項目各配一個獨立 memoryDir同時把這類跨項目通用的經(jīng)驗通過手動claude-mem remember寫入一個共享的核心記憶庫里然后在涉及到的項目里把memoryDir指向這個共享庫。這種做法在技術(shù)上是可行的它的本質(zhì)是把 core-level 的記憶和 project-level 的記憶分開管理符合我之前說的三層記憶模型。但要注意共享庫一旦建立它的內(nèi)容增長速度會很快建議每兩周做一次清點去除不然過了兩三個月這套庫就變成了沒人敢動的大泥球。6.2 記憶結(jié)構(gòu)的分類與標(biāo)簽我強烈建議在 workflow 里加一道分類標(biāo)簽的工序。claude-mem 允許給記憶條目附加類型標(biāo)簽我的習(xí)慣是分成四類標(biāo)簽含義示例decision技術(shù)決策及理由支付模塊改用狀態(tài)機而非直接 if-elseinterface接口約定與變更user API 的 email 字段改為可選bug根因復(fù)盤的 Bug 記錄空指針根因是上游返回了 null 而非空數(shù)組preference個人或團(tuán)隊偏好提交信息用 Angular 規(guī)范加了標(biāo)簽之后最大的收益是召回和篩選可以聯(lián)動。比如每次新會話我只想注入decision和interface就可以在手動的記憶檢索指令中帶上標(biāo)簽過濾。日常巡檢也更有目標(biāo)性刷一遍bug標(biāo)簽就能快速回看最近修過的坑。給記憶做標(biāo)簽看起來多了一步操作但長期積累下來檢索效率的提升非常明顯。6.3 我踩過幾次坑之后的體會文章最后說點我自己的真實體會。第一點是別指望純自動。現(xiàn)在很多工具宣傳語都強調(diào)零配置、全自動但 claude-mem 這種記憶工具提取質(zhì)量完全依賴于模型的判斷而模型判斷必然有誤差。我前兩周過度相信自動提取后來發(fā)現(xiàn)大量關(guān)鍵決策根本沒有被記錄反而是很多臨時性的討論被當(dāng)成重點存了下來。把它調(diào)成自動提取 每周手動巡檢的模式之后效果才真正穩(wěn)定起來。第二點是記憶要斷舍離。記憶系統(tǒng)最重要的品質(zhì)不是大而全而是精而準(zhǔn)。寧可每次新會話注入三條高質(zhì)量記憶也不要塞入二十條正確但無用的廢話。定期清理過時條目這一點怎么強調(diào)都不過分。第三點是記憶里最有價值的不是做了什么而是為什么這樣做。AI 幫你改代碼的過程本身已經(jīng)有了代碼注釋和 git 記錄但當(dāng)時為什么放棄方案 A 選方案 B這種隱性的決策理由只會存在于對話里。claude-mem 存下來的最大價值正在于它把這種決策理由結(jié)構(gòu)化地保留了下來。你問它這個模塊為什么用狀態(tài)機它真的能給你一個帶著來龍去脈的答案。用 claude-mem 這幾個月我最直觀的感受是AI 從每次都得重新自我介紹一遍的臨時工變成了好像一直記得你做事風(fēng)格的長期搭檔。光憑這一點就足夠讓我把它列為 Claude Code 用戶的第一件官方外掛了。