[2026 實戰筆記] 端午連假愉快。這篇可以單獨讀，不需要先看我的設計日誌。我想丟出一個鮮明的主張，再用實作（和翻車）把它撐起來；讀完若想看更底層的拆解，文末有完整章節連結。

歷史總是不斷重演。整部文明史，說穿了就是同一個循環：收集資料 → 處理資料 → 分析資料，然後再收集更多。而每一個世代，都在為「該怎麼裝這些資料」吵架——從關聯式資料庫（RDB）、到 NoSQL、再到大數據（Big Data），一波一波的技術浪潮，本質上都在回答同一個問題：這個世代的資料，到底該怎麼存、怎麼撈？

現在，輪到 AI 了。而且這次的題目更尷尬：AI 的「記憶」該怎麼處理——結構化，還是非結構化？ 幾乎每篇入門教學的標準答案，都是 RAG（檢索增強生成）＋向量資料庫：把東西全切碎、轉成向量、丟進去、再撈出來。但這其實只是「聲音最大」的那個——真正認真做長期記憶的，早就往結構化、知識圖譜、時序記憶那邊走了（純向量撈回來是一坨扁平的相似片段，沒有關係、也沒有時間軸）。我自己土法煉鋼做完一輪後也站同一邊，而且想得更極端一點——把整段對話塞進向量庫，那到底是在存「記憶」，還是只是把「文件」存起來而已？

先把整篇的核心論點一句講完：

長期記憶不該儲存「對話紀錄」，而該儲存「狀態、事件與知識」。

下面是這句話為什麼成立、以及怎麼落地。

先講那個你一定遇過的痛

你跟 ChatGPT（或 Claude、Gemini）深聊了京都自由行。一週後想接續：「上次那份飯店清單你還記得嗎？」——剛好點回同一個視窗，它接得上；順手開了新視窗，它當場失憶。

這個本質差異，技術上叫「跨 Session（跨對話階段）」難題：主流 AI 介面都是「同一視窗內記得，換一個視窗歸零」。對「問完即走」很合理，但你要把它當長期助理，就是災難——沒人想每次見私人秘書都重新自我介紹一次。

而業界想跨視窗記住你，目前大致三條路：長對話上下文（整年塞進去，token 爆、長了仍會爆）、自動摘要（必丟細節、無法事實稽核）、結構化記憶（拆成可檢索的結構，要用時精準撈）。前兩條的共同盲點，就是它們本質上都還在存「對話」。我選第三條，也就是本篇的主張。

把記憶拆成三種「卡片」

與其塞整段對話，不如把它拆成原子化的小卡（卡片盒筆記、Obsidian 都是這哲學）。我分三類：

• 狀態卡（State）：此刻為真的動態事實。[現居地: 台北]、[專案進度: 開源前驗收]。會被更新、取代。
• 事件卡（Event）：過去某時間點發生過的事。[2026-04-30 決策: 選 B 路徑]。累積、不覆蓋歷史。
• 知識卡（Knowledge）：抽象概念。[JWT 的運作原理]。可跨對話引用、互相連結。

再加一個藏在三者底下的第四維——時間。

為什麼硬要把「狀態」和「事件」分開？ 因為它們解的是兩種不同的問題：問「我現在住哪？」要的是狀態（最新唯一真相），不該逼 AI 把十年搬家史讀完自己推；問「當時為什麼那樣決定？」要的是事件（過去那個不變的座標），狀態卡根本答不出來。所以：狀態卡可被取代、回答「現在」；事件卡只准累積、回答「過去」。

幾個讓它真的能用的設計

魔鬼在維運：

• 會替換 vs 會累積（Cardinality）：「現居地」是單一值（新的進來覆蓋舊的），「用過哪些技術」是可累積（PostgreSQL 跟 Redis 並存）。寫入前先判斷屬於哪種。
• 分叉取代、不刪舊資料（Supersede-Fork）：地址變了，舊卡不刪，標記「已於某日被取代」，新卡另立。就像修訂法律——舊條文不焚毀，而是註記被新法取代。這樣「現在」和「兩年前」的地址都查得到。
• 記憶半衰期：半年前說「改用某瀏覽器」大概過時，半年前說「熱愛某語言」大概還算數。不同事實用不同指數衰減速度打分。
• 把「今天」釘死成絕對日期：使用者說「昨天搬家」，這個「昨天」一定要在當下換算成 2026-06-17，不能存字串——否則一週後撈出來會以為是讀卡那天搬的。LLM 自己沒時鐘，得在它抽卡時「配一支手錶」，逼它把相對時間算成絕對日期。

不這樣設計會死得多慘？一個真實翻車

設計論講再多，不如一個翻車現場。某次縱向老化測試，系統產出 166 張狀態卡，事後一查——所有卡的 superseded_at（過時時間）欄位全是 NULL。意思是上面講得頭頭是道的「分叉取代」，過去幾個月一次都沒成功觸發過。

後果：你換過公司、搬過家，AI 卻永遠吐第一次聽到的舊值。問「我現在在哪上班？」它自信報出三年前的舊東家；極端一點，同一個人被記成「同時住台北又住京都」。

根因藏在程式碼骨髓：寫入端抽出來的標籤，跟取代機制要求的判定條件「詞彙對不上」，每張卡都被誤當成「可累積」而從不退休。這就是為什麼那四條規則必須是硬規則——少一條，記憶會在你看不見的地方悄悄腐爛。 單日、單輪的 benchmark 永遠一片祥和；系統跑長、對話一深，隱藏的結構性 bug 才露獠牙。

弱勝強：換更強的模型，反而更糟

還有一個更反直覺的案例，是這整章我最想丟出來的。同一套 fibon、同一批記憶卡，只把對話主腦從 Claude Sonnet 4.6 換成 Gemini 2.5 Pro（背景抽卡都用 Haiku 4.5）：跨 Session 事實回溯，Sonnet 只有 16.7–20.8%，Gemini 卻有 64.6–72.9%——理應更強的旗艦輸了 46–52pp。多輪改寫題更誇張，Sonnet 28.6%、Gemini 那組幾乎全過。

先排除「Claude 抽的卡比較爛」——把抽卡也換成 Gemini 重跑，Claude 還是輸。真兇是：Sonnet 太聰明、太聽話。我在系統提示裡寫了條抗幻覺鐵律「沒看到的不准編」，普通模型乖乖遵守，但 Sonnet 對 prompt 過度服從，把資料庫撈回、明明正確的記憶卡當成「不該擅自宣稱知道的外部資料」一槍否決，回「抱歉，我無法存取你的外部系統」——等於白做 RAG。（這現象目前只記錄為待辦，受限預算還沒根治，誠實說在前面。）

冷靜定調一下，免得被當成「是不是你 prompt 寫太爛」：這本質上是**「過度對齊（Over-alignment）」在 RAG 檢索下的經典副作用**——模型太想當個誠實的乖小孩，反而失去了在上下文（Context）中靈活辨識結構化事實的彈性。換更聰明的模型，不會自動修好這件事，反而可能放大它。

（這個「弱勝強」案例我另外整理成一份白話的公開筆記＋原始數據，放在 GitHub Gist：https://gist.github.com/AaronChuang/e4088e2724b7c8d7b22f5444796d6aae）

撈記憶：不要只押向量

很多人做 RAG 就是：問題轉向量 → 算 cosine → 撈 top 5。複雜場景會漏成篩子：對精確比對遲鈍、對中文錯字易脫靶、對時間查詢沒輒。所以我用「五路平行召回」再投票融合：

1. 語意向量（Vector）：抓「感覺對」但沒關鍵字的查詢。
2. 標籤精確匹配（Exact Match）：中文要先用 jieba 結巴斷詞（配繁中字典）才切得出正確的詞。
3. 字元級模糊比對（n-gram）：刻意不斷詞，用 n-gram 抓錯字（中文兩字一組 bigram、英文三字母一組 trigram）。
4. 時間區間查詢（Temporal）：把「上週」解析成日期區間，直接查時間軸。
5. 圖譜關係展開（Graph）：沿關聯往外踩一步，把「聊到 JWT 就帶出 OAuth」這種隱性關聯也拉進來。

五路結果用 RRF 投票，再做衰減／情境重排，最後只挑最精純的 5 張卡。真正難的從來不是「記住更多」，而是「記住但不要撈錯」。

知識卡最難：怎麼不讓它長成垃圾場

三種卡裡，知識卡最棘手——狀態卡有「唯一現值」、事件卡有「時間軸」，但知識沒有客觀唯一答案、而且會演化（JWT 最佳實踐、Reflection pattern 寫法、DDD 詮釋，每一兩年都在變）。放著不管，它很快變成一堆重複、過時、互相矛盾的爛卡——那就是負債不是資產。目前靠三道機制壓住熵增：

1. Tag 正規化：語意相近的標籤自動合併，不讓 JWT 和 json web token 裂成兩棵樹。
2. 新鮮度標記：超過 90 天沒驗證的卡，撈出來自動標「此摘要可能已過時」，AI 引用後主動問你要不要重驗。
3. 綁定事件卡：每張知識卡連回「你在哪幾次對話真的討論過它」，有出處、可追溯，不是孤兒卡。

但老實說，這三道只是「延緩腐爛」，不是「保證新鮮」。知識卡會不會在更大規模、更長時間下還是劣化成垃圾場，是我還沒驗證、卻最想繼續解的開放難題。

一個很值錢的延伸：記憶就是省錢

對 LLM 來說，讀進去的 input token 比生成出來的 output token 便宜得多（多數供應商 output 單價是 input 的好幾倍）。所以一個知識點第一次想清楚就存成卡，下次當 input 讀回去，不必讓模型從頭「想」「寫」一遍——省下的正是最貴的 output。

在 Token 經濟學裡，復用不只是體驗問題，直接是成本問題。能當 input 讀進去的，就別逼 LLM 用最貴的 output 重新生成。

換句話說，個人助理級的 agent 不解 token 經濟學，再聰明也會被自己的運行成本壓垮。

帶得走的幾條原則

1. 別把整段歷史硬塞：拆成原子化、可檢索的結構，模型看更少、看更準。
2. 分清「現在」和「過去」：可變的事實與不可變的事件，用不同規則維運。
3. 時間是第一公民：相對時間一定要在寫入當下釘死成絕對日期。
4. 檢索別單押向量：精確、模糊、時間、關係，多路並行再融合。
5. 記住但不要撈錯，比記住更多重要。
6. 記憶就是省錢：能復用的知識，省的是最貴的 output token。

最後，留一題給你一起燒腦

順著這個「弱勝強」往外想一題，丟給你一起燒腦：工程做得好，模型是不是就可以不用那麼好？如果一條 GUARD 護欄、一套五路檢索、一層記憶卡，就能讓較弱、較便宜的模型在真實任務上贏過旗艦——那是不是代表，當系統層打磨到位，底層模型的「絕對智商」就沒那麼關鍵了？省下的模型費用，該不該轉投到工程？

但反過來也成立：越聰明、越聽話的模型，越容易被你寫死的護欄綁住手腳。所以到底是「把模型換更強」邊際效益高，還是「把工程做更好」邊際效益高？這題我沒有定論，但我不想只有自己一個人在這裡轉——如果是你，你會把下一塊錢押在模型，還是押在工程？

這是把第三章濃縮、可獨立閱讀的設計主張版。完整章節（每條規則的資料表設計、衝突仲裁、3×6 多維結構、那場翻車的完整排查紀錄，以及一張標出每個 LLM 呼叫位置的循序圖）中英雙語都有：

👉 完整章節連結：https://fibon.stepbyday.com/chapters/03-memory/

先打個預防針：這套記憶系統我前後弄了 2–3 個月、到現在都還沒完全收工，所以完整章節是全站最長的一篇——要看請有點心理準備，或挑有興趣的小節跳著讀就好。

端午連假愉快。