LLM Wiki —— 用 LLM 建個人知識庫的模式（Andrej Karpathy）

📌 30 秒摘要

一份「點子檔」（idea file，2026-04-04 發布），設計成讓你直接貼給自己的 LLM agent（Claude Code、Codex…），由 agent 跟你一起把細節做出來。

核心主張是：多數人用 LLM 讀文件的方式是 RAG，每次提問都從原始檔重新撈片段、重新拼答案，什麼都沒累積。改成讓 LLM 持續建立並維護一個互相連結的 markdown wiki：新來源進來時，LLM 不只是建索引，而是讀完、萃取重點，再整合進既有頁面——更新實體頁、修訂主題摘要、標出新舊說法的矛盾。

知識「編譯一次、之後保持最新」，wiki 會隨每個來源、每個問題複利成長。人負責挑來源、提問、思考意義；LLM 負責其他所有雜務。

本知識庫就是照這個模式建的：「有紀律的 wiki 維護員」這個定位、CLAUDE.md 當規則檔、ingest／lint 流程，都出自這篇。

🗺 心智圖（Canvas）

LLM Wiki（Karpathy）

📚 LLM Wiki

（Karpathy）

🗃 整套模式

工具-讓LLM維護的個人Wiki

🎯 什麼情境該想到我

當你「讀了一堆文章、書、論文，筆記卻散落各處、維護不下去，每次要用又得從頭找」的時候。

⚙️ 怎麼用（步驟 / 公式）

核心轉換：不要每次提問都讓 LLM 從原始檔重新撈（RAG 式，什麼都沒累積），改成讓 LLM 把知識編譯進一個互相連結的 markdown wiki，之後持續更新。人負責挑來源、提問、思考；LLM 負責摘要、交叉連結、歸檔、記帳。

1. 分三層開資料夾
   • raw/（或按書／文章分）：原始來源，LLM 只讀不改，是事實的最終依據。
   • wiki 頁面：LLM 全權撰寫與維護。
   • 規則檔：CLAUDE.md（Claude Code）或 AGENTS.md（Codex）。
2. 寫規則檔（這是整套系統的設定檔），至少寫清楚：
   • 資料夾各放什麼、檔名怎麼取
   • 每種頁面的 frontmatter 與段落結構
   • 收錄、提問、健檢三個流程各怎麼走
   • 品質底線，例如不杜撰、來源與衍生頁要雙向連結
     規則檔讓 LLM 從聊天機器人變成「有紀律的維護員」；它是跟你一起演化的，踩到坑就補一條。
3. Ingest：一次收一個來源
   • LLM 讀完，先跟你討論重點
   • 寫摘要頁
   • 更新索引和所有相關的實體／概念頁
   • 記一筆日誌
     正常情況下，一個來源會動到 10–15 頁；只多出一頁摘要的話，就沒有整合。
4. 建索引：index.md 每頁一行連結＋一行摘要，按類別分組。提問時讓 LLM 先讀索引再深入。約 100 個來源、數百頁以內，不需要向量檢索。
5. Query 與 Lint：問答結果要存回 wiki（見 工具-把好答案存回知識庫），並定期健檢（見 工具-知識庫定期健檢）。
6. 工作姿勢：一邊開 agent、一邊開 Obsidian。即時看它改了什麼，順著連結讀，看 graph view 有沒有孤兒頁。「Obsidian 是 IDE、LLM 是程式設計師、wiki 是 codebase。」wiki 本身放進 git，免費拿到版本紀錄。

為什麼行得通：人放棄 wiki，是因為維護負擔（更新連結、同步摘要、標矛盾）長得比價值快。LLM 不會累、不會漏改連結、一次能改 15 個檔，維護成本趨近零，wiki 才活得下去。

本庫的實例：這個知識庫就是這樣建的。

• 規則檔：CLAUDE.md 的鐵律 1–11
• 收錄流程：/ingest-book、/ingest-url、/ingest-ugc、/ingest-docs
• 健檢：/lint-wiki
• 另外把原文的「實體頁」改成「工具卡＋白話 triggers」，照情境找東西。

🧪 我實際套用的紀錄

• 2026-09：用這套模式建立本知識庫，並完成十階段深度健檢（相當於一次大型 Lint）。

⚠️ 注意 / 什麼時候不適用

• LLM 會杜撰：規則檔一定要寫「以原始來源為準、關鍵數字核對原文」，而且原始來源要保存，才有東西可以對照。
• 收錄時要人在場：批次收錄省力，但你不讀摘要、不引導重點，wiki 會變成 LLM 的觀點，不是你的。原作者偏好一次一個、全程參與。
• 規則檔會膨脹：規則越補越多，要定期整併，否則 LLM 顧此失彼。
• 規模上限：索引檔撐得住約數百頁；再大就要上本機搜尋（原文推薦 qmd：BM25＋向量＋LLM 重排）。
• 只是偶爾查一兩份文件的話，直接丟給 LLM 問就好，不必建 wiki。

🔗 相關工具

• 工具-把好答案存回知識庫 —— Query 這一步的關鍵做法
• 工具-知識庫定期健檢 —— Lint 這一步
• 工具-RAG檢索增強生成 —— 對照：RAG 每次提問才檢索、不累積；這張卡是先編譯、再維護
• 工具-主題閱讀 —— 跨多份來源形成自己觀點的閱讀方法，是收錄時「討論重點」的功夫

❓ Query：好答案存回

工具-把好答案存回知識庫

🎯 什麼情境該想到我

當你「剛跟 AI 聊出一份很有價值的比較或分析，而它馬上就會沉進聊天紀錄、再也找不到」的時候。

⚙️ 怎麼用（步驟 / 公式）

核心想法：知識庫不只靠「收錄來源」長大，你問出來的東西也是知識。你要求做的比較、一段分析、一個新發現的關聯，都跟收錄的來源一樣有價值。只留在聊天紀錄裡，就等於沒發生過。

1. 提問時先查 wiki：讓 LLM 先讀索引、找相關頁、讀完，再附引用回答。答案建立在已編譯的知識上，不要回頭從原始檔重撈。
2. 選合適的輸出形式：問題不同，答案形式就不同，例如 markdown 頁、比較表、Marp 投影片、matplotlib 圖表、Obsidian canvas。
3. 判斷值不值得存：
   • 存：跨多個來源的比較、你會再問第二次的問題、推出新結論的分析、發現兩個概念之間的關聯
   • 不存：一次性事實查詢、只是換句話說的摘要
4. 存成正式頁面：照規則檔的格式存，放進索引，並跟被引用的頁雙向連結。有新結論的話，回頭更新原本的概念頁。
5. 記一筆日誌：例如 ## [日期] query | 問題標題，之後才知道這頁是從哪次探索來的。

★ 效果：你的探索跟收錄的來源一樣會複利。下次問相關問題時，LLM 直接站在上一次的結論上往前走。

🧪 我實際套用的紀錄

• （尚無）

⚠️ 注意 / 什麼時候不適用

• AI 的答案可能錯：存回去之前要核對它引用的頁面。錯的結論進了 wiki 會被後續問答當成事實引用，錯誤一路擴散。
• 不要什麼都存：一次性問答全存，wiki 會充滿低價值的頁，淹沒真正的工具卡。
• 標清楚來源：存回的頁是「推論」不是「原文」，frontmatter 或開頭要寫明是由哪些頁綜合而來。

🔗 相關工具

• 工具-讓LLM維護的個人Wiki —— 整套模式，這張是其中的 Query 步驟
• 工具-知識庫定期健檢 —— 存回的頁也要被健檢，看有沒有跟新來源矛盾
• 工具-主題閱讀 —— 綜合多份來源形成觀點；存回的往往就是這種綜合結果

🩺 Lint：定期健檢

工具-知識庫定期健檢

🎯 什麼情境該想到我

當你「的知識庫長大了，開始出現前後矛盾、孤兒頁、過時說法，或者跨好幾次工作階段後忘了上次做到哪」的時候。

⚙️ 怎麼用（步驟 / 公式）

核心想法：wiki 一長大就會自然腐化。定期讓 LLM 當檢查員掃一遍，就像程式碼的 lint。

健檢清單（原文列的六項）：

檢查項	怎麼查	怎麼修
頁面間的矛盾	同一概念在不同頁的定義、數字不同	回原始來源核對，改掉錯的那頁，或註明兩種說法
被新來源推翻的過時說法	較新的來源與舊頁結論衝突	更新舊頁，標註查證日期
孤兒頁（沒有任何連入）	掃描所有 wikilink，找出沒被任何頁引用的頁	從相關頁或索引連入，或判斷該刪
被提到卻沒有自己頁面的重要概念	同一個詞在多頁出現，但沒有對應頁	建頁
缺漏的交叉連結	兩頁講相關的事卻沒互連	補連結（只連真正相關的）
可以補的資料缺口	頁面寫「待查」或內容太薄	上網查證後補上

LLM 在健檢時也很適合提議新問題與新來源，順便決定下一步要讀什麼。

能自動化的先腳本化：斷連結、孤兒頁、frontmatter 欄位缺漏、trigger 重複，用幾行腳本就查得出來，每次健檢固定跑。矛盾、過時、缺口這類需要判斷的，才交給 LLM 逐頁看。

配一個只追加的操作日誌 log.md：

## [2026-04-02] ingest | Article Title
## [2026-04-05] query | 某某比較
## [2026-04-10] lint | 修 3 個斷連結、2 處矛盾

每筆用固定開頭，就能用 grep "^## \[" log.md | tail -5 看最近 5 筆。它讓你和 LLM 知道 wiki 怎麼演化到現在，跨工作階段接手時不必重新摸索。

🧪 我實際套用的紀錄

• 2026-09：本庫十階段深度健檢。每階段固定跑斷連結、trigger 撞車、來源↔工具雙向連結檢查，並把進度記在 _meta/深度健檢.md（相當於分主題的日誌）。

⚠️ 注意 / 什麼時候不適用

• LLM 健檢也會誤報：例如表格裡的 \|、canvas 嵌入被誤判成斷連結。腳本的輸出要人看一眼再修。
• 修矛盾要回原始來源：不要讓 LLM 在兩頁之間「挑一個看起來合理的」，要回原文核對。
• 補連結寧缺勿濫：為了消滅孤兒頁而硬連，只會讓連結失去意義。
• 小型知識庫（幾十頁）人工瀏覽就夠了，不必排定期健檢。

🔗 相關工具

• 工具-讓LLM維護的個人Wiki —— 整套模式，這張是其中的 Lint 步驟
• 工具-把好答案存回知識庫 —— 存回的推論頁最容易跟新來源矛盾，健檢時要優先看

Link to original

🎯 為什麼存這篇 / 未來想拿它做什麼

• 這是本知識庫架構的出處。以後要調整規則、或跟別人解釋這套系統為什麼長這樣，回來看原始設計意圖。
• 原文有幾個做法我還沒用，之後可以補：log.md 時間紀錄、把好答案存回 wiki、wiki 變大後用本機搜尋引擎。
• 可以把同一套模式搬到非個人場景，例如團隊內部 wiki、研究某個主題、盡職調查。

🧰 這篇給我的工具（連到 tools/）

• 工具-讓LLM維護的個人Wiki —— 讀了很多東西卻沒累積、筆記維護不下去時
• 工具-把好答案存回知識庫 —— 問 AI 得到一份好分析，卻只留在聊天紀錄裡時
• 工具-知識庫定期健檢 —— 知識庫長大後，開始出現矛盾、孤兒頁、過時說法時

✨ 關鍵重點

三層架構

層	內容	誰擁有
原始來源 Raw sources	文章、論文、圖片、資料檔。不可改動，是事實的最終依據	人挑選，LLM 只讀
Wiki	LLM 產生的 markdown：摘要、實體頁、概念頁、比較、總覽、綜合	LLM 全權擁有：建頁、更新、維護交叉連結
規則檔 Schema	例如 CLAUDE.md／AGENTS.md，寫 wiki 的結構、慣例與各流程怎麼走	人與 LLM 一起演化

★ 規則檔是關鍵：它讓 LLM 成為「有紀律的 wiki 維護員」，而不是一般的聊天機器人。

三個操作

• Ingest（收錄）：丟一個新來源進來。LLM 讀完、跟你討論重點，接著寫摘要頁、更新索引、更新相關實體與概念頁，最後記一筆日誌。一個來源可能動到 10–15 頁。作者偏好一次收一個、自己全程參與，但也可以批次處理。
• Query（提問）：對 wiki 提問，LLM 先找相關頁、讀完，再附引用回答。答案可以是頁面、比較表、Marp 投影片、matplotlib 圖表、canvas。★ 好答案要存回 wiki 變成新頁，探索成果才會跟來源一樣累積。
• Lint（健檢）：定期檢查頁面間的矛盾、被新來源推翻的過時說法、沒有連入的孤兒頁、被提到卻沒有自己頁面的重要概念、缺漏的交叉連結、可以上網補的資料缺口。

兩個特殊檔案

• index.md（照內容組織）：每頁一行連結＋一行摘要，按類別分組，每次收錄都更新。回答問題時 LLM 先讀索引再深入。作者說在約 100 個來源、數百頁的規模下出奇地好用，不需要 embedding RAG。
• log.md（照時間排序）：只追加的紀錄。每筆用固定開頭（例：## [2026-04-02] ingest | Article Title），就能用 grep "^## \[" log.md | tail -5 看最近 5 筆。

比喻：「Obsidian 是 IDE；LLM 是程式設計師；wiki 是 codebase。」一邊開 agent、一邊開 Obsidian，即時看它改了什麼、看 graph view。

為什麼行得通：維護知識庫的苦差事不在閱讀或思考，而在記帳——更新交叉連結、保持摘要最新、標出矛盾、維持幾十頁的一致性。人類放棄 wiki，是因為維護負擔長得比價值快。LLM 不會無聊、不會忘了更新連結、一次能改 15 個檔，維護成本趨近零，wiki 才維持得住。

精神源頭：Vannevar Bush 的 Memex（1945）——私人、主動策展、文件之間的關聯跟文件本身一樣有價值。Bush 解決不了的是「誰來維護」，這件事現在由 LLM 接手。

選配工具

• qmd：本機 markdown 搜尋引擎，混合 BM25 與向量搜尋，並用 LLM 重排，有 CLI 和 MCP 兩種介面。wiki 大到索引檔不夠用時再上。
• Obsidian Web Clipper：把網頁轉成 markdown。
• 圖片存到本機：把附件資料夾設成固定位置，再綁一個快捷鍵執行「Download attachments for current file」。LLM 沒辦法一次讀完含內嵌圖的 markdown，要先讀文字，再個別看圖。
• Dataview：查詢 frontmatter，自動產生表格。
• Marp：markdown 投影片。
• git：wiki 本身就是一個 markdown 的 git repo，版本紀錄、分支、協作都免費拿到。

刻意抽象：原文只講模式、不講實作。目錄結構、頁面格式、工具全部選配，「分享給你的 LLM agent，一起做出適合你的版本」。

本知識庫與原文的差異

原文	本知識庫
以實體頁／概念頁為中心	以「工具卡＋白話 triggers」為中心：憑情境找工具，不是憑書名找
單一 index.md	主題 MOC 當入口，另有公開網站首頁
有 log.md	沒有時間日誌；進度追蹤放在 _meta/
個人在 Obsidian 瀏覽	另外用 Quartz 發布成公開網站
無品質門檻	鐵律 1–11：只抓 3–7 個工具、深度自足、UGC 來源先查證

💬 原文摘錄

• “The wiki is a persistent, compounding artifact.”
• “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”
• “Humans abandon wikis because the maintenance burden grows faster than the value.”
• “The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.”

🔗 相關

• 工具-RAG檢索增強生成 —— 原文拿來對照的「每次都重新推導」做法；LLM Wiki 則是把知識先編譯好
• 工具-主題閱讀 —— 同一個主題整合多份來源、形成自己的觀點；原文「Research」用途的人工版