LLM Wiki 模式

這個模式從哪來：Karpathy 的 LLM Wiki

以下是 Andrej Karpathy 原文（gist）的摘譯；WikiBrain 的介面就照這個模式做。

核心想法

多數人用 LLM 讀文件的方式是 RAG：上傳一堆檔案，提問時 LLM 撈出相關片段來回答。能用，但每次提問都在從頭重新發現知識，什麼都沒累積。LLM Wiki 的做法不同：LLM 逐步建立並維護一座持久的 wiki，坐在你和原始來源之間。每加一份來源，LLM 不只索引它，而是讀完、抽出重點、整合進既有的 wiki：更新實體頁、修訂主題摘要、標記新資料與舊說法的矛盾。知識編譯一次，之後持續維護。你幾乎不自己寫 wiki，LLM 寫；你負責找來源、探索、問對的問題。

適用情境：研究（數週到數月的深讀，累積文獻綜述）、專案管理（會議紀錄與決策的追蹤）、讀一本書（人物、主題、情節線）、個人（目標、健康、日記）、團隊內部 wiki、競品分析、課程筆記。

三層架構

• 原始來源 raw/：你策展的來源集合，不可變，LLM 只讀不改。
• wiki/：LLM 生成的 Markdown 頁面。這一層完全由 LLM 擁有：建頁、更新、維護交叉引用。你讀，LLM 寫。
• schema/：告訴 LLM「wiki 怎麼組織、慣例是什麼、該走什麼流程」的文件（如果你用過 Cursor 的規則檔，就是那個角色）。你和 LLM 一起隨時間演化它。

三個操作是編纂（Ingest）、對話（Query）、健檢（Lint），兩個特殊頁是 index.md 與 log.md；見使用指南。Obsidian 的圖譜、Dataview 資料表、Marp 投影片、把圖片下載到本地、wiki 就是一個 git repo，這些 Karpathy 提到的技巧在 WikiBrain 裡分別對應圖譜、資料表、投影片頁、圖片附件與版本快照加匯出。

為什麼有效

維護知識庫最累的不是讀和想，是簿記：更新交叉引用、讓摘要跟上、標記矛盾、跨幾十頁保持一致。人放棄 wiki 是因為維護成本長得比價值快。LLM 不會無聊、不會忘記更新交叉引用、一次可以動十幾頁；維護成本趨近於零，wiki 就能一直維護下去。人的工作是策展來源、引導分析、問好問題、思考這一切的意義；其餘交給 LLM。