llm-wiki 是 Andrej Karpathy（前 Tesla AI 總監、OpenAI 創始成員）公開的一份 GitHub Gist，描述用大型語言模型建立與維護個人知識庫的模式。它是 0406備忘錄這座 wiki 的基底文件，另一半是 personal_wiki_skill，兩者如何拼裝見 LLM Wiki。
文件開頭就聲明自己是「想法檔案」，用途是複製貼上給使用者自己的 LLM agent，目標只是傳達高層次的構想，具體實作要由 agent 與使用者協作長出來。結尾再重申一次：目錄結構、schema 慣例、頁面格式、工具鏈全部取決於領域與偏好，「文件唯一的工作是傳達這個模式」。這解釋了為什麼 0406備忘錄的 /wiki skill 跟原文長得不一樣，也解釋了為什麼分歧本身不算偏離。
核心主張：編譯，不是檢索
Karpathy 用 RAG 當對照組。多數人的 LLM 文件經驗是這樣：上傳一批檔案、模型在查詢時檢索相關片段、生成答案。NotebookLM、ChatGPT 檔案上傳、大多數 RAG 系統都是這樣運作。他指出這套的缺陷不在準確度而在累積：模型每一次提問都在從零重新發現知識，沒有任何東西被建立起來。問一個需要綜合五份文件的細緻問題，模型每次都要重新找、重新拼一遍。
llm-wiki 的做法是在使用者與原始來源之間插進一層持久的 wiki。新來源進來時，模型不是把它建索引等待日後檢索，而是讀它、抽出關鍵資訊、整合進既有的 wiki：更新實體頁、修訂主題摘要、標記新資料與舊主張衝突之處、強化或挑戰演進中的綜合判斷。知識編譯一次，然後持續保持最新，而不是每次查詢重新推導。
由此得出他的核心句：wiki 是一個持久的、會複利的產物。交叉引用已經在那裡了，矛盾已經被標記過了，綜合判斷已經反映了讀過的一切。
對照組只有一次點名
RAG 那段的最後一句把 NotebookLM、ChatGPT 檔案上傳與「大多數 RAG 系統」並列成例子。這是 NotebookLM 在全文唯一一次出現。沒有專節、沒有功能對照、沒有優劣分析，也沒有為「NotebookLM 屬於 RAG」提出任何論證，那是斷言不是結論。想拿這份 gist 當作兩套工具的比較依據，材料並不存在。
語氣上也不是反對。原文明說這套做法行得通，缺陷不在準確度、成本或幻覺，只在不累積。Karpathy 要立的不是「RAG 錯了」，而是「RAG 之上還缺一層」。
全文其實有兩處反 RAG 陳述，層級不同，容易被讀成同一件事：
| 位置 | 層級 | 主張 |
|---|---|---|
| 核心主張段 | 認識論 | RAG 每次從零重新發掘，沒有累積 |
| 索引與日誌段 | 工程 | 約 100 份來源的規模下索引檔就夠了，不需要 embedding-based 的 RAG 基礎設施 |
第二處是實作建議而不是立場，它回答的是「要不要架向量資料庫」，見下方索引與日誌節。
N+1 判準
分界線不畫在檢索機制上。判斷一套工具落在哪一邊，要問的是：加入第 N+1 份來源，會不會改寫已經存在的東西？
不會改寫的，每次請求都是重生成，先前的產出停在生成當下的狀態。會改寫的，舊頁面被回頭修訂，矛盾被標記，交叉引用被更新。機制是 chunk retrieval 還是把來源整包塞進長脈絡，對這條線沒有影響。
NotebookLM 產出的摘要、簡報文件、音訊摘要、心智圖都是單次請求的產物，再丟一份來源進去，先前生成的東西不會被回頭修訂。這才是「沒有累積」指的事，而不是它用了向量搜尋。
這條判準比「wiki 對上 RAG」好教，因為受眾多半用過 NotebookLM，而它的優點（零設定、引用清楚、音訊摘要）恰好標出它的邊界：它讓人更快讀完手上的東西，不替人累積。
NotebookLM 現況未實測
NotebookLM 後來加了筆記功能且筆記可轉為來源，這條路徑若順暢，帳面上的差距會縮小。但關鍵那一步是否仍然缺席——新材料與舊結論衝突時回頭改寫舊頁面——尚未實測。上課引用前要先驗。
分工也隨之確定。使用者負責找來源、探索、問對問題；模型負責摘要、交叉引用、歸檔、簿記。Karpathy 描述他自己的工作方式是一邊開 agent 一邊開 Obsidian，模型依對話改檔，人即時瀏覽結果、跟著連結走、看關聯圖、讀更新過的頁面。他用一句話收攏這個配置：
Obsidian 是 IDE，LLM 是程式設計師，wiki 是 codebase。
三層架構
| 層 | 誰擁有 | 性質 | 對應到 0406備忘錄 |
|---|---|---|---|
| 原始來源 | 使用者策展 | 不可變。模型只讀不寫，是真相來源 | 0406/、Clippings/ 與各主題資料夾的筆記檔 |
| wiki | 模型完全擁有 | 建頁、更新、維護交叉引用、保持一致。人讀，模型寫 | wiki/ |
| schema | 人與模型共同演化 | 告訴模型 wiki 怎麼組織、慣例是什麼、各工作流怎麼走 | /wiki skill、wiki/CLAUDE.md、wiki/references/ |
Karpathy 把第三層標為關鍵設定檔，理由是它決定模型是一個有紀律的 wiki 維護者還是一個通用聊天機器人。他也明說這一層應該由人與模型長期共同演化，而不是一次寫定。0406備忘錄把這一層拆成五個檔案（skill、CLAUDE.md、writing.md、schema.md、rubric.md），並在 CLAUDE.md 累積踩過的 gotchas，走的正是共同演化的路徑。
三個操作
Ingest。 使用者丟一份新來源進去並要求處理。示範流程是：模型讀來源、跟使用者討論重點、在 wiki 寫一頁摘要、更新索引、更新全 wiki 相關的實體與概念頁、在 log 追加一條。一份來源可能動到 10 到 15 頁。Karpathy 說他偏好一次一份、全程參與，讀摘要、檢查更新、指導模型該強調什麼；批次吸收也可以，只是監督較少。
Query。 對 wiki 提問，模型找相關頁面、讀、綜合出帶引用的答案。答案形態可以是 markdown 頁、比較表、Marp 投影片、matplotlib 圖表、canvas。他在這裡標了一個關鍵洞見：好的答案應該回存成新的 wiki 頁面。一份比較表、一個分析、一條發現的連結都有價值，不該消散在對話紀錄裡，這樣探索本身也會像吸收來源一樣複利。
Lint。 定期做健康檢查。要找的東西有六類：頁面之間的矛盾、被新來源推翻的過時主張、沒有入鏈的孤立頁、被提及但缺少獨立頁面的重要概念、缺少的交叉引用、可以用網路搜尋補上的資料缺口。他補了一句用途：模型擅長提出新的待查問題與該找的新來源。
索引與日誌
兩個特殊檔案，性質不同。index.md 是內容導向的，是 wiki 全部頁面的目錄，每頁一行連結加一句摘要，可選帶日期或來源數等中繼資料，按類別組織，每次 ingest 更新。回答查詢時模型先讀索引找到相關頁面，再往下鑽。
log.md 是時間導向的，只增不改，記錄何時發生了什麼：吸收、查詢、健檢。Karpathy 給了一個具體技巧：每條用一致前綴（他舉的例子是 ## [2026-04-02] ingest | Article Title），log 就能用 unix 工具解析，grep "^## \[" log.md | tail -5 直接拿到最近五條。0406備忘錄的 log 格式規範直接繼承這個前綴，六個動詞的白名單是本地加的約束。
他同時給出這套的規模判斷：在約 100 份來源、數百頁的量級下，索引檔的做法運作得意外地好，不需要 embedding-based 的 RAG 基礎設施。這座 wiki 到 2026 年 8 月吸收了 74 份來源、寫出 84 篇文章，仍在索引檔可負荷的範圍；來源池另有 482 份，多數尚未吸收。
索引檔這個位置，LYT框架 放的是 MOC——同樣是一份主題總表，同樣被拿來解決「模型怎麼快速掌握 context」的問題，但 MOC 由人按自己的思路排列並且是給人讀的，index.md 每頁一行、每次吸收後由模型重建。兩份文件都沒有提到對方，是這座 wiki 把它們擺在一起比較的。
為什麼人類維護不了 wiki
Karpathy 的論證是把維護成本抽出來單獨看。知識庫裡累人的部分不是閱讀，也不是思考，是簿記：更新交叉引用、讓摘要保持最新、標記新資料推翻舊主張、維持數十頁之間的一致性。人類放棄 wiki，是因為維護負擔成長得比價值快。LLM 不會無聊、不會忘記更新交叉引用、一次可以動 15 個檔案，所以維護成本趨近於零，wiki 就維持得住。
劉亮自己記錄的「悄悄劣化」現象是這個論證的另一半：維護成本降到近零，不等於維護會自動發生（見 LLM Wiki）。
他把這個模式接到 Vannevar Bush 1945 年的 Memex：一個私人的、經過策展的知識儲存，文件之間有聯想路徑。Bush 的構想比後來實際長成的網路更接近這件事，私有、主動策展、文件之間的連結與文件本身同等重要。他解不了的是誰來做維護，而這正是 LLM 接手的部分。
適用場景
Karpathy 列了一批例子，涵蓋範圍比個人筆記寬得多：個人（目標、健康、心理、自我改善）、研究（數週數月深挖一個主題，帶著演進中的論點）、讀一本書（邊讀邊建角色、主題、情節線的頁面，像 Tolkien Gateway 那類粉絲 wiki，只是由一個人建）、企業團隊（Slack 討論串、會議逐字稿、專案文件、客戶通話，人在迴圈裡審核）、競品分析、盡職調查、旅行規劃、課程筆記、興趣深挖。
劉亮的兩座 wiki 剛好落在頭兩項，生活工作版是「個人」，學術版是「研究」。LLM Wiki 開課計劃 的四堂課結構也是照這兩類切的。
未採用的工具建議
原文列了一組可選的工具與技巧，這座 wiki 只用了其中一部分。
| 項目 | 原文用途 | 這座 wiki |
|---|---|---|
| qmd | 本地 markdown 搜尋引擎，混合 BM25 與向量搜尋加 LLM 重排，有 CLI 也有 MCP server | 未採用，規模仍在索引檔可負荷的範圍 |
| Obsidian Web Clipper | 把網頁文章轉成 markdown | 根目錄有 Clippings/，存的是網頁剪輯稿 |
| 下載圖片到本地 | 把附件資料夾固定，讓模型能直接看圖 | Attachments/ 已固定，但吸收時讀的是 alt 文字不是圖 |
| Obsidian 關聯圖 | 看 wiki 的形狀，哪些是樞紐哪些是孤立頁 | 是當初觸發劉亮接觸 Obsidian 的概念之一 |
| Marp | markdown 投影片格式 | 未採用 |
| Dataview | 對頁面 frontmatter 下查詢，生成動態表格 | 未採用。文章 frontmatter 已有 type／created／updated 可用 |
| git | wiki 就是一個 markdown 的 git repo，版本歷史與分支免費取得 | 未採用，這個 vault 不是 git repo |
圖片那一項還帶了一個限制說明：LLM 無法在單次讀取中原生讀懂含內嵌圖片的 markdown，變通做法是先讀文字、再另外看圖，Karpathy 形容這有點笨拙但夠用。0406備忘錄的 alt 文字規則走的是另一條路，它選擇不看圖，改為要求人在 alt 裡寫實質說明，因為 alt 文字是圖片唯一會被吸收進 wiki 的部分。
相關原始筆記
llm-wiki.md（00 LLM WIKI 開課計劃/）— gist 全文0406/USEFUL/llm-wiki · GitHub.md— gist 連結與臉書分享連結