如何用 AI 做個人知識管理：我的 LLM Wiki 流程

我現在做知識管理，最在意的是：那些已經被我記下來的東西，之後到底能不能用得上。記更多反而不是重點。

我以前其實是用 Notion 做知識管理：看到文章時，會先把文章複製到 Notion 裡，再寫下自己的感想，最後設定幾個我覺得對應的標籤，之後就靠這些標籤把資料找回來。這套流程有用，但它很吃我當下有沒有標對、後面有沒有繼續整理。

所以我現在採用的原則是：來源先封存、想法再疊加、AI 最後整理。人負責留下真實來源跟當下判斷，AI 則在明確規則下，把碎片整理回一個可以查詢、可以維護、也可以反覆擴充的知識庫。

底層邏輯：知識管理的負擔其實是維護結構

寫筆記本身不是最困難的。真正耗力的是後面的結構維護：這則筆記要放哪裡、跟哪些主題有關、要不要更新既有頁面、是不是需要建立新概念，還有舊結論有沒有被新資料修正。

如果這些事情都靠自己手動做，知識庫很快就會變成另一份工作。筆記越多，維護成本越高；分類越細，越容易在整理之前就先放棄。這也是我以前覺得知識管理很有價值，但很難長期維持的原因。

Notion 的標籤流程其實解決了一部分問題：我可以靠標籤搜尋，把同一類素材找回來。但標籤更像索引，不是理解。它不會主動把文章、感想跟舊概念接起來，也不會提醒我哪些內容該合併、拆開或更新。

AI 對我最有用的地方，是接手那些我很容易偷懶的維護工作：補連結、整理索引、檢查重複概念、更新 MOC，或提醒哪些內容該合併、拆開、回頭驗證。

我的核心方法：來源先封存、想法再疊加、AI 最後整理

我目前的底層做法，比較接近 Karpathy 提到的 LLM Wiki。它會把來源、整理後的 Wiki、規則跟操作紀錄拆開，讓人跟 AI 都知道每一種內容應該放在哪裡。

第一層是原始來源。文章、逐字稿、截圖、想法片段都先保留下來，不急著改寫成漂亮結論。這一層的重點是可追溯，之後整理出來的任何觀點，都要能回頭找到來源。

第二層是我自己的理解。我會把讀完、看完、想到的東西補成一段自己的判斷：我同意哪裡、懷疑哪裡、它可能跟哪些舊概念有關。這一步很重要，因為知識庫只存資料不夠，還要留下我如何理解這些資料。

第三層才交給 AI 整理。AI 依照 Schema、Dictionary、MOC、log 這些規則，把新內容接回 Wiki：該補到舊頁的補舊頁，該建立新概念的建立新概念，該放進索引的放進索引。這就是我說的「AI 最後整理」。

來源怎麼進來：Obsidian、網頁顯示層、Memo

我會選 Obsidian，是因為它把筆記留在本機 Markdown 檔案裡。這讓知識庫不會被鎖在某個 SaaS 資料庫裡，也比較容易被 Git、腳本、Codex 或其他 AI agent 讀取跟處理。

但我現在不再把 iCloud 同步當成主要儲存跟顯示方式。知識庫的核心仍然是一組可被 agent 操作的 Markdown 檔案；真正需要跨裝置時，我比較偏向把它整理成網頁來看，而不是讓每台裝置都同步整包筆記庫。

原因也很現實：手機上的 Obsidian 編輯體驗的確不差，但我實際上很少在手機上編輯這些深度筆記。多數時候只是瀏覽、搜尋、回查某個概念。當文本量變多，如果繼續用同步方式處理，速度會變慢，也比較不直覺。

所以我現在會把「儲存 / 編輯」跟「顯示 / 瀏覽」拆開看。資料層維持在適合 Git、腳本、Codex 跟 Multica 讀寫的位置；閱讀層則用網頁呈現，讓手機或其他裝置只需要打開、搜尋、瀏覽。這比把所有裝置都變成編輯端更符合我的使用方式。

網頁顯示層怎麼實作：Quartz + GitHub + Cloudflare Workers

目前 SecBrain 並不是把 Obsidian vault 丟到某個同步資料夾就算了。我把它整理成一個 private GitHub repo：content/ 裡放可以發布的知識庫內容，包含 00-規範、10-來源、20-Wiki、log、index.md 跟 觀察清單.md。這樣做之後，它就不再是散落的筆記資料夾；agent 可以改 Markdown，Git 可以留下版本，build pipeline 也可以把它部署成網站。

網頁層用 Quartz 把 Markdown build 成靜態網站，再用 Cloudflare Workers Static Assets 發出去。GitHub 接上之後，main 有新的 commit，就能觸發 Cloudflare Workers Builds 重新跑 npm run install-plugins && npx quartz build，把輸出的 public/ 部署成可瀏覽網站。對我來說，這比「每台裝置都同步一份完整 vault」清楚很多：GitHub 是版本跟部署邊界，網站是閱讀入口。

我也有針對手機瀏覽做取捨。左側的站名、搜尋、閱讀模式、本頁目錄跟 Explorer 被收進同一個浮動選單；手機上不啟動 graph runtime，contentIndex.json 也只保留每頁前 384 字摘要，避免整個 vault 的全文跟圖譜一次塞進瀏覽器。我沒有想把手機版做成縮水版，只是讓手機回到它最適合的角色：快速搜尋、瀏覽、回查，不承擔主要編輯。

影音來源：先用 Memo 把 YouTube 變成可整理的文字

如果來源是 YouTube，我不會只把影片連結丟進知識庫。影片本身很難被搜尋、引用跟重新整理，所以我會先把它轉成可以閱讀的文字來源。

目前我會用 Memo 做語音分析跟字幕爬取。Memo 不負責替我下結論；它先把影片變成逐字稿，保留影片連結、必要的時間脈絡，以及後續可以引用的原始內容。

接著我會把自己的想法疊上去：這支影片哪裡有啟發、哪裡跟我原本的理解不同、哪幾段值得之後回頭看。這樣進入 Wiki 的內容，就會多一層我當下的判斷；影片摘要只是底稿。

最後再讓 LLM 依照 LLM Wiki 的規則吸收進系統。它可以判斷這段內容應該補到哪個既有概念、是否需要建立新頁、要連到哪張 MOC，或只適合先留在來源層等待之後整理。

這套流程讓影音內容不再只是「看過」。只要先把影音轉成可靠文字，再加上人的判斷，後面就能讓 AI 協助分類、連結跟回收，變成知識庫裡可以長期使用的材料。

我怎麼用 Codex / Multica 跟 Dictionary 對話

我的互動方式不是打開一個通用聊天機器人，然後期待它猜懂我的知識庫。我會在 Multica 裡建立專門角色，讓它知道自己面對的是特定 Wiki，而不是一場沒有上下文的閒聊。

這個角色會讀取專門的 Dictionary，理解這個知識庫裡有哪些名詞、資料夾規則、Wiki 結構、MOC 入口跟常見互動方式。當我提出問題時，它會把問題、Dictionary、既有 Wiki 內容跟當下任務一起考慮。

例如我可能會問：「我最近一直在想 AI 跟知識管理的關係，幫我找出 SecBrain 裡已經有哪些相關知識點，哪些地方還沒有整理成穩定結論。」這時候 AI 有用，是因為它幫我看見自己已經知道什麼、還缺什麼、哪些概念可以接起來。

這套方式不一定只能綁在 Multica。只要一個系統能讓角色讀取對應的 Dictionary、知識庫內容跟互動規則，它也可以接到 Codex、CoWork 或其他 agent 系統。Multica 只是我目前的入口，重點是這三件事要同時存在：專門角色、專門知識庫、可反覆整理的互動流程。

讓知識庫維持健康：ingest、query、lint

知識庫能不能長期有用，不只看一開始怎麼建立，也看後面怎麼維護。我會把知識庫 Bot 的工作拆成三個固定動作：ingest、query、lint。

Ingest 是把新資料放進系統。它先保留原始來源，再確認這段內容代表什麼、要不要更新既有概念、是否需要放進某張 MOC，最後才寫入 Wiki 層跟 log。

Query 是帶著問題回到知識庫。AI 不應該只靠聊天記憶回答，而是先找 MOC、index 或相關頁面，必要時回查原始來源。好的回答如果產生新的連結或觀點，也應該能回流成筆記，而不是消失在對話紀錄裡。

Lint 是定期健康檢查。知識庫會有死連、重複概念、過時說法、命名不一致、同一觀點在不同頁面漂移。當筆記也要給 AI 用，這些問題會直接影響後續回答品質。

這三個動作的目的，是讓知識庫不要變成另一種聊天紀錄。新資料要能進來，舊資料要能被查到，系統本身也要定期被檢查，AI 才不會只是幫我多產生一堆文字。

GitHub 接進來後，這三個動作也有更清楚的版本邊界。Ingest 可以變成 Markdown diff，不會散落在聊天紀錄裡；lint 的修正可以被 review；如果某次整理不理想，也能從 commit history 回頭。這讓知識管理更像在維護一個長期專案，資料不會只是在不同 app 之間搬來搬去。

對 agent 來說，GitHub 還有一個好處：我可以要求它針對某個主題開 branch、做小範圍修改、跑檢查，再用 diff 或 PR 回看。這比直接在 SaaS 文件裡改一大段更容易知道這次到底改了什麼，也比較適合長期累積。

這套方法適合誰，以及要注意的邊界

• 適合已經有 Obsidian、Markdown 或本機筆記習慣的人；如果所有資料都只在封閉 SaaS 裡，AI agent 能處理的空間會比較小。
• 適合想把「讀過、看過、想過」重新變成可查詢材料的人；如果只是要快速摘要單篇文章，用一般 AI 摘要工具就夠了。
• 原始來源跟整理結果要分開，原文不要被 AI 改寫蓋掉，否則之後很難判斷某個結論是來源說的，還是 AI 整理時推論出來的。
• 重要判斷要回到人的理解跟確認。AI 可以協助歸檔、連結跟檢查，但不應該替我決定哪些結論已經可以被當成穩定知識。
• MOC、index、Schema、log 要穩定存在，讓下一次 AI 進來時知道系統目前長什麼樣，而不是每次都重新猜一次。
• 影音逐字稿要保留影片連結跟必要時間脈絡，自己的想法也要跟原始逐字稿分清楚。
• 手機端主要拿來瀏覽時，不一定要同步整包筆記庫；網頁顯示層通常會比跨裝置同步更直覺。
• 儲存、編輯跟顯示最好分開思考：Markdown 檔案是 agent 可操作的資料層，網頁是閱讀層，不要為了行動裝置瀏覽把整套流程綁回同步服務。
• 網頁顯示層要跟權限控管一起設計。只要內容上雲，就要先決定哪些內容能發布、哪些素材只留在 repo 或外部備份，必要時用 Cloudflare Access 這類權限層擋住。
• 這套做法的 token 消耗量會比較高，因為每次互動可能會讀 Dictionary、MOC、Wiki 頁跟來源摘要。它適合深度整理跟探索，不一定適合每一則零碎筆記都完整跑一次。

Notion 跟 Obsidian 各自適合什麼

這裡也要回到工具選擇。Notion 不是不適合知識管理，它更像一套多人協作的文件系統。當目標是多人編輯、多人維護、集中管理一份有明確主題的文件或專案資料，Notion 很順。它適合當文件中心、專案管理系統，或團隊共同維護的資料庫。

但如果目標是個人數位大腦，尤其是要跟自己電腦裡的 agent 系統連在一起，Notion 就沒有那麼直接。資料在 SaaS 裡，AI 要讀寫通常要經過 API、權限跟資料結構轉換，維護成本會比較高。

Obsidian 的優勢則在於它原生就是一組 Markdown 檔案。只要 AI agent 能讀寫檔案，就能直接吃到筆記，也能修改、拆分、補連結或整理 MOC。這也是我會把個人知識庫放在 Obsidian / Markdown 上的原因：它比較像可以被人跟 AI 一起操作的本機工作區。

收束：知識庫是一個人機協作的工作現場

對我來說，AI 幫不了我理解知識，但能幫我維持那段最容易被我放掉的整理工作。

理解、取捨跟判斷還是我的事。AI 能做的是把想法接回結構，把對話中浮出的概念回寫到 Wiki，也定期檢查這套系統有沒有開始長歪。

最後留下來的，是一個我跟 agent 都能回來工作的地方；查詢、整理、檢查，都有固定入口。