1. 項(xiàng)目緣起為什么我要給 Claude 造一個(gè)“記憶外掛”第一次用 Claude 做長(zhǎng)周期項(xiàng)目的人大概率都經(jīng)歷過同一種崩潰昨天剛跟它對(duì)齊好的接口字段命名規(guī)范今天新開一個(gè)會(huì)話它就像失憶一樣又把userId寫成user_id把分頁(yè)參數(shù)從pageSize改成per_page。你不得不把之前幾十輪的上下文重新粘貼一遍token 燒得心疼時(shí)間也全耗在“復(fù)讀”上。claude-mem這個(gè)項(xiàng)目就是沖著這個(gè)痛點(diǎn)去的。它不是官方功能而是社區(qū)里一群被“上下文失憶”折磨過的開發(fā)者自己動(dòng)手?jǐn)€出來的一套跨會(huì)話記憶層。核心目標(biāo)很樸素讓 Claude 在多次對(duì)話之間記住你的項(xiàng)目約定、代碼風(fēng)格、業(yè)務(wù)術(shù)語(yǔ)、甚至你個(gè)人的表達(dá)偏好而不是每次都從零開始。它解決的不是“模型不夠聰明”的問題而是“模型記性太差”的問題。適合誰(shuí)來參考三類人最值得看一是天天用 Claude 寫代碼、做重構(gòu)的工程師二是拿 Claude 做長(zhǎng)文檔寫作、知識(shí)庫(kù)維護(hù)的內(nèi)容工作者三是想在自己產(chǎn)品里集成 Claude、又不想每次調(diào)用都重傳海量上下文的獨(dú)立開發(fā)者。哪怕你只是偶爾用 Claude 查資料理解這套記憶機(jī)制的設(shè)計(jì)思路也能幫你省下不少重復(fù)解釋的口水。我先把結(jié)論擺在這兒claude-mem的本質(zhì)是把“會(huì)話內(nèi)上下文”和“跨會(huì)話長(zhǎng)期記憶”這兩件事拆開處理。前者交給模型原生的 context window后者交給一套外部存儲(chǔ)加檢索機(jī)制。這個(gè)拆分思路是后面所有技術(shù)選型和實(shí)操細(xì)節(jié)的根基。2. 整體設(shè)計(jì)思路把“記憶”從模型里搬出來2.1 核心矛盾上下文窗口再大也扛不住長(zhǎng)期項(xiàng)目很多人有個(gè)誤區(qū)覺得現(xiàn)在模型上下文動(dòng)輒 200K token記憶問題自然就解決了。實(shí)際用下來完全不是這么回事。上下文窗口是“工作臺(tái)”不是“倉(cāng)庫(kù)”。你把三個(gè)月前的需求文檔、上周的代碼評(píng)審記錄、昨天的接口變更全塞進(jìn)工作臺(tái)結(jié)果就是真正當(dāng)前要處理的那段代碼被淹沒在噪音里模型注意力被稀釋回答質(zhì)量反而下降。更現(xiàn)實(shí)的問題是成本。200K token 的輸入每次調(diào)用都按這個(gè)量計(jì)費(fèi)一天調(diào)幾十次賬單能讓你懷疑人生。所以claude-mem的設(shè)計(jì)出發(fā)點(diǎn)很明確當(dāng)前會(huì)話只加載跟當(dāng)前任務(wù)強(qiáng)相關(guān)的記憶片段而不是全量歷史。這就引出了第一個(gè)關(guān)鍵設(shè)計(jì)——記憶的分層。2.2 記憶分層短期、中期、長(zhǎng)期三檔怎么分我在實(shí)際搭建時(shí)把記憶分成三檔這個(gè)分法參考了常見的人類記憶模型也貼合工程實(shí)踐記憶層級(jí)存儲(chǔ)內(nèi)容生命周期加載策略短期記憶當(dāng)前會(huì)話的對(duì)話歷史會(huì)話結(jié)束即棄全量保留在 context中期記憶當(dāng)前項(xiàng)目的約定、術(shù)語(yǔ)、風(fēng)格項(xiàng)目周期內(nèi)有效按項(xiàng)目 ID 檢索注入長(zhǎng)期記憶跨項(xiàng)目的個(gè)人偏好、通用規(guī)范長(zhǎng)期沉淀按語(yǔ)義相似度召回短期記憶不用管模型原生就支持。真正要?jiǎng)邮值氖侵衅诤烷L(zhǎng)期。中期記憶解決“同一個(gè)項(xiàng)目里別反復(fù)改口”長(zhǎng)期記憶解決“我這個(gè)人一貫的偏好別每次都講”。為什么這么分因?yàn)椴煌瑢蛹?jí)的記憶檢索頻率和更新頻率完全不同。項(xiàng)目約定可能一周改一次但每次會(huì)話都要用個(gè)人偏好可能幾個(gè)月才更新一次但一旦確定就長(zhǎng)期穩(wěn)定?；煸谝黄鸫鏅z索效率會(huì)很低。2.3 存儲(chǔ)選型為什么我最終選了本地文件加向量索引存儲(chǔ)方案我試過三種踩了不少坑最后落在一個(gè)組合上純本地 JSON 文件最簡(jiǎn)單但檢索只能靠關(guān)鍵詞匹配語(yǔ)義相近但用詞不同的記憶召不回來。純向量數(shù)據(jù)庫(kù)語(yǔ)義檢索強(qiáng)但部署重小項(xiàng)目殺雞用牛刀而且記憶條目少的時(shí)候向量檢索的優(yōu)勢(shì)體現(xiàn)不出來。本地文件加輕量向量索引記憶正文存 Markdown 或 JSON向量只存索引檢索時(shí)先向量召回候選再讀文件拿全文。第三種是我實(shí)測(cè)下來最穩(wěn)的。原因有三一是記憶內(nèi)容人類可讀出問題能直接打開文件排查不用去數(shù)據(jù)庫(kù)里翻二進(jìn)制二是向量索引可以隨時(shí)重建不怕?lián)p壞三是遷移方便整個(gè)記憶庫(kù)就是一個(gè)文件夾拷走就能用。提示向量索引和記憶正文分離存儲(chǔ)是我踩過最大的坑之后定下的規(guī)矩。早期我把兩者混在一起索引一壞記憶全丟血的教訓(xùn)。2.4 注入時(shí)機(jī)什么時(shí)候把記憶喂給 Claude記憶存好了什么時(shí)候注入也是個(gè)學(xué)問。我見過有人每次調(diào)用都把全部記憶塞進(jìn)去結(jié)果 token 爆炸。我的做法是分兩個(gè)注入點(diǎn)第一個(gè)注入點(diǎn)是會(huì)話初始化。新會(huì)話開始時(shí)根據(jù)當(dāng)前項(xiàng)目 ID把該項(xiàng)目的中期記憶全量注入一次作為系統(tǒng)提示的一部分。這部分內(nèi)容通常不大幾百到幾千 token但能立刻讓 Claude 進(jìn)入狀態(tài)。第二個(gè)注入點(diǎn)是按需召回。在對(duì)話過程中當(dāng)用戶提到某個(gè)特定主題時(shí)用當(dāng)前輸入去向量索引里檢索最相關(guān)的幾條長(zhǎng)期記憶動(dòng)態(tài)追加到上下文里。這樣既保證了相關(guān)性又控制了 token 消耗。這個(gè)“初始化全量加過程按需”的雙注入策略是我反復(fù)調(diào)優(yōu)后覺得最平衡的方案。全量注入保證基礎(chǔ)一致性按需召回補(bǔ)充細(xì)節(jié)兩者配合Claude 的表現(xiàn)明顯比裸奔強(qiáng)一大截。3. 核心細(xì)節(jié)拆解記憶條目到底長(zhǎng)什么樣3.1 記憶條目的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)一條記憶不是隨便寫句話就完事。我設(shè)計(jì)的記憶條目包含這幾個(gè)字段每個(gè)字段都有明確用途{ id: mem_20250101_001, project_id: proj_payment_service, layer: mid, category: convention, content: 所有接口的金額字段統(tǒng)一用整數(shù)分表示字段名后綴 _cents, tags: [api, naming, money], created_at: 2025-01-01T10:00:00Z, updated_at: 2025-01-01T10:00:00Z, hit_count: 0, embedding: [0.012, -0.034, ...] }project_id用來隔離不同項(xiàng)目的記憶避免串味。layer區(qū)分中期長(zhǎng)期。category是分類方便按類型批量檢索。content是記憶正文用自然語(yǔ)言寫越具體越好。tags是輔助關(guān)鍵詞。hit_count記錄這條記憶被召回多少次用來做熱度排序。embedding是向量單獨(dú)存索引文件。為什么content要用自然語(yǔ)言而不是結(jié)構(gòu)化字段因?yàn)樽罱K是喂給 Claude 的自然語(yǔ)言它理解得最好。結(jié)構(gòu)化字段反而增加了解析成本得不償失。3.2 記憶的寫入手動(dòng)、半自動(dòng)、自動(dòng)三條路記憶怎么進(jìn)庫(kù)我實(shí)踐下來有三條路各有適用場(chǎng)景手動(dòng)寫入最可靠。我在項(xiàng)目里定了個(gè)規(guī)矩每當(dāng)跟 Claude 對(duì)齊了一個(gè)重要約定立刻手動(dòng)記一條。比如“這個(gè)項(xiàng)目所有時(shí)間戳用 UTC”“錯(cuò)誤碼統(tǒng)一用五位數(shù)字”。手動(dòng)寫的好處是精準(zhǔn)壞處是容易忘。半自動(dòng)寫入是折中方案。我寫了個(gè)小腳本掃描當(dāng)前會(huì)話的對(duì)話記錄用規(guī)則提取出疑似約定的句子比如包含“統(tǒng)一”“一律”“以后都”“記住”這類詞的句子生成候選記憶我確認(rèn)后再入庫(kù)。這樣既減輕負(fù)擔(dān)又保留人工把關(guān)。自動(dòng)寫入最省事但風(fēng)險(xiǎn)最高。讓 Claude 自己在對(duì)話結(jié)束時(shí)總結(jié)本次會(huì)話的關(guān)鍵約定自動(dòng)生成記憶條目。我試過準(zhǔn)確率大概七成剩下三成要么總結(jié)偏了要么把臨時(shí)決定當(dāng)成了長(zhǎng)期約定。所以自動(dòng)寫入我只用在低風(fēng)險(xiǎn)場(chǎng)景重要項(xiàng)目還是手動(dòng)加半自動(dòng)。注意自動(dòng)寫入一定要加人工復(fù)核環(huán)節(jié)。我有次偷懶沒復(fù)核結(jié)果一條“臨時(shí)用下劃線命名”的測(cè)試約定被當(dāng)成長(zhǎng)期規(guī)范后面生成的代碼全帶下劃線排查了半天才發(fā)現(xiàn)是記憶污染。3.3 記憶的檢索向量加關(guān)鍵詞的混合召回檢索是記憶系統(tǒng)的核心。純向量檢索的問題是有時(shí)候關(guān)鍵詞精確匹配更靠譜。比如你搜“payment_cents”向量可能召回一堆跟支付相關(guān)的記憶但真正包含這個(gè)精確字段名的那條反而排在后面。所以我用的是混合召回先用關(guān)鍵詞在content和tags里做精確匹配命中直接加權(quán)。再用向量做語(yǔ)義召回取相似度 top N。兩路結(jié)果合并去重按加權(quán)分?jǐn)?shù)排序。取 top K 條注入上下文。加權(quán)分?jǐn)?shù)怎么算我的經(jīng)驗(yàn)公式是score 0.6 * 向量相似度 0.3 * 關(guān)鍵詞命中權(quán)重 0.1 * 熱度權(quán)重。熱度權(quán)重就是hit_count歸一化后的值。這個(gè)比例不是拍腦袋是我拿幾十次實(shí)際檢索結(jié)果調(diào)出來的。向量占大頭保證語(yǔ)義相關(guān)性關(guān)鍵詞保證精確性熱度讓常用記憶更容易被召回。3.4 記憶的更新與淘汰別讓記憶庫(kù)變成垃圾場(chǎng)記憶庫(kù)用久了會(huì)膨脹里面混著過時(shí)約定、重復(fù)條目、甚至錯(cuò)誤信息。我定了三條清理規(guī)則過期淘汰每條記憶可以設(shè)expire_at到期自動(dòng)標(biāo)記為失效檢索時(shí)不再召回但保留在庫(kù)里備查。沖突檢測(cè)新記憶入庫(kù)時(shí)跟同項(xiàng)目同 category 的舊記憶做相似度比對(duì)相似度超過閾值就提示沖突讓我決定是覆蓋還是并存。熱度降權(quán)連續(xù) 90 天hit_count為 0 的記憶自動(dòng)降權(quán)檢索時(shí)排到最后相當(dāng)于軟刪除。這三條規(guī)則配合使用記憶庫(kù)能保持在一個(gè)健康規(guī)模。我有個(gè)項(xiàng)目跑了半年記憶條目穩(wěn)定在兩百條左右沒有失控膨脹。4. 實(shí)操落地從零搭一套可用的記憶系統(tǒng)4.1 環(huán)境準(zhǔn)備與依賴安裝先說環(huán)境。我用的是 Python 3.10主要依賴三個(gè)庫(kù)sentence-transformers做向量化numpy做向量運(yùn)算scikit-learn做相似度計(jì)算。向量模型我選的是all-MiniLM-L6-v2理由是體積小、速度快、效果夠用。你要是追求更高精度可以換更大的模型但推理成本會(huì)上去。pip install sentence-transformers numpy scikit-learn目錄結(jié)構(gòu)我這樣組織claude-mem/ ├── memories/ │ ├── proj_payment_service.json │ └── proj_user_center.json ├── index/ │ └── embeddings.npy ├── config.yaml └── mem.pymemories放記憶正文按項(xiàng)目分文件。index放向量索引。config.yaml放配置。mem.py是主程序。4.2 記憶寫入的完整代碼實(shí)現(xiàn)寫入邏輯我封裝成一個(gè)函數(shù)核心是生成向量并追加到索引import json import numpy as np from sentence_transformers import SentenceTransformer from datetime import datetime model SentenceTransformer(all-MiniLM-L6-v2) def add_memory(project_id, layer, category, content, tagsNone): mem_id fmem_{datetime.now().strftime(%Y%m%d%H%M%S)} embedding model.encode(content).tolist() entry { id: mem_id, project_id: project_id, layer: layer, category: category, content: content, tags: tags or [], created_at: datetime.now().isoformat(), updated_at: datetime.now().isoformat(), hit_count: 0, embedding: embedding } filepath fmemories/{project_id}.json try: with open(filepath, r, encodingutf-8) as f: data json.load(f) except FileNotFoundError: data [] data.append(entry) with open(filepath, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) rebuild_index() return mem_id這里有個(gè)細(xì)節(jié)每次寫入都重建索引。聽起來低效但記憶寫入頻率很低一天可能就幾次重建成本可以忽略。換來的是索引永遠(yuǎn)跟正文一致不會(huì)出現(xiàn)索引漂移。4.3 混合檢索的核心算法檢索函數(shù)是整套系統(tǒng)的靈魂我把向量召回和關(guān)鍵詞召回合并def search_memory(project_id, query, top_k5): with open(fmemories/{project_id}.json, r, encodingutf-8) as f: memories json.load(f) query_vec model.encode(query) scored [] for mem in memories: vec_sim np.dot(query_vec, np.array(mem[embedding])) / ( np.linalg.norm(query_vec) * np.linalg.norm(mem[embedding]) ) kw_score 0 for tag in mem[tags]: if tag.lower() in query.lower(): kw_score 1 if any(word in mem[content] for word in query.split()): kw_score 0.5 heat min(mem[hit_count] / 10, 1.0) final_score 0.6 * vec_sim 0.3 * min(kw_score, 1.0) 0.1 * heat scored.append((final_score, mem)) scored.sort(keylambda x: x[0], reverseTrue) results [mem for _, mem in scored[:top_k]] for mem in results: mem[hit_count] 1 save_memories(project_id, memories) return results這段代碼里hit_count的更新是寫回文件的所以檢索本身也有副作用。這是故意的讓熱度統(tǒng)計(jì)自然累積。但要注意并發(fā)問題多進(jìn)程同時(shí)檢索會(huì)互相覆蓋。我的做法是加文件鎖或者干脆單進(jìn)程串行處理。4.4 注入 Claude 的拼接模板檢索出來的記憶怎么拼進(jìn) prompt 也有講究。我用的模板是這樣的[項(xiàng)目記憶] 以下是本項(xiàng)目已確認(rèn)的約定請(qǐng)嚴(yán)格遵守 - 所有接口的金額字段統(tǒng)一用整數(shù)分表示字段名后綴 _cents - 時(shí)間戳統(tǒng)一使用 UTC 格式 - 錯(cuò)誤碼統(tǒng)一使用五位數(shù)字 [當(dāng)前任務(wù)] {用戶輸入}為什么用這個(gè)格式因?yàn)?Claude 對(duì)“請(qǐng)嚴(yán)格遵守”這類指令響應(yīng)很好明確告訴它這些是約束而不是參考遵守率明顯提高。另外把記憶放在用戶輸入之前符合系統(tǒng)提示在前、用戶輸入在后的常規(guī)順序模型處理起來更自然。4.5 會(huì)話初始化的自動(dòng)化腳本每次新會(huì)話手動(dòng)拼記憶太麻煩我寫了個(gè)初始化腳本自動(dòng)拉取項(xiàng)目記憶并生成系統(tǒng)提示def build_system_prompt(project_id): with open(fmemories/{project_id}.json, r, encodingutf-8) as f: memories json.load(f) mid_memories [m for m in memories if m[layer] mid] if not mid_memories: return 你是一個(gè)樂于助人的助手。 lines [[項(xiàng)目記憶], 以下是本項(xiàng)目已確認(rèn)的約定請(qǐng)嚴(yán)格遵守] for mem in mid_memories: lines.append(f- {mem[content]}) return \n.join(lines)這個(gè)函數(shù)返回的字符串直接作為 system prompt 傳給 Claude。實(shí)測(cè)下來新會(huì)話第一輪回答就能帶上項(xiàng)目約定不用再手動(dòng)提醒。5. 常見問題與排查技巧實(shí)錄5.1 記憶召回不準(zhǔn)怎么辦最常見的問題是檢索出來的記憶跟當(dāng)前任務(wù)不相關(guān)。排查思路分三步第一步檢查向量模型是否適合你的領(lǐng)域。通用模型在專業(yè)領(lǐng)域比如醫(yī)療、法律表現(xiàn)會(huì)打折。如果發(fā)現(xiàn)語(yǔ)義召回質(zhì)量差考慮換領(lǐng)域微調(diào)過的模型。第二步檢查記憶條目的content寫得夠不夠具體。我見過有人寫“注意命名規(guī)范”這種記憶召回后等于沒召回因?yàn)樘：?。好的記憶?yīng)該像“所有接口的金額字段統(tǒng)一用整數(shù)分表示字段名后綴 _cents”這樣具體到能直接執(zhí)行。第三步調(diào)整加權(quán)公式。如果發(fā)現(xiàn)關(guān)鍵詞命中太少把關(guān)鍵詞權(quán)重從 0.3 提到 0.4 試試。如果發(fā)現(xiàn)老記憶總被召回把熱度權(quán)重降下來。這個(gè)公式?jīng)]有標(biāo)準(zhǔn)答案得根據(jù)你的實(shí)際數(shù)據(jù)調(diào)。5.2 記憶沖突怎么處理沖突的典型場(chǎng)景是項(xiàng)目初期定了“用駝峰命名”中期改成“用下劃線命名”兩條記憶都在庫(kù)里檢索時(shí)都召回Claude 就懵了。我的處理流程是新記憶入庫(kù)時(shí)自動(dòng)跟同項(xiàng)目同 category 的舊記憶做相似度比對(duì)相似度超過 0.85 就標(biāo)記為潛在沖突在寫入時(shí)返回警告。我看到警告后手動(dòng)決定是刪除舊記憶還是保留兩條并加時(shí)間戳區(qū)分。提示給記憶加updated_at字段很重要。檢索時(shí)可以優(yōu)先召回更新的記憶或者在注入時(shí)標(biāo)注“此約定于 X 日期更新”讓 Claude 知道哪條是最新的。5.3 記憶庫(kù)膨脹太快怎么控制有個(gè)項(xiàng)目我用了兩個(gè)月記憶條目從 20 條漲到 500 多條檢索質(zhì)量明顯下降。后來我加了三條限制每個(gè)項(xiàng)目的中期記憶上限 100 條超了就觸發(fā)合并或淘汰。自動(dòng)寫入的記憶默認(rèn) 30 天過期手動(dòng)寫入的不過期。每周跑一次清理腳本把hit_count為 0 且超過 60 天的記憶歸檔。加了限制之后記憶庫(kù)穩(wěn)定在 80 條左右檢索又快又準(zhǔn)。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案記憶召回不相關(guān)向量模型不匹配領(lǐng)域人工檢查 top 10 召回結(jié)果換領(lǐng)域模型或調(diào)權(quán)重記憶沖突新舊約定并存檢查同 category 記憶刪除舊記憶或加時(shí)間戳記憶庫(kù)膨脹無(wú)淘汰機(jī)制統(tǒng)計(jì)條目增長(zhǎng)曲線加上限和過期規(guī)則檢索變慢索引未優(yōu)化測(cè)單次檢索耗時(shí)重建索引或分片記憶丟失索引與正文不一致對(duì)比索引和文件從正文重建索引5.5 幾個(gè)我踩過的坑第一個(gè)坑是向量維度不一致。我中途換過一次向量模型新舊模型維度不同索引直接報(bào)錯(cuò)。教訓(xùn)是換模型必須全量重建索引不能增量更新。第二個(gè)坑是中文編碼問題。早期用默認(rèn)編碼寫 JSON中文記憶讀出來是亂碼。后來統(tǒng)一用ensure_asciiFalse加 UTF-8問題解決。第三個(gè)坑是并發(fā)寫入覆蓋。有次我開了兩個(gè)終端同時(shí)寫記憶后寫的把先寫的覆蓋了。后來加了文件鎖或者干脆規(guī)定記憶寫入必須串行。第四個(gè)坑是過度依賴自動(dòng)寫入。前面提過自動(dòng)總結(jié)準(zhǔn)確率只有七成重要項(xiàng)目千萬(wàn)別偷懶。6. 進(jìn)階玩法讓記憶系統(tǒng)更聰明6.1 記憶的自動(dòng)摘要與合并當(dāng)同 category 記憶超過一定數(shù)量可以觸發(fā)自動(dòng)摘要。比如十條關(guān)于命名的記憶讓 Claude 總結(jié)成一條綜合規(guī)范。這樣既壓縮了體積又保留了核心信息。我試過十條壓成一條信息保留率大概八成但檢索效率提升明顯。6.2 跨項(xiàng)目記憶共享長(zhǎng)期記憶層可以跨項(xiàng)目共享。比如“我習(xí)慣用中文注釋”“我偏好函數(shù)式寫法”這類個(gè)人偏好所有項(xiàng)目都能用。實(shí)現(xiàn)上就是給長(zhǎng)期記憶不設(shè)project_id檢索時(shí)全局召回。這樣新項(xiàng)目啟動(dòng)時(shí)個(gè)人偏好自動(dòng)帶上不用重新配置。6.3 記憶的可視化面板記憶條目多了之后純靠命令行管理很累。我后來寫了個(gè)簡(jiǎn)單的 Web 面板能瀏覽、搜索、編輯、刪除記憶還能看每條記憶的召回次數(shù)。工具不復(fù)雜但管理效率提升很大。你要是懶得寫直接打開 JSON 文件用編輯器改也行就是麻煩點(diǎn)。6.4 與版本控制結(jié)合記憶文件我建議納入 Git 管理。每次記憶變更都有 commit 記錄出問題能回滾還能看到約定是怎么演進(jìn)的。我有個(gè)項(xiàng)目的記憶庫(kù)半年下來 commit 記錄清清楚楚哪條約定什么時(shí)候加的、為什么加的一目了然。這對(duì)團(tuán)隊(duì)協(xié)作尤其有用新人接手看記憶庫(kù)的 Git 歷史比看文檔還快。7. 我個(gè)人的使用體會(huì)這套claude-mem我用了大半年最大的感受是記憶系統(tǒng)的價(jià)值不在于技術(shù)多復(fù)雜而在于堅(jiān)持維護(hù)。工具本身幾百行代碼就搞定了難的是養(yǎng)成習(xí)慣——每次對(duì)齊約定就記一條每次發(fā)現(xiàn)沖突就清理一次。我見過太多人搭好了系統(tǒng)用兩周就荒廢了因?yàn)閼械镁S護(hù)記憶庫(kù)變成垃圾場(chǎng)檢索質(zhì)量下降最后干脆不用了。所以我的建議是從小處開始。別一上來就搞全自動(dòng)、搞復(fù)雜架構(gòu)。先手動(dòng)記十條最重要的約定用起來感受到好處再慢慢加自動(dòng)化。記憶系統(tǒng)是養(yǎng)出來的不是搭出來的。另外一點(diǎn)體會(huì)是記憶的粒度很關(guān)鍵。太粗了沒用太細(xì)了爆炸。我的經(jīng)驗(yàn)是一條記憶對(duì)應(yīng)一個(gè)可執(zhí)行的約定能直接指導(dǎo)一次具體操作。比如“金額用分”就是好粒度“注意代碼質(zhì)量”就是壞粒度。你拿這個(gè)標(biāo)準(zhǔn)去篩記憶庫(kù)的質(zhì)量自然就上去了。最后分享一個(gè)小技巧我會(huì)定期大概每月一次把記憶庫(kù)整個(gè)導(dǎo)出來讓 Claude 自己讀一遍問它“這些約定有沒有互相矛盾的地方”。它有時(shí)候能發(fā)現(xiàn)我自己沒注意到的沖突。這個(gè)“記憶體檢”習(xí)慣幫我避免了好幾次潛在的規(guī)范打架。