[Dev Workflow] 搜尋找得到,卻要每個 session 重推一遍:幫 AI 記憶加一層蒸餾層

白話版:別讓 AI 每天上工都要你從頭解釋一遍

你請了一個很會查資料的 AI 助理。它有個好處:你把踩過的坑、想通的事寫成一個一個純文字檔,它隨時查得到。但它有個毛病——查回來的永遠是『原始材料』:當初那段程式碼、那則寫得亂糟糟的原始筆記。它不會自動把『上次已經想通的結論』收好,所以每換一個新助理、甚至同一個助理隔天再上工,你都得從頭再講一次:我是誰、我試過哪些做法、哪條路我親手走過發現不通。

這篇要補的,就是這一層。我把那些『已經想通、而且確定不會馬上變的結論』另外抄成一張一張卡片,貼好標籤,放進一個『定案結論專用』的盒子。之後不管哪個助理上工,遇到這些事直接翻卡片,不用你再解釋一遍。

要注意的是:這層的重點不是『逼每個助理講出一模一樣的話』——它們讀同一批卡片,還是會有各自的解讀,這沒關係。重點是『同一件事只解釋一次』。真正花你時間的,從來不是它們意見不合,而是你每開一個新的一天、每帶一個新來的助理,都得把同一套背景重講一遍。卡片盒幫你省掉的,就是這筆重複解釋的稅。

---

前言

這個系列寫到這裡,我一直在拆同一套東西:餵給 AI 的那份長期記憶,到底該長什麼樣。Part 12 講的是檢索——搜尋加一張知識圖譜,讓那幾百個 markdown 檔『找得到、連得起來』。這篇再往上疊一層。

先講個我很晚才想通的比喻。搜尋是一座很強的礦場:你要鐵,它幾秒鐘就幫你找到礦脈、把礦石挖出來。問題是礦石不能直接鎖到機器上——你得先把它冶煉成一個零件。而我發現,我每開一個新任務,都是從『重新冶煉同一批礦石』開始的。同一段推導、同一個我早就下過的判斷,每個新 session 都從頭再煉一次。這時候瓶頸根本不在礦場,在冶煉。

蒸餾層就是那個零件盒:同一批礦石,冶煉一次、貼上標籤,之後每個任務直接伸手拿零件,不再回去挖礦。這篇先把這個盒子講清楚——它是什麼、每一塊為什麼存在、換來什麼——最後才講我怎麼學會真的去信它。

檢索撈回的是礦石,不是你要的那顆零件

你已經有搜尋、也有圖了,agent 開工前確實會自己先查記憶。但你很快會撞到一件事:它查回來的是『原始材料』——當初那段程式碼、那則寫得亂七八糟的原始筆記——不是你要的那個結論。

『找得到』跟『用得上結論』是兩回事。搜尋撈回一則三個禮拜前的筆記,裡面躺著十件事的來龍去脈;agent 還是得把整則讀完、重新推一遍,才知道『所以結論到底是什麼』。換一個 session、換一個 agent,這趟推導就要重跑。有了搜尋,你省掉的只是『找』,省不掉『每次都要重新想通一遍』。

這件事會隨著你養越多 agent 而越來越貴——因為重複的不是儲存,是思考。你付一次錢挖到礦,卻在每一個任務、每一個新 agent 身上,重複付冶煉的錢。

蒸餾層是什麼:規範更嚴的一個 markdown 資料夾,而且只有你能蓋章

說穿了,蒸餾層還是一個裝 markdown 的資料夾——跟底下那層記憶同一種東西。差別在規範更嚴。

底層的記憶什麼都收:原始筆記、對話節錄、隨手記的東西。蒸餾層不是。它一檔只放一個『已經定案的結論』,配上證據、還有這個結論會影響到什麼(implications)。它不是把你學到的全部倒進去,是那個『夠格拿來當現行事實用』的精選子集。我給這批筆記一個名字:canonical——指『已經定案、可以直接拿來當事實用』的那批。

那『夠不夠格』誰說了算?這就是整層唯一的閘門。一筆知識的生命週期是這樣:先進收件匣(inbox,還沒被信任的來件)→ 被檢視 → 才蓋章升成 canonical。而那顆蓋章的按鈕,全世界只有一個,就是你。agent 只能『提案』把東西丟進收件匣;要不要升成 canonical,是人的決定,不是另一個 agent 的決定。

這一刀劃出去,檢索那層之後交給 agent 的,就直接是『結論』,不再是『原料』。

這層是為了少解釋一次,不是逼五個 AI 講一樣的話

這是整篇最重要、也最反直覺的一段,值得慢慢講。

你可能會馬上反問:五個 AI 讀同一批 canonical,還不是各有各的解讀?對,會——而且沒差。一致從來就不是目標。

因為你真正在付的稅,不是『它們彼此不同意』,是『重複解釋』。對每一個新 agent、對同一個 agent 每一個新 session,你都得把同一套背景再講一遍:我是誰、我否決過哪些做法、哪個看起來很聰明的改法我其實測過、然後丟掉了。這套東西不寫下來,它就活在你腦子裡,每次靠嘴巴(或靠 prompt)重講。

蒸餾層省下的就是這筆稅:結論寫一次,大家自己去讀。它們讀完會不會給出一模一樣的句子,我一點都不在乎——我在乎的是那段最花腦力的推導,我只做了一次。

想通這件事之後,底下幾個看起來很懶的決定,其實都是同一個原則的延伸。

所以我放著 drift 不管——過時在讀的時候抓,不在寫的時候擋

順著上面那個原則,我刻意做了三件『不追一致』的事。

第一,容忍 drift(兩台機器上的狀態不用隨時一模一樣)。兩邊晚幾分鐘才同步,我不追問『到底哪一份才是真的』——最終一致性就夠了。第二,不設 AI 審查閘門。整條流程是:你丟來源 → agent 去研究 → 『你』決定 → 記下來。沒有一個 agent 去審另一個 agent 能不能進 canonical。第三,承接上一段,那顆蓋章的按鈕只有你。

放著 drift 不管,為什麼安全?靠兩件事。一是 supersede:當一個新決策要蓋過一則舊筆記,我不是回去把舊筆記改掉或刪掉,而是替它貼一條『這條已經被取代』的告示、再記一筆紀錄。二是 JIT 重驗(just-in-time,召回的當下才驗):agent 召回一則舊筆記、要採信它之前,先拿它去對現況重新驗一次。過時是在『讀取的時候』抓出來的,不是在『寫入的時候』想辦法擋掉。

⚠️ 這裡有個要主動避開的反模式:工廠。你一旦動手去蓋一致性檢查器、auto-reviewer、跨機對帳這種東西,你就是在把『記憶』變成另一個要你維護的系統。輕量的那版之所以站得住,是因為這層的目的是『少做工』,不是『多疊一套要顧的機器』。動手蓋工廠、最後 ship 出零產出,是我很熟的一種死法。

352 檔餵 59 檔:那不是還沒搬完,是箭頭本來就往上

你看到數字可能會誤讀:底層那份原始鏡像有 352 檔,蒸餾層只有 59 檔。直覺會把它讀成『你遷移的工作只做了一小半』。錯了,方向剛好相反。

原始鏡像是『全量記錄』——什麼都留著。蒸餾層是疊在它上面的『精選結論』,吃鏡像當上游。所以 352 餵 59,是『記錄的摘要』,不是『欠的帳』。上一篇 Part 11 講的是退役舊鏡像的另一半故事;這裡只借它一個結論:箭頭永遠是『原始餵蒸餾』,不會反過來。

正因為箭頭只往上,蒸餾層才能又小又不失真:篩選的時候我不怕丟東西,因為全量記錄還躺在底下——真要回頭考古,原礦一顆都沒少。這也是我一路守著單一事實來源的原因:底層那份原始記錄永遠是正本,蒸餾層只是疊在上面、隨時可以重挑一次的一層。

這樣疊一層,換來什麼

這層蒸餾疊上去,換來四個我在任何記憶系統裡都會想留住的性質:

• 最花腦力的推導只做一次。 蓋章那一刻,讀、推、決定都做完了;之後每一次召回,是『查表』,不是『重推』。同一段推導不會在每個 session 重跑。
• 多接一個 agent,不用多解釋一次。 新來的 agent 直接讀 canonical,你的解釋成本是零。省下來的隨著你的 fleet 養越大,複利越明顯。
• drift 便宜、不危險。 過時在讀取的時候抓(靠 supersede 加召回重驗),你不用養一台對帳器、也不用排程去 diff 兩邊。
• 維持輕量。 它到頭來還是 markdown 加一個蓋章閘門。沒有 reviewer bot、沒有一致性 daemon、沒有你得回頭伺候的第二個系統。

架構到這裡就講完了。只想直接套用的,文末那份五行 checklist 就是全部;想看我怎麼『學會信這一層』的,再往下讀。

我實際上怎麼走到這裡——那些走錯的路

底下是我怎麼一路確認『這層真的在出力』的過程——包括一次差點翻船的發現,和一個反方向的證據。這些都不是『用這套系統』的必要知識,只想要設計的,直接跳到收穫。

最可怕的不是沒筆記,是它有筆記卻不去查

這一段是整個蒸餾層真正的起點。

有一次我問值班的 agent 一條內部規則——一條當天早上我才剛改過的風控規則。剛改過,意思是它背不出來:標準答案不在它的權重裡,只能靠『真的去查那份現行筆記』才會對。而資料是齊的——同步好了、搜得到,一查就在。

結果它沒查。它自由發揮,流暢地給了我一個答案——而那個答案,正好是我自己實測過、然後否決掉的那個『教科書標準做法』。

這件事把我嚇醒了。一個聰明、但手上沒有事實根據的模型,遇到不確定,會回去抱教科書;而我整個 edge,恰恰建立在『教科書在這裡是錯的,而且我有數據可以證明』。所以問題不是模型笨,是它在該查證的時候,用先驗把洞給補起來了。

想清楚之後我才發現:這一件事,就是蒸餾層存在的全部理由。教科書答案又免費又流暢——它會自己從權重裡掉出來;而那則說『教科書在這裡是錯的、證據在此』的 canonical 筆記,必須(a)先存在,而且(b)在模型動用先驗補洞之前,就先被查到。蒸餾層給你的是(a)。至於(b),解法是一條檢索順序的規則:碰到這種『教科書 vs 我的做法』的問題,先查 canonical,再查自己的舊對話——你昨天講過的話,不會因為被搜出來,就自動變成一條規則。

反方向的證據:兩份不相干的蒸餾,拼出同一個我

再給你一個反方向的證據,是它讓我真的放心。

我起了一個冷 context 的自架模型——全新開機、完全沒讀過我個人那批 canonical。我只餵它兩份彼此不相交的蒸餾資料:一份是它自己那套 fleet 記憶,一份是共享的知識庫。沒有給任何提示、沒有『我是誰』的開場白。

它自己拼出了一個『我』:我是誰、我否決過哪些做法、我在哪些限制底下工作——輪廓對得嚇人。

兩份獨立蒸餾、原料不同,卻收斂到同一個結論,這是我能想到最強的證據,證明蒸餾抓到的是真訊號,不是回音。只餵單獨一份 corpus,模型有可能只是把裡面的噪音背了下來;但兩份互不相交的,模型很難剛好對同一段噪音都 overfit。而那顆模型的『重複解釋稅』是真的歸零了——它靠讀,不靠問。

收穫

最花時間的地方

不是把 canonical 筆記寫出來,是學會『信』它們。寫筆記是機械活;難的是去證明『一則筆記可以明明存在、卻被無視』(前面那次差點翻船),然後建立起檢索順序加 supersede 的習慣,讓筆記真的變成 load-bearing(有在承重、不是擺著好看)。一則沒人真的去讀、去信的 canonical,跟沒有它沒兩樣。

可以搬走的診斷

先把『找到』跟『重用』分乾淨——搜尋解決前者,蒸餾解決後者,兩件事別混為一談。要測一個 agent 到底有沒有真的在召回,用『今天才改的規則』去問它:這是唯一誠實的測法,因為舊規則它本來可能就背得出來,只有剛改的那條,答對了才代表它真的去查了。當 agent 對一條你有定見的問題給出流暢答案,先分清楚它是『查到的』還是『腦補的』。還有,把『352 對 59』這種數字讀成層次,不要讀成欠帳。

通用原則

蒸餾層的目的,是把最花腦力的推導只做一次、把重複解釋這筆稅省下來——不是逼大家講一樣。所以你會刻意容忍 drift、讓自己當唯一的蓋章閘門、把過時留到讀取的時候再抓。反過來說:哪天你開始長出 reviewer bot 加對帳器、想用它們逼出一致,這層就從『幫你省工』變成『另一份工』了。

如果你要幫 AI 記憶加一層蒸餾,這是我試出來的順序

1. 蒸餾出來的結論,不能只是一則筆記。 一檔放一個定案結論,配上證據、還有它會影響到什麼——不是把學到的全倒進去。
2. 留一條生命週期,加一個閘門。 收件匣 → 檢視 → 蓋章升 canonical;那顆蓋章的按鈕只有你。agent 負責提案,你負責蓋章。
3. 為『講一次』最佳化,不是為『處處一致』。 容忍 drift,別動手去蓋一致性強制器。
4. 過時在讀取時抓,不在寫入時防。 覆蓋舊筆記時貼告示、記一筆;採信之前拿它對現況重驗一次。
5. 先用 canonical 打底,再讓模型動用先驗。 碰到有定見的問題,先查 canonical、再查自己的舊對話,不然模型會拿教科書把洞補起來。

下一篇:持久的知識只是一半。另一半是『即時狀態』——一個 agent 現在正在做什麼——以及一群 AI 要怎麼交接手上的任務,而不用把那個也從頭再講一遍。