上一篇講了為什麼要有一個由 LLM 維護的知識庫。這篇是實作：怎麼把庫建起來、怎麼接線讓任何專案資料夾都能一句「這個坑寫進 wiki」就寫入、四個工作流各自怎麼跑，以及四天實際用下來踩到的坑。
文中的目錄結構、schema 片段、指令內容都是我自己知識庫的真實產出，不是示意。
前置需求
| 項目 | 說明 |
|---|---|
| Claude Code | 知識庫的維護者。其他能讀資料夾層級指示檔的 agent 理論上也行，但我只用這個驗證過 |
| 一個資料夾 | 全部就是 markdown 檔。不需要資料庫、不需要向量索引、不需要任何服務 |
| Obsidian | 選配，純檢視用。graph view 和 wikilink 跳轉很值得，但沒有它系統照常運作 |
步驟一：建庫
目錄結構長這樣：
1 | D:/claude/Session2/ |
四個核心檔案裡，CLAUDE.md（schema）是唯一真正重要的，其他都是照它長出來的產物。它定義頁面型別、frontmatter 欄位、命名規範、引用格式、每個工作流的完整步驟。Claude Code 進到這個資料夾就會自動讀它，於是在這裡它的身分不是通用聊天機器人，而是「wiki 維護者」。
每一頁都有固定的 YAML frontmatter，這是之後能用 Dataview 查詢、能機械化健檢的前提。以經驗筆記為例（節錄自 templates/通用筆記.md）：
1 |
|
模板的內文骨架是「問題 → 做法 → 陷阱 → 不適用的情況 → 相關」，還有兩條很實用的細則：標題寫成可搜尋的形式（「用 X 做 Y 的技巧」而不是「X 心得」），以及錯誤訊息要照抄原文——之後才搜得到。
schema 不必手寫。把 Karpathy 的 gist 和你的需求丟給 Claude，讓它生一份，再邊用邊改。schema 本來就是活的——我的在建立當天就大改過一次（加入經驗沉澱軌，見上一篇），改 schema 這件事本身也會記進 log.md。
步驟二：全域接線（整套系統的關鍵）
這是最容易被略過、但決定成敗的一步。問題很簡單：知識庫在 D:/claude/Session2，可是踩坑的當下人在別的專案資料夾。要是每次沉澱都得 cd 過去另開 session、重新描述剛剛發生什麼，沉澱就永遠不會發生。
接線是三件事：
1. ~/.claude/settings.json 把知識庫加進 additionalDirectories。 這樣在任何專案裡，Claude Code 都能直接寫入知識庫，不會每個檔案跳一次權限詢問。
2. ~/.claude/CLAUDE.md（全域指示檔）加一段知識庫說明。 內容三塊：路徑在哪、觸發詞有哪些（「寫進 wiki」「沉澱」「這個記下來」）、以及最重要的一條——動手前先讀知識庫自己的 CLAUDE.md，照那份 schema 執行，不要憑印象寫。
3. ~/.claude/commands/wiki.md 建一個全域 /wiki 指令。 放在 ~/.claude/commands/ 的指令檔任何資料夾都叫得到。我的版本把步驟寫死成「順序不可跳」：
1 | 1. 先 Read D:/claude/Session2/CLAUDE.md —— 那是知識庫的 schema，不要憑印象寫 |
「不要憑印象寫」這條會重複出現三次，是有原因的：LLM 對「個人 wiki 該長什麼樣」有自己的想像，不先讀 schema 就會寫出格式不合的頁面——之後要人工清理，比不寫更糟。
接完線之後，日常的畫面是：在專案資料夾裡剛除完一個錯，順口說一句「這個坑寫進 wiki」，Claude 自己去讀 schema、搜既有頁、給草稿、寫檔、更新索引，然後回來繼續原本的工作。摩擦力低到接近零，習慣才養得起來。
步驟三：四個工作流
Distill（沉澱）——最常用
觸發時機：剛除完一個錯、做完一個技術決策、跑完一輪測試。流程長這樣：
flowchart TB
T(["觸發：「這個坑寫進 wiki」"]) --> S["讀 schema 與 index"]
S --> B{"換一個專案
還用得到嗎？"}
B -->|用得到| N["wiki/notes/"]
B -->|只在這個專案成立| P["wiki/projects/{專案名}/"]
N --> G["Glob / Grep 搜既有頁"]
P --> G
G -->|已有同主題頁| A["補進既有頁"]
G -->|沒有| D["草稿給使用者確認"] --> C["寫新頁"]
A --> L["與相關頁互加 wikilink"]
C --> L
L --> I["更新 index.md"] --> LG["append log.md"]
歸屬判準就是圖裡那句：換一個專案還用得到 → notes/；只在這個專案成立 → projects/{專案名}/。 同一次沉澱常常兩邊都寫：通用技巧進 notes/，這次的來龍去脈進 projects/，兩頁互連。
一次沉澱不是只寫一頁。摘一筆真實的日誌（專案細節隱去）感受一下規模：
1 | ## [2026-08-10] distill | 兩筆固定值偏離慣例的修正 |
新增一頁、更新三頁、記下根因和下一步——這種「一個發現輻射到多頁」的維護，正是人手不會做、LLM 卻做得很甘願的雜活。
Ingest（匯入來源）
把文章、論文、逐字稿丟進 raw/，說 /ingest <檔名>。流程：讀全文 → 先回報 5–10 條要點與「會新增／影響哪些頁」→ 我確認後才寫來源摘要頁（S001-標題.md 這樣編號）→ 更新受影響的實體頁、概念頁 → 有衝突就雙方標註 disputed。raw/ 對 LLM 是唯讀的，連錯字都不改——要修正就寫在 wiki 頁裡註明。
誠實聲明：這條軌道我四天還沒用過（S001 還沒出生），流程是照 Karpathy 原始模式設計的，等第一份來源進來實測。
Query（提問）
「wiki 裡有沒有…」「之前怎麼解的」。它會先讀 index.md 找候選頁、再讀內文，回答一律附引用，而且必須區分三種內容：wiki 裡有的（附出處）、它自己的推論（標「推論」）、wiki 裡沒有的（明說沒涵蓋，建議去找什麼）。
有保存價值的答案（比較表、新發現的關聯）會問要不要存成 synthesis/ 的一頁——探索成果不該留在對話紀錄裡蒸發，這條跟整個系統的初衷一致。
Lint（健檢）
/lint 會逐項掃：斷鏈、孤兒頁、未解的矛盾、過期宣稱、被提及多次卻沒有自己頁面的主題、缺出處的頁、歸屬錯誤（notes/ 裡其實只在單一專案成立的內容）、機密外洩、frontmatter 格式、重複頁。先出報告，我同意才動手修。建議節奏是每 10–15 份來源跑一次。
步驟四：搭配 Obsidian
把 vault 根目錄選在知識庫資料夾就好。Karpathy 建議的用法是左邊 Claude Code、右邊 Obsidian：LLM 邊改，你邊看——跟著 wikilink 跳、看 graph view、讀剛更新的頁面。
實際有用的三個功能：graph view 看 wiki 的形狀（什麼連到什麼、哪些是樞紐、哪些是孤兒——孤兒頁在圖上一眼就看到）；Dataview 對 frontmatter 下查詢（欄位固定的好處，例如列出所有 status: disputed 的頁）；Web Clipper 一鍵把網頁轉 markdown 存進 raw/。
唯一的紀律：LLM 不碰 .obsidian/ 目錄，兩邊互不干擾。
實際踩到的坑
檔名裡的 # 會被 Obsidian 當成標題錨點。 有一頁叫「SQL邏輯搬進C#的語意陷阱」，wikilink [[SQL邏輯搬進C#的語意陷阱]] 在 Obsidian 裡會被解讀成「頁面 SQL邏輯搬進C ＋ 錨點 的語意陷阱」——證據是我的知識庫根目錄躺著一個空殼檔 SQL邏輯搬進C.md，應該就是在 Obsidian 裡點了這個連結時自動生出來的。schema 的檔名禁字清單（\ / : * ? " < > |）是照 Windows 限制訂的，沒想到 Obsidian 的 wikilink 語法還要多避開 #（錨點）和 ^（block 引用）。C# 相關的頁名，老實寫成「CSharp」。
敏感值的代換要在寫入當下做，不能指望事後掃。 知識庫在工作機上，內容涉及公司專案。實際的做法是寫入時就代換——例如分析資料庫 trace 的筆記裡，登入帳號直接寫成 <內部帳號>，日誌裡也記一筆「敏感值處理」交代代換了什麼。Lint 有機密外洩檢查兜底，但最好的狀態是根本不落地。
搬舊資料時，錯誤會一起搬進來。 我的庫是從一個舊 vault 併過來的，搬入時刻意「內容不動、只補 frontmatter」——結果舊筆記裡一個記載錯誤（測試時驗證碼的處理方式寫反了）也原封搬入，直到後來一次相關沉澱才抓到。更正時標注原因、保留錯誤紀錄。教訓是：搬移不等於審查，舊資料的可信度要打折，發現錯就照「矛盾要留下」的鐵則處理。
README 建議用 git 管版本，我自己還沒做。 wiki 全是 markdown，git init 就有演進歷史和還原能力，每次 ingest 完 commit 一次就好。目前 33 頁還小所以一直拖著，但這件事越早做越便宜——寫壞了能還原，這對「LLM 擁有整個 wiki/ 寫入權」的系統不是小事。
節奏建議與規模上限
README 裡給自己的四條節奏建議，四天下來覺得都成立：
- 一次匯一份來源，讀 LLM 給的要點、確認它抓對重點再讓它寫。前十份特別重要——這段時間你會發現 schema 哪裡不合用。
- 覺得哪裡寫得不對，就叫它改
CLAUDE.md。schema 是活的。 - 每 10–15 份來源跑一次
/lint。 - 重要的提問結果一定要歸檔，別讓探索成果蒸發在對話紀錄裡。
規模上限：索引式導航（讀 index.md → 跳相關頁）大約撐到 100 份來源、數百頁。超過之後再考慮加本機搜尋工具（例如 qmd，BM25＋向量混合檢索，有 CLI 也有 MCP server）。在那之前，不需要任何額外基礎設施——這也是這套系統最舒服的地方：它就是一個資料夾的 markdown。
留言