What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis

原始來源與檔名：2026-07-03T094728+0800-What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis.md

SOURCE | 資訊源評估

• 準確性: 高 - 基於 Andrej Karpathy 的實際實踐與清晰的系統架構，邏輯嚴謹且具體。
• 易理解性: 高 - 使用具象的比喻（如沒有記憶的助理 vs. 不知疲倦的圖書管理員），文章結構清晰。
• 閱讀策略建議: 本文概念性強且容易理解，建議直接閱讀並開始動手建立個人的 LLM 知識庫，以實踐代替單純理解。

NAPKIN | 餐巾纸

餐巾纸公式

LLM Wiki = Raw Sources (不可變) + Markdown Directory (動態) + Schema (規則) + Agent (不知疲倦的維護者)

將知識從單次檢索（RAG）轉變為累積編譯（Compilation），依靠 LLM 處理知識庫的維護負擔。

一句話

放棄讓 LLM 每次從頭找答案的 RAG，給它一個 Markdown 知識庫，讓它成為不知疲倦、自動維護交叉連結的私人圖書館長。

餐巾纸草图

[Raw Sources] ----(Ingest)----> [LLM Agent] <----(Query)---- [Human]
 (Immutable)                        | (Lint)
                                    v
                            [Markdown Wiki]
                           - index.md
                           - log.md
                           - concept_A.md
                           - concept_B.md

ROUND 1: SKELETON | 骨架掃描

“这本书在说什么”

• 核心问题: 如何讓 AI 不只是檢索知識，而是能夠隨著時間累積、編譯並維護個人的知識體系？
• 核心答案: 建立 LLM Wiki 模式，提供 LLM 一個包含 Schema 和 Markdown 檔案的目錄，讓 LLM 負責新增、更新與維護交叉連結，人類則負責提供來源與提問。
• 论证结构: 對比型（傳統 RAG vs. LLM Wiki）與架構型（定義三個分層與三個操作）。

章节骨架

1. 問題背景: RAG 缺乏記憶與累積。
2. 核心理念: 從檢索走向知識的持續編譯。
3. 三層架構: Raw Sources、Wiki、Schema。
4. 三大操作: Ingest、Query、Lint。
5. 核心檔案: index.md 與 log.md 的作用。
6. 應用場景: 個人、團隊、研究到全社會知識。

ROUND 2: DISSECTION | 血肉解剖

“凭什么这么说”

论证链

人類放棄維護 Wiki 是因為記帳負擔過重 --> LLM 擅長處理瑣碎的更新與連結且成本極低 --> 將 Wiki 的讀寫權限交給 LLM，人類只負責提供素材與引導 --> 知識從無狀態的檢索轉變為有狀態的持續累積

关键证据

1. Andrej Karpathy 已經實踐此系統數月，人類負責在 Obsidian 瀏覽器中指導，LLM 代理負責執行修改與維護。
2. 傳統 RAG 就像一個每次回答完就失憶的助理，無法將兩次查詢之間的知識關聯起來。
3. LLM 在一次操作中可以輕鬆讀取並更新 10 到 15 個 Markdown 檔案的交叉參考，這是人類難以持續做到的。

隐形假设与边界

• 隐形假设:
  • LLM 具有足夠的 Context Window 和推理能力來理解跨越多個檔案的邏輯與 Schema。
  • 底層儲存（Markdown 檔案與 Git）能夠處理版本控制，允許人類在 LLM 出錯時回溯。
• 边界条件:
  • 當 Wiki 規模超過數百個檔案時，單純依賴 index.md 索引將失效，必須引入輕量級的搜尋引擎或向量資料庫。
  • 若來源包含非文字內容（如大量影片或複雜圖表），LLM 處理效率會大幅降低。

ROUND 3: SOUL | 靈魂提取

“还能怎么用”

• 作者盲点: 如何在團隊協作中解決多個 LLM Agent 同時修改 Wiki 導致的 Git 衝突，文章僅簡單提及，未深入探討協定機制。
• 知识连接: 與軟體工程中的 “Event Sourcing” 相似：Raw Sources 是事件日誌，Wiki 是具體化視圖 (Materialized View)；與 Vannevar Bush 在 1945 年提出的 “Memex” 概念完美契合。
• 行动触发: 立刻將個人 Obsidian 知識庫與 Claude Code 結合，撰寫第一版 Schema，嘗試丟入幾篇原始文章讓它自動生成與連結。

留白提問 (Guided Reflection)

• 如果你將過去一年的工作日誌全部交給 LLM 整理成 Wiki，你認為它會發現你工作模式中的哪些盲點或重複勞動？
• 當個人的「第二大腦」完全由機器維護時，你會如何確認這些被提煉出來的知識仍然真正屬於「你」？

跨域映射

• 在 軟體工程，这叫 具體化視圖 (Materialized View)
• 在 組織行為學，這叫 組織記憶 (Organizational Memory)

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. The Core Idea: 作者點出「將 Obsidian 當作 IDE，LLM 視為程式設計師，Wiki 則是程式碼庫」的比喻，這是理解人機協作邊界的精華。
2. The Three Layers & The Three Operations: 這是構建 LLM Wiki 的核心架構，詳細定義了資料層面（Raw、Wiki、Schema）與行為層面（Ingest、Query、Lint）的運作機制。

What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis (Architectural Deep Dive)

前言/背景

本文旨在解決傳統 RAG（檢索增強生成）系統中「無狀態」與「缺乏知識累積」的痛點。作者借鑒 Andrej Karpathy 的實踐，提出「LLM Wiki 模式」：透過讓 LLM 代理直接維護一個實體的 Markdown 檔案庫，將知識獲取從單次的「檢索」昇華為持久的「編譯」，從而打造出一個會隨時間成長、自動維護交叉參照的知識狀態機 (Stateful Knowledge Base)。

章節詳細總結

The Core Idea (核心理念)

RAG 系統的致命傷在於每次提問都需要從頭檢索，如同一個每次回答完問題就會失憶的助理。LLM Wiki 模式則賦予 LLM 一個「真實的 Wiki」（不斷成長的 Markdown 檔案目錄）。當你引入新來源時，LLM 不僅僅是建立索引，而是會閱讀來源、提取重點、更新現有頁面、建立新頁面，甚至標記新舊資訊的矛盾處。 在 Andrej Karpathy 的實踐中，這形成了一種完美的關注點分離 (Separation of Concerns)：Obsidian 作為 IDE，LLM 作為程式設計師，Wiki 則是 Codebase。人類負責下達指令與提供素材，LLM 負責繁瑣的維護（摘要、連結、歸檔）。

Why This Works (為什麼有效)

個人或團隊的 Wiki 往往走向死亡，原因並非缺乏閱讀或思考，而是記帳負擔 (Bookkeeping) 越來越重：更新交叉參照、維持摘要的時效性、確保數十個頁面的一致性。LLM Wiki 模式的成功在於，LLM 不會感到厭倦，能在一次操作中精準修改 15 個檔案，將 Wiki 維護的邊際成本降至接近於零。

The Three Layers (三層架構)

要實作這個系統，架構上需要切割為三個層次：

• Raw Sources (原始來源)：這是你的輸入庫，包含文章、論文、會議紀錄等。這個層級是不可變的 (Immutable)，LLM 只能讀取，不能修改。
• The Wiki (維基層)：由 Markdown 檔案組成的目錄，包含摘要、實體頁面、概念整合等。這個層級完全由 LLM 擁有並負責 CRUD 操作。
• The Schema (結構定義)：一個配置檔 (Configuration file)。它定義了 Wiki 的結構、寫作慣例以及工作流，這是確保 LLM 行為穩定，使其從「通用聊天機器人」轉變為「紀律嚴明的 Wiki 維護者」的關鍵。

The Three Operations (三大操作)

系統的生命週期由三個主要操作維持：

• Ingest (攝取)：放入新來源後，LLM 會讀取並與你討論，接著撰寫摘要頁、更新索引、更新相關的實體與概念頁面，最後寫入日誌。一個來源可能會觸發對十幾個 Markdown 檔案的更新。
• Query (查詢)：向 Wiki 提問。LLM 會搜尋相關頁面並綜合出帶有引用的答案。關鍵在於，好的答案應該被重新沉澱到 Wiki 中，成為新的頁面，而不是消失在對話紀錄裡。
• Lint (健康檢查)：定期讓 LLM 掃描 Wiki 以尋找：頁面間的矛盾點、過時的主張、沒有入站連結的孤兒頁面 (Orphan pages)、以及缺乏交叉參照的概念。

Two Special Files (兩個特殊檔案)

隨著系統增長，有兩個核心檔案協助導航：

• index.md：內容導向。它是整個 Wiki 的目錄，包含每個頁面的連結與單行摘要。LLM 在處理查詢時會先讀取此檔。在數百個頁面的適度規模下，這運作得非常好。
• log.md：時間軸導向。這是一個「僅限附加 (Append-only)」的事件紀錄檔，紀錄了 Ingest、Query 與 Lint 的發生時間與內容，幫助 LLM 理解系統最近發生了什麼事。

Scale & Practical Tips (擴展性與實戰建議)

• 擴展性：這個模式可應用於個人、團隊、學術研究甚至全社會知識。傳統維護死角在於人類無法負荷持續更新，而 LLM 可以充當這個「不知疲倦的整合者」。當規模超過 index.md 能處理的極限時（數百頁以上），則需引入搜尋引擎（如 grep 加上 LLM 重排序）來協助檢索。
• 圖片處理：LLM 無法在一次文本掃描中讀取圖片，實務上的 Workaround 是讓 LLM 先讀取文本，隨後再透過多模態模型單獨檢視圖片以補充上下文。
• 避免幻覺 (Hallucination)：必須強制所有的 Wiki 更新都與 Raw Sources 綁定。Schema 應規定所有斷言都必須帶有特定來源的引用（如 (source: raw/article-xyz.md)）。

總結與結論

• 知識架構的典範轉移：將 LLM 的應用從「Stateless RAG (無狀態檢索)」推進到「Stateful Compilation (有狀態編譯)」，這大幅改變了知識沉澱的效率與深度。
• CQRS 架構的思想體現：系統將 Immutable 的 Raw Sources (Event Store) 與可變的 Wiki (Materialized View) 分離，這是經典的分散式系統設計，確保了系統的可追溯性與可重建性。
• 維護成本的自動化：此模式證明了 LLM 最強大的企業級應用場景之一，不是從零生成靈感，而是執行枯燥但需要語義理解的「記帳工作 (Bookkeeping)」，如更新連結與發現資料矛盾。
• Agentic IDE 的最佳實踐：人類只負責提供指令 (Schema) 和資料源 (Sources)，並透過版本控制 (Git) 進行審閱，這是人類與 AI Agent 協作最穩定的工作流範本。