用 CLAUDE.md 把 AI 變成你的 Obsidian 知識庫維護者¶

摘要¶

這篇筆記整理了我目前在 Obsidian vault 裡使用的 CLAUDE.md——一份給 Claude 看的操作手冊，讓 AI 從一個逐輪聊天的工具，變成能夠持續維護、查詢、健康檢查我個人知識庫的「唯一維護者」。

核心概念來自 Andrej Karpathy 對 LLM Wiki 的設計理念：AI 不只是回答問題的工具，而是知識庫的主動整理者。本文描述的是我的 vault-specific 版本，不是 Karpathy 原始設計，也不是 coding guideline——而是一個針對知識整理與發布工作流的操作規則集。

這份 CLAUDE.md 解決什麼問題¶

一般人用 AI 的模式是：問問題→得到答案→結束。每次對話都是孤立的，AI 沒有記憶，知識也不會累積。

這個問題在個人知識管理（PKM）場景裡特別明顯：你把一篇論文丟給 Claude，它給你一個摘要，但這個摘要不會自動和你之前整理的相關概念連結，也不會被存進你的筆記系統——除非你自己動手。

CLAUDE.md 要解決的就是這個問題。它做了三件事：

定義 AI 的角色與邊界：明確告訴 Claude「你是這個 wiki 的唯一維護者」，而不是一個泛用問答機器。
建立操作協議：Ingest 怎麼做、Query 怎麼回答、Lint 要檢查什麼，都有明確步驟。
設定資料夾權限：哪些資料夾可以動、哪些絕對不能碰，用結構性規則防止 AI 出軌。

核心設計：把 AI 從聊天工具變成知識庫維護者¶

這個設計的關鍵轉換在於：把 AI 的行為從「回答」轉換為「維護」。

傳統用法是：你問，AI 答。知識停在對話裡。

LLM Wiki 的用法是：你餵資料，AI 整理進 wiki；你問問題，AI 從 wiki 合成答案；你定期讓 AI 做健康檢查，確保知識庫的一致性。

這個轉換需要幾個前提：

AI 每次進入對話時都能讀到這份操作手冊（CLAUDE.md），知道自己在哪個脈絡下工作。
知識庫有固定的資料夾結構與頁面格式，讓 AI 知道去哪裡找、怎麼寫。
有明確的「黃金原則」：Wiki 是累積的，只增加與修正，絕不刪除有來源標記的資訊。

這個設計讓每次對話都不再是一次性的——AI 的輸出會沉澱進知識庫，下次對話可以在這個基礎上繼續。

三個基本操作：Ingest / Query / Lint¶

Ingest：消化新資料¶

當我說「幫我消化這篇」，或把文件放進 Sources/ 資料夾時，Claude 會：

閱讀來源文件，提取實體、概念、主張、數據。
逐一判斷：Wiki 裡是否已有對應頁面？
有 → 更新（加入新資訊，保留舊資訊）。
沒有 → 新建頁面。
在每個更新或新建的頁面底部標記來源與日期。
更新 Wiki/_Index.md 的頁面清單。

黃金原則再強調一次：知識只能累積，不能被覆蓋刪除。

Query：回答問題¶

當我問問題時，Claude 不是直接用訓練資料回答，而是：

先讀 Wiki/_Index.md，確認知識庫裡有哪些頁面。
讀取相關頁面。
從 wiki 內容合成答案。
若分析過程中產生新洞見，主動新建一個 type: synthesis 的綜合分析頁面。

這樣的設計讓答案有出處，也讓分析本身成為知識庫的一部分。

Lint：健康檢查¶

當我說「幫我做 lint」，Claude 會掃描整個 Wiki，找出：

互相矛盾的主張。
過時資訊（有明確日期可判斷的）。
孤兒頁面（沒有被其他頁面連結的）。
明顯的資訊缺口。

最後產出一份報告，逐條列出問題與建議修正方式。

這個操作讓知識庫不會隨著時間累積變成一堆雜亂、矛盾的碎片。

資料夾權限與安全邊界¶

這是 CLAUDE.md 最重要的「結構性保護」。我的 vault 有幾個資料夾有明確的讀寫限制：

Sources/：原始資料，只讀。Claude 可以讀來消化，但絕對不能修改。
Wiki/：Claude 的主戰場，可以建立與更新頁面。
Notes/：使用者私人筆記，Claude 不能動。
docs/：MkDocs 公開網站來源，只放已整理完成且通過發布條件的內容。

這些限制不是信任問題，而是職責分工。Sources/ 保留原始性，Notes/ 保留私人空間，Wiki/ 才是 AI 的工作區域。

此外有幾條禁止事項： - 不捏造資訊。若不確定，寫「待確認」。 - 不刪除有來源標記的資訊，只能標注「已更新」或「待驗證」。

從 Obsidian 到 GitHub Pages 的發布流程¶

知識整理的最終目標是讓有價值的內容可以對外分享。整個流程是：

AI 協助整理（Claude / Codex / GPT）
        ↓
Obsidian Vault（單一事實來源）
        ↓
GitHub Private Repo（版本控制 / 備份）
        ↓
MkDocs（公開知識網站建置）
        ↓
GitHub Pages（對外發布）

AI 產出的工作流¶

當 AI 回答問題或產生分析時：

先回答問題。
再產生可保存的版本。
轉換成 Obsidian Markdown 格式。
新內容預設先放 Inbox/，整理完成後再移至 Knowledge/。

這個「先草稿，後整理」的設計避免了知識還沒成熟就被錯誤分類。

發布到 MkDocs 的條件¶

不是所有筆記都適合公開。只有符合以下條件的內容才能移入 docs/：

已整理完成，不是草稿。
有摘要。
有案例或實作範例。
有自己的理解與詮釋（不只是轉述）。
不含私人資訊、敏感資料或不適合公開的內容。

Git 使用規則¶

GitHub private repo 用於版本控制與備份，不是發布管道。
不把大型原始資料、private data、API keys、token、.env、資料庫檔放進 Git。
GitHub Pages 只發布 MkDocs 從 docs/ 產生的內容。

為什麼要把 Coding Guidelines 與 Vault Rules 分開¶

這個分流設計是整個架構裡我最想強調的一個決策。

我的 vault 根目錄有這份 CLAUDE.md，負責知識庫的操作規則。但我另外還有 coding 任務——修改 scripts、整理其他 repo 的 CLAUDE.md。這兩件事的規則是不同的，甚至有時候是互相矛盾的。

Coding guideline（參考自 multica-ai 整理的 Andrej Karpathy coding 準則）強調的是：測試、最小化 diff、不要重構沒壞的東西。

Vault rule 強調的是：只增加不刪除、保留來源標記、用 Obsidian 語法連結。

如果把這兩套規則混在同一個文件裡，AI 在做知識整理時可能會套用 coding 思維（例如「刪除重複」），反而破壞 wiki 的累積性。

解法是明確分流： - 維護知識庫、整理筆記、發布 docs 時，優先遵守 vault CLAUDE.md。 - 進行 coding 任務時，引用獨立保存的 coding guideline 文件。 - 兩份文件互不干擾。

可複用的實作原則¶

如果你想在自己的 vault 複製這個設計，以下是最核心的幾個原則：

明確角色定義：在 CLAUDE.md 第一行就說清楚「你是這個 wiki 的唯一維護者」，而不是讓 AI 自己猜。

用資料夾結構代替規則描述：與其寫「不要動私人筆記」，不如直接定義 Notes/ 是禁止修改區。結構比文字更難被誤解。

操作步驟要明確到可執行：「整理資料」是沒用的指令。「讀取來源 → 提取實體 → 比對 wiki → 更新或新建 → 標記來源 → 更新 index」才是可執行的步驟。

累積性是 wiki 的核心不變量：這一條必須寫進禁止事項，不能只是原則。AI 天生有「整合與刪除重複」的傾向，必須明確抑制。

發布條件要具體：「整理完成」不是條件，「有摘要 + 有案例 + 有自己的理解 + 非草稿」才是條件。模糊的條件等於沒有條件。

分流管理不同脈絡下的規則：如果你同時用 AI 做知識整理和 coding，把兩套規則放在不同文件，在不同脈絡下引用不同文件。

延伸閱讀¶

Andrej Karpathy 關於 LLM Wiki 概念的討論（可搜尋其 X / Twitter 貼文與訪談）
multica-ai 整理的 CLAUDE.md coding guideline（GitHub：multica-ai/andrej-karpathy-skills）
MkDocs 官方文件（mkdocs.org）——用於設定 docs/ 到 GitHub Pages 的發布流程
Obsidian 官方文件——特別是 frontmatter 與內部連結（[[]] 語法）的設計

附錄：我的 CLAUDE.md 原文¶

這是本文的參考附件，不是另一篇需要先讀的文章。建議先讀完本文，再回頭看實際原文：

本筆記整理自我目前 Obsidian vault 根目錄的 CLAUDE.md。核心概念參考 Andrej Karpathy 的 LLM Wiki 設計理念，以及 multica-ai 整理的 CLAUDE.md coding guideline，但本文重點是 vault-specific 的知識工作流，不代表 Karpathy 或 multica-ai 的原始設計。