什麼是 LLM 維基？解析 Karpathy 的模式

這個構想從何而來

2026 年 4 月 4 日，OpenAI 共同創辦人、前 Tesla AI 負責人 Andrej Karpathy 發布了一份名為 llm-wiki.md 的簡短 gist。它不是工具，也不是程式碼儲存庫，而是一份構想文件，目的是交給你自己的 LLM 代理（Claude Code、Codex 等），再由代理和你一起擬定具體的實作方式。短短幾個月內，它就累積了超過 5,000 顆星，催生了社群實作，也讓「LLM 維基」成為人們主動搜尋的詞彙。

這份 gist 用一句話說明核心概念：「Obsidian 是整合開發環境；LLM 是程式設計師；維基是程式碼庫」——你仍然負責選擇來源、提出問題，所有撰寫、歸檔與交叉參照工作則交給 LLM。

LLM 維基與 RAG：編譯一次，還是不斷檢索

多數結合 AI 與文件的產品採用 RAG（檢索增強生成）：你上傳檔案，模型在你提問時擷取相關片段，再即時組織出答案。這確實可行，但每個問題都得從零開始。查詢之間不會累積任何成果。

LLM 維基把這個流程反過來。新來源一加入，LLM 就會立即閱讀、擷取重點，並整合進既有的頁面網絡：更新實體頁面、修訂摘要，並標記與先前資料的矛盾。知識只需編譯一次，之後持續更新，因此每次回答都以已整合的全貌為起點，而不是從原始片段開始。

三層架構

這份 gist 的架構刻意保持精簡：

1. 原始來源——文章、論文、逐字稿、資料檔案。保持不變；LLM 只讀取，絕不編輯。
2. 維基——由 LLM 產生、彼此連結的頁面：摘要、實體頁面、概念頁面、比較頁面。這一層完全由 LLM 負責；你只管閱讀。
3. 結構規範——一份規範檔案（CLAUDE.md、AGENTS.md），告訴代理維基的結構，以及匯入、回答與維護時該遵循的方式。正是這一層，讓通用聊天機器人成為有條有理的圖書館員。

日常運作中，維基依靠三項操作：匯入（放入來源，由 LLM 整合；單篇文章就可能涉及 10–15 個頁面）、查詢（提出問題；好答案會以新頁面形式歸檔回維基），以及檢查（定期健檢，找出矛盾、過時的說法，以及沒有任何連結指向的孤立頁面）。

LLM 維基、第二大腦與知識庫的差別

這些詞彙的意義有所重疊，搜尋結果也經常混用。最清楚的區分方式如下：

最後一欄就是關鍵。人們放棄維基和第二大腦，是因為整理維護的工作——更新交叉參照、釐清舊說法與新來源之間的出入——增加得比帶來的價值還快。LLM 不會覺得無聊，因此在手動系統悄悄荒廢之處，這種模式卻能持續運作。

如何建立 LLM 維基

依照你目前存放知識的地方，有三條實用路線：

• Markdown 檔案 + Obsidian——Karpathy 原本的配置。一個來源資料夾、一個維基頁面資料夾、一份記載規範的 CLAUDE.md，以及終端機中的代理。Obsidian 的網頁擷取工具負責匯入文章；圖譜檢視則呈現維基逐漸成長的樣貌。
• Notion + MCP——如果你的筆記與資料庫已經放在 Notion，就不必搬移任何內容：透過 Notion 的 MCP 伺服器連接代理，讓它直接讀寫頁面。我們在〈Notion 的 LLM 維基：Claude 第二大腦 + 3D 知識圖譜〉中完整記錄了這個流程。
• 團隊維基——同樣的循環流程，以會議逐字稿、文件與聊天討論串為來源，再由人員審核更新。維基能持續保持最新，是因為 LLM 接手了團隊中沒人想做的維護工作。

知識圖譜如何融入其中

維基的內容是文字，但它的結構是一張圖譜：頁面是節點，連結是邊。Karpathy 的 gist 本身就推薦圖譜檢視，認為這是看清持續成長的維基樣貌的最佳方式：哪些頁面成了樞紐、哪些是孤立頁面、群集在哪裡形成。檢查操作其實就是圖譜健檢。

當你的 LLM 維基放在 Notion 中，這點就更重要，因為 Notion 沒有內建圖譜檢視。IVGraph 補上了這個缺口：它將你的工作空間——每個頁面、反向連結與資料庫關聯——呈現為互動式 3D 知識圖譜，讓你親眼看見 LLM 建立的維基逐漸成形。代理也能透過 IVGraph LLM API，以程式方式查詢同一套結構。

常見問題