📚 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：好答案存回

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

🎯 什麼情境該想到我

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

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

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

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

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

🧪 我實際套用的紀錄

  • （尚無）

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

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

🔗 相關工具

🩺 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 在兩頁之間「挑一個看起來合理的」，要回原文核對。
  • 補連結寧缺勿濫：為了消滅孤兒頁而硬連，只會讓連結失去意義。
  • 小型知識庫（幾十頁）人工瀏覽就夠了，不必排定期健檢。

🔗 相關工具