LLM-Wiki實戰演練

LLM-Wiki實戰演練

個人頭像 Wayne,

你有過這種經驗嗎？為了研究一個主題，電腦分頁開了幾十個，筆記軟體裡塞滿了剪輯下來的文章，但當你要寫報告或做決策時，卻發現自己溺死在資料海裡，根本不知道從何找起。

==後續更新==
怎麼開始？
最快的方式就是把LLM-wiki.md直接丟給語言模型理解即可，他閱讀之後會依照內容來建立目錄結構，只不過「務必」要自己再修正
使用的過程當中可以不斷調整既有的prompt，讓結果趨近自己想要的結果

最近 OpenAI 的共同創辦人 Andrej Karpathy 提出了一個超酷的概念叫做 LLM-wiki。簡單來說，它不是讓你「存」資料，而是讓 AI 幫你「理」資料。我最近親自下場實作了一番，發現這玩意兒真的很有潛力，但也藏了不少坑

什麼是 LLM-wiki？為什麼我們需要它？

過去我們做筆記，就像是在堆積木，一塊一塊疊上去，但積木之間沒什麼關聯。LLM-wiki 的核心邏輯則是把同一個主題的所有資料通通丟進去，讓 AI 擔任你的「超級圖書館管理員」。

這位管理員不只是幫你把書放好，他還會：

  • 自動抓重點：一眼看出每份文件的關鍵訊息。
  • 建立關聯網：告訴你 A 文件跟 B 文件其實在講同一件事。
  • 隨問隨答：你可以直接問它：「幫我比較這三篇論文的觀點差異」，它會立刻生出一份統整表格給你。

如果你想靠人力完成這種規模的統整，那真的是工程浩大，資料一多就容易迷失方向。

工具怎麼選？我的「平替版」實作方案

Karpathy 在他的 GitHub 上分享了原始碼，那是 LLM-wiki 的基礎框架。雖然他推薦用 Claude，但說實話，Claude 的 API 費用對個人玩家來說真的有點傷荷包。

在經過一番測試後，我最後選擇了 VSCode + Roo Code 的組合：

  1. 省錢又彈性：它可以串接多個不同的 API 提供商（像是 OpenRouter 等），有很多免費或低成本的選項。
  2. 模型隨你換：同等級的模型，表現可能大不同。例如我在測試時發現，GLM-5.1 的聯想力竟然比 Gemini 3.1 Pro 還要出色，這在建立知識關聯時非常有用。

理想很豐滿，現實很骨感：實作中的 3 個大挑戰

雖然概念很美好，但在實作過程中，我發現 AI 還是有它的脾氣：

1. 它是個「吃代幣」怪獸

LLM-wiki 非常耗費上下文（Context Window）的 Token。因為 AI 需要同時讀取大量資料才能進行比對，如果你的資料量太大，API 帳單可能會讓你心驚肉跳。
這點出另一個問題，就是這個自建的圖書館，會因為內容文件數量增加而影響到處理的效率，建議建立圖書館的時候，要管控文件的數量，最好可以緊扣主題，內容不要太過發散。

2. 「思考型」模型才是正解

我嘗試過用那種速度很快、價格便宜的「Flash」型模型，結果慘不忍睹。處理這種深度統整的工作，必須選擇具備思考能力（Reasoning）的模型。雖然處理起來很慢，但輸出的質量才有參考價值。
這些品質好的模型，很難找到免費的資源，必要的時候還是得花點錢才可以解決

3. AI 的理解跟你想的不一樣

這是我遇到最頭痛的問題。舉例來說，當我想整理「占星資料」時，我希望 AI 把資料按照「時運太陽」來分類，結果它卻自作主張把資料散落在各個「本命行星」下。這代表即便 AI 很聰明，我們還是得透過更精準的 Prompt（提示詞） 來規範它的輸出格式。

4. 輸出格式與內容不穩定

雖然已經用了品質比較好的模型，但仍會有輸出格式不穩定的問題，如果是細節控的人可能會感到困擾。

給想嘗試 LLM-wiki 的你：3 個實戰建議

如果你也想開始建構自己的 AI 知識庫，這裡有幾個血淚建議：

  • 不要一次塞太多：把 Raw Data 像倒垃圾一樣一次丟進去，AI 只會當機或亂寫。建議分批次、小量處理，效果更好。
  • 摘要先行，統整在後：只要來源資料（如逐字稿）品質夠好，AI 生出的摘要通常很準確。先讓它做好各別摘要，再來做整體的關聯分析。
  • 嚴格規範格式：如果你的輸出格式不穩定，後續在 WordPress 或其他平台使用時會非常痛苦。記得在 Prompt 裡強調你要的標題層級與清單格式。

結論：

即便有諸多小問題，但整體使用起來我還是很滿意
只要找到適當的模型，加上要有耐心把prompt調整到自己想要的樣子
整理出來的資料應該都可以讓人滿意
唯一要擔心的就是當圖書館掌到一定程度之後，所需要耗費的token資源了

附上LLM-wiki的翻譯版說明

LLM Wiki 個人知識庫建構模式
使用大型語言模型（LLM）建構個人知識庫的模式。
這是一份概念文件，設計用於複製到您自己的 LLM Agent（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目標是傳達高層次的概念，而您的 Agent 會與您協作建立具體細節。

核心概念
大多數人與 LLM 和文件的互動體驗是這樣的 RAG（檢索增強生成）：您上傳一堆檔案，LLM 在查詢時檢索相關片段，然後生成答案。這種方式有效，但 LLM 每次回答問題時都要從頭開始重新發現知識。沒有累積。當您問一個需要綜合五份文件才能回答的細節問題時，LLM 每次都必須找到並拼湊相關的片段。沒有任何東西是被建立起來的。NotebookLM、ChatGPT 檔案上傳和大多的 RAG 系統都是這樣運作的。

這裡的想法不同。不只是在查詢時從原始文件檢索，LLM 增量地建立和維護一個持久的維基——一個結構化、互相連結的 Markdown 檔案集合，位於您和原始來源之間。當您新增一個來源時，LLM 不只是為後續檢索而索引它。它會閱讀它、提取關鍵資訊，並將其整合到現有的維基中——更新實體頁面、修訂主題摘要、註記新資料與舊聲明矛盾的地方、加強或挑戰不斷演進的綜合論述。知識被編譯一次，然後保持最新，而不是每次查詢時重新衍生。

這是關鍵差異：維基是一個持續累積的構作物。 交叉引用已經存在。矛盾已經被標記。綜合論述已經反映了您所閱讀的一切。隨著您新增的每個來源和每個問題，維基變得越來越豐富。

您幾乎不需要自己寫維基——LLM 會撰寫和維護所有內容。您負責來源收集、探索和提出正確的問題。LLM 做所有的辛苦工作——摘要、交叉引用、歸檔和簿記，使知識庫隨著時間推移真正有用。在實務上，我會將 LLM Agent 開在一側，Obsidian 開在另一側。LLM 根據我們的對話進行編輯，我即時瀏覽結果——追蹤連結、查看圖形視圖、閱讀更新的頁面。Obsidian 是 IDE；LLM 是程式設計師；維基是程式碼庫。

這可以應用於許多不同的情境。以下是一些範例：
- 個人用途：追蹤自己的目標、健康、心理學、自我提升——歸檔日誌条目、文章、播客筆記，並隨著時間建立自己的結構化圖像。
- 研究：在數週或數月內深入一個主題——閱讀論文、文章、報告，並逐步建立一個具有演進論點的綜合維基。
- 閱讀書籍：隨著閱讀每個章節進行歸檔，為角色、主題、情節線條及其關聯建立頁面。閱讀完後，您會擁有一個豐富的伴讀維基。想想粉絲維基如 [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page)——數千個互相連結的頁面，涵蓋角色、地點、事件、語言，由志願者社群多年建立。您可以在個人閱讀時建立類似的東西，由 LLM 完成所有交叉引用和維護工作。
- 商業/團隊：由 LLM 維護的內部維基，餵入 Slack 討論串、會議記錄、專案文件、客戶電話。可能有人類在迴圈中審查更新。維基保持最新，因為 LLM 做了團隊中沒有人想要做的維護工作。
- **競爭分析、盡職調查、旅遊規劃、課程筆記、嗜好深入研究**——任何需要隨時間累積知識並希望其有組織而非分散的情境。

架構
有三個層次：
原始來源 — 您策劃的來源文件集合。文章、論文、圖像、資料檔案。這些是不可變的——LLM 從中讀取但從不修改。這是您的真理來源。

維基 — 由 LLM 生成的 Markdown 檔案目錄。摘要、實體頁面、概念頁面、比較、總覽、綜合論述。LLM 完全擁有這層。它建立頁面、當新來源到來時更新它們、維護交叉引用並保持一切一致。您閱讀它；LLM 撰寫它。

結構定義（Schema） — 一份文件（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告訴 LLM 維基的結構是什麼、慣例是什麼，以及在攝取來源、回答問題或維護維基時要遵循什麼工作流程。這是關鍵的設定檔——它使 LLM 成為一個有紀律的維基維護者，而不是一個通用聊天機器人。您和 LLM 隨著時間共同演化這個檔案，因為您會弄清楚什麼適用於您的領域。

操作
攝取（Ingest）。您將新來源放入原始集合中，並告訴 LLM 處理它。一個範例流程：LLM 閱讀來源、與您討論要點、在維基中撰寫摘要頁面、更新索引、更新維基中相關的實體和概念頁面，並在日誌中附加条目。單一來源可能會觸及 10-15 個維基頁面。就個人而言，我偏好一次攝取一個來源並保持參與——我閱讀摘要、檢查更新，並引導 LLM 強調什麼。但您也可以批量攝取多個來源並減少監督。這取決於您開發適合您風格的工作流程並將其記錄在結構定義中供未來工作階段使用。

查詢（Query）。您針對維基提出問題。LLM 搜尋相關頁面、閱讀它們，並綜合引用答案。答案可以根據問題有不同的形式——Markdown 頁面、比較表格、簡報（Marp）、圖表（matplotlib）、畫布。重要的見解：好的答案可以作為新頁面歸檔回維基。您要求的比較、分析、您發現的關聯——這些是有價值的，不應該消失在聊天歷史中。這樣您的探索就像攝取的來源一樣在知識庫中累積。

整理（Lint）。定期要求 LLM 對維基進行健康檢查。尋找：頁面之間的矛盾、被新來源取代的過時聲明、沒有入站連結的孤立頁面、被提及但缺乏自己頁面的重要概念、缺失的交叉引用、可以通過網路搜尋填補的資料缺口。LLM 善於建議要調查的新問題和要尋找的新來源。這樣維基在成長過程中保持健康。

索引和日誌
兩個特殊檔案幫助 LLM（和您）在維基成長時導航。它們服務不同的目的：

index.md：是面向內容的。它是維基中所有內容的目錄——每個頁面列出並附帶連結、一行摘要，以及可選的中繼資料如日期或來源數量。按類別組織（實體、概念、來源等）。LLM 在每次攝取時更新它。當回答查詢時，LLM 首先閱讀索引以找到相關頁面，然後深入閱讀它們。這在中等規模（~100 個來源、~數百個頁面）下出奇地有效，避免了對基於嵌入的 RAG 基礎設施的需求。

log.md：是按時間順序的。它是發生的事情和時間的append-only 記錄——攝取、查詢、整理通過。一個有用的提示：如果每個条目以一致的前綴開頭（例如 `## [2026-04-02] ingest | 文章標題`），日誌就可以用簡單的 unix 工具解析——`grep "^## \[" log.md | tail -5` 給您最後 5 個條目。日誌給您維基演進的時間線，並幫助 LLM 理解最近做了什麼。
小知識