選型指南
如何選 AI 知識庫工具：8 個真正重要的檢查
先分清文件問答、RAG、筆記工具與維護型知識庫，再用來源、更新、審查、資料控制與實測結果選擇工具。
關於這篇指南
工作流程
正在選擇文件問答、RAG、本地筆記或跨 AI agent 知識系統的繁體中文使用者
8 分鐘閱讀
01
先選操作模式，再比較功能清單。
02
用來源改變與衝突測試答案是否仍可追溯、可更新。
03
用自己的小型文件集對每個候選工具執行同一套驗收。
工作流程比較指南
換一種工具，平常的工作會怎麼變？
先看哪些工作想保留，再決定哪些交給工具。以下依公開文件整理適用情況，不是易用性實測，也不是每個人都該換工具的結論。
來源核對：2026-09-07 · 依官方文件與原始碼整理，並非實機效能評比。
01
Wenlan 的設定、模型與脈絡
Wenlan 欄位背後共用的設定與證據邊界。
讓你和 AI，共用隨工作累積的知識。
Wenlan 把來源文件與工作中保存的決策、經驗，編成有來源的 Living Wiki。 Sources、Memories、Pages 模型把決策、經驗與修正存成獨立的知識紀錄；需要修正舊知識時，可記錄明確的取代關係，再與文件共同支撐知識頁。
這個知識生命週期延伸自社群 Rohitg00 LLM Wiki v2 提案所討論的方向，但不是官方版本認證。 先連接來源、指定背景模型並建立首批頁面；之後本機 daemon 同步已連接資料夾的變更，刷新符合條件的既有頁面，保留變更歷程。
新主題不保證自動建頁；模型不可用、來源或引用檢查未通過時，更新會暫停。 你親自撰寫或修改的頁面先提出修訂，審核通過才改原文；不是每一筆 AI 寫入都需要批准。
人與已連接工具可透過 plugin／CLI／MCP 共用所選 Space 的知識，不必開桌面 App。 資料儲存在本機，模型處理可依設定使用本機或雲端服務。
- 文件＋獨立決策
- 來源文件與獨立保存的決策、經驗、修正，共同支撐知識頁面。
- 持續維護的 Wiki
- 機器維護的頁面，能依目前支持它的來源重建。
- 審核＋變更歷程
- 你寫的內容先審再改，頁面版本始終可查。
- 跨 AI 工具共用
- 接好 MCP 的工具共用本機知識，不必各留一份。
02
AI 工具＋文件
AI 能替你讀寫文件；Wenlan 再把來源追蹤、知識頁更新與修訂審核整合好，讓工作留下的不只是回答，而是一份持續維護的知識庫。
- 一開始要做什麼
- 選好文件與支援格式的 AI 工具，確認讀到哪個版本、能否改原檔；不一定需要先建立完整知識庫。
- 什麼情況下，繼續用它就好
- 文件少而穩定，現有工具已能找到並讀取每次任務需要的資料。
- 什麼情況下，值得加入 Wenlan
- 某份規格改了，你希望引用它的知識頁也進入更新流程，而不只在下次提問時讀到新版。Wenlan 已內建來源關聯、過期追蹤與修訂審核，不必自己用腳本搭出這一層。先連接支援的來源、設定模型；符合條件的頁面可在背景刷新，你編輯過的頁面則先提出修訂讓你審核。
這裡比較原生 AI 直接處理文件、尚未另外建置 Wiki 維護系統的做法，不代表每種 AI 產品。 Claude Code 有跨對話的 auto memory；官方將記憶上下文與強制執行機制分開。
hooks 可執行自訂自動化，但來源與頁面的關聯、過期判定及修訂分流，仍需實作與驗證，不是一段提示詞就提供的系統。 Wenlan 已整合這些機制；產出仍需核對依據與內容版本。
直接目錄來源支援 Markdown、text（純文字）與 text-extractable PDF；Word 與 PowerPoint 先匯出為 text/Markdown 或 text-extractable PDF，scanned PDF 另做 OCR。 新主題不保證自動建頁；背景刷新需要已設定且可用的模型。
03
LLM Wiki · nashsu
兩者都有資料夾監看，也不只處理文件。Wenlan 還追蹤每則知識與引用它的頁面；LLM Wiki 則以來源與 Wiki 頁面的編整為主。
- 一開始要做什麼
- nashsu/llm_wiki 要先安裝 App、建立專案、設定模型並加入來源；之後可用資料夾監看自動編整，MCP 則另行連接。
- 什麼情況下，繼續用它就好
- 你想把文件與有用的回答編成 Markdown Wiki，而且它的 App、專案結構與 MCP 流程已經合用。它已有產品介面與自動化，不只是研究配方。
- 什麼情況下，值得加入 Wenlan
- 例如，已保存的交付日期從九月改為十月，你希望系統找出受影響的知識頁，而不只多存一則筆記。Wenlan 接受取代修訂後，會把頁面依據接到新記憶並標記待更新；背景刷新仍需可用模型，你改過的頁面則先提出修訂讓你審核。
此處比較 nashsu/llm_wiki，不是 Karpathy 的方法或整個 LLM Wiki 類別。 它已有引用、Review、MCP 與 skills。
設定匯入模型後，把回答「存回 Wiki」也能自動編整；DeepResearch 直接寫入附引用的問答頁，不再進入來源匯入流程。 刪除來源時，也會清理受影響的頁面與連結。
Business 範本則在決策頁記錄狀態與 supersedes。 Wenlan 把決策存成獨立紀錄：修改、刪除或接受取代修訂後，標記引用該紀錄的頁面待更新；接受修訂時，也把頁面的依據接到新記憶。
新紀錄還可補入匹配的既有頁面。 背景刷新需要可用模型與符合條件的頁面；人改過的頁面先提出修訂，批准才改原文。
nashsu 的匯入則先寫頁面，再列 Review 待辦。 這些是實作差異，不等於易用性或內容正確性的保證。
04
Obsidian
你可以繼續用 Obsidian 寫筆記，再讓 Wenlan 讀取原文，另外建立並維護一份給你和 AI 共用的 Wiki。
- 一開始要做什麼
- 開啟 vault、撰寫筆記即可開始。AI 是選配：挑選外掛或外部工具，再確認模型、檔案權限與備份需求。
- 什麼情況下，繼續用它就好
- 自己撰寫與整理筆記，就是你思考的一部分；現有搜尋、連結與外掛也已經夠用。
- 什麼情況下，值得加入 Wenlan
- 你希望保留原本的 vault 不動，另外維護一份有來源、供後續 AI 工作取用的 Wiki。Wenlan 仍需連接來源與設定模型，不會省掉所有初始設定，也不取代你的筆記編輯器。
適合想自己撰寫、整理與連結筆記的人，Markdown 檔案存放在自己的裝置。 需要 AI 搜尋、摘要或改寫時，可以另外安裝外掛或接上 AI 工具。
外掛與同步服務可能把資料傳到其他服務；筆記存在本機，不代表所有 AI 處理都在本機。
05
Notion
Notion 讓你設定 Agent 處理工作區任務；Wenlan 把來源追蹤、知識頁更新與修改審核做成內建流程。兩者都能自動執行。
- 一開始要做什麼
- 先安排工作區頁面與權限。若要 Custom Agent 無人值守執行，再確認方案、設定指示、觸發條件與存取範圍。
- 什麼情況下，繼續用它就好
- 共享頁面、團隊協作、資料庫與工作區權限是主要需求；Notion 的 Agent 也能自動處理工作區任務。
- 什麼情況下，值得加入 Wenlan
- 你需要一份不依附工作區的本機知識庫，讓已連接的 AI 工具取用，並有內建的來源追蹤與頁面審核流程。Wenlan 不取代 Notion 的團隊工作區或專案管理功能。
Notion 是個人與團隊共用的雲端工作區，不只是資料庫或被動筆記。 Notion Agent 可搜尋、建立與編輯；Custom Agents 更能按事件或排程在背景執行，包括知識維護。
你可用範本或自行設定指示、觸發條件與存取權限，再查看活動紀錄，使用 Notion 的歷史與還原功能。 官方文件列 Custom Agents 需 Business 或 Enterprise 方案。
雲端內容可下載指定頁面離線使用，也能匯出備份。 差異在通用工作區自動化與 Wenlan 內建的知識維護流程，不是 Notion 沒有自動化或不能接外部工具。
06
NotebookLM
NotebookLM 幫你讀懂一組來源；Wenlan 把資料與工作決策累積成 Wiki，讓已連接的 AI 工具在後續工作取用。
- 一開始要做什麼
- 建立筆記本、選定來源。支援的 Google Drive 匯入會在開啟筆記本時同步，上傳檔案則保留匯入副本；先確認格式與分享設定。
- 什麼情況下，繼續用它就好
- 主要任務是讀懂一組材料，根據來源提問、摘要或製作學習材料，也會在 Gemini 使用這些來源。
- 什麼情況下，值得加入 Wenlan
- 閱讀結論要接回後續工作：保存新的決策、維護相關 Wiki 頁，再從已連接 AI 工具找回。這和製作學習材料是不同任務，不是說 NotebookLM 不能重用來源。
NotebookLM 是大家熟悉的產品；Google 官方文件現在將它標為 Gemini Notebook。 它提供來源問答、摘要與學習材料，筆記本也可用在 Gemini 對話，不能說只能待在一個獨立 App。
支援的 Google Drive 來源會在開啟筆記本時同步；本機上傳檔是匯入副本。 你選擇提問引用的來源與雲端分享權限，它不會改寫原始 Drive 文件。
來源同步不等於保證先前產生的每份學習材料都會重新生成。
01
先分清你需要哪一種 AI 知識庫
不要先問哪個工具最好。先判斷需要的是當次會話的文件上傳、針對一組文件的 RAG 問答、讓 AI 直接讀取筆記或 Markdown vault，還是跨會話與多個 agent 維護有來源的目前答案。
這四種模式可以組合，但解決的問題不同。把它們放在同一張功能表比較，通常會買到不符合實際工作方式的產品。
02
8 個真正重要的檢查
用一小組具代表性的文件，先寫下預期答案，再對每個候選工具做相同測試。
- 來源可追溯：重要答案能否開啟支持它的確切來源或引用？
- 更新狀態：來源改變後，哪些答案過期、哪些需要刷新是否看得見？
- 衝突與審查：矛盾證據會進入明確審查，還是被模型靜默改寫？
- 資料所有權與匯出：能否保留或匯出可讀檔案與歷史，不被單一服務綁住？
- 隱私邊界：哪些檔案、提示、檢索片段與模型呼叫會離開電腦？
- Agent 互通：同一份知識能否供實際使用的 Claude Code、Codex、Cursor 或 ChatGPT 讀取？
- 輸入限制：真正支援哪些格式、掃描文件、資料夾、vault 與檔案大小？
- 可重複驗收：工具能否處理可回答、不可回答、跨來源三種問題，並在來源修改後得到正確結果？
03
一組能揭露問題的驗收資料
不要一開始匯入整個資料庫。準備一份乾淨來源、一份過期版本、一組互相矛盾的說法，以及一個資料中沒有答案的問題。好的工具應該暴露不確定性和衝突，而不是只產生流暢文字。
修改其中一份來源後重跑相同問題。若答案不會顯示過期、引用仍指向舊內容，或無法判斷哪些頁面需要更新，這套系統就還不適合承擔長期知識。
04
Wenlan 適合哪一種模式
Wenlan 對應維護型、具來源的本地知識層。Sources、原子知識與 Pages 分開保存；Claude Code、Codex、Cursor、ChatGPT 等客戶端透過 plugin 或 MCP 使用同一套知識；引用、過期狀態、修訂與人工審查保持可見。
完成平台與客戶端設定後，可用一個小型來源集驗證，而不是只相信產品描述。
Wenlan 驗證流程
wenlan status
wenlan sources add ~/Knowledge/evaluation-set
/distill <測試主題>
/pages <測試主題>
/lint
/curate05
何時不該增加另一套知識庫
如果只是讀一份短文件、現有 wiki 已由團隊穩定維護，或 AI 不需要跨會話重用答案，直接文件閱讀或目前的筆記工具可能已經足夠。
選擇的標準不是功能最多，而是以最低維護成本通過你的來源、更新、衝突、隱私與可重複驗收。
用同一套 8 項檢查測試 Wenlan
從一組小型來源開始，驗證引用、更新與審查，再判斷維護型本地知識層是否適合你的工作流。
常見問題