Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

LLM Wiki

一種使用 LLM 建立個人知識庫的模式。

這是一份構想文件，設計用來複製貼上給你自己的 LLM Agent（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。其目標是傳達整體概念，具體細節則由你的 Agent 與你協作完成。

核心概念

大多數人使用 LLM 處理文件的方式看起來像 RAG：你上傳一批檔案，LLM 在查詢時檢索相關片段，然後生成答案。這種方式可行，但 LLM 每次回答問題都是從頭重新發現知識，沒有任何累積。如果你提出一個需要綜合五份文件才能回答的微妙問題，LLM 每次都得重新找出並拼湊相關片段。什麼都沒有建立起來。NotebookLM、ChatGPT 檔案上傳，以及大多數 RAG 系統都是這樣運作的。

這裡的概念不同。與其在查詢時從原始文件中擷取，LLM 改為逐步建立並維護一個持久的 Wiki — 一套結構化、相互連結的 Markdown 檔案集合，位於你與原始來源之間。當你加入新的來源時，LLM 不只是將其索引供日後檢索，而是讀取它、提取關鍵資訊，並將其整合到現有的 Wiki 中 — 更新實體頁面、修訂主題摘要、記錄新資料與舊主張的矛盾之處，強化或挑戰持續演進的綜合分析。知識只需編譯一次，然後保持更新，而非每次查詢都重新推導。

這就是關鍵差異：**Wiki 是一個持久的、複利增長的產出物。**交叉引用已經存在。矛盾之處已被標記。綜合分析已經反映了你所讀過的一切。每加入一個新來源、每提出一個問題，Wiki 就會變得更豐富。

你幾乎不需要親自撰寫 Wiki — LLM 負責撰寫和維護所有內容。你的工作是尋找來源、進行探索、提出正確的問題。LLM 承擔所有繁瑣的工作 — 摘要、交叉引用、歸檔，以及讓知識庫真正有用的各種書務工作。實際上，我會在一側開啟 LLM agent，另一側開啟 Obsidian。LLM 根據我們的對話進行編輯，我即時瀏覽結果 — 跟隨連結、查看圖譜視圖、閱讀更新的頁面。Obsidian 是 IDE；LLM 是程式設計師；Wiki 是程式碼庫。

這可以應用在許多不同的情境中，以下是幾個例子：

  • 個人用途：追蹤自己的目標、健康、心理、自我成長 — 歸檔日記條目、文章、播客筆記，隨時間建立起對自己的結構化認識。
  • 研究：深入鑽研一個主題，歷時數週或數月 — 閱讀論文、文章、報告，逐步建立一個具有持續演進論點的完整 Wiki。
  • 閱讀一本書：邊讀邊歸檔每一章，為人物、主題、情節線索建立頁面，並呈現它們之間的關聯。讀完後你將擁有一個豐富的伴讀 Wiki。想想像托爾金閘道這樣的粉絲 Wiki — 數千個相互連結的頁面，涵蓋人物、地點、事件、語言，由一個社群的志願者歷經多年建立。你可以在閱讀時個人化地建立類似的東西，由 LLM 負責所有交叉引用和維護工作。
  • 商業/團隊：由 LLM 維護的內部 Wiki，由 Slack 討論串、會議記錄、專案文件、客戶電話提供內容。可能由人工在循環中審查更新。Wiki 能保持更新，因為 LLM 承擔了團隊中沒有人想做的維護工作。
  • 競爭分析、盡職調查、旅遊規劃、課程筆記、深度嗜好探索 — 任何你需要隨時間累積知識，並希望其有條理而非散落各處的情境。

架構

共有三個層次：

原始來源 — 你精選的來源文件集合。文章、論文、圖片、資料檔案。這些是不可變的 — LLM 從中讀取但從不修改。這是你的唯一真實資料來源。

Wiki — 一個由 LLM 生成的 Markdown 檔案目錄。摘要、實體頁面、概念頁面、比較、概覽、綜合分析。LLM 完全擁有這個層次。它創建頁面、在新來源加入時更新頁面、維護交叉引用，並保持一切一致。你閱讀；LLM 撰寫。

Schema — 一份文件（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告訴 LLM Wiki 的結構、慣例，以及在擷取來源、回答問題或維護 Wiki 時應遵循的工作流程。這是關鍵的配置檔案 — 它使 LLM 成為一個有紀律的 Wiki 維護者，而非一個通用聊天機器人。你和 LLM 會隨著時間共同演進這份文件，找出最適合你領域的方式。

操作流程

擷取（Ingest）。 你將新來源放入原始集合並告訴 LLM 處理它。範例流程：LLM 讀取來源，與你討論關鍵收穫，在 Wiki 中撰寫摘要頁面，更新索引，更新 Wiki 中相關的實體和概念頁面，並在日誌中追加一條記錄。單一來源可能會觸及 10-15 個 Wiki 頁面。就個人而言，我偏好一次擷取一個來源並保持參與 — 我閱讀摘要、檢查更新，並引導 LLM 強調什麼。但你也可以一次批量擷取多個來源，監督較少。由你來發展適合自己風格的工作流程，並將其記錄在 Schema 中供未來工作階段使用。

查詢（Query）。 你對 Wiki 提問。LLM 搜尋相關頁面、閱讀它們，並綜合整理出附有引用來源的答案。答案可以根據問題採取不同形式 — Markdown 頁面、比較表、投影片（Marp）、圖表（matplotlib）、畫布。重要的洞察：**好的答案可以作為新頁面歸檔回 Wiki 中。**你要求的比較、分析、發現的關聯 — 這些都是有價值的，不應消失在聊天記錄中。這樣你的探索就像擷取的來源一樣，在知識庫中持續複利增長。

整理（Lint）。 定期請 LLM 對 Wiki 進行健康檢查。尋找：頁面之間的矛盾、被較新來源取代的過時主張、沒有入站連結的孤立頁面、被提到但缺乏自己頁面的重要概念、缺少的交叉引用、可以通過網路搜尋填補的資料空缺。LLM 擅長建議需要調查的新問題和需要尋找的新來源。這使 Wiki 在成長過程中保持健康。

索引與日誌

兩個特殊檔案幫助 LLM（和你）在 Wiki 成長時進行導航。它們的用途各不相同：

index.md 以內容為導向。它是 Wiki 中所有內容的目錄 — 每個頁面列有連結、一行摘要，以及可選的元數據如日期或來源數量。按類別組織（實體、概念、來源等）。LLM 在每次擷取時更新它。回答查詢時，LLM 先讀取索引找到相關頁面，再深入其中。這在中等規模（約 100 個來源、約數百頁）下效果出奇地好，避免了對基於嵌入的 RAG 基礎設施的需求。

log.md 以時間為導向。它是一個只追加記錄的日誌，記錄發生了什麼以及何時發生 — 擷取、查詢、整理。一個實用技巧：如果每條記錄都以一致的前綴開頭（例如 ## [2026-04-02] ingest | Article Title），日誌就可以用簡單的 Unix 工具解析 — grep "^## \[" log.md | tail -5 會給你最後 5 條記錄。日誌為你提供 Wiki 演進的時間軸，並幫助 LLM 了解最近做了什麼。

可選：CLI 工具

在某個時間點，你可能想建立小型工具來幫助 LLM 更有效率地操作 Wiki。對 Wiki 頁面的搜尋引擎是最明顯的 — 在小規模時索引檔案就足夠了，但隨著 Wiki 成長，你會需要合適的搜尋功能。qmd 是一個好選擇：它是一個用於 Markdown 檔案的本地搜尋引擎，具有混合 BM25/向量搜尋和 LLM 重新排序功能，完全在設備上運行。它同時提供 CLI（讓 LLM 可以呼叫它）和 MCP 伺服器（讓 LLM 可以將其作為原生工具使用）。你也可以自己建立更簡單的東西 — 在需要時 LLM 可以幫你快速撰寫一個簡單的搜尋腳本。

技巧與竅門

  • Obsidian Web Clipper 是一個將網頁文章轉換為 Markdown 的瀏覽器擴充功能。對於快速將來源加入你的原始集合非常有用。
  • 在本地下載圖片。 在 Obsidian 設定 → 檔案與連結中，將「附件資料夾路徑」設為固定目錄（例如 raw/assets/）。然後在設定 → 快捷鍵中，搜尋「Download」找到「Download attachments for current file」並將其綁定到快捷鍵（例如 Ctrl+Shift+D）。擷取文章後，按下快捷鍵，所有圖片就會下載到本地硬碟。這是可選的但很有用 — 它讓 LLM 可以直接查看和引用圖片，而不是依賴可能失效的 URL。注意 LLM 無法在一次處理中原生讀取含有行內圖片的 Markdown — 解決方法是讓 LLM 先讀取文字，然後分別查看部分或全部被引用的圖片以獲取額外的上下文。這有點笨拙，但效果足夠好。
  • Obsidian 的圖譜視圖是查看 Wiki 形狀的最佳方式 — 什麼與什麼相連，哪些頁面是樞紐，哪些是孤立的。
  • Marp 是一種基於 Markdown 的投影片格式。Obsidian 有它的插件。適合直接從 Wiki 內容生成簡報。
  • Dataview 是一個對頁面 frontmatter 執行查詢的 Obsidian 插件。如果你的 LLM 在 Wiki 頁面中加入 YAML frontmatter（標籤、日期、來源數量），Dataview 可以生成動態表格和列表。
  • Wiki 就是一個 Markdown 檔案的 git 倉庫。版本歷史、分支和協作都是免費附送的。

為什麼這個方法有效

維護知識庫最繁瑣的部分不是閱讀或思考 — 而是書務工作。更新交叉引用、保持摘要的時效性、記錄新資料何時與舊主張相矛盾、在數十個頁面上維持一致性。人類放棄 Wiki 是因為維護負擔的增長速度超過了其價值。LLM 不會感到無聊，不會忘記更新交叉引用，而且可以在一次處理中觸及 15 個檔案。Wiki 能持續維護，因為維護的成本幾乎為零。

人的工作是整理來源、指導分析、提出好問題，以及思考這一切意味著什麼。LLM 的工作是其他一切。

這個想法在精神上與 Vannevar Bush 的 Memex（1945 年）相關 — 一個具有文件間聯想路徑的個人精選知識庫。Bush 的願景比網路所演變成的樣子更接近這個概念：私人的、積極策劃的，文件之間的連結與文件本身同等重要。他無法解決的部分是誰來做維護工作。LLM 解決了這個問題。

備注

本文件刻意保持抽象。它描述的是概念，而非具體的實作。確切的目錄結構、Schema 慣例、頁面格式、工具 — 所有這些都取決於你的領域、你的偏好以及你選擇的 LLM。上面提到的一切都是可選的和模組化的 — 選取有用的，忽略不適用的。例如：你的來源可能只有文字，所以你根本不需要圖片處理。你的 Wiki 可能足夠小，只需要索引檔案，不需要搜尋引擎。你可能不在乎投影片，只想要 Markdown 頁面。你可能想要一套完全不同的輸出格式。正確的使用方式是將本文件分享給你的 LLM agent，共同合作實例化一個適合你需求的版本。本文件唯一的工作是傳達這個模式。你的 LLM 能搞定其餘的部分。