核心概念

2024-2025 年間，三位科技領域一線人物分別公開了自己的 AI 知識管理架構，代表三種截然不同的思考路徑。

Andrej Karpathy — 羅盤（LLM Wiki）

Karpathy（深度學習教育者、Tesla AI 前總監、Eureka Labs 創辦人）提出的不是一套軟體，而是一種工作模式：用不可變的原始資料為地基，讓 LLM 維護一層持久性 wiki（摘要、實體、概念、交叉引用），並用 schema 檔（如 CLAUDE.md）約束「怎麼攝入、怎麼查詢、怎麼健檢」。他的 CS231n 課程影響整代工程師入門深度學習；「Software 2.0」與「vibe coding」概念塑造了開發者理解 LLM 與 Agent 的框架；2024 年創辦 Eureka Labs 則是這套思維往 AI 原生教育產品的延伸。

核心洞見：好檢索不如好編纂。知識要跨多次對話、多份來源被寫進結構，而不是每次從零拼湊。規模數十到數百頁時，index.md 加連結即夠導航，不必急著上向量庫。

Tobi Lütke — 望遠鏡（QMD）

Shopify CEO 提出的 QMD（Query Markup Documents）是裝在本機的混合搜尋引擎：BM25、向量語意、查詢擴展與重排序，以本地 GGUF 模型完成，強調隱私、零雲端 API、可腳本化與 MCP 整合。

核心洞見：在資料已存在的前提下，把「找得到」做到極致，而且不離開你的機器。適合需要搜尋離線或敏感 corpus 的工程師，尤其是 AST 感知的程式碼庫與技術文件。

Garry Tan — 營運系統（GBrain）

Y Combinator 總裁 Garry Tan 的 GBrain 是真實運行的系統：萬級 Markdown、千級人物檔、多年日曆與會議轉錄，由 Postgres + pgvector 與混合搜尋支撐。頁面模型是 compiled truth（當前最佳論述）+ timeline（只增不刪的證據鏈）；Agent 透過 skills 知道何時讀、何時寫、如何做 enrichment。

核心洞見：當個人知識庫像一家公司一樣有資產負債表，需要的是資料庫與管線，而不只是資料夾。

關鍵要點

維度 Karpathy Lütke Tan
比喻 羅盤 望遠鏡 營運系統
核心問題 知識有沒有在長大？ 找不找得到？ 能不能每天自動變聰明？
技術層次 Markdown + LLM 維護 本地混合搜尋引擎 Postgres + pgvector + Agent
隱私導向 彈性 強本地、零雲 雲端資料庫
適合規模 數十到數百頁 整個本機 corpus 萬頁以上
適合對象 研究者、深度閱讀者 工程師、大量技術文件 高密度知識工作者

三種系統解決不同層次的問題：Karpathy 解決「知識是否被結構化」，Lütke 解決「已存在的資料是否可被找到」，Tan 解決「知識庫是否可以自我演進」。三者可組合，並非互斥。

實務應用

從小到大的自然演進路徑：

  1. 起點（Karpathy 模式）：建立 wiki 式知識庫，用 LLM 維護結構。規模小時連結 + 索引即夠，不需向量庫。柒藍 wiki 目前走的就是這條路。參考 AI 輔助知識管理。

  2. 中期（加入 Lütke 概念）：當本機檔案量大到 grep 失效，加入 QMD 類本地混合搜尋層。不改變 wiki 架構，只是強化「找得到」的能力，且維持隱私。

  3. 大規模（Tan 架構）：當規模達萬頁、需要增量同步與圖譜關聯，引入 Postgres + pgvector 工程方案。此時知識庫已是可運營的平台，而非個人筆記本。可參考 RAG 檢索增強生成架構 的向量檢索設計。

領域專用變體：三種典範都可窄化為特定領域的知識系統——例如把 Karpathy 模式應用在投資研究，就會演化出「公司頁面 + 產業地圖 + 研究報告」的結構，用 skills 組織研究管線，儀表板呈現結構化查找結果，重點是「研究資產複利」而非泛用筆記本。領域明確反而讓編纂紀律更容易落實：因為什麼值得寫進去，判斷標準清晰。

選擇時，最重要的問題不是「哪個最強」，而是「我目前的瓶頸在哪」。多數人的瓶頸不是搜尋不夠好，而是根本沒有持續將想法寫進結構。先把 Karpathy 的「好編纂」做到位，再考慮其他層次的升級。

參見 電馭大腦三層架構、Harness Engineering。

延伸觀點

RAG 的根本限制是「失憶」，不是「不準」

多篇分析指出，RAG 的核心問題不是準確率，而是每次查詢都從零開始，沒有累積。LLM wiki 的優勢不在於「找得更準」，而在於「每次查詢都會在知識庫留下沉澱」——Karpathy 原文裡真正重要的一句話是：「My own explorations and queries always add up in the knowledge base.」這個複利機制才是根本差異，而不是 Markdown 對 Vector DB 的技術選型之爭。

複利的前提是雙向流動

典型 AI 工作流是單向的：輸入 → 輸出 → 消失於對話歷史。Karpathy 模式的突破在於把「輸出」轉為「存入」，讓每次互動沉澱到知識庫，下次查詢時可以站在上一次的結果上繼續推進。這個邏輯不需要複雜的向量架構就能實現，反而是「堅持寫入」的工作紀律更關鍵。

Postgres + pgvector 已足夠覆蓋 Tan 的大規模需求

實作案例顯示，多數個人知識庫不需要獨立的向量資料庫——PostgreSQL 16 + pgvector 搭配非同步 AI enrichment（標籤、摘要、嵌入在後台跑，不阻塞主流程），已能支撐千級頁面規模，且維運成本遠低於專屬向量服務。Tan 所描述的「工程級方案」在技術上已是相對平易的選擇，門檻更多在於「你是否真的有萬頁以上的資料需要管理」。

「記帳負擔」才是知識庫棄用的真正原因

多篇分析指出，傳統個人知識庫（Notion、Roam、Obsidian 手動維護）最終失敗，根因不是搜尋不夠好，而是「記帳負擔」（bookkeeping burden）增速超過價值創造速度：標籤整理、交叉引用、過時內容清理、矛盾偵測——這些維護工作逐漸讓人精疲力竭。LLM wiki 模式的根本創新在於把這層負擔轉移給模型，人只需負責「找到好輸入」與「提出有意義的問題」。這也是為什麼三位大師的系統都共同強調「schema 約束 AI 行為」——不是為了限制模型，而是讓維護工作可以自動化地可預期執行。

反向連結

以下頁面引用了本頁：