LLM Wiki 知識庫架構

每個人都有筆記的死角。

你在 Notion 寫過讀書心得，在 Bear 貼過文章連結，在 Obsidian 建過「以後要整理」的資料夾。結果幾個月後，你想找某個概念，找不到。或者找到了，但已經不記得當初為什麼覺得重要。

我去年也有同樣的困境。直到看到 Andrej Karpathy 提出的一個想法，才真正解決這個問題。這篇是把這套架構跑了大半年、反覆長大之後的現況紀錄。

傳統 RAG 的錯誤假設

在大型語言模型流行後，個人知識管理的「正確解法」似乎是：把所有筆記餵進向量資料庫，用語意搜尋查詢。這就是所謂的 RAG（Retrieval-Augmented Generation）。

但這個方案有個根本問題：它假設你的原始資料已經足夠好了。

實際上，原始筆記充滿雜訊，倉促抄下的引文、未完成的思路、沒有脈絡的截圖。每次查詢，LLM 都要從這些雜訊重新推導答案，成本高且品質不穩定。

Karpathy 的觀察更犀利：

“The wiki is a persistent, compounding artifact.”

真正有價值的不是原始資料，而是整理過的知識。RAG 每次都在從頭整理；wiki 方法是整理一次，反覆複用。

核心架構：三層分工

Karpathy LLM Wiki 的核心思路是明確分工：

層	內容	誰負責
Raw	原始文件（文章、書摘、財報）	人類放入，LLM 只讀
Wiki	整理後的知識頁、摘要、交叉引用	LLM 維護
Schema	`CLAUDE.md`，定義結構與規則	人類制定

人類做策展，LLM 做基礎建設。這個分工讓知識可以隨時間複利累積，而不是每次查詢都從零開始。

我的實作：域優先結構

我在 Obsidian 上實作了這個架構，並加了一層設計：以生活域為頂層資料夾。

vault/
  books/        ← 閱讀
  finance/      ← 財務追蹤
  coffee/       ← 咖啡品飲
  engineer/     ← 技術筆記
  art/          ← 展覽與藝評
  ideas/        ← 跨域觀察、碎片想法
  skateboard/   ← 滑板練習日記
  projects/     ← 對外專案（對應 Hugo section）
  others/       ← 雜項暫存區（dance、drawing、games、commute…）

每個域從最小結構開始，按追蹤型態長大成兩種型別之一：

{domain}/
  records.md 或 logs/YYYY-MM-DD.md   ← 追蹤型域，兩者擇一
  raw/                               ← 原始素材，累積到 5 個檔才開
  wiki/                              ← 整理後的知識頁
  index.md                          ← 域的目錄

records.md 是單檔表格追蹤，適合 coffee、art 這種一列一筆的域。logs/YYYY-MM-DD.md 是每日一檔的時序 journal，適合 skateboard、dance 這種記當日體感的練習域。同一個域只能擇一。

這個設計的好處是：查詢有路徑可循。要找咖啡相關知識，先看 coffee/index.md，再往下看 coffee/wiki/，不需要掃整個 vault。LLM 每次讀的檔案數從幾百個降到 2 到 4 個。

不確定歸屬的東西也不強塞。無明確域的外部素材先進 others/raw/，同主題聚到 5 個檔以上再升成子域。往上搬比往下藏的心理成本低，所以預設 others/、長大再升頂層。

資料流向：Inbox 作為入口

所有新資料都先進 Inbox/，以時間戳命名（如 2026-04-15T10_33_21.txt）。這是關鍵設計：把「放入」和「分類」解耦。

Inbox/（時間戳檔名）
  → /inbox-triage → {domain}/raw/（概念素材，有意義檔名）
                  → {domain}/logs/YYYY-MM-DD.md（練習日記）
                  → TODO.md（需要後續 skill 的待辦，統一收納）
  ↳ /note-enrich（缺事實時，網路補充就近融入，帶來源連結）
  → /book-review、/note-explore、/wiki-build → {domain}/wiki/
  → /wiki-render（選用）→ slides

/inbox-triage 是第一個 skill：讀取 Inbox 裡每個檔案的內容，推斷它屬於哪個域，建議一個有意義的路徑，讓我確認後再移動。它還會把需要後續處理的 note 一律追加進根目錄 TODO.md，讓管線不斷在人腦記憶。

這條動線有一條硬規矩：不准跳過 raw/ 直接寫 wiki/。raw 是 wiki 的前置沉澱。唯一例外是從書頁或藝評頁「外提」的概念頁，沉澱留在來源側，用 frontmatter 的 sources 溯源。

Skills 系統：從原子指令長成管線

整個架構的操作介面是一組 Claude Code skills，存在 .claude/skills/。剛開始是 9 個原子指令，跑了半年後收斂成更少、更成套的管線。

指令	用途
`/inbox-triage`	分類 Inbox，路由至 raw/ 或 logs/，待辦寫進 TODO.md
`/note-enrich`	對任何 note 做網頁搜尋擴充，事實就近融入
`/wiki-build`	整合多份 raw + Inbox 為 wiki 頁，反壓縮紀律
`/note-explore`	靈魂拷問 + 發散探索一份 note
`/wiki-query`	索引加速查詢，不掃全 vault
`/book-review`	書籍管線一條龍：登記 → 對話式心得 → 概念 ingest
`/art-review`	展覽/劇場登記 + 藝評頁 + 概念外提至 ideas
`/vault-maintain`	vault 健康唯一入口，掃描 + 安全項自動修復
`/wiki-render`、`/wiki-compile`	渲染 Marp 投影片、打包域匯出
`/threads-cards`、`/medium-cover`	從文章產 Threads 圖卡、Medium 封面
`/retro`	對當前 session 做對話式 retrospective

最大的變化是合併。原本的 book-add / book-review / book-ingest / book-update 四個指令，收成一個 /book-review 一條龍；wiki-lint 併入 /vault-maintain；inbox-enrich 升級成 /note-enrich。設計法則是單一寫入點與 pull-not-push：每個管線只有一個入口，收尾時主動提議下一步，而不是散成一堆得自己記得串接的小指令。

舉個 /book-review 的例子：讀完一本書，一個指令就走完登記、對話式心得、概念提取三段。LLM 會從心得提取幾個核心概念，依「概念路由規則」分配到對應域。有明確域歸屬的（如「複利思維」）進 finance/wiki/；跨域或通用的心理學概念進 ideas/wiki/。然後自動更新對應域 index.md，並在根目錄 log.md 追加記錄。

最後一塊拼圖：Karpathy Guidelines

架構設計完了，還有一個問題沒解決：LLM 執行 skill 時，怎麼避免它「多做了一些你沒要求的事」？

我整合了 andrej-karpathy-skills 的四個行為原則，把它們直接寫進每個 skill 檔案：

1. 行動前陳述理解 每個 skill 執行前，先說出計劃：「我理解這是 X，計劃做 Y，確認嗎？」讓我有機會在任何副作用發生前糾正誤解。

2. 最小化操作 只執行 skill 定義的步驟。看到格式不統一？不管。看到可以順手優化的地方？不做。

3. 手術式修改 只更新指定欄位或區塊。更新書籍 status 只改 status，不動其他欄位，不重寫整個檔案。

4. 目標驅動驗證 每個 skill 末尾有「成功標準」checklist：目標檔案存在嗎？log.md 更新了嗎？index.md 有新條目嗎？LLM 逐一確認後才算完成。

這四條原則讓 LLM 從「有點不可控的助理」變成「可以放心授權的執行者」。

從 guideline 到 hook：把準則變成物理擋牆

寫進 skill 的準則是軟約束，靠 LLM 自律遵守。跑久了會發現，光靠自律不夠，總有幾類錯誤反覆發生。

於是我把最常犯的違規變成硬約束，用 Claude Code 的 hooks 在 .claude/hooks/ 攔下。PreToolUse 會在寫入前物理擋下這幾種動作：根目錄寫一次性腳本（.py / .js / .json）、寫進依賴夾、產生 iCloud 衝突副本、以及 wiki 頁缺 summary / tags / date。Stop 時另外掃 iCloud 衝突副本提醒。

這一步的意義是：行為準則不再只是「希望 LLM 記得」，而是「做錯了根本存不進去」。這跟 Harness Engineering 的精神一致，把智慧從人工遵守轉成機械化驗證。

vault 位在 iCloud Drive、跨 Mac 與 Windows 同步，這些 hook 也順手擋掉了 iCloud 最愛咬人的兩個行為：脫水佔位檔、以及雲端權威檔名把 rename 還原成衝突副本。

跨域視圖：Hub 策展頁

三層架構解決的是「單一主題怎麼長」。但有些主題天生跨域，例如「注意力」同時牽動閱讀、工程、情緒。

這類主題我開一個 hub 策展頁放在頂層 hubs/，例如 hub-注意力、hub-ai-協作工程、hub-學習方法。hub 只聚合、不合成：它把各域既有的 wiki 頁連過來，每條連結都必附一句「為什麼在這個展間」，禁止純連結清單。

hub 和 wiki-build 的分工很清楚。wiki-build 把單域的 raw 合成成內容頁；hub 策展跨域的既有 wiki 頁，永遠不完成、持續累積。新開 hub 需要 tag 探勘數據支持（跨兩域以上的主題叢），維持少量。

實際效果

目前活躍的域有 books、finance、coffee、engineer、art、ideas、skateboard 等十個左右。每次讀完一本書，從 inbox 到概念頁上線，大約 15 分鐘。查詢某個財務概念，三個 index 跳轉就找到答案，不需要全文搜尋。

最重要的是知識真的在累積。讀第 20 本書的時候，LLM 會自動找到它與之前 19 本書的交叉引用，連結我當時沒有意識到的關係。這才是 Karpathy 說的 compounding artifact：不是筆記數量增加，而是知識密度在提升。

技術細節

前端：Obsidian（免費、本地優先，附件走 per-folder _attachments/）
執行：Claude Code（跑 skills）
Schema：CLAUDE.md（domain 結構、路由規則、LLM 行為準則）
護欄：.claude/hooks/（PreToolUse 物理擋違規、Stop 掃衝突副本）
輸出：/wiki-render 出 Marp 投影片；/threads-cards、/medium-cover 出社群圖卡
發布：Vault 到 Hugo 的推送交給獨立工具 vault-forge，vault 端只寫扁平 frontmatter 的內容，不為發布改結構
成本：無向量 DB，查詢 context 通常少於 10 個檔案，費用可忽略不計

如果你也在用 Obsidian，覺得筆記越來越多但越來越難查，這個架構值得試試。不需要任何付費插件，只需要一個能執行 Claude Code 的終端機。從最小的三層分工開始，等它自己長出你需要的域、管線和護欄。

傳統 RAG 的錯誤假設#

核心架構：三層分工#

我的實作：域優先結構#

資料流向：Inbox 作為入口#

Skills 系統：從原子指令長成管線#

最後一塊拼圖：Karpathy Guidelines#

從 guideline 到 hook：把準則變成物理擋牆#

跨域視圖：Hub 策展頁#

實際效果#

技術細節#

延伸閱讀#