生化危機女主vibe coding讓紅皇后照進現實
整理版優先睇
MemPalace 用「存全部，靠結構揾」嘅理念，以 96.6% 準確率刷新 AI 記憶基準，但 vibe coding 嘅快速亦帶嚟誇大聲明，社區迅速糾錯凸顯開源價值。
呢篇文章介紹咗 GitHub 上一個爆紅項目 MemPalace，由 milla-jovovich 帳號發布，兩日內攞到近 3 萬星。佢嘅核心係一個 AI 記憶系統，喺 LongMemEval 基準測試中達到 96.6% R@5 準確率，完全本地運行而且免費。作者解釋，傳統 AI 會選擇性摘要對話，容易漏咗重要脈絡；MemPalace 就唔同，佢用「記憶宮殿」嘅概念——將所有對話原文逐字儲存，並用 Wing（翼樓）、Hall（大廳）、Room（房間）等空間結構去導航檢索，結果效能遠超其他系統。
不過，項目亦暴露咗 vibe coding 嘅典型問題：AAAK 壓縮聲稱 30 倍無損，實際上用 tokenizer 計反而多咗 token；Palace Boost 嘅 34% 提升其實係 ChromaDB 原生功能；矛盾檢測功能亦未連接到主流程。作者 Milla 同 Ben 發現後幾小時內就公開承認錯誤，逐條說明點樣修正。作者認為呢啲唔係道德問題，而係快速開發令元認知追唔上產出速度。
儘管有誇大，但核心嘅 96.6% 結果可以獨立復現——有用戶喺 M2 Ultra 上 5 分鐘就重現到。成件事最重要嘅啟示係：喺 vibe coding 年代，開源同可復現基準令糾錯速度追得上構建速度，呢個係付費閉源系統做唔到嘅。而家 MemPalace 可以用 pip install 直接裝，真係將紅皇后帶到現實。
- MemPalace 用「存全部，靠結構揾」嘅理念，以 96.6% R@5 準確率刷新 AI 記憶基準，完全本地免費，係目前公開最高分。
- 不同於傳統 AI 選擇性摘要，MemPalace 完整儲存對話，利用 ChromaDB 語義搜索同記憶宮殿嘅 Wing/Hall/Room 結構導航。
- 項目因 vibe coding 快速開發導致三處誇大聲明：AAAK 壓縮虛假、Palace Boost 無創新、矛盾檢測未集成，但作者快速承認錯誤。
- 社區幾小時內就發現問題並獨立驗證核心結果，形成高速迭代加高速糾錯嘅閉環，展示開源嘅關鍵作用。
- 任何人可以 pip install mempalace 立即使用，將 AI 記憶系統部署喺本地 MacBook，真正實現紅皇后級別嘅記憶能力。
MemPalace GitHub Repo
AI 記憶系統，96.6% 準確率，本地運行，完全免費。
愛麗絲出現：96.6% 嘅震撼
2026 年 4 月 7 日，GitHub 上出現咗一個叫 MemPalace 嘅項目，作者係 milla-jovovich。README 第一句就話係「迄今為止基準測試得分最高嘅 AI 記憶系統，而且免費」。兩日內星數突破 29,400，遠超 LangChain 當年嘅速度。
但真正令成個開發者社區沸騰嘅係核心數據：LongMemEval 基準測試，96.6% R@5 準確率，500 題，零 API 調用，完全本地運行。
業界之前最佳成績大約係 85%-88%，而且好多要靠付費雲服務。呢三個詞——96.6%、免費、本地——疊埋一齊，等於一個獨立開發者跑贏曬所有商業系統。
紅皇后嘅邏輯：存全部，靠結構揾
要理解 MemPalace，就要先知道傳統 AI 記憶嘅問題：AI 自己決定記咩，結果會漏曬啲重要脈絡。你跟佢傾三個鐘架構決定，佢淨係留低一句「用戶傾向微服務」，你點解咁揀、有咩疑慮、排除咗邊啲方案全部消失。
MemPalace 作者 Milla 同 Ben 揀咗一個反直覺方向：唔畀 AI 決定記咩，所有嘢都存曬，然後靠檢索去揾。
呢個概念源自古希臘嘅記憶宮殿技術：喺腦入面起一棟建築，將要記嘅內容放落唔同房間，演講時「行」過棟樓就會自動浮現。MemPalace 將佢翻譯成數碼結構：
- Wing（翼樓）：按人同項目分區，每個協作者或項目一棟樓
- Hall（大廳）：按記憶類型分類——決策記錄、代碼討論、架構辯論
- Room（房間）：具體話題或想法單元
- Closet / Drawer（壁櫥/抽屜）：細粒度資訊碎片
底層用 ChromaDB 做向量數據庫，原文逐字儲存，唔做摘要唔做提取。檢索時語義搜索喺呢套空間結構入面導航。96.6% 準確率就係嚟自呢個「存全部，靠結構揾」嘅原始模式。
Vibe Coding 嘅雙面刃：快但粗疏
不過好快社區就發現問題。第一個係 AAAK 壓縮方案：README 聲稱 30 倍無損壓縮，但用 OpenAI tokenizer 一計，AAAK 版本仲多咗 7 個 token。原來作者係用 len(text)//3 呢個粗糙方法估算。
第二個係 +34% Palace Boost：呢個提升係比較「無過濾全量搜索」同「加咗元數據過濾嘅搜索」，而元數據過濾係 ChromaDB 原生功能，唔係 MemPalace 創新。
第三個係矛盾檢測：README 寫到好似知識圖譜級別，但實際只係一個獨立嘅 fact_checker.py 檔案，根本冇連接到主流程。
值得一讚係作者幾小時內就喺 README 頂發布詳細公開聲明，逐條承認錯誤同修復計劃，語氣係「社區發佈幾小時內就發現真實問題，我哋想直接正視」。呢啲態度喺開源社區唔係常態。
真正嘅意義：開源令糾錯速度追上構建速度
今次事件令我想反思一個更大問題：當 vibe coding 將構建速度提高 10 倍，評估速度有冇同步提高？MemPalace 嘅答案係：社區評估速度都提高咗 10 倍。幾小時內三處關鍵問題就被發現、公開同修復，傳統開源項目可能要幾星期。
而家 MemPalace 仍然持續更新：AAAK 用真 tokenizer 重寫、矛盾檢測接入主流程、ChromaDB 依賴版本固定、macOS ARM64 segfault Bug 亦在追蹤。呢個唔係完成咗嘅項目，而係一個正在成為嘅項目。
READme 新加咗一句：「多謝所有人嚟挑毛病。殘酷誠實嘅批評，正係令開源運轉嘅嘢。」
尾聲：紅皇后跑喺你嘅 MacBook 上
《生化危機》最後愛麗絲跑出咗棟樓，紅皇后留喺地下繼續運轉。而家呢個紅皇后叫 MemPalace，跑喺你嘅本地機器上，等你 pip install。
呢個就係 vibe coding 最真實嘅樣：唔係一鍵生成完美產品，而係以空前速度從「大概跑通」走向「真係靠譜」，然後喺社區目光下將段距離逐點填平。
如果你對 AI Agent 深度實踐有興趣，歡迎關注我（努力撞蘑菇AI），一齊將 AI 玩明白。
一、「愛麗絲」出咗現
2026年4月7號，GitHub上面爆咗個項目。
個項目叫 MemPalace，作者帳號係 milla-jovovich。
README第一句係：
“"The highest-scoring AI memory system ever benchmarked. And it's free."（到目前為止基準測試得分最高嘅AI記憶系統，仲要係免費。）
截至2026年4月9號，呢個項目喺GitHub上已經累積攞到 29,400 個 Star，Fork數超過 3,700，Issues同Pull Requests加埋超過 210條——大部份係喺48個鐘內湧入嘅。
呢個數字係咩概念？
LangChain嘅GitHub倉庫，用咗差唔多 8個月先突破30,000 Star（數據來源：GitHub Stars History公開工具，2023年數據）。MemPalace用咗唔夠兩日。
但呢個只係表面。
真正令開發者社區沸騰嘅，係嗰個核心數據：LongMemEval基準測試，96.6% R@5準確率，500題，零API調用，完全本地運行。
LongMemEval係目前AI記憶領域最廣泛引用嘅標準評測集，由史丹福HAI實驗室（Human-Centered AI Institute）聯同多間機構喺2024年發佈，測試AI系統喺長對話入面嘅記憶檢索能力。喺呢之前，業界公認嘅最佳成績大概喺 85%~88% 嘅範圍，而且好多時依賴外部API調用或者付費雲服務。
96.6%，免費，本地。
呢三個詞疊埋一齊，等於一個獨立開發者跑出咗超越曬所有商業系統嘅成績。
呢個就係「愛麗絲」第一次出現喺鏡頭入面嘅樣。
二、紅皇后嘅邏輯：記憶宮殿唔係隱喻
要理解MemPalace做咗啲咩，就要先理解佢喺解決緊一個咩問題。
AI嘅記憶問題，長期以嚟有個標準答案：等AI自己決定記咩。
對話結束之後，系統提取關鍵資訊——「用戶喜歡PostgreSQL」、「用戶喺度做B端產品」——壓縮成結構化摘要，下次調用嗰陣注入上下文。
聽落好合理。但係有一個致命嘅裂縫：AI決定咗咩值得記，亦即係決定咗咩會被遺忘。
你同佢傾咗三個鐘嘅架構決策，佢畀你留低一句「用戶傾向於微服務」。嗰三個鐘入面你點解做呢個決定、你當時嘅疑慮係咩、你排除咗邊啲方案——全部冇曬。
MemPalace嘅作者Milla同佢嘅拍檔Ben，揀咗一個反直覺嘅方向：
唔畀AI決定記咩，將所有嘢都存低，然後等檢索去揾。
呢個思路本身來自古希臘。
公元前5世紀，希臘詩人西摩尼德斯發展出一套「記憶宮殿」技術（Method of Loci）：喺腦海入面起一棟建築物，將需要記憶嘅內容放喺唔同嘅房間。演講嗰陣，你只需要喺腦海入面「行」過呢棟建築，資訊就會按空間順序自動浮現。
MemPalace將呢套2500年前嘅方法翻譯成數碼結構：
Wing（翼樓）：按人同項目分區，每個協作者或項目一棟樓 Hall（大廳）：按記憶類型分類——決策記錄、代碼討論、架構辯論 Room（房間）：具體嘅話題或想法單元 Closet / Drawer（壁櫥/抽屜）：細粒度嘅資訊碎片
底層儲存用 ChromaDB（一個本地向量數據庫），原文逐字存入，唔做摘要唔做提取。檢索嗰陣，語義搜索喺呢套空間結構入面導航。
96.6%嘅準確率，嚟自呢個「存全部，靠結構揾」嘅原始模式。
呢個令我想起《生化危機》入面嘅紅皇后。
遊戲設定入面，紅皇后係保護傘公司開發嘅超級AI，運行喺地下設施嘅巨型電腦上面。佢嘅設計邏輯唔係「選擇性記憶」，而係完整記錄成個設施發生嘅一切——每一次門鎖開關、每一條走廊嘅温濕度、每一次生化事故嘅過程數據。
佢唔需要決定咩值得記，因為佢有足夠嘅容量裝曬全部。
MemPalace嘅核心哲學，同紅皇后驚人地相似：儲存能力已經夠曬平，遺忘反而係一種浪費。
三、Vibe Coding嘅雙面刃
但係，呢個故事仲有另一半。
項目發佈 幾個鐘之後，社區就開始揾問題了。
第一個被揭發嘅係 AAAK壓縮方案。
README原版聲稱，AAAK（一種針對AI對話嘅縮寫編碼方言）可以實現「30倍無損壓縮」，仲配咗一個Token對比示例。
社區用戶@panuh用OpenAI官方tokenizer重新跑咗一次：
原文英文示例：66 tokens AAAK壓縮版本：73 tokens
AAAK比原文多多咗7個Token。
「30倍無損壓縮」嘅依據，係作者用 len(text)//3（字符數除以3）呢個粗糙嘅啟發式方法估算出嚟，而唔係實際tokenizer輸出。
第二個被揭發嘅係 +34% Palace Boost。
README聲稱記憶宮殿結構帶嚟咗34%嘅檢索提升。實際上，呢個數字比較嘅係「無過濾嘅全量搜索」同「加咗元數據過濾嘅搜索」——而元數據過濾係ChromaDB嘅原生功能，唔係MemPalace嘅創新。
換句話講：你用ChromaDB原生過濾都會得到同樣嘅提升。
第三個係 矛盾檢測（Contradiction Detection）。
README描述咗一個知識圖譜級別嘅矛盾檢測功能。實際上，呢個功能存在於一個叫 fact_checker.py 嘅獨立工具檔入面，根本冇連接到主流程。
值得注意嘅係：項目作者Milla同Ben喺發現呢啲問題之後，喺2026年4月7號當日喺README頂部發佈咗一份詳細嘅公開聲明，逐條承認錯誤，逐條說明修復計劃。
呢份聲明嘅語氣係咁嘅：
“"The community caught real problems in this README within hours of launch and we want to address them directly."（社區喺發佈咗幾個鐘之內就發現咗README入面嘅真實問題，我哋想直接正視呢啲問題。）
然後佢哋用「What we got wrong」（我哋邊度做錯咗）作為小標題，將錯誤一條條列清楚。
呢個喺GitHub開源社區入面，唔係常態。
四、一個更值得問嘅問題
喺討論MemPalace嘅過程入面，有一個背景被反覆提起，但好少被認真討論：
呢個項目，係用vibe coding做嘅。
Milla喺PR討論區嘅留言入面提到，MemPalace嘅核心架構，大概用咗三天完成初版，主要工具係Claude同Cursor。基準測試腳本、ChromaDB集成、hooks機制——大量代碼係喺AI輔助下高速疊代出嚟。
呢個解釋咗嗰啲Bug嘅來源，亦解釋咗嗰個96.6%嘅真實性。
呢個係vibe coding嘅典型樣貌：可以好快整出一個「真係行到」嘅嘢，但係文件、邊界條件、誇張嘅benchmark聲明，往往跟唔上代碼嘅速度。
我想喺度做一個唔係咁受歡迎嘅判斷：
MemPalace俾社區發現嗰三處問題，唔係作者道德問題，而係工作方式嘅產物。
當你喺AI輔助下以3倍速度推進，你對自己工作嘅 元認知（meta-cognition） 係落後於產出速度嘅。你寫咗一段AAAK Token估算代碼，覺得啱咗，冇仔細驗證。你描述咗一個矛盾檢測功能，覺得連到咗，冇跑端到端測試。
唔係呃人，而係自我感知同實際產出之間嘅時間差。
呢個時間差，喺手工編程時代，通常由「慢」本身嚟彌合——你寫每一行代碼，你對嗰行代碼就有基本嘅感知。
Vibe coding將呢個「慢」壓縮咗，但係冇畀出新的校驗機制。
呢個係目前成個vibe coding浪潮入面最被忽視嘅結構性風險：速度係真嘅，理解係可選嘅。
五、96.6%點解仲係值得認真對待
但我唔想將呢篇文章變成一篇「AI編程危害論」。
因為有一件事係確鑿嘅：
96.6% R@5喺LongMemEval上面，係可以獨立復現嘅。
社區用戶@gizmax喺M2 Ultra機器上面，獨立運行咗benchmarks/目錄下面嘅評測腳本，喺 5分鐘內復現咗呢個結果。500題，零API調用，本地跑完。
呢個唔係數字遊戲，唔係cherry-pick，唔係淨係測咗50題然後外推。
呢個意味住嗰個核心思路——原文逐字儲存 + ChromaDB語義檢索 + 空間結構導航——喺記憶檢索呢件事上面，打出咗目前公開發表成果入面嘅最高分。
更重要嘅係：佢係免費嘅，本地嘅，任何人都可以部署嘅。
喺呢之前，如果你想幫AI Agent裝一個「記得住半年對話歷史」嘅記憶系統，你要唔係用付費雲服務（截至2026年4月，主流AI記憶雲服務嘅月費喺 200之間，各平台公開定價頁面都可以查到），唔係就要自己維護一套相當複雜嘅向量數據庫 + 摘要管道。
MemPalace將呢個門檻，降到 pip install mempalace。
返返去紅皇后嘅比喻。
紅皇后嘅恐怖之處，唔在於佢有幾聰明，而在於佢永遠唔會停。佢喺地下設施入面實時處理每一條傳感器數據，唔做篩選，唔做優先級排序，只係將一切存低，等需要嗰陣去揾。
而家，喺一部M2 Ultra嘅本地機器上面，一個叫Milla嘅開發者，用vibe coding整咗一個可以用96.6%準確率「回憶」半年對話嘅系統。
紅皇后由科幻走入咗現實。
分別只係：佢而家運行喺你嘅MacBook上面。
六、呢件事真正嘅意義
我想用呢件事嚟反思一個更大嘅問題：
當vibe coding令構建速度提高10倍，評估速度有冇同步提高？
MemPalace呢個案例，畀咗一個有趣嘅答案：社區評估速度都提高咗10倍。
幾個鐘之內，三處關鍵問題被發現、被公開、被修復。呢個喺傳統開源項目入面，可能需要幾個禮拜。
呢個唔係偶然。係因為：
項目係開源嘅——所有人都睇到代碼同benchmark腳本 基準測試係可以復現嘅——任何人都可以獨立驗證嗰96.6% 作者揀咗即刻公開承認錯誤——而唔係刪帖或者沉默
呢三點組合埋一齊，形成咗一個高速疊代 + 高速糾錯嘅閉環。
速度對稱咗。
但呢個閉環成立，依賴一個前提：構建者願意承認錯誤，社區有能力獨立驗證。
如果係一個付費嘅閉源商業系統，聲稱96.6%，冇可復現嘅benchmark腳本，冇GitHub Issues畀人提問——呢套閉環就唔存在啦。
呢個係vibe coding時代入面，開源精神變得前所未有咁重要嘅原因之一。
唔係因為開源更加「道德」，而係因為喺速度優先嘅構建文化入面，開源係唯一可以令糾錯速度跟得上構建速度嘅機制。
尾聲：愛麗絲仲喺度跑
《生化危機》最後，愛麗絲跑咗出嗰棟樓。
紅皇后留咗喺地下，繼續運轉。
MemPalace嘅GitHub README而家有一行字係新加嘅：
“"Thank you to everyone who poked holes in this. Brutal honest criticism is exactly what makes open source work."（多謝所有人嚟揾錯處。殘酷誠實嘅批評，正正係令開源運轉嘅嘢。）
Milla而家仲喺度持續更新呢個項目。AAAK嘅Token計算正在用真實tokenizer重寫，矛盾檢測正在接入主流程，ChromaDB依賴版本正在被鎖定，macOS ARM64嘅segfault Bug正在被追蹤。
呢個唔係一個「完成咗」嘅項目。呢個係一個正在變成嘅項目。
呢個，先係vibe coding最真實嘅樣：
唔係一鍵生成完美產品，而係喺AI輔助下以前所未有嘅速度由「大概行得通」走向「真係靠譜」——然後喺社區嘅目光之下，將嗰段距離一點點填平。
至於紅皇后？
佢而家叫MemPalace，跑喺你嘅本地機器上面，等緊你 pip install。
我係專注AI Agent深度實踐嘅努力撞蘑菇AI，致力分享真實可用嘅AI使用經驗同工作流探索，歡迎你同我一齊將AI玩到明，如果內容對你有幫助，歡迎關注、讚好、轉發。
我創建咗「OpenClaw完全指南」知識星球，專注記錄我使用OpenClaw嘅真實過程，由安裝部署、核心能力到真實案例全面覆蓋，記錄嘅都係我嘅實踐經驗，歡迎加入、一齊探索，幫助大家真正將OpenClaw用起嚟、用好佢。
一、"愛麗絲"出現了
2026 年 4 月 7 日，GitHub 上炸了一個項目。
項目名叫 MemPalace，作者賬號是 milla-jovovich。
README 的第一句話是：
“"The highest-scoring AI memory system ever benchmarked. And it's free."（迄今為止基準測試得分最高的 AI 記憶系統。免費。）
截至 2026 年 4 月 9 日，該項目在 GitHub 上已累計獲得 29,400 個 Star，Fork 數超過 3,700，Issues 和 Pull Requests 合計超過 210 條——大部分是在 48 小時內湧入的。
這個數字是什麼概念？
LangChain 的 GitHub 倉庫，花了將近 8 個月才突破 30,000 Star（數據來源：GitHub Stars History 公開工具，2023年數據）。MemPalace 用了不到兩天。
但這只是表面。
真正讓開發者社區沸騰的，是那個核心數據：LongMemEval 基準測試，96.6% R@5 準確率，500 題，零 API 調用，完全本地運行。
LongMemEval 是目前 AI 記憶領域最廣泛引用的標準評測集，由斯坦福 HAI 實驗室（Human-Centered AI Institute）聯合多所機構於 2024 年發佈，測試 AI 系統在長對話中的記憶檢索能力。在此之前，業界公認的最佳成績大致在 85%~88% 區間，且往往依賴外部 API 調用或付費雲服務。
96.6%，免費，本地。
這三個詞疊在一起，相當於一個獨立開發者跑出了超越所有商業系統的成績。
這就是"愛麗絲"第一次出現在鏡頭裏的樣子。
二、紅皇后的邏輯：記憶宮殿不是隱喻
要理解 MemPalace 做了什麼，得先理解它在解決一個什麼問題。
AI 的記憶問題，長期以來有個標準答案：讓 AI 自己決定記什麼。
對話結束，系統提取關鍵信息——"用戶喜歡 PostgreSQL"、"用戶在做 B 端產品"——壓縮成結構化摘要，下次調用時注入上下文。
聽起來很合理。但有一個致命的裂縫：AI 決定了什麼值得記，也就決定了什麼被遺忘。
你跟它聊了三個小時的架構決策，它給你留了一句"用戶傾向於微服務"。那三個小時裏你為什麼做這個決定、你當時的疑慮是什麼、你排除了哪些方案——全沒了。
MemPalace 的作者 Milla 和她的搭檔 Ben，選擇了一個反直覺的方向：
不讓 AI 決定記什麼，把所有東西都存下來，然後讓檢索去找。
這個思路本身來自古希臘。
公元前 5 世紀，希臘詩人西摩尼德斯發展出一套"記憶宮殿"技術（Method of Loci）：在腦海中構建一棟建築，把需要記憶的內容放進不同的房間。演講時，你只需要在腦海中"走"過這棟建築，信息就會按空間順序自動浮現。
MemPalace 把這套 2500 年前的方法翻譯成了數字結構：
Wing（翼樓）：按人和項目分區，每個協作者或項目一棟樓 Hall（大廳）：按記憶類型分類——決策記錄、代碼討論、架構辯論 Room（房間）：具體的話題或想法單元 Closet / Drawer（壁櫥/抽屜）：細粒度的信息碎片
底層存儲用 ChromaDB（一個本地向量數據庫），原文逐字存入，不做摘要不做提取。檢索時，語義搜索在這套空間結構裏導航。
96.6% 的準確率，來自這個"存全部，靠結構找"的原始模式。
這讓我想到《生化危機》裏的紅皇后。
遊戲設定裏，紅皇后是保護傘公司開發的超級 AI，運行在地下設施的巨型計算機上。她的設計邏輯不是"選擇性記憶"，而是完整記錄整個設施發生的一切——每一次門鎖開關、每一條走廊的温濕度、每一次生化事故的過程數據。
她不需要決定什麼值得記，因為她有足夠的容量裝下全部。
MemPalace 的核心哲學，和紅皇后驚人地相似：存儲能力已經足夠便宜，遺忘反而是一種浪費。
三、Vibe Coding 的雙面刃
但是，這個故事還有另一半。
項目發佈 幾小時後，社區就開始挖坑了。
第一個被掀翻的是 AAAK 壓縮方案。
README 原版聲稱，AAAK（一種針對 AI 對話的縮寫編碼方言）能實現"30 倍無損壓縮"，並配了一個 Token 對比示例。
社區用戶 @panuh 用 OpenAI 官方 tokenizer 重新跑了一遍：
原文英文示例：66 tokens AAAK 壓縮版本：73 tokens
AAAK 比原文多了 7 個 Token。
"30 倍無損壓縮"的依據，是作者用 len(text)//3（字符數除以 3）這個粗糙啓發式方法估算的，而非實際 tokenizer 輸出。
第二個被掀的是 +34% Palace Boost。
README 聲稱記憶宮殿結構帶來了 34% 的檢索提升。實際上，這個數字比較的是"無過濾的全量搜索"和"加了元數據過濾的搜索"——而元數據過濾是 ChromaDB 的原生功能，並非 MemPalace 的創新。
換句話說：你用 ChromaDB 原生過濾也能得到同樣的提升。
第三個是 矛盾檢測（Contradiction Detection）。
README 描述了一個知識圖譜級別的矛盾檢測功能。實際上，這個功能存在於一個叫 fact_checker.py 的獨立工具文件裏，根本沒有連接到主流程。
值得注意的是：項目作者 Milla 和 Ben 在發現這些問題後，於 2026 年 4 月 7 日當天在 README 頂部發布了一份詳細的公開聲明，逐條承認錯誤，逐條說明修復計劃。
這份聲明的語氣是這樣的：
“"The community caught real problems in this README within hours of launch and we want to address them directly."（社區在發佈後幾小時內就發現了 README 中的真實問題，我們想直接正視這些問題。）
然後他們用"What we got wrong"（我們哪裏做錯了）作為小標題，把錯誤一條條列清楚。
這在 GitHub 開源社區裏，不是常態。
四、一個更值得問的問題
在討論 MemPalace 的過程中，有一個背景被反覆提及，但很少被認真討論：
這個項目，是用 vibe coding 做的。
Milla 在 PR 討論區的留言裏提到，MemPalace 的核心架構，大約用了三天完成初版，主要工具是 Claude 和 Cursor。基準測試腳本、ChromaDB 集成、hooks 機制——大量代碼是在 AI 輔助下高速迭代出來的。
這解釋了那些 Bug 的來源，也解釋了那個 96.6% 的真實性。
這是 vibe coding 的典型樣貌：可以很快造出一個"真的能跑"的東西，但文檔、邊界條件、誇張的 benchmark 聲明，往往跟不上代碼的速度。
我想在這裏做一個並不討好的判斷：
MemPalace 被社區發現的那三處問題，不是作者道德問題，而是工作方式的產物。
當你在 AI 輔助下以 3 倍速度推進，你對自己工作的 元認知（meta-cognition） 是落後於產出速度的。你寫了一段 AAAK Token 估算代碼，感覺對了，沒有仔細驗證。你描述了一個矛盾檢測功能，感覺連上了，沒有跑端到端測試。
不是騙人，是自我感知與實際產出之間的時間差。
這個時間差，在手工編程時代，通常由"慢"本身來彌合——你寫每一行代碼，你就對那行代碼有基本的感知。
Vibe coding 把這個"慢"壓縮掉了，但沒有給出新的校驗機制。
這是目前整個 vibe coding 浪潮裏最被忽視的結構性風險：速度是真的，理解是可選的。
五、96.6% 為什麼還是值得認真對待的
但我不想讓這篇文章變成一篇"AI 編程危害論"。
因為有一件事是確鑿的：
96.6% R@5 在 LongMemEval 上，是可獨立復現的。
社區用戶 @gizmax 在 M2 Ultra 機器上，獨立運行了 benchmarks/ 目錄下的評測腳本，在 5 分鐘內復現了這個結果。500 道題，零 API 調用，本地跑完。
這不是數字遊戲，不是 cherry-pick，不是隻測了 50 題然後外推。
這意味着那個核心思路——原文逐字存儲 + ChromaDB 語義檢索 + 空間結構導航——在記憶檢索這件事上，打出了目前公開發表成果中的最高分。
更重要的是：它是免費的，本地的，任何人都可以部署的。
在此之前，如果你想給 AI Agent 裝一個"記得住半年對話歷史"的記憶系統，你要麼用付費雲服務（截至 2026 年 4 月，主流 AI 記憶雲服務的月費在 200 之間，各平台公開定價頁面均可查），要麼自己維護一套相當複雜的向量數據庫 + 摘要管道。
MemPalace 把這個門檻，降到了 pip install mempalace。
回到紅皇后的比喻。
紅皇后的恐怖之處，不在於她有多聰明，而在於她永不停歇。她在地下設施裏實時處理每一條傳感器數據，不做篩選，不做優先級排序，只是把一切存下來，等需要時去找。
現在，在一台 M2 Ultra 的本地機器上，一個叫 Milla 的開發者，用 vibe coding 做出了一個能以 96.6% 準確率"回憶"半年對話的系統。
紅皇后從科幻走進了現實。
區別只是：她現在運行在你的 MacBook 上。
六、這件事真正的意義
我想用這件事來反思一個更大的問題：
當 vibe coding 讓構建速度提高 10 倍，評估速度有沒有同步提高？
MemPalace 這個案例，給出了一個有趣的答案：社區評估速度也提高了 10 倍。
幾小時內，三處關鍵問題被發現、被公開、被修復。這在傳統開源項目裏，可能需要幾周。
這不是偶然。這是因為：
項目是開源的——所有人都能看到代碼和 benchmark 腳本 基準測試是可復現的——任何人都能獨立驗證那 96.6% 作者選擇了立刻公開承認錯誤——而不是刪帖或沉默
這三點組合在一起，形成了一個高速迭代 + 高速糾錯的閉環。
速度對稱了。
但這個閉環成立，依賴一個前提：構建者願意承認錯誤，社區有能力獨立驗證。
如果是一個付費的閉源商業系統，聲稱 96.6%，沒有可復現的 benchmark 腳本，沒有 GitHub Issues 讓人提問——這套閉環就不存在了。
這是 vibe coding 時代裏，開源精神變得前所未有地重要的原因之一。
不是因為開源更"道德"，而是因為在速度優先的構建文化裏，開源是唯一能讓糾錯速度跟上構建速度的機制。
尾聲：愛麗絲還在跑
《生化危機》最後，愛麗絲跑出了那棟樓。
紅皇后留在地下，繼續運轉。
MemPalace 的 GitHub README 現在有一行字是新加的：
“"Thank you to everyone who poked holes in this. Brutal honest criticism is exactly what makes open source work."（謝謝所有人來挑毛病。殘酷誠實的批評，正是讓開源運轉的東西。）
Milla 目前還在持續更新這個項目。AAAK 的 Token 計算正在用真實 tokenizer 重寫，矛盾檢測正在接入主流程，ChromaDB 依賴版本正在被固定，macOS ARM64 的 segfault Bug 正在被追蹤。
這不是一個"完成了"的項目。這是一個正在成為的項目。
這，才是 vibe coding 最真實的樣子：
不是一鍵生成完美產品，而是在 AI 輔助下以前所未有的速度從"大概跑通"走向"真的靠譜"——然後在社區的目光下，把那段距離一點點填平。
至於紅皇后？
她現在叫 MemPalace，跑在你的本地機器上，等着你 pip install。
我是專注 AI Agent深度實踐的努力撞蘑菇AI，致力於分享真實可用的 AI 使用經驗與工作流探索，歡迎你和我一起把 AI 玩明白，如果內容對你有幫助，歡迎關注、點贊、轉發。
我創建了「OpenClaw完全指南」知識星球，專注記錄我使用OpenClaw的真實過程，從安裝部署、核心能力到真實案例全面覆蓋，記錄的都是我的實踐經驗，歡迎加入、一起探索，幫助大家真正把OpenClaw用起來、用好它。