1. 項(xiàng)目緣起與核心定位第一次看到claude-mem這個(gè)名字我的直覺(jué)是這大概率是一個(gè)圍繞 Claude 生態(tài)做“記憶層”的工具。事實(shí)也確實(shí)如此。簡(jiǎn)單說(shuō)claude-mem解決的是一個(gè)非常具體、也非常痛的問(wèn)題——讓 Claude 在跨會(huì)話、跨任務(wù)、跨項(xiàng)目的使用過(guò)程中擁有可持久化、可檢索、可復(fù)用的記憶能力。如果你只是偶爾用 Claude 聊幾句天氣、改一段文案可能感受不到這個(gè)需求的迫切性。但只要你把 Claude 當(dāng)成日常開(kāi)發(fā)、寫(xiě)作、研究、運(yùn)維的長(zhǎng)期協(xié)作對(duì)象很快就會(huì)撞上那堵墻每次新開(kāi)一個(gè)會(huì)話它就像失憶了一樣昨天剛講過(guò)的項(xiàng)目背景、代碼規(guī)范、業(yè)務(wù)約束、命名習(xí)慣全部歸零。你得一遍遍重復(fù)“我們這個(gè)項(xiàng)目用的是 TypeScript 嚴(yán)格模式”“數(shù)據(jù)庫(kù)字段統(tǒng)一用 snake_case”“部署走的是內(nèi)部流水線不要給我 GitHub Actions 的示例”。這種重復(fù)勞動(dòng)時(shí)間一長(zhǎng)就讓人抓狂。claude-mem要做的就是把這層記憶從“人腦記憶 手動(dòng)粘貼”變成“結(jié)構(gòu)化存儲(chǔ) 自動(dòng)召回”。它適合幾類人一是把 Claude 深度嵌入日常工作流的開(kāi)發(fā)者二是需要長(zhǎng)期維護(hù)同一套知識(shí)體系的寫(xiě)作者、研究者三是團(tuán)隊(duì)里想把 Claude 使用經(jīng)驗(yàn)沉淀下來(lái)、避免每個(gè)人重復(fù)踩坑的技術(shù)負(fù)責(zé)人。哪怕你只是剛接觸 Claude、還沒(méi)形成固定工作流理解claude-mem的設(shè)計(jì)思路也能幫你少走很多彎路。我自己的使用場(chǎng)景比較典型同時(shí)維護(hù)三個(gè)不同技術(shù)棧的項(xiàng)目一個(gè)是 Python 數(shù)據(jù)處理一個(gè)是 Node.js 后端一個(gè)是純前端。三個(gè)項(xiàng)目的代碼風(fēng)格、依賴管理、測(cè)試框架完全不同。以前每次切換項(xiàng)目我都要在會(huì)話開(kāi)頭花五分鐘“喂背景”。用了claude-mem之后這部分工作基本被自動(dòng)化了。下面我就把這套東西拆開(kāi)從設(shè)計(jì)思路到實(shí)操細(xì)節(jié)再到踩過(guò)的坑完整講一遍。2. 記憶層的整體設(shè)計(jì)與思路拆解2.1 為什么不能只靠“長(zhǎng)上下文”很多人第一反應(yīng)是Claude 的上下文窗口已經(jīng)很大了直接把所有歷史記錄塞進(jìn)去不就行了這個(gè)想法在理論上成立實(shí)操中會(huì)撞上三個(gè)硬約束。第一是成本。上下文越長(zhǎng)每次請(qǐng)求消耗的 token 越多費(fèi)用是線性甚至超線性增長(zhǎng)的。你不可能為了記住三個(gè)月前的一句約定每次都把三個(gè)月的對(duì)話全帶上。第二是信噪比。歷史記錄里大量?jī)?nèi)容是寒暄、試錯(cuò)、廢棄方案。把這些全塞進(jìn)去反而會(huì)稀釋真正重要的信息模型更容易被無(wú)關(guān)內(nèi)容干擾輸出質(zhì)量下降。第三是結(jié)構(gòu)化程度。對(duì)話是線性的、非結(jié)構(gòu)化的。而真正有價(jià)值的記憶往往是結(jié)構(gòu)化的這個(gè)項(xiàng)目的技術(shù)棧是什么、有哪些硬性約束、常用的命令是什么、哪些坑已經(jīng)踩過(guò)。線性對(duì)話很難高效承載這種結(jié)構(gòu)。所以claude-mem的核心思路不是“把上下文拉長(zhǎng)”而是把記憶從對(duì)話流里抽離出來(lái)做成獨(dú)立的、可增刪改查的存儲(chǔ)層。對(duì)話時(shí)按需召回相關(guān)片段而不是全量灌入。這個(gè)設(shè)計(jì)決策是整個(gè)項(xiàng)目的地基。2.2 記憶的三種粒度在實(shí)際落地中我把記憶分成三種粒度來(lái)管理這個(gè)劃分方式在claude-mem的實(shí)踐中非常關(guān)鍵。全局記憶跨所有項(xiàng)目通用的偏好。比如“回答盡量簡(jiǎn)潔不要過(guò)度解釋”“代碼示例優(yōu)先用 TypeScript”“不要用 emoji”。這類記憶量少、穩(wěn)定幾乎每次會(huì)話都該帶上。項(xiàng)目記憶綁定到具體項(xiàng)目。比如“這個(gè)倉(cāng)庫(kù)用 pnpm 不用 npm”“測(cè)試命令是pnpm test:unit”“API 返回統(tǒng)一包一層{ code, data, msg }”。這類記憶在切換到對(duì)應(yīng)項(xiàng)目時(shí)才召回。會(huì)話記憶單次任務(wù)內(nèi)的臨時(shí)上下文。比如“這次重構(gòu)只動(dòng)utils/date.ts別碰其他文件”。這類記憶生命周期短任務(wù)結(jié)束就可以歸檔或丟棄。把粒度分清楚好處是召回時(shí)可以做精準(zhǔn)匹配避免全局記憶被項(xiàng)目細(xì)節(jié)污染也避免項(xiàng)目記憶在無(wú)關(guān)會(huì)話里浪費(fèi) token。這個(gè)分層不是claude-mem強(qiáng)制規(guī)定的而是我在使用中總結(jié)出的最順手的方式你可以根據(jù)自己的工作流調(diào)整。2.3 存儲(chǔ)格式的選型考量記憶存成什么格式直接決定了后續(xù)能不能高效檢索。我試過(guò)三種方案最后落在 Markdown 前置元數(shù)據(jù)front matter的組合上。純文本最簡(jiǎn)單但沒(méi)法結(jié)構(gòu)化查詢。純 JSON 結(jié)構(gòu)化好但人讀起來(lái)痛苦手動(dòng)維護(hù)容易出錯(cuò)。Markdown 加 front matter 是個(gè)折中正文用自然語(yǔ)言寫(xiě)方便人和模型理解元數(shù)據(jù)用 YAML 寫(xiě)方便程序過(guò)濾。一個(gè)典型的記憶條目長(zhǎng)這樣--- id: proj-backend-001 scope: project project: order-service tags: [tech-stack, convention] created: 2024-05-12 updated: 2024-06-01 priority: high --- 后端項(xiàng)目 order-service 使用 NestJS PostgreSQL。 數(shù)據(jù)庫(kù)遷移統(tǒng)一用 TypeORM migration禁止手寫(xiě) SQL 改表結(jié)構(gòu)。 所有 DTO 必須用 class-validator 做入?yún)⑿ｒ?yàn)。這種格式的好處是檢索時(shí)可以先按scope、project、tags過(guò)濾再把命中的正文拼進(jìn)上下文。人也能直接打開(kāi)文件讀維護(hù)成本低。我強(qiáng)烈建議不要一上來(lái)就上向量數(shù)據(jù)庫(kù)先用文件系統(tǒng) 元數(shù)據(jù)過(guò)濾跑通了再考慮語(yǔ)義檢索。過(guò)早引入復(fù)雜度是這類項(xiàng)目最常見(jiàn)的翻車原因。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 記憶的寫(xiě)入時(shí)機(jī)記憶什么時(shí)候?qū)懕仍趺磳?xiě)更重要。寫(xiě)早了記的都是廢話寫(xiě)晚了重要信息已經(jīng)丟了。我的經(jīng)驗(yàn)是抓住三個(gè)時(shí)機(jī)。時(shí)機(jī)一會(huì)話結(jié)束前的復(fù)盤(pán)。每次一個(gè)任務(wù)告一段落花一分鐘問(wèn)自己這次有沒(méi)有產(chǎn)生“下次還用得上”的信息如果有立刻寫(xiě)進(jìn)記憶。比如這次搞清楚了某個(gè)報(bào)錯(cuò)的根因下次大概率還會(huì)遇到那就記下來(lái)。時(shí)機(jī)二用戶明確糾正時(shí)。當(dāng)你說(shuō)“不對(duì)我們不用這種方式”這本身就是高價(jià)值記憶。因?yàn)檫@說(shuō)明默認(rèn)行為不符合你的預(yù)期必須顯式固化下來(lái)否則下次還會(huì)錯(cuò)。時(shí)機(jī)三項(xiàng)目初始化時(shí)。新項(xiàng)目開(kāi)始時(shí)把技術(shù)棧、目錄結(jié)構(gòu)、命令、約束一次性寫(xiě)全。這部分投入產(chǎn)出比最高能省掉后續(xù)無(wú)數(shù)次重復(fù)解釋。注意不要試圖記錄所有東西。記憶庫(kù)的價(jià)值在于精不在于多。我見(jiàn)過(guò)有人把每次對(duì)話都存下來(lái)結(jié)果檢索時(shí)噪音太大反而不好用。寧可少記也要保證每條記憶都是“下次真的會(huì)用”。3.2 記憶的召回策略召回是記憶層真正發(fā)揮作用的地方。我的策略是“先過(guò)濾再排序后截?cái)唷?。先按?dāng)前會(huì)話的上下文做過(guò)濾如果當(dāng)前在處理order-service項(xiàng)目就只召回scope: global和project: order-service的記憶其他項(xiàng)目的直接排除。再按優(yōu)先級(jí)和更新時(shí)間排序priority: high的排前面最近更新的排前面。因?yàn)轫?xiàng)目約束往往會(huì)演進(jìn)舊記憶可能已經(jīng)過(guò)時(shí)。最后按 token 預(yù)算截?cái)嘟o記憶層分配一個(gè)固定的 token 上限比如 2000 token。超出就按排序結(jié)果截?cái)啾ＷC不會(huì)擠占正常對(duì)話的空間。這個(gè)策略聽(tīng)起來(lái)簡(jiǎn)單但效果很穩(wěn)。我實(shí)測(cè)下來(lái)2000 token 的記憶預(yù)算配合精準(zhǔn)的元數(shù)據(jù)過(guò)濾能覆蓋 90% 以上的場(chǎng)景需求。剩下的 10% 靠臨時(shí)手動(dòng)補(bǔ)充就夠了。3.3 記憶的更新與失效記憶不是寫(xiě)完就完事了它會(huì)過(guò)期、會(huì)沖突、會(huì)被推翻。處理不好記憶庫(kù)會(huì)變成“謊言庫(kù)”比沒(méi)有記憶還糟糕。我的做法是給每條記憶加updated字段并且在召回時(shí)優(yōu)先信任新記憶。如果兩條記憶沖突比如一條說(shuō)“用 npm”一條說(shuō)“用 pnpm”那就以u(píng)pdated更晚的為準(zhǔn)同時(shí)把舊的那條標(biāo)記為deprecated而不是直接刪除。保留歷史的好處是萬(wàn)一新決策有問(wèn)題還能回溯。另外我會(huì)定期大概每月一次做一次記憶庫(kù)清理。把超過(guò)三個(gè)月沒(méi)被召回過(guò)的低優(yōu)先級(jí)記憶歸檔把明顯過(guò)時(shí)的刪掉。這個(gè)維護(hù)動(dòng)作不能省否則記憶庫(kù)會(huì)越來(lái)越臃腫召回質(zhì)量越來(lái)越差。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 目錄結(jié)構(gòu)設(shè)計(jì)落地claude-mem的第一步是把記憶庫(kù)的目錄結(jié)構(gòu)定下來(lái)。我用的結(jié)構(gòu)是這樣的claude-mem/ ├── global/ │ ├── preferences.md │ └── conventions.md ├── projects/ │ ├── order-service/ │ │ ├── tech-stack.md │ │ ├── commands.md │ │ └── pitfalls.md │ └──>import os import yaml from datetime import datetime def load_memories(root, scopeNone, projectNone): results [] for dirpath, _, filenames in os.walk(root): for fn in filenames: if not fn.endswith(.md): continue path os.path.join(dirpath, fn) with open(path, r, encodingutf-8) as f: content f.read() if not content.startswith(---): continue _, meta_raw, body content.split(---, 2) meta yaml.safe_load(meta_raw) if scope and meta.get(scope) ! scope: continue if project and meta.get(project) ! project: continue results.append({ meta: meta, body: body.strip(), updated: meta.get(updated, 1970-01-01) }) results.sort(keylambda x: (x[meta].get(priority) ! high, x[updated]), reverseFalse) return results def build_context(memories, token_budget2000): out [] used 0 for m in memories: text m[body] approx_tokens len(text) // 2 if used approx_tokens token_budget: break out.append(text) used approx_tokens return \n\n.join(out)這段代碼不復(fù)雜但有幾個(gè)細(xì)節(jié)值得說(shuō)。token_budget用字符數(shù)除以 2 粗略估算 token中文場(chǎng)景下這個(gè)比例接近實(shí)際。排序時(shí)把priority: high的排前面同優(yōu)先級(jí)按更新時(shí)間倒序。實(shí)際用的時(shí)候把build_context的輸出拼到系統(tǒng)提示詞里就行。4.3 與 Claude 的集成方式集成方式取決于你用的是哪種 Claude 入口。如果是 API 調(diào)用就在構(gòu)造 messages 時(shí)把記憶內(nèi)容作為 system prompt 的一部分注入。如果是網(wǎng)頁(yè)版就手動(dòng)把召回結(jié)果粘貼到會(huì)話開(kāi)頭。API 方式的關(guān)鍵是把記憶和指令分開(kāi)。記憶放在 system prompt 的前半部分用明確的分隔符隔開(kāi)比如[記憶上下文開(kāi)始] 這里放召回的記憶內(nèi)容 [記憶上下文結(jié)束] 以上是歷史記憶請(qǐng)?jiān)诖嘶A(chǔ)上回答后續(xù)問(wèn)題。這樣模型能清楚區(qū)分“這是背景”和“這是任務(wù)”不會(huì)把記憶內(nèi)容當(dāng)成用戶指令來(lái)執(zhí)行。我踩過(guò)一次坑沒(méi)加分隔符結(jié)果模型把記憶里的一句“禁止手寫(xiě) SQL”當(dāng)成了當(dāng)前任務(wù)的指令回復(fù)里反復(fù)強(qiáng)調(diào)這一點(diǎn)很尷尬。4.4 參數(shù)選擇與調(diào)優(yōu)過(guò)程幾個(gè)關(guān)鍵參數(shù)我調(diào)過(guò)好幾輪分享下最終值和理由。token 預(yù)算從 1000 調(diào)到 2000最后定在 2000。1000 經(jīng)常不夠用重要記憶被截?cái)?000 以上又會(huì)擠占正常對(duì)話空間而且邊際收益遞減。2000 是個(gè)平衡點(diǎn)。召回條數(shù)上限不設(shè)硬上限只設(shè) token 上限。因?yàn)椴煌洃涢L(zhǎng)度差異大按條數(shù)限制不合理。優(yōu)先級(jí)權(quán)重high的記憶無(wú)條件優(yōu)先normal的按時(shí)間排序low的只在 token 有富余時(shí)才帶。這個(gè)權(quán)重劃分讓召回結(jié)果更符合直覺(jué)。更新頻率項(xiàng)目記憶隨項(xiàng)目演進(jìn)實(shí)時(shí)更新全局記憶大概每月 review 一次。全局記憶變化慢頻繁改反而容易引入不一致。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 記憶沖突怎么辦最常見(jiàn)的沖突是“新舊規(guī)則打架”。比如三個(gè)月前記的是“用 Jest 測(cè)試”上個(gè)月項(xiàng)目遷移到了 Vitest但舊記憶沒(méi)刪。這時(shí)候召回會(huì)把兩條都帶上模型可能隨機(jī)選一條行為不穩(wěn)定。我的處理方式是新記憶寫(xiě)入時(shí)主動(dòng)搜索是否有同主題的舊記憶有就標(biāo)記為 deprecated。具體做法是在 front matter 里加supersedes字段指向被替代的記憶 id。召回時(shí)如果發(fā)現(xiàn)某條記憶被supersedes引用就自動(dòng)跳過(guò)。這樣既保留了歷史又不會(huì)造成沖突。5.2 記憶召回不相關(guān)的內(nèi)容有時(shí)候明明在處理 A 項(xiàng)目卻召回了 B 項(xiàng)目的記憶。排查下來(lái)通常是兩個(gè)原因一是project字段寫(xiě)錯(cuò)了或漏寫(xiě)了導(dǎo)致過(guò)濾失效二是全局記憶里混入了項(xiàng)目特定的內(nèi)容。解決辦法是嚴(yán)格區(qū)分全局和項(xiàng)目記憶的邊界。判斷標(biāo)準(zhǔn)很簡(jiǎn)單這條記憶換到另一個(gè)項(xiàng)目還成立嗎成立就是全局不成立就是項(xiàng)目。我一開(kāi)始圖省事把一些項(xiàng)目約定寫(xiě)進(jìn)了全局結(jié)果在別的項(xiàng)目里被錯(cuò)誤召回改了半天才找到原因。5.3 記憶庫(kù)越來(lái)越大怎么辦用久了記憶庫(kù)會(huì)膨脹召回變慢噪音變多。我的應(yīng)對(duì)是三層機(jī)制一是priority: low的記憶定期歸檔二是超過(guò) 90 天沒(méi)被召回的記憶自動(dòng)降級(jí)三是每季度做一次人工 review把確實(shí)沒(méi)用的刪掉。這里有個(gè)反直覺(jué)的經(jīng)驗(yàn)不要怕刪記憶。很多人覺(jué)得刪了可惜萬(wàn)一以后用得上呢但實(shí)際上真正重要的記憶會(huì)被反復(fù)召回不會(huì)被遺忘而那些長(zhǎng)期不用的記憶大概率就是沒(méi)用的。刪掉它們反而讓召回更精準(zhǔn)。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向解決方式記憶完全沒(méi)生效注入位置錯(cuò)誤檢查 system prompt 是否包含記憶確認(rèn)拼接邏輯加分隔符召回了無(wú)關(guān)項(xiàng)目記憶project 字段缺失檢查 front matter補(bǔ)全 project 字段新舊規(guī)則沖突舊記憶未標(biāo)記搜索同主題記憶加 supersedes 字段召回內(nèi)容被截?cái)鄑oken 預(yù)算太小統(tǒng)計(jì)召回總長(zhǎng)度調(diào)大預(yù)算或精簡(jiǎn)記憶模型把記憶當(dāng)指令缺少分隔符檢查注入格式加明確的上下文標(biāo)記記憶庫(kù)檢索變慢文件過(guò)多統(tǒng)計(jì)文件數(shù)量歸檔低優(yōu)先級(jí)記憶5.5 幾個(gè)我踩過(guò)的坑第一個(gè)坑是記憶寫(xiě)得太啰嗦。一開(kāi)始我像寫(xiě)文檔一樣寫(xiě)記憶一條記憶寫(xiě)幾百字結(jié)果 token 預(yù)算很快用完真正重要的短記憶反而帶不上。后來(lái)我強(qiáng)制自己每條記憶控制在 100 字以內(nèi)只寫(xiě)結(jié)論和關(guān)鍵約束效果立刻好轉(zhuǎn)。第二個(gè)坑是過(guò)度依賴自動(dòng)召回。有段時(shí)間我完全信任腳本結(jié)果某次腳本配置出錯(cuò)召回了一堆無(wú)關(guān)內(nèi)容我還沒(méi)察覺(jué)導(dǎo)致輸出質(zhì)量下降?，F(xiàn)在我養(yǎng)成了習(xí)慣每次重要會(huì)話開(kāi)始前掃一眼召回內(nèi)容確認(rèn)沒(méi)問(wèn)題再繼續(xù)。第三個(gè)坑是忘記更新記憶。項(xiàng)目從 npm 遷到 pnpm 之后我忘了改記憶結(jié)果 Claude 一直給我 npm 的命令。這個(gè)教訓(xùn)讓我意識(shí)到記憶維護(hù)必須和項(xiàng)目變更綁定改配置的時(shí)候順手改記憶形成肌肉記憶。6. 記憶層的擴(kuò)展玩法6.1 團(tuán)隊(duì)共享記憶庫(kù)個(gè)人用熟了之后我把這套東西擴(kuò)展到了團(tuán)隊(duì)。做法是把記憶庫(kù)放進(jìn) Git 倉(cāng)庫(kù)團(tuán)隊(duì)成員共享。每個(gè)人都可以提交新的記憶通過(guò) PR review 保證質(zhì)量。這里的關(guān)鍵是建立記憶的準(zhǔn)入標(biāo)準(zhǔn)。不是什么都能進(jìn)共享庫(kù)只有“對(duì)多人有用、且經(jīng)過(guò)驗(yàn)證”的記憶才允許合并。比如某個(gè)報(bào)錯(cuò)的解決方案一個(gè)人踩過(guò)坑記下來(lái)另一個(gè)人遇到時(shí)直接召回省下大量排查時(shí)間。但如果是個(gè)人偏好比如“我喜歡用箭頭函數(shù)”就不該進(jìn)共享庫(kù)。共享庫(kù)還需要一個(gè)沖突解決機(jī)制。不同人對(duì)同一件事可能有不同看法比如有人堅(jiān)持用 tabs有人堅(jiān)持用 spaces。這種時(shí)候要么投票決定要么在記憶里注明“團(tuán)隊(duì)約定”和“個(gè)人偏好”的區(qū)別避免混淆。6.2 記憶的版本管理記憶庫(kù)用 Git 管理之后天然就有了版本歷史。這帶來(lái)一個(gè)額外好處可以追溯某條記憶是什么時(shí)候加的、為什么加的。我現(xiàn)在的習(xí)慣是每次提交記憶都寫(xiě)清楚 commit message比如“add: order-service 遷移到 Vitest 的測(cè)試約定”。半年后回頭看能快速理解當(dāng)時(shí)的決策背景。如果某條記憶引發(fā)了問(wèn)題還能直接 revert 回退。這比手動(dòng)改文件安全得多。我建議從第一天就用 Git 管理記憶庫(kù)哪怕只有你一個(gè)人用版本歷史的價(jià)值也會(huì)在幾個(gè)月后顯現(xiàn)出來(lái)。6.3 和其他工具的聯(lián)動(dòng)claude-mem的思路不局限于 Claude。任何需要長(zhǎng)期記憶的 AI 協(xié)作場(chǎng)景都可以套用這套“分層存儲(chǔ) 元數(shù)據(jù)過(guò)濾 按需召回”的模式。我自己就把它擴(kuò)展到了其他 AI 工具上記憶庫(kù)是同一套只是注入方式不同。另外記憶庫(kù)還可以和筆記工具聯(lián)動(dòng)。比如把 Obsidian 的筆記導(dǎo)出成記憶格式或者把記憶庫(kù)同步到 Notion 做可視化瀏覽。核心思路是記憶庫(kù)是數(shù)據(jù)源怎么展示和消費(fèi)是另一層的事。保持?jǐn)?shù)據(jù)源的干凈和結(jié)構(gòu)化上層怎么玩都行。6.4 一個(gè)實(shí)用的小技巧最后分享一個(gè)我常用的小技巧給記憶加“觸發(fā)詞”。在 front matter 里加一個(gè)triggers字段列出這條記憶相關(guān)的關(guān)鍵詞。召回時(shí)除了按 scope 和 project 過(guò)濾還可以按當(dāng)前會(huì)話內(nèi)容匹配觸發(fā)詞命中就優(yōu)先召回。比如一條關(guān)于“數(shù)據(jù)庫(kù)連接池”的記憶觸發(fā)詞設(shè)為[連接池, pool, 超時(shí), timeout]。當(dāng)會(huì)話里出現(xiàn)這些詞時(shí)這條記憶就會(huì)被優(yōu)先帶出來(lái)。這個(gè)機(jī)制讓召回更精準(zhǔn)尤其是在全局記憶里能有效減少無(wú)關(guān)內(nèi)容的干擾。觸發(fā)詞的維護(hù)成本很低寫(xiě)記憶時(shí)順手加幾個(gè)就行。但效果很明顯我實(shí)測(cè)下來(lái)加了觸發(fā)詞之后召回的相關(guān)性提升了大概三成。這個(gè)投入產(chǎn)出比值得每個(gè)用claude-mem的人試試。