前 OpenAI 聯合創始人 Andrej Karpathy 最近在 X 上丟了一顆炸彈——他說他已經不怎麼用 AI 寫程式了。
那他在幹嘛？他用 LLM 養了一個會自己長大的知識庫。一個主題就長到了 100 篇文章、40 萬字。不是他自己打的，是 AI 幫他讀完素材後自動產出、自動更新、自動整理的。
這條推文在一週內衝到了 1,600 萬次觀看。他隨手貼出的 GitHub Gist 幾天內拿了 5,000+ stars。整個開源社群跟著炸開，一週內冒出七個以上的開源實作專案。
為什麼這麼誇張？因為 Karpathy 碰到的痛點，基本上每個知識工作者都有：你收藏了一堆文章、筆記散落在五個 App、PDF 下載完就再也沒打開過。你知道你「有」這些知識，但你找不到、用不上。
他的解法叫做 LLM Wiki。不是又一個筆記 App，而是一套讓 AI 幫你當圖書館員的工作流程。這篇文章拆解它的運作原理，然後教你用 Claude Code 三步驟複製一個自己的版本。
LLM Wiki 是什麼？一句話講完
你丟素材進去，AI 幫你讀完、整理成一套互相連結的 Markdown 知識庫，然後持續維護它。
聽起來像 RAG（Retrieval-Augmented Generation）？不一樣。RAG 是每次問問題才去翻一遍原始文件。LLM Wiki 是 AI 事先把所有素材消化完，寫成結構化的 wiki 頁面，知識是「累積」的，不是每次重新推導的。
Karpathy 自己的比喻：RAG 像是每次考試都重新讀課本，LLM Wiki 像是有人幫你做好了讀書筆記，而且這個人會在你加新資料的時候自動更新所有相關的筆記。
三層架構：Raw → Wiki → Schema
整個系統只有三層，簡單到有點不像話：
第一層：Raw（原始素材）
你的研究論文、網頁文章、PDF、截圖，全部丟進 raw/ 資料夾。這一層是「不可變」的——AI 只讀不改。你放什麼進去，它就永遠在那裡。Karpathy 用 Obsidian Web Clipper 把網頁一鍵轉成 Markdown 檔存進去。
第二層：Wiki（知識庫）
這是 AI 的主場。它讀完你的素材後，自動產出摘要頁、概念頁、實體頁、綜合分析頁。每個頁面之間有交叉連結，就像一個迷你版的維基百科——但內容全是你的研究領域。
第三層：Schema（規則檔）
一個 CLAUDE.md（或類似的設定檔），告訴 AI 這個 wiki 的結構規範、命名慣例、工作流程。相當於給你的 AI 圖書館員一本員工手冊。
三個核心操作：Ingest、Query、Lint
LLM Wiki 的日常運作就三件事：
Ingest（吸收）——你丟一篇新文章進 raw/，AI 會讀完它、提取關鍵資訊、寫一篇摘要頁、更新索引，然後回頭刷新所有相關的概念頁和實體頁。不是只做個摘要就了事，是把新知識織進整個知識網裡。
Query（查詢）——你問問題，AI 搜相關頁面、綜合出答案、附上引用來源。如果你的提問本身有價值（比如問出了一個跨領域的洞察），AI 還會把這次查詢的結果寫回 wiki 變成新頁面。
Lint（健康檢查）——定期讓 AI 掃一遍整個 wiki，找矛盾的資訊、過時的數據、孤立的頁面、缺少的交叉引用。Karpathy 形容這是「一個會自我修復的活知識庫」。
三步驟用 Claude Code 複製一個
講了這麼多原理，來動手。截至 2026 年 4 月，最簡單的實作路徑是 Obsidian + Claude Code。
步驟一：建好資料夾結構
wiki/
├── raw/ # 你的原始素材（AI 只讀不改）
├── wiki/ # AI 產出的知識頁面
├── _templates/ # 頁面模板
├── index.md # 自動維護的目錄
├── log.md # 操作日誌
└── CLAUDE.md # Schema 規則檔用 Obsidian 開一個新 Vault 指向這個資料夾。Obsidian 只是你的瀏覽器，真正幹活的是 Claude Code。
步驟二：寫好 CLAUDE.md 規則檔
這是整個系統的靈魂。你要在裡面定義：wiki 的主題範圍、頁面命名規則、摘要格式（每頁開頭一句話描述）、標籤系統、以及 Ingest / Query / Lint 三個操作的具體流程。
Karpathy 的原版 Gist 已經寫好了一份完整的範本（GitHub Gist 連結），直接複製貼上再根據你的需求改就行。
步驟三：開始丟素材，讓 AI 幹活
# 安裝 Claude Code（如果還沒裝）
npm install -g @anthropic-ai/claude-code
# 進入你的 wiki 資料夾
cd ~/wiki
# 啟動 Claude Code
claude然後對 Claude 說：「請讀取 raw/ 資料夾裡的所有檔案，根據 CLAUDE.md 的規則建構 wiki。」它就會開始工作了——讀素材、寫摘要、建概念頁、拉交叉連結。
之後每次你加新素材到 raw/，只要跟 Claude 說「ingest 新檔案」，它就會把新知識整合進現有的 wiki 裡。想做健康檢查？跟它說「lint」。
為什麼不用 RAG 就好？
這是我看到最多人問的問題。答案很直接：RAG 是無狀態的，LLM Wiki 是有狀態的。
RAG 每次查詢都是獨立事件。你問了一個關於「BTC 減半對礦工的影響」的問題，得到答案後，系統不會記住這件事。下次你問相關問題，它又要重新搜索、重新推導。知識不會複利。
LLM Wiki 不一樣。你 ingest 了一篇關於 BTC 減半的報告，AI 不只做了摘要——它還去更新了「挖礦成本」頁面、「算力分佈」頁面、「減半歷史」頁面。下次你再加一篇新的礦工報告進去，AI 已經有了之前的脈絡，能做出更深的綜合分析。
另一個關鍵差異：可追溯性。RAG 用向量嵌入（vector embedding）存知識，你看不到 AI 的「腦子」裡裝了什麼。LLM Wiki 用的是純 Markdown 文字檔，每一條知識都可以追溯到具體哪個檔案、哪一段。你能讀、能改、能刪。透明到不行。
開源生態已經炸開了
Karpathy 4 月 4 日貼出 Gist 之後，開源社群的反應速度快得離譜。四天之內冒出了至少七個主要的開源實作：
| 專案 | 特色 | Stars |
|---|---|---|
| llmwiki | 上傳文件 + MCP 連接 Claude，最簡單的入門方案 | — |
| nvk/llm-wiki | 多 Agent 平行研究 + 論文驅動調查 | — |
| second-brain | Obsidian 原生，丟素材進去直接用圖形視圖瀏覽 | — |
| karpathy-llm-wiki | 兼容 Claude Code / Cursor / Codex 的 Agent Skills | 230+ |
| OmegaWiki | 完整研究平台，全生命週期管理 | — |
這還不包括在 Karpathy 模式上做延伸的 v2 版本——有人加了多 Agent 並行、有人加了知識圖譜、有人做了安全性和身份驗證的企業級擴展。
如果你不想從零開始，直接 clone 上面任何一個專案，10 分鐘內就能跑起來。
我自己的看法
用了兩週之後說幾句實話。
LLM Wiki 解決的問題是真的。知識管理最煩的從來不是閱讀和思考，而是那些瑣碎的整理工作——分類、歸檔、建連結、定期更新。這些事情佔了維護知識庫 80% 的時間，但產出 0% 的洞察。讓 AI 來做這些，是目前為止我看到最合理的 AI 使用方式之一。
但也有幾個坑要先知道：
第一，成本。每次 ingest 和 lint 都要消耗大量 token。如果你的知識庫長到幾百篇文章，一次完整的 lint 可能要跑好幾塊美金。這不是免費午餐。
第二，AI 會出錯。它偶爾會把兩篇不相關的文章硬扯在一起，或者在摘要中遺漏重要細節。你不能完全放手不管，定期抽查還是必要的。
第三，Schema 設計很關鍵。CLAUDE.md 寫得好不好，直接決定了整個 wiki 的品質。花時間把規則檔寫清楚，比後面修一堆亂七八糟的頁面划算得多。
整體來說，如果你是研究者、內容創作者、或任何需要長期追蹤某個領域的人，LLM Wiki 值得試。它不會取代你的思考，但會讓你的思考有個乾淨、可搜索、會自動更新的基礎。
接下來關注什麼
這個模式才剛開始。幾個值得追蹤的方向：
多 Agent 協作——現在是一個 AI 維護整個 wiki，未來可能是多個專業 Agent 各管一個領域，再由一個「編輯長」Agent 負責跨領域整合。已經有人在做了。
跟既有工具整合——Notion、Google Docs、Logseq 這些筆記工具的 LLM Wiki 適配器會越來越多。不一定要用 Obsidian。
團隊版——目前 LLM Wiki 基本是單人使用。多人協作的版本（權限控制、衝突解決、版本歷史）是遲早的事。
Karpathy 在他的 Gist 裡也留了一句話，我覺得是整件事最精準的總結：「維護知識庫最繁瑣的部分從來不是閱讀或思考——是記帳。而記帳正好是 LLM 最擅長的事。」
免責聲明：本文內容僅供教育和資訊用途，不構成任何投資建議。AI 工具和開源專案的功能、定價隨時可能變動，請以官方最新資訊為準。截至 2026 年 4 月。
發表迴響