EP-80｜LLM Wiki：讓 AI 把資料變成第二顆大腦
Karpathy 的 LLM Wiki：讓 AI 先讀完素材、整理成會持續累積的知識庫，三步就能裝在自己的資料夾。
前言
平常你怎麼在處理眾多的資料？
如果你有一大堆會議紀錄、程式碼、專案報告等等，你要怎麼樣整理這些資料，才能夠更快的提取、彙整資訊？
我過去使用的方式，其實都只是單純地讓 Claude Code 或者是 Codex 去閱讀我電腦上的文件，由我指定文件內容後，再讓它產出我要的資訊。
當然這樣做其實已經很好用，可是如果文件越來越多的話，自己在整理上也是需要花很多的腦力。
這禮拜在網路上有許多人都提到了 OpenAI 共同創辦人 Andrej Karpathy 的 LLM Wiki 概念。
根據 Karpathy 的說法，採用 LLM Wiki 的話，應該就能解決上述的問題。
讓我們來看看怎麼做。
在你的電腦建立 LLM Wiki
Andrej Karpathy 最近公開一份筆記，提出一個跟主流完全相反的 AI 讀文件方法。
他說大多數人用的是檢索增強生成（RAG，Retrieval-Augmented Generation）：你把一堆檔案丟上去，每次提問，AI 才臨時去翻出相關片段、拼一個答案。
問題是，大型語言模型本身是沒有任何記憶的。
所以 AI 每次都從零開始去查找你的資料，知識永遠不會累積。無論它怎麼樣幫你整理知識脈絡，你換一個對話（Session）之後，全部都要重新開始。
Karpathy 的做法是反過來，不要每次查才翻原稿，而是讓 AI 先把素材全部讀完，整理成一個會長大的知識庫（Wiki）。
這個知識庫是一疊互相連結的 Markdown 檔案，夾在你跟原始素材中間。
平常你就是把專案相關的素材丟進去。
讓 AI 讀完資料、抓重點、整合進現有頁面，順手更新相關條目、標出跟舊資料衝突的地方。
你收集的知識只需要整理一次，之後就會一直保持最新的狀態，所以不必每次問問題時都還要再重新整理一遍。
如何設定 LLM Wiki？
在設定 LLM Wiki 之前，你需要兩大工具：
AI Agent：無論你是使用 Claude Code、Codex、OpenCode、Hermes Agent 或 OpenClaw 都可以
可閱讀 Markdown 格式的軟體：Antigravity IDE、VS Code、Obsidian 都行。如果你不是工程師的話，建議你使用 Obsidian
接下來就是將 Karpathy 那份筆記資料丟給 AI Agent，讓他閱讀。
因此步驟只需要 3 個：
第一步，把筆記網址丟給 AI。
在你想放知識庫的那個資料夾裡，打開 Claude Code 或 Codex，把 Karpathy 的筆記網址（或整份內容）貼給它，叫它讀過一遍。
指令可以這樣下：「請先讀這份筆記 gist.github.com/karpathy/442a6bf555914893e9891c11519de94f ，讀完跟我說你理解到的重點。」
第二步，讓 AI 讀完，跟你對一次重點。
這份筆記是觀念說明、不是安裝腳本，所以先讓 AI 消化過，確認它抓到了「三層架構」跟「三個操作」，再往下執行。
記得一定要讓 AI 跟你對齊想法。當你確認它理解了 LLM Wiki 的概念之後，才開始讓它執行，因為你有可能需要根據你的專案狀況做部分的微調。
第三步，叫 AI 照著裝在這個資料夾。
確認它讀懂了，就請它動手：「照這份筆記的做法，在這個資料夾幫我建一套 LLM Wiki，用途是整理我的會議紀錄。」（把用途換成你自己的，例如產業研究、讀書筆記、客戶資料。）
AI 就會幫你把整個骨架建出來，你不用自己開任何資料夾或檔案。
骨架則分為三層：
第一層是原始素材（Raw Sources），例如你蒐集的文章、論文、逐字稿、圖片，AI 只准讀、不准改，當作唯一的真實來源。
第二層是知識庫（Wiki），AI 自己生成與維護的 Markdown 文件，裡面有摘要頁、實體頁、概念頁、比較頁，這層完全歸 AI 管，你只負責讀。
第三層是規則檔（Schema），用 Claude Code 就是 CLAUDE.md，用 Codex 就是 AGENTS.md，它告訴 AI 這個知識庫怎麼編排、有哪些慣例、收到新素材或被提問時該跑什麼流程。
第三層的規則檔可以讓你的 AI Agent 變成一個有紀律的知識庫管理員。
你如果要做客製化的修正，就是讓 AI 去把你的需求告訴你的 AI Agent，讓他幫你修改這一份規則檔。
如果你有一些固定的流程，就是跟 AI Agent 說明你的流程內容，請它幫你寫成「技能」。
注意上述的內容，全部都要在你的 LLM Wiki 目錄底下去跟你的 AI Agent 說明。
當你設定了 Karpathy 的 LLM Wiki 的時候，AI 還會順手幫你建兩個導航檔。
index.md 是內容目錄，每頁一行摘要、依類別排好，AI 回答前先讀取它，再決定深入哪幾頁資料，適合你的素材量還不是很多的情況。
log.md 是時間軸，只往後追加，記錄每次匯入、提問、體檢，開頭用固定格式（像 ## [2026-04-02] ingest | 文章標題），AI Agent 就能直接用 grep 指令去撈它最近做了什麼。
如何使用 LLM Wiki？
平常你就靠三個動作跟它互動。
第一個是匯入（Ingest），你把新素材丟進 raw 資料夾叫 AI 處理，它會讀完、跟你討論重點、寫一頁摘要、更新索引、改動相關的實體頁與概念頁、再往日誌補一筆，一份素材通常會牽動 10 到 15 個頁面。
第二個是提問（Query），AI 去知識庫找相關頁面、附引用回答你，你如果有發現某個討論內容不錯，還可以回存成新頁面，讓你每次探索也跟著累積，而不是消失在對話紀錄裡。
第三個是體檢（Lint），定期叫 AI 自我檢查，揪出彼此矛盾的內容、被新素材推翻的舊說法、沒人連到的孤兒頁、缺漏的交叉連結、可以補查的資料缺口。
Karpathy 自己的工作畫面是一邊開 AI 代理、一邊開 Obsidian 筆記軟體，AI 在對話裡改檔案，他在 Obsidian 這頭即時瀏覽，看關聯圖（Graph View）哪些頁是樞紐、哪些是孤兒。
一個實際例子：我用它寫一本修仙小說
講到這裡可能還是有點抽象，我用自己的私底下在做的專案當例子。
我最近在寫一本修仙小說《凡人滅仙傳》，我打算按照 LLM Wiki 的方式去整理資料。
原始素材那層，我開了一個 raw 資料夾，底下分神話典籍（山海經、搜神記的妖怪條目）、明代歷史（建文年間、靖難之役），之後我會把相關的資料丟進去。
知識庫那層，是一本「故事聖經」，裡面有人物頁、世界觀頁、妖怪圖鑑、主角能力表、伏筆追蹤，全部互相連結，由 AI 維護。
比如說我在書裡有隻妖怪叫山魈，牠的頁面就會記載出處（山海經、子不語）、外型（紅緯帽、獨腳）、能力（天生隱身）。
當我要寫山魈出場那章，AI 只要把這一頁夾進去，負責寫正文的 AI 就不會把設定寫錯。
平常我在使用的時候，例如我可能會跟 AI 討論要如何擴充我的「妖怪知識庫」，它就會幫我整理相關資料，並介紹我還可以去哪裡抓取哪些素材。
素材其實也可以交給 AI agent 去抓啦，但是有些資料的抓取方式，還是只能靠人工處理，因為現在很多網站都會擋爬蟲。
例如臺灣有一個「中國哲學書電子化計劃」網站，如果你想叫爬蟲去爬就有點困難，它的網站會擋。
我自己覺得 LLM Wiki 最好的概念是 log.md 日誌。
因為我們在建置這種知識庫的時候，其實挺需要記錄 AI 到底在過程中做了些什麼事情。一般來說，我們自己不太會去讀這份日誌，所以這些內容其實是交給 AI 看的。
畢竟 AI 是沒有記憶的，所以你要讓它知道之前做了些什麼，它就比較不容易出錯。
我建議每個人都要安裝 LLM Wiki。
無論你是要寫程式、寫書，或是在做自媒體、寫電子報，其實許多工作本質上都是在處理知識管理。設定 LLM Wiki 對你來說只有好處沒有壞處。
最後，我們還可以透過 Git 來管理這些內容，針對整個 LLM Wiki 知識庫進行版本控制，這樣就更完美了。
參考連結：
如果你也想把這種用法真正練起來，看我在真實專案裡怎麼設定、怎麼調整，我會在社畜進化論｜Raven AI社群裡一步步帶。
要是你更傾向直接把自己的事業或工作流程套進去，需要有人幫你盤點從哪裡開始，那就預約一對一AI 一人公司啟動諮詢，我們一起畫出你的自動化藍圖
。