OpenAI 創辦團队成員、Tesla 前 AI 總監 Andrej Karpathy 在 X 上发布「LLM 知识庫」工作流程、解釋他近期把大量 token 用量从「操控程式碼」转向「操控知识」—用 LLM 把分散的論文、文章、资料夾、影像、整理成一个自动維護的个人 wiki。整套流程已在他自己的研究專案上累積 ~100 篇文章、~40 万字、且全程由 LLM 寫入与更新。本文整理 Karpathy 的完整 setup、給想自己複製的开发者一張可实作清單。
核心理念：raw 资料 → LLM 編譯 → wiki → Q&A
Karpathy 的设计哲学可以濃縮成一句話：「raw data 进来、LLM 編譯成 wiki、wiki 再供 LLM 查詢、查詢結果继续寫回 wiki」。整个系统的关鍵是把人類的角色从「寫筆記」转成「監看 LLM 寫出的筆記」、knowledge base 不再是手动維護的 Notion 或 Roam Research、而是 LLM 自动寫入並維護的 markdown 檔案集合。
他描述自己很少直接編辑 wiki—寫入、補连結、抽取結構、檢查一致性、全是 LLM 做。这个「LLM 主導內容、人類監看」的模式、与多數人手动寫 Obsidian／Notion 的習慣完全不同、是这个工作流程的核心转變。
Step 1：Data Ingest—把所有 raw 资料丟进一个 raw/ 资料夾
Karpathy 的入口很簡單：建一个 raw/ 资料夾、把所有来源资料倒进去—論文 PDF、新聞文章、code repo、资料集、影像、講稿。LLM 会以这个资料夾为输入、逐步「編譯」出 wiki。
他特別提到两个工具：
Obsidian Web Clipper 擴充套件—把網頁文章直接转成 .md 檔放进 raw/
自訂 hotkey—把網頁的相关圖像下載到本地、让 LLM 能在后续引用时直接读
关鍵设计：所有外部资料以「离線、本地」形式存在、確保 LLM 后续查詢时不会卡在「找不到原始连結」的问題。
Step 2：LLM 編譯 wiki—自动产生分類、文章、反向连結
raw/ 资料就緒后、Karpathy 用 LLM 增量地（incrementally）「編譯」一个 wiki—就是一堆 .md 檔案組成的目錄結構。LLM 会做四件事：
对 raw/ 中所有资料寫摘要
把资料分類成概念（concepts）
为每个概念寫一篇文章
在文章之间建立反向连結（backlinks）
这个过程是「增量」的—新加入 raw/ 的资料、LLM 只更新受影響的 wiki 区塊、不必整个重編。对长期累積的研究主題（Karpathy 自己的研究 wiki 已经有 ~100 篇、40 万字規模）、这種增量更新比一次性大編譯实用得多。
Step 3：用 Obsidian 作为 IDE「前端」、Marp 等外掛擴充
Karpathy 用 Obsidian 作为这套系统的視覺化前端—可以同时看 raw/ 资料、編譯出的 wiki、与衍生的視覺化（slide、圖表）。Obsidian 的好處是它本身就是 markdown 編辑器、与 LLM 寫出的 .md 檔天然相容、且支援 plugin 擴充。
他特別提到 Marp 这个 plugin—可以把 markdown 直接渲染成投影片格式、让 LLM 不只能输出文字、还能输出簡报。
Step 4：Q&A—把整个 wiki 当 LLM 的查詢对象
Karpathy 的 wiki 进入「~100 篇文章、~40 万字」規模后、最有趣的能力浮现：可以对 LLM agent 提任意複雜的问題、它会自己跑去研究答案、引用 wiki 中的相关段落。
原本他预期需要用「fancy RAG」（向量檢索、嵌入模型、re-ranking 等）才能跑这个規模、但实測发现：LLM 自己会維護 index 檔与每篇文章的簡短摘要、查詢时靠这些 index 与摘要就能找到相关段落、在「~40 万字」这个尺度下、不必複雜的 RAG 也能跑得不错。
这个觀察与 2024 年以来「向量 DB 过熱、实际很多场景不必用」的产业共识一致—当你的 knowledge base 在百万字以下、structured markdown + LLM 自管 index 已足夠。
Step 5：输出—不是純文字、而是 markdown／slides／圖表
Karpathy 的另一个设计：他不要 LLM 只回 terminal 文字、而是让 LLM 产出有結構的输出—markdown 檔、Marp 簡报、matplotlib 圖、視覺化资料。这些输出在 Obsidian 內檢視。
更关鍵的是循環：产出的結果常常被 Karpathy 「歸檔」回 wiki、強化未来的查詢。他形容「自己的探索与查詢永远都在累加（add up）到 knowledge base」—这是 stateful、会长大的、与 ChatGPT 对話「每次都从零开始」的模式相反。
Step 6：Linting—LLM 自我健檢、找一致性问題与新文章候选
Karpathy 对 wiki 跑 LLM「健康檢查」、處理三類问題：
找出资料不一致（同一概念在不同篇章的描述衝突）
用網路搜尋補上缺失资料
找出有趣的跨概念连結、推薦新的文章候选
这个 linting pass 是让 wiki 随时间「越来越乾淨」的关鍵—沒有它、自动編譯出来的 wiki 会逐漸累積矛盾与雜訊。LLM 在这个任務上表现不错、是 Karpathy 认为这套工作流程可长期运行的原因之一。
Step 7：自製額外工具—例如自架 wiki 搜尋引擎
Karpathy 提到他「vibe coded」一个小型搜尋引擎、跑在自己的 wiki 上。这个工具有两个用法：（1）他自己直接用 web UI 查；（2）更常见的是把这个搜尋引擎透过 CLI 介面、丟給 LLM 当作工具、让 LLM 在大型查詢时能精準命中相关段落。
这个模式（人類搭一个 CLI、LLM 把它当工具用）、是 Claude Code、OpenAI Codex 这類 agent 框架下的核心设计—LLM 不直接读全部资料、而是透过工具（CLI、search engine、file system）取得需要的子集。
Step 8：未来方向—合成资料生成、模型微调
当 wiki 規模夠大、Karpathy 提出两个进階方向：
用 wiki 生成合成资料（synthetic data）—让 LLM 为某些主題自动产出 Q&A 配对、教学文、範例
用合成资料微调一个專屬 LLM—让你的个人 LLM「在權重中知道」这些资料、而不只是在 context window 中读
这个方向把 knowledge base 从「外部記憶」推进到「內化記憶」、是个人化 AI 的下一步。但 Karpathy 自己也承认这需要更多基礎建设、目前还是探索階段。
Karpathy 的「Idea File」想法：分享構想、不分享 code
該則貼文爆紅后、Karpathy 在后续貼文提出新概念「idea file」—在 LLM agent 时代、与其分享具體 code、不如分享「想法」、让对方的 agent 为他客製化、为他打造。
他把这套 LLM Knowledge Bases 的「idea file」放在一个 GitHub gist、刻意保持抽象、留空间給每个人的 agent 自由发揮。这可能是未来 dev community 的新分享模式—不是 GitHub repo、不是 npm 套件、而是「指令文件」、給 LLM 看的开源規格。
实作建议：台灣读者怎麼开始
对想複製这套系统的台灣开发者、实務上的入门路徑：
Obsidian 是免费软體、macOS／Windows／Linux 皆可、可从官網下載
Web Clipper 擴充套件可在 Chrome／Firefox／Edge 安裝
LLM 端可选 Claude Code（CLI）、ChatGPT（API）、或本地 Ollama（如果你有強顯卡）
raw/ 与 wiki/ 两个资料夾建议放 Obsidian vault 同層、且加入 .gitignore 之外的版本控制（万一 LLM 寫壞可以救回）
从一个你最熟悉的研究主題开始—例如「2026 加密交易所合規动態」「LLM 推論架構」、累積到 30–50 篇后 Q&A 能力会明顯改善
Karpathy 在貼文最后说：「这裡有打造一款厲害新产品的空间、不是现在这種粗糙腳本拼湊的形式。」对 builder 来说、这條 thread 既是工作流程说明、也是創业題材—LLM 自动 wiki、是个还沒有明確产品贏家的市场。
这篇文章 Karpathy 親揭：用 LLM 打造个人知识庫的完整方法 最早出现於 链新聞 ABMedia。
相关文章
