High-Fidelity Translation

LLM Wiki

一種利用大模型建立個人知識庫的範式

📝 學習摘要

本文譯自 Andrej Karpathy 的 Gist。其核心論點在於：傳統 RAG 是碎片的重新發現，而 LLM Wiki 是知識的持續編譯。這是一份「Idea File」，旨在啟發開發者與 AI 協作，將對話沈澱為可維護的代碼化知識庫。

Original Author Andrej Karpathy

Translator Gemini Agent (Good Student Mode)

Last Updated 2026-04-23

這是一份 Idea File（想法草案）。它被設計成可以直接複製並貼給你的 LLM Agent（例如 OpenAI Codex, Claude Code, OpenCode / Pi 等等）。它的目標是傳達高層次的設計理念，但具體的實作細節，則需要由你的 Agent 在與你的協作過程中共同構建出來。

核心理念 (The core idea)

大多數人使用 LLM 處理文件的經驗看起來像 RAG：你上傳一堆檔案，LLM 在提問時檢索相關的碎片（chunks），然後生成答案。這雖然可行，但 LLM 每次都在針對每個問題「從頭開始重新發現知識」。這沒有累積。

如果你問一個需要綜合五份文件的微妙問題，LLM 每次都必須重新尋找並拼湊這些相關片段。沒有任何東西被建立起來。NotebookLM、ChatGPT 的檔案上傳功能，以及大多數 RAG 系統都是以這種方式運作的。

這裡的想法不同。LLM 不僅僅是在查詢時從原始文件中檢索，而是會增量式地構建並維護一個持久的 Wiki —— 一個結構化、互聯的 Markdown 文件集合，介於你與原始資料源之間。

當你加入新資料源時，LLM 不只是對其進行索引以備後查。它會閱讀它、提取關鍵資訊，並將其整合到現有的 Wiki 中 —— 更新實體頁面（entity pages）、修正主題摘要、註記新數據與舊主張矛盾之處，並強化或挑戰不斷演化中的綜合論述。知識被編譯了一次，隨後保持更新，而不是在每次查詢時重新推導。

🎯 建築師視角

類比這就像從「2D 繪圖」轉向「BIM 建模」。RAG 是在浩如煙海的圖紙中尋找標註；LLM Wiki 則是維護一個參數化的模型中心檔。

應用當我們把《建築技術規則》丟進去時，AI 不該只是搜尋條文，而是要將條文轉化為 Wiki 裡的「空間約束規則」。新舊法規更迭時，它應自動指出設計邏輯的衝突點。

這就是關鍵差異：Wiki 是一個持久的、具備複利效應的產物 (Compounding Artifact)。 交叉引用已經建立好了。矛盾之處已經被標記出來。綜合論述已經反映了你讀過的所有內容。Wiki 會隨著你加入的每個資料源和問出的每個問題，變得越來越豐富。

你從不（或很少）親自撰寫 Wiki —— 全部由 LLM 來撰寫與維護。你負責的是來源提供、探索方向，以及提出正確的問題。LLM 負責所有的粗重活 —— 摘要、交叉引用、存檔和簿記，這些工作讓知識庫隨著時間的推移真正變得有用。

在實踐中，我一邊開著 LLM Agent，另一邊開著 Obsidian。LLM 根據我們的對話進行編輯，而我實時瀏覽結果 —— 點擊連結、檢查關聯圖視圖（graph view）、閱讀更新後的頁面。Obsidian 是 IDE；LLM 是程式設計師；Wiki 是代碼庫 (Codebase)。

架構 (Architecture)

系統分為三層：

Raw sources（原始來源）：你策展的來源文件集合。文章、論文、圖片、數據文件。這些是不可變的 (Immutable) —— LLM 只從中讀取，絕不修改。這是你的「真相來源」。
The Wiki（維基層）：由 LLM 生成的 Markdown 文件目錄。包含摘要、實體頁面、概念頁面、對照表、總覽與綜合論述。LLM 完全擁有這一層。它創建頁面、隨新來源更新頁面、維護交叉引用，並保持一切的一致性。你讀，LLM 寫。
The Schema（架構規範）：一份告訴 LLM 該 Wiki 如何組織的文件（例如 CLAUDE.md 或 AGENTS.md）。它定義了慣例、攝取來源的流程、回答問題的規範，以及如何維護 Wiki。這是關鍵的配置檔案 —— 正是它讓 LLM 成為一名自律的 Wiki 維護者，而不是一個通用的聊天機器人。 你與 LLM 會隨著時間共同演化這份文件，直到找到最適合你領域的範式。

操作 (Operations)

Ingest (攝取)：你將新來源放入原始集合中，並告訴 LLM 進行處理。例如：LLM 閱讀來源、與你討論關鍵要點、在 Wiki 中寫下摘要頁、更新索引 (index)、更新整個 Wiki 中相關的實體與概念頁面，最後在日誌 (log) 中附加一條條目。一個來源可能會觸動 10 到 15 個 Wiki 頁面。
Query (查詢)：你針對 Wiki 提出問題。LLM 搜尋相關頁面、閱讀它們，並綜合出帶有引用的答案。答案可以有多種形式 —— Markdown 頁面、比較表、簡報、圖表或畫布。重要的洞察是：好的答案可以作為新頁面歸檔回 Wiki。 你要求的對比、你的分析、你發現的關聯 —— 這些都是有價值的，不應該消失在對話歷史中。
Lint (健檢)：定期要求 LLM 對 Wiki 進行健康檢查。尋找：頁面間的矛盾、被新來源取代的陳舊主張、沒有入站連結的孤兒頁面、被提及但沒有獨立頁面的重要概念。這能保持 Wiki 隨著增長依然健康。

🎯 建築師視角

類比 Lint 操作就像是 BIM 模型的 Clash Detection (碰撞檢查)。我們不是在檢查管線衝突，是在檢查「知識邏輯」的衝突。

索引與日誌 (Indexing and logging)

兩個特殊檔案幫助 LLM（和你自己）在 Wiki 增長時導航：

index.md 是內容導向的。它是 Wiki 中所有內容的目錄。按類別（實體、概念、來源等）組織。LLM 在每次攝取時更新它。
log.md 是時序導向的。它是「發生了什麼以及何時發生」的追加紀錄。如果每個條目都有統一的前綴，日誌就可以用簡單的 Unix 工具（如 grep）來解析。

為什麼這有效 (Why this works)

維護知識庫最枯燥的部分不是閱讀或思考 —— 而是「簿記 (Bookkeeping)」。更新交叉引用、保持摘要即時、記錄新數據何時與舊主張矛盾、維護數十個頁面間的一致性。

人類會放棄維護 Wiki，是因為維護負擔的增長速度超過了價值產生的速度。而 LLM 不會感到無聊，不會忘記更新交叉引用，並且可以在一次處理中改動 15 個檔案。Wiki 能夠持續維持，是因為維護成本趨近於零。