「AI 的長期記憶不就是一堆筆記嗎?想到什麼就記下來,需要的時候撈出來用,幹嘛還要分類?」
第一部講完 CLAUDE.md 跟 Skill 這兩層——一層是「幾乎每次都要遵守的規範」,一層是「特定情境才要套用的規則」。今天要進入第二部:除了這兩層,AI 還需要第三種東西——記憶。而記憶這東西,比 CLAUDE.md 跟 Skill 更容易被寫成一份扁平的筆記,也更容易因為扁平而失去用處。
一份扁平的記憶筆記,最終會累積出一個共同的毛病:裡面同時混著「幾乎不會過期的事實」跟「上週才成立、這週可能已經不成立的狀態」,但讀取的人(不管是 AI 還是回頭看的自己)沒辦法從格式上分辨哪個是哪個。
例如「這個使用者偏好簡潔的回覆風格」跟「這項任務目前卡在等某個外部依賴」,這兩句話如果寫在同一份筆記裡、格式完全一樣,AI 讀取時很容易一視同仁地相信兩者——但前者大概率長期成立,後者可能過幾天就已經解除了。記憶的問題往往不是記得不夠多,是記得的東西時效性天差地遠,卻被同一種格式一視同仁地對待。
把記憶拆成四種類型,本質上是把「這件事的時效性跟查詢時機」也編碼進記憶結構本身,而不是靠讀取的人自己判斷。
❌ 全部塞進一份扁平筆記:
「使用者喜歡簡潔回覆。上次那個排序 bug 已經修好用了固定
排序邏輯。目前這個功能卡在等後端 API 改版。有個效能問題
已知但先不處理,之後有空再看。」
→ 四句話四種時效性、四種查詢時機,全部用同一個格式寫在
一起,讀取的人沒辦法從結構上分辨「這句話現在還可不可信」,
只能每次都重新讀完整份筆記自己判斷
✅ 按類型分開記錄:
user: 溝通風格偏好簡潔回覆
feedback: 排序邏輯之前用了不穩定排序,被指出後改成固定排序,
這條規則長期適用
project(標注日期): 這項功能卡在等後端 API 改版,
下次接手前先確認 API 是否已經改版完成
reference: 已知有個效能問題,決定先不處理,
之後排時間全面檢視時再一併看
→ 四種記憶各自標明了「這句話的可信期限」跟
「該在什麼時候被查詢」,讀取的人可以直接判斷
哪些內容可以放心引用、哪些要先驗證現況
這四種分類不是為了整齊好看,是把「這句話還可不可信」這個判斷,從讀取的人身上,轉移到記憶本身的結構上。 project 類型的記憶會被明確標注「讀之前先驗證」,reference 類型會被明確標注「這是刻意的決定,不是待辦」——分類本身就是一種預先寫好的使用說明。
回想你自己用過的某種「筆記」或「知識庫」:裡面有沒有一句話寫的時候是對的,現在早就過期了,卻因為格式跟其他內容一模一樣,你差點就直接相信了?
明天要用一個具體案例,走一次一條 feedback 記憶怎麼從「一次被使用者糾正」變成「一條長期適用的規則」——中間到底發生了什麼事,讓一次性的糾正變成可以重複套用的東西。