llmwiki 評測：讓 Claude 透過 MCP 替你維護個人維基
Open Source Implementation of Karpathy's LLM Wiki. Upload documents, connect your Claude account via MCP, and have it write your wiki !
秒懂
- 它是什麼？
- llmwiki 把一個資料夾的文件索引成本地知識庫，再讓 Claude 經 MCP 讀寫 wiki 頁面。它的價值取決於你願不願意把「整理」這件事外包給排程提示詞，而它的限制也來自同一個設計。
- 適合誰用？
- llmwiki 適合已經在用 Claude Code 或 Claude Desktop、手上有一個長期累積的文件資料夾、而且願意設定排程提示詞讓它自己跑的人；如果你要的是多人協作、要對外分享的知識庫，或者你的文件不能離開自己的機器卻又想用 hosted 版，那它就不是對的工具。動手前先確認三件事：本機的 Python 是否達 3.11 與 Node.js 是否達 20，你的文件格式在沒有 LibreOffice 與 MISTRAL_API_KEY 的情況下抽取品質能不能接受，以及你打算把 wiki 目錄與 .llmwiki 索引放在哪個備份策略底下。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
llmwiki 想解決的是「讀過就忘」而不是「找不到檔案」
多數個人知識管理工具的假設是：你的問題在於檢索，所以它們做全文搜尋、做標籤、做雙向連結。llmwiki 的假設不一樣。README 開頭寫得很直白，它要處理的是「scattered reading and research」，把散落的閱讀與研究變成一個由 AI 維護的持久知識庫。真正被針對的痛點是維護成本：筆記系統通常不是死於搜尋功能不足，而是死於你不再更新它。
所以它的產品邏輯是把「更新」從人手上拿走。你只負責蒐集來源，也就是把 PDF、Word、PowerPoint、Markdown 丟進一個資料夾，或用 Chrome 擴充功能剪藏網頁並畫重點、留評論；整理與改寫交給 Claude。README 對這件事的說法是，wiki 會成為「a record of not just what you read but what you thought about it」，因為剪藏工具會一併保留你的畫線與邊註。
目標讀者輪廓因此相當明確：已經有大量既有文件、已經在用 Claude、而且對「讓模型直接寫入自己的知識庫」這件事不排斥的人。README 另外提到組織層級的用法，說多數組織的機構記憶很差，因為 know-how 多半存在人的腦袋裡。這是願景陳述，不是已驗證的部署案例，看的時候當成方向就好。
MCP 是主幹，wiki 只是資料夾裡的一堆檔案
這個專案的架構可以拆成三塊：一個 Python API、一個 MCP server、一個 Next.js 前端。三者之中真正決定它能做什麼的是 MCP server，因為 Claude 對 wiki 的讀、寫、搜尋都走這條路。README 的敘述是 MCP 讓 Claude 能「read, write, and search your wiki」，這是整個系統的能力邊界。
資料流並不複雜。你用 `llmwiki open` 指向一個資料夾後，它會把該資料夾索引成本地搜尋索引，讓檔案在 app 裡出現、也讓 Claude 讀得到。之後 Claude 產生的頁面寫進 workspace 裡的 `wiki/` 資料夾，索引資料放在隱藏的 `.llmwiki/`。README 特別強調它不會搬移、修改或上傳你的原始檔案，只新增這兩個目錄。這是一個值得肯定的設計選擇，因為它讓「試用」這件事的風險降到很低：最壞情況就是刪掉這兩個目錄。
頁面之間有原生交叉連結，也能連回原始來源，另外有圖形檢視器看概念與實體之間的關係，以及支援 SVG 與 Mermaid 的視覺化。這些功能的共同前提是 wiki 頁面本身要是結構化的文字，而這件事完全取決於 Claude 每次執行排程提示詞時寫出來的品質。
安裝路徑與兩個模式：本地 loopback 與 hosted 版
README 說明它支援 remote 與 local 兩種模式，remote 可以自架，或直接用 llmwiki.app 的免費版；local 則是 clone 下來用 CLI 跑。本地需求是 Python 3.11+ 與 Node.js 20+，LibreOffice 與 MISTRAL_API_KEY 都是選配，前者用來抽取 Word 與 PowerPoint，後者用來提高 PDF OCR 品質。
安裝步驟在 macOS 與 Linux 上是 `git clone` 之後建立虛擬環境，再 `pip install -r api/requirements.txt -r mcp/requirements.txt`，最後進 `web` 目錄跑 `npm install`。Windows 的差異在啟用虛擬環境的指令，README 也提醒若執行原則擋下啟用，可以用 `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned`，或直接改用 `.venv\Scripts\python`。
接著是兩個關鍵指令。`./llmwiki open ~/research` 會初始化 workspace、索引資料夾、啟動 API 與前端，並打開 localhost:3000；`./llmwiki mcp-config ~/research` 會印出一段 JSON，讓你貼進 `claude_desktop_config.json` 或 `.claude/settings.json`。這裡有個容易忽略的細節：一個 workspace 對應一個 MCP server 項目，所以多個資料夾就要加多筆。
最後是讓它自我維護的部分。README 建議設定 Claude Routine，也就是排程提示詞，並提供一段可直接使用的範本，內容大意是讀取指南、找出上次執行後新增的來源與剪藏、逐篇閱讀後更新 wiki，該開新頁就開新頁，該併入既有頁面就併入，並修掉受影響的交叉引用與引用來源。排程方式有兩種：Claude Code Routines 跑在 Anthropic 雲端，固定頻率執行，筆電闔上也會跑；Desktop scheduled task 則在你自己的機器上跑。
本地模式只綁 127.0.0.1，這條線決定了誰不能用
README 對本地模式的描述相當強硬：API 只監聽 `127.0.0.1`，不支援 LAN 或遠端綁定。這不是設定沒寫清楚，而是刻意的設計。
對單人使用來說這沒問題，甚至更好。但如果你想把 wiki 放在一台家用伺服器上、讓手機或另一台電腦連進來，本地模式直接出局，你得改走自架 remote 模式，而 README 對自架 remote 的步驟著墨明顯少於本地模式，這部分在文件上是偏薄的。反過來說，如果你選 hosted 版 llmwiki.app，那就等於把文件交給第三方處理，這跟「檔案不離開我的機器」是互斥的兩條路，README 並沒有試圖調和這個矛盾，它只是把兩種模式並列。
另一個容易被低估的限制是抽取品質。Word 與 PowerPoint 需要 LibreOffice，PDF 想要更好的 OCR 要 `MISTRAL_API_KEY`。兩個都沒裝的狀態下系統仍可運作，但你丟進去的掃描檔或簡報能抽出多少內容，會直接決定 wiki 頁面的可信度。這種錯誤不會報錯，只會讓 Claude 在錯誤的基礎上寫出看起來很合理的頁面。
與其說它像 RAG，不如說它是一份會被覆寫的編譯產物
把 llmwiki 跟一般的 RAG 檢索層放在一起比，會看不出重點。RAG 的做法是保持原始文件不動，在查詢時動態檢索片段丟進上下文，答案用完即丟。llmwiki 走的是相反方向：它把來源預先編譯成 wiki 頁面，這些頁面是持久的、可被人直接閱讀的、而且會被後續的排程執行改寫。
這個差異帶來兩個實際後果。第一，wiki 的品質會隨時間累積，因為每次執行都會把新材料折進既有頁面，而不是每次從零開始檢索。第二，錯誤也會累積。如果某次執行把一份抽取失敗的 PDF 當成有效來源寫進頁面，那個錯誤不會在下一次查詢時自動消失，它已經變成 wiki 的一部分。RAG 的錯誤通常是單次問答的錯誤，llmwiki 的錯誤是檔案裡的錯誤。
所以真正該問的不是「它比 RAG 準嗎」，而是「你願不願意讓一個排程執行程式改寫你的知識庫，而且你會不會去讀 diff」。如果你不會看它改了什麼，那這個系統的長期狀態就是不可控的。
維護成本落在兩件事上：排程提示詞與 MCP 設定
這個專案沒有版本發布紀錄可以參考，README 也沒有描述升級流程或遷移步驟，所以升級成本目前無法從材料判斷，只能說它是一個持續推送的 repository，最後一次推送時間是 2026 年 9 月。
可以判斷的維護成本有兩項。第一項是排程提示詞。README 提供的那段範本本身就是需要你持續調整的東西：它要求 Claude 找出「上次執行後新增的一切」，這件事的準確度取決於 workspace 的索引狀態，而提示詞寫得越模糊，每次執行改動的範圍就越不可預測。第二項是 MCP 設定。因為一個 workspace 對應一個 server 項目，資料夾一多，`claude_desktop_config.json` 或 `.claude/settings.json` 就會變成一份需要手動同步的清單，換機器或換路徑時要逐筆改。
授權是 Apache-2.0，屬於寬鬆授權，允許修改與再散布，也包含專利授權條款，對自架與內部使用通常不會構成障礙。但這不是法律意見，如果你打算把它包進商業產品或對外提供服務，還是要自己確認 Apache-2.0 的標示與 NOTICE 相關要求。另外要注意的是，hosted 版 llmwiki.app 與你自架的程式碼是兩件事，前者的資料處理方式不在這個 repository 的授權範圍內。
該不該採用，取決於你會不會去讀它寫的東西
判斷標準其實只有一條：你會不會定期打開 localhost:3000，讀 Claude 寫出來的頁面，並且在它寫錯時動手修。會，這個工具就成立，因為它省下的是你原本不會花的整理時間；不會，那它就只是在你的硬碟上持續生成沒人看的 Markdown。
如果你要的是團隊共用的知識庫，這個專案的本地模式從綁定位址上就排除了這個用法，而 README 對組織層級的說法停留在期許，沒有提供權限、審核或多人同時編輯的機制。如果你要的是把文件交給 hosted 服務處理，那要先接受文件離開自己的機器。
想試的話，從一個你已經很熟、檔案量不大的資料夾開始，跑 `./llmwiki open` 之後先確認索引出來的內容跟你預期的一致，尤其是 PDF 與簡報的抽取結果，再跑 `./llmwiki mcp-config` 接上 Claude。第一次不要直接上排程，先手動請 Claude 跑一次那段提示詞，看它寫出來的頁面結構與引用來源合不合理，再決定要不要把 `wiki/` 與 `.llmwiki/` 納入備份。
編輯結論
llmwiki 適合已經在用 Claude Code 或 Claude Desktop、手上有一個長期累積的文件資料夾、而且願意設定排程提示詞讓它自己跑的人；如果你要的是多人協作、要對外分享的知識庫，或者你的文件不能離開自己的機器卻又想用 hosted 版，那它就不是對的工具。動手前先確認三件事：本機的 Python 是否達 3.11 與 Node.js 是否達 20，你的文件格式在沒有 LibreOffice 與 MISTRAL_API_KEY 的情況下抽取品質能不能接受，以及你打算把 wiki 目錄與 .llmwiki 索引放在哪個備份策略底下。這三項沒確認完，後面排程跑得再勤也只是把不完整的內容固化下來。
社群筆記