你的 Notion 第幾次爛掉了？我用 LLM 維護我的個人知識庫，這次真的活下來了
我有三個爛掉的 Notion workspace。
第一個是大學時代建的，野心很大，分了十幾個資料庫，用了各種 relation、rollup，最後因為每次新增一個東西就要手動更新五個地方而放棄。
第二個是幾年前從 Notion 換 Obsidian 的時候建的。雙向連結的概念讓我很興奮，花了兩個週末把舊筆記全部搬過去，做了漂亮的知識圖譜。然後一個月後就完全沒在更新了。
第三個是去年底的。我告訴自己這次要簡單一點，不要過度設計。但還是爛了，原因一樣。
前幾個月，我找到了一個讓知識庫真正活下來的方法。這篇要聊的就是這件事。
核心答案先給你： 知識庫爛掉的真正原因是維護 cross-reference 的 bookkeeping 成本，不是你懶。這個成本可以外包給 LLM——你負責丟素材，LLM 負責整理和維護連結。具體做法是三層架構（raw/ + wiki/ + CLAUDE.md）加上一個遠端 inbox，讓靈感捕捉和整理完全解耦。
真正的問題不是你懶
這是我花了很久才意識到的事。
我以前以為筆記系統爛掉，是因為「沒有養成習慣」。所以我嘗試的解法也都圍繞習慣：在手機設提醒、在日曆排時間、買付費課程學怎麼用 Notion。
都沒用。
後來我才發現，筆記系統爛掉的真正成本不是「寫」的成本，是「維護」的成本。
寫一條新筆記其實不難，五分鐘就能寫一個。但是：
- 新筆記跟舊筆記有沒有關聯？要不要手動連結？
- 這個概念之前有沒有記過類似的？要不要去翻舊頁面、合併、去重？
- 之前寫的那個 tag 到底怎麼分類的？要不要統一？
每次新增東西，腦袋要同時記「我現在想記什麼」和「這跟我已經記過的東西有什麼關係」。
這個 overhead 太高了。人腦不適合做這件事，所以我們就不做了，系統就爛了。
你放棄的不是記筆記，你放棄的是持續整理筆記的 bookkeeping 工作。
LLM 非常適合做這件事
Bookkeeping——更新連結、補 cross-reference、找重複、做分類——是一種很機械性的工作。
它煩透人，但 LLM 不嫌煩。
這個洞察讓我想到一個完全不同的架構：不要讓自己維護 wiki，讓 LLM 去維護。
你的工作變成：看到有趣的事情，寫下來丟進去（原始素材）。 LLM 的工作是：定期整理那些素材，更新 wiki，補交叉連結，找概念之間的關係。
人做人擅長的（observation、sourcing、決策），LLM 做 LLM 不煩的（整理、維護、cross-reference）。
我的三層架構
LLM 維護個人知識庫的核心是三層架構：用 raw/ 存放你的原始素材、wiki/ 作為 LLM 維護的知識庫主體、CLAUDE.md 作為規範 LLM 行為的指引文件。三層各有不同的角色：
第一層：raw/（原始素材，只進不改）
你看到一篇文章覺得有趣，貼進來。你讀完一本書有感想，寫幾行。你今天用 AI 踩了個坑，記下來。
這一層的規則只有一個：不改、不刪、不整理。你只管丟，LLM 不能動這層的東西。
第二層：wiki/（LLM 維護的知識庫）
真正的 wiki 在這裡。每個概念一個 Markdown 檔，有 TL;DR、詳細說明、還有跟其他概念的交叉連結。
這層完全由 LLM 負責寫和更新——你不直接編輯這裡，讓 LLM 去整理。
第三層：CLAUDE.md（規範，讓 LLM 有紀律）
這是整個架構最關鍵的地方。
光說「去整理 raw/ 然後更新 wiki/」還不夠。LLM 需要知道：
- 什麼樣的東西值得獨立成一個 wiki 頁面？
- cross-reference 怎麼寫？
- 哪些東西屬於哪個分類？
CLAUDE.md 就是這套規範，告訴 LLM 如何維護這個 wiki。有了它，LLM 才不是隨機亂寫，而是有一致性的維護者。
規範的內容大概長這樣：
## wiki 維護規範
- 每個概念獨立一個 .md 檔，命名用英文小寫
- 每頁必須有 TL;DR（一句話）、詳細說明、和相關頁面的連結
- cross-reference 格式：[[概念名稱]]
- 判斷是否值得獨立成頁：這個概念在三個以上不同地方出現過
- 有矛盾的資料：兩個來源都保留，標記為 [CONFLICT]
這份規範越清楚，LLM 整理出來的結果越一致。
這三層的關係：
raw/ ← 你丟素材進去
wiki/ ← LLM 從 raw/ 整理出來
CLAUDE.md ← 規範 LLM 怎麼整理
遠端 inbox：把「靈感的時間」和「整理的時間」分開
三層架構解決了維護的問題，但還有另一個問題：靈感是在分散的時間出現的，但整理需要相對連續的注意力。
在捷運上滑到一段話覺得很有共鳴，在跟人吃飯時突然想到一個觀察，在洗澡時腦袋裡閃過一個連結——這些時候你沒辦法打開電腦好好整理，但你也不想讓它消失。
所以我在本地系統之外，加了一個遠端 inbox：一個 HTTP 端點，接受 POST 請求，把內容落到 inbox/pending/ 資料夾。用 Flask、Fastify、或任何你熟悉的框架都可以，10-20 行程式碼就夠了，有 Git 基礎的人半小時能搞定。
這樣的好處是：
- 任何地方都可以丟。手機、網頁、Claude Code session 直接 POST、未來還可以接 LINE webhook——所有入口丟進同一個 inbox。
- 丟進去的東西不會直接進 wiki。先躺在
inbox/pending/等你有空整理。 - inbox/pending/ 的待辦數量 =
ls inbox/pending/ | wc -l，最直觀的 backlog 指標，不需要資料庫。
整理的動作是分開的：有空的時候，叫 LLM 把 inbox/pending/ 的東西處理掉，更新 wiki，然後移到 inbox/processed/。
靈感的捕捉不等整理，整理不擋靈感，兩件事完全解耦了。
這跟「RAG 查詢」哪裡不一樣？
這個問題我自己也想了很久。
很多人說的「用 AI 管理知識」，其實是 RAG（Retrieval-Augmented Generation）：你有一堆筆記，丟進向量資料庫，然後用自然語言查詢。
這個方式有一個根本問題：每次查詢都從零開始。
RAG 每次 retrieve，找相關段落，組合答案。但它從來不會主動去「想」不同概念之間的關係，也不會去注意你在 A 筆記裡說的跟 B 筆記裡說的有矛盾，更不會主動建立 cross-reference。
LLM 升格成 maintainer 的差別是：知識是 compound 的。
每次 LLM 更新 wiki，不只是「把這條新資料摘要一下放進去」，而是思考「這條資料跟已有的哪些概念有關？要更新哪些 cross-reference？有沒有矛盾需要解決？」
這個差別讓知識庫越用越強，而不是一堆孤立的筆記。
用起來是什麼感覺？
最直接的感受是：我現在在不同的 Claude Code session 之間切換時，可以把個人 context 帶著走了。
以前我在 A session 寫文章，在 B session 做工具，在 C session 規劃事情——這三個 session 互相不知道對方發生了什麼，每次都要從頭解釋背景。
現在寫文章之前，我會讓 Claude 先看一下 wiki 裡跟這個主題相關的內容——我以前怎麼思考的、有沒有相關的觀察、有沒有踩過相關的坑。知識流通了，每個 session 可以建立在之前的成果上，不用每次從零開始。
就像我之前寫的「五月才過七天，我快有 500 個 commits」裡提到的——AI 的價值不只是讓你更快，而是讓你的工作可以在不同地方之間流通。知識庫就是讓「你的個人 context」也能流通的基礎建設。
跟 Karpathy 的版本差在哪？
你可能看過 Andrej Karpathy（OpenAI 創辦成員、Tesla 前 AI 總監）分享他的 LLM Wiki 系統。那個貼文在 X 上獲得 1,600 萬次瀏覽，讓他建出了一個 100 篇文章、40 萬字的個人知識庫，幾乎沒有一個字是他自己手寫的。
我的系統核心概念跟他很像，但有幾個差異：
Karpathy 版本：
- 主要用 Obsidian 做視覺化瀏覽
- 以學術研究為主（論文、技術文章）
- 系統相對精密，需要一定的設定成本
我的版本：
- 純 Markdown + Git，沒有額外工具依賴
- 個人生活向的 commonplace book（entries、quotes、ideas、observations）
- 遠端 inbox server（這個 Karpathy 版本沒有）
- 更輕量，設定成本低
如果你是要管理學術研究，Karpathy 版本更完整。如果你想管理的是「個人觀察、生活洞察、隨手的想法」，我這個版本更適合。
常見問題
這樣的系統設定起來複雜嗎？
不複雜，但要有一點 Git 基礎。核心架構就三個資料夾（raw/、wiki/、inbox/）加一個 CLAUDE.md 說明規範。初始設定一個下午可以搞定，之後維護幾乎不需要人力。
LLM 整理出來的 wiki 品質怎麼樣？
品質跟 CLAUDE.md 的規範有直接關係。規範寫越清楚，LLM 整理出來的東西越一致。初期可能需要幾次調整，找到你喜歡的分類和格式，之後就會穩定下來。
我現有的 Notion/Obsidian 筆記怎麼辦？
可以整批倒進 raw/，讓 LLM 重新消化整理進 wiki。這也是這個系統的好處之一——它不在乎你的舊資料長什麼樣，LLM 會負責把它轉換成一致格式。
LLM 維護和自己維護，差別到底是什麼？
自己維護知識庫，每次新增一條資料你都要同時思考「這跟我以前記過的什麼有關係」——這個 overhead 累積起來，才是系統爛掉的真正原因。LLM 維護的差別是：你只管丟素材，cross-reference 和分類的工作整批交給 LLM 在你有空的時候一次處理，不拖慢你捕捉靈感的速度。
結論
個人知識庫爛掉，真正的原因是維護 cross-reference 的 bookkeeping 成本，不是你沒有時間或不夠勤奮。
這個成本現在可以外包給 LLM。你做人擅長的：觀察、捕捉靈感、做判斷。LLM 做它不嫌煩的：整理、連結、維護。
這個分工讓知識庫第一次真正活過了三個月，目前 wiki 已經有將近 60 個概念頁面，還在持續增加中。
如果你對 AI 如何從「工具」變成「替你工作的人」感興趣，可以看看這篇：「五月才過七天，我快有 500 個 commits——這不是工具用更快，是 AI 在替我幹活」，裡面有完整的概念框架。
希望這篇對你有一丁點兒的幫助，讓你下一個知識庫不會是第四個爛掉的😄
喜歡這篇文章嗎？
📧 訂閱 Newsletter — 新文章直接寄到你信箱 🎬 追蹤我的 YouTube — 看 AI / 工具實作影片 💬 加我的 LINE — 有問題隨時問我 🧵 追蹤 Threads — 平常的工程隨筆
掰掰～👋
