比較
Obsidian + Claude Code：檔案、MCP 與可維護的 AI 知識庫
比較直接讀取 Obsidian vault、即時編輯器 context、MCP 與有來源的知識維護，選出 Claude Code 真正需要的最小整合層。
文章封包
Comparisons
使用 Obsidian vault 的繁體中文 Claude Code 使用者
8 分鐘閱讀
01
Claude Code 能存取本地 Markdown 時，直接讀取 vault 通常是最小且最清楚的起點。
02
IDE bridge 補上目前檔案與選取內容；Obsidian MCP 補上結構化 vault 操作或其他 client surface。
03
能連上 vault 不等於會維護知識；來源、過期、修訂與審查仍是另一個決策。
01
先給答案：從最小整合層開始
如果 Claude Code 已能存取你的 Markdown 資料夾，先讓它直接讀取需要的 vault 路徑。當缺少的是目前檔案與選取內容，再加 IDE bridge；當需要 Obsidian 指令、結構化 vault 操作或另一個支援的 client，再考慮 MCP。
這些連線都能改善存取，但不會自動建立可維護的 AI 知識庫。當答案要跨 session 與工具重用，還需要來源、provenance、刷新規則、衝突處理與人工審查。
02
四種 Obsidian + Claude Code 整合層
把直接檔案、編輯器 context、MCP 與內嵌 assistant 分開看，才能避免為同一件事安裝四套工具。選擇標準應該是目前缺少的能力，而不是哪個工具名稱最熱門。
- 直接檔案：Claude Code 讀寫它有權限存取的 Markdown；最適合一般搜尋、整理與修改。
- IDE bridge：把 Obsidian 目前檔案與選取內容傳給 Claude Code，檔案操作仍可保持直接。
- Obsidian MCP：提供結構化 vault tools、workspace context、Obsidian 指令或其他支援的 client。
- 內嵌 assistant：只有當你想在 Obsidian UI 裡直接對話與操作時才需要。
03
連得上 vault，不等於有可維護的 AI 知識庫
Vault access 解決的是 agent 如何看到或修改筆記；知識 lifecycle 解決的是哪個答案目前有效、它來自哪裡、來源改變時要刷新哪一頁，以及衝突是否需要人審。兩者可以組合，但不能互相冒充。
Obsidian 應繼續是人擁有的寫作與 Markdown 知識面。只有會影響未來 AI 工作的結論，才需要進入可追溯、可刷新、能跨 session 重用的知識層。
04
用 Wenlan 把 vault 當來源，而不是複製品
Wenlan 可以把 Obsidian vault 註冊為 read-only Source，按需重新同步 Markdown，再把來源與工作中確認的決策編成有引用、過期狀態與修訂記錄的 Pages。它不需要接管 Obsidian，也不應靜默覆寫人寫的 vault。
當同一份知識還要給 Codex、Cursor、ChatGPT 或其他 MCP client 使用時，Wenlan 提供的是共用的 knowledge lifecycle；Obsidian 仍保留人最容易閱讀與編輯的知識面。
- 原始 Markdown 留在 read-only vault；Wenlan 按需重新掃描、分段並索引目前內容。
- Atomic knowledge 保存會影響未來工作的事實、決策與修正。
- Pages 把相關證據編成目前答案，並保留引用與刷新狀態。
- Lint 與 review 暴露缺少來源、衝突、過期依賴與不安全的改寫。
05
一個最小的 Obsidian AI 知識庫流程
先選一個無風險的小主題，而不是導入整個 vault。確認 Claude Code 能讀到一篇來源筆記，再捕捉一個會影響未來工作的結論，蒸餾成頁面，最後從頁面回到來源檢查證據。
如果只需要查找與改寫 Markdown，到這裡可以停在 Obsidian。只有當答案需要跨 session、跨 client 保持一致，才增加 Wenlan 的 distill、lint 與 review 流程。
最小驗證循環
/brief Obsidian AI 知識庫
/capture <結論 + 來源 + 為什麼重要>
/handoff
/distill Obsidian AI 知識庫
/pages Obsidian AI 知識庫
/lint06
如何驗證整合真的可用
不要只看 plugin 或 MCP 是否顯示 connected。用一個 disposable note 做端到端驗收：確認誰能讀、誰能寫、目前檔案是否正確傳入、來源是否可追溯，以及失敗時哪個 process 擁有每一次寫入。
同時檢查 vault backup、模型供應商會收到哪些 context、bridge 是否只綁 localhost，以及自動化是否會改寫人擁有的筆記。連線能力不是 governance policy。
- 讀取一篇指定筆記，確認沒有把整個 vault 送進 context。
- 修改一篇 disposable note，確認權限與寫入者符合預期。
- 加入衝突來源，確認 lint 或 review 能把問題暴露出來。
- 重新開啟 client，確認目前答案能被找到並回到原始來源。
讓 vault 與 AI 知識庫各司其職
保留 Obsidian 作為人類可讀的知識面；答案需跨工具保持目前、可追溯且可審查時，再用 Wenlan 維護具引用的 Pages。
FAQ