標準標籤系統 (Taxonomy) 標籤：AI, 工作流, 系統架構

個人知識庫的 AI 化重構：從碎片到系統

1. 核心觀察：筆記從來就假設讀者是人

在導入 AI 輔助工作前，我們的筆記幾乎都是寫給未來的自己看的：跳過已內化的前提，只寫需要提醒自己的那一小段。Michael Polanyi 講的「默會知識（tacit knowledge）」——我們知道的比說得出來的多——放在筆記情境裡，意思是寫筆記的人和讀筆記的人共享同一段生活脈絡，省略的上下文不會造成理解斷裂，讀者的腦子會自動補上。

問題是 AI Agent 沒有那段共享脈絡，讀到的只有字面。當上下文停留在「默會」而非「外顯」，AI 不是讀不懂，是會用自己的假設填補空白——這正是幻覺最常見的來源之一：不是模型編造事實，是結構逼它猜測本該寫清楚的關聯。舊結構在人類讀者面前運作良好，換成 AI 當第一線讀者，就成了幻覺的溫床。

2. 解決方案：把 Vault 當成一個需要治理的共有資源

我們把 ObsidianBook 重新設計為 AI-Ready 的真相層（Truth Layer）。這背後其實是個治理問題：當 Claude、Gemini、Codex 同時讀寫同一個知識庫，它就不再只是「我的筆記」，而可以借用經濟學家 Elinor Ostrom 研究**共有資源（commons）**時的治理視角來看。這裡不是把檔案庫直接等同於漁場或牧場，而是借用她歸納的第一項設計原則：清楚界定資源與合法使用者的邊界。放到 vault 裡，就是先說清楚哪些區域做什麼、哪些流程可以改它。

A. 三層分工架構

把邊界具體畫在資料夾上：

1. Inbox（收件箱）：人類的輸入端，隨手的想法與會議記錄，刻意保持低摩擦。
2. Knowledge & Sources（知識與來源）：結構化儲存庫，每篇都要有明確的 type、status、source 與 related。
3. Action（行動）：進行中的草稿與規格書，允許隨工作進度持續改寫；知識與來源層的變更則走各自的整理、編譯與關係治理流程。

邊界不是為了美觀，是讓每一層的讀寫規則對應真正的使用條件——Ostrom 第二條原則「規則要與在地條件相稱」的白話版：Inbox 要的是速度，Knowledge 要的是穩定，兩者共用一套規則，其中一邊一定出問題。

B. AI Entry Shared Block（單一真相來源）

Ostrom 的研究恰好不是說「沒有中央權威就必然崩壞」，而是指出使用者能在清楚邊界、監督與衝突處理等條件下自我治理。對這個 vault 而言，多個 AI 客戶端各自維護一份規則文件——CLAUDE.md、GEMINI.md、AGENTS.md——會讓規則在某一份改了、其他份默默過期。解法是讓入口文件只做薄引用，實際規則集中在一份 AI-ENTRY-SHARED.md，確保「制度的改變只在一個地方發生」。

C. 自動化優化迴圈

透過 Review、Compile、Relation Audit、Connect 等分工，讓 AI 定期抓缺 Frontmatter 或孤立節點、把來源編譯成知識、清理錯線，再補齊缺少的語義連結。但這裡有個容易忽略的陷阱：若把「有沒有 related 連結」當成目標本身，AI 很可能為了達標而生成大量語意薄弱的連結湊數——這正是 Goodhart 定律：一旦指標變成目標，它就不再是好指標。這也是為什麼 vault 的實際規則要求先審計、再補線：連結錯亂或灌水要先被抓出來，才輪到補缺線，順序反過來，指標會比知識圖譜本身更快被優化壞。

3. 反方與判準：這套結構什麼時候是過度設計

如果唯一的讀者是你自己，筆記量不大，也沒有多個 AI 客戶端共讀，這整套治理成本很可能大於它解決的問題。要求每則筆記在捕捉當下就填齊 type、source、related，只會讓人在靈感最脆弱的那幾秒先面對一張表單，多數人會乾脆不記。這也是為什麼 Inbox 層刻意保持低摩擦、延後結構化——結構該在 COMPILE 階段才長出來，不該在捕捉瞬間就要求完整。

這不是紙上推演。這個 vault 自己就出過「結構壞了但沒人喊痛」的真實案例：sparse-checkout 抓不到路徑仍回退出碼 0，checkout 看起來成功，實際少一個檔；GitHub Contents API 回 404，程式碼把它降級成 partial 就繼續跑，週報草稿數長期是假的；10_Action/12_寫作/草稿/ 這個資料夾清空後，因為 git 不追蹤空目錄，直接從版控上消失；一支腳本遇到目錄不存在就默默 continue，語意連結的語料因此少掃了 26 篇。四種情況的共通點是：workflow 全部顯示成功，沒有一次觸發錯誤訊息。這正是舊結構的風險所在——AI 不是讀到錯的東西才出包，是在你毫無警覺的地方悄悄少讀、少連、少記，而流程看起來一切正常。

值不值得投入這套結構，可以用三個問題快速判斷：有沒有兩個以上 AI 客戶端會讀同一份知識庫？有沒有你會依賴 AI 輸出回溯過去決策依據的場景？這份知識庫會不會跨 session、跨機器共享？三題都不成立就先別做重結構；有兩題成立，才值得把治理成本花在邊界、單一真相來源與審計迴圈上。