如何用 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、iCloud、Memo

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

同步層我目前先用 iCloud，原因很現實：我的主要裝置都在 Apple 生態系裡，iCloud 對我來說已經足夠穩定，也不需要為了 AI 另外改變平常記筆記的位置。

但這不是說 iCloud 一定適合所有人。如果大量跨平台，Obsidian 官方同步可能會更穩。這裡真正的選擇標準不是品牌，而是同步層要可靠，讓 AI 操作的是同一份可預期的 Markdown 資料。

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

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

目前我會用 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 才能真的幫我擴展思考邊界。

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

• 適合已經有 Obsidian、Markdown 或本機筆記習慣的人；如果所有資料都只在封閉 SaaS 裡，AI agent 能處理的空間會比較小。
• 適合想把「讀過、看過、想過」重新變成可查詢材料的人；如果只是要快速摘要單篇文章，用一般 AI 摘要工具就夠了。
• 原始來源跟整理結果要分開，原文不要被 AI 改寫蓋掉，否則之後很難判斷某個結論是來源說的，還是 AI 整理時推論出來的。
• 重要判斷要回到人的理解跟確認。AI 可以協助歸檔、連結跟檢查，但不應該替我決定哪些結論已經可以被當成穩定知識。
• MOC、index、Schema、log 要穩定存在，讓下一次 AI 進來時知道系統目前長什麼樣，而不是每次都重新猜一次。
• 影音逐字稿要保留影片連結跟必要時間脈絡，自己的想法也要跟原始逐字稿分清楚。
• 同步層要可靠；如果跨平台需求變高，就應該優先考慮官方同步，而不是硬撐 iCloud。
• 這套做法的 token 消耗量會比較高，因為每次互動可能會讀 Dictionary、MOC、Wiki 頁跟來源摘要。它適合深度整理跟探索，不一定適合每一則零碎筆記都完整跑一次。

Notion 跟 Obsidian 各自適合什麼

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

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

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

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

對我來說，AI 不是知識管理的替代品，而是讓知識管理裡最容易被放棄的那一段，有機會持續運作下去。

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

這樣的知識庫就不只是倉庫，也不是單純的聊天紀錄，而是一個可以被查詢、被整理、被檢查，並且會隨著每次思考慢慢長大的工作現場。