nashsu LLM Wiki：把文件整理成會持續生長的可追溯知識庫

如果你的資料已經多到「找得到檔案，卻找不回當時的脈絡」，nashsu LLM Wiki 提供的不是一次性文件問答，而是一套把來源文件逐步整理成 wiki 的桌面工作流。它會依官方說明分析文件，產生帶有來源欄位的知識頁，建立頁面之間的連結，再讓你透過搜尋與對話，以及圖譜與 Review 持續修正。

它比較適合長期研究與持續累積的知識庫。若你只想上傳幾份 PDF 問一次問題，這套系統可能比需求更重。

先看懂它與一般文件問答的差異

一般 RAG 工具常在你提問時臨時找出片段，再組合一次答案。LLM Wiki 的核心想法是先把文件編譯成可持續維護的知識結構，之後再從這個結構查詢。

官方 README 將基本模型分成三層：

Raw Sources：保留匯入的原始材料，作為回查依據。
Wiki：由 LLM 產生與更新的摘要，概念頁，實體頁以及交叉連結。
Schema：規定 wiki 如何分類與命名，以及如何維護的規則。

日常操作則圍繞三個動作：

Ingest：讀取來源，分析內容，再建立或更新 wiki。
Query：從 wiki 與原始來源，以及關聯圖譜中找答案。
Lint：檢查知識庫中的待整理事項與衝突，以及需要人工判斷的部分。

關鍵差異不在於「能不能聊天」，而在於每次匯入是否留下可維護的頁面與來源線索。

從一批文件到可查詢 wiki，會經過什麼

依官方 README，LLM Wiki 的匯入不是直接要求模型邊讀邊寫，而是拆成兩個階段。

第一階段先分析來源中的實體與概念，辨識論點與潛在矛盾，以及它與既有 wiki 的關係。第二階段才根據分析結果產生來源摘要，概念頁，實體頁，索引更新與 Review 項目。

完成一次匯入後，你預期會看到的不是單一聊天回答，而是多種可繼續使用的產物：

帶有 sources 欄位的 wiki 頁面，可回到構成該頁的來源。
index.md，作為內容目錄與模型導航入口。
log.md，記錄知識庫的操作歷程。
overview.md，提供整體知識庫摘要。
概念頁與實體頁之間的 [[wikilink]]。
等待人工處理的 Review 項目與建議搜尋方向。

官方也描述 SHA-256 增量快取。內容未改變的來源可跳過重複匯入，來源資料夾監控則用來處理後續新增與修改，以及刪除。

它可以處理哪些材料

官方文件列出的解析範圍不只 Markdown 與純文字：

PDF，可使用內建解析器。複雜版面可另外設定 MinerU Cloud，Local API 或 Local Pipeline。
DOCX，保留標題與清單，以及表格與基本文字結構。
PPTX，依投影片抽取標題與清單內容。
XLSX 與 XLS 以及 ODS，將工作表與儲存格整理成 Markdown 表格。
EPUB 與 MOBI，抽取書籍資訊，章節與正文。
網頁剪藏，透過官方 Chrome extension 轉成 Markdown 後匯入。
圖片與音訊，以及影片，可在應用程式中預覽或播放。圖片內容分析仍取決於模型與相關設定。

「格式被列為支援」不等於每份檔案都能正確還原。掃描 PDF，複雜簡報，特殊字型與大型試算表仍應先用非敏感樣本驗證。

第一次使用的合理順序

官方 Quick Start 的操作邏輯可以整理成以下流程：

建立新專案，選擇 Research, Reading, Personal Growth, Business 或 General 等情境模板。
在 Settings 設定模型 provider，API key 與模型。
視需求設定 embedding，Web Search，PDF 處理方式與來源資料夾監控。
從 Sources 匯入一小批文件。
在 Activity Panel 觀察分析與 wiki 產生進度。
打開產生的頁面，確認內容與 sources 是否能回到原始材料。
使用 Chat 提問，再檢查回答引用了哪些 wiki 頁面。
查看 Knowledge Graph 與 Review，處理錯誤連結與知識缺口，或需要人工判斷的項目。
定期執行 Lint，避免知識庫只增加內容卻沒有維護。

這套流程的成本主要不在下載，而在模型設定，第一次 schema 調整，以及持續 Review。若你不打算做人工校正，產生更多頁面不一定等於得到更可靠的知識庫。

搜尋與圖譜，以及 Agent 能力各自解決什麼

LLM Wiki 的搜尋流程不只比對關鍵字。官方描述的查詢管線會先搜尋 wiki 與 raw sources，再用頁面連結和來源重疊擴展相關內容。你也可以選擇啟用 LanceDB 向量搜尋，連接 OpenAI-compatible embedding endpoint，補足沒有相同關鍵字的語意結果。

知識圖譜則用直接連結，來源重疊，共同鄰居與頁面類型計算關聯。它比較適合用來發現「哪些主題彼此相連」與「哪一塊資料仍然稀疏」，而不是把圖畫得漂亮而已。

如果你想讓 Claude Code 與 Codex 或其他工具讀取知識庫，官方版本另提供綁定 127.0.0.1 的本機 HTTP API，MCP server 與獨立 Agent Skill。這些介面能查詢專案，讀取檔案，走訪圖譜與重新掃描來源，但仍需要你自行檢查 token 與權限，以及實際資料邊界。

使用前最重要的資料邊界

「桌面應用程式」不等於「所有處理都只在本機」。你選擇的設定會改變資料可能流向哪些服務。

Chat 與 Ingest 需要模型。官方列出 OpenAI，Anthropic，Google，Ollama 與 Custom provider。
Vector Search 預設為可選功能。啟用後會連接你設定的 embedding endpoint。
Deep Research 可使用 Tavily 與 SerpApi 或 SearXNG。
複雜 PDF 可選 MinerU Cloud，也可選本機處理模式。
Firecrawl 可設定 hosted 或 self-hosted 服務。

因此，真正需要確認的不是「它是不是本機軟體」，而是你目前啟用了哪些 provider，以及哪些文件會被送到那些端點。涉及客戶，公司或個人敏感資料時，不應直接把正式資料當成第一次測試材料。

先用小型測試判斷是否值得投入

在搬入完整資料庫之前，可以先準備 5 到 10 份不敏感文件，刻意包含一個重複概念，一組互相矛盾的說法，以及一份結構較複雜的檔案。接著檢查：

每份來源是否產生可辨識的摘要頁。
wiki 頁面的 sources 是否真的能回到相關材料。
同一概念出現在多份文件時，系統是合併或建立連結，還是產生重複頁。
Chat 的引用能否支持答案，而不是只有看起來合理的敘述。
Review 是否把矛盾交給人判斷，而不是自行消除差異。
刪除測試來源後，相關摘要與索引，以及失效連結是否依預期更新。
一次完整 Ingest 使用多少時間與模型費用。

如果來源追溯與人工 Review 沒有改善你的決策速度，圖譜與更多自動化功能也不會自動讓它變成更好的第二大腦。

哪些人比較適合，哪些人可以先跳過

你可能適合評估 LLM Wiki，如果你：

長期處理研究資料，讀書筆記，產品文件或跨格式專案材料。
希望知識頁保留來源，而不是只保存聊天答案。
願意設定模型 provider，並定期處理 Review 與 Lint。
想讓 Obsidian 或 AI Agent 繼續讀取產生的 Markdown wiki。

你可以先跳過，如果你：

只需要針對少量文件做一次性問答。
不想管理 API key 與模型費用或本機模型環境。
期待匯入後完全不需人工確認。
必須先取得企業權限，稽核，多人協作或資料落地保證，而官方資料尚不足以回答你的要求。

官方下載與版本

請只從 nashsu/llm_wiki 官方 repository 或官方 releases 取得程式。

2026-08-11 重新核對 GitHub API 時，最新版本為 v0.6.8，發布時間為 2026-08-08。Windows x64 提供 portable ZIP，setup EXE 與 MSI。portable ZIP 的官方 SHA-256 為：

5e6e921a276d2f98a7b52a7d43a96c4cd4ea74ab1d630069b347df0b1ed75906

Gwarket 不鏡像或重新打包這些檔案。下載前仍應回到 release 頁面確認目前版本，檔名與 checksum。

我們目前能下的結論

從官方架構與功能設計來看，nashsu LLM Wiki 最值得評估的地方，是它試圖把「每次重新回答」改成「持續維護一套能回查來源的知識結構」。這比單純列出支援格式更有辨識度。

但 Gwarket 尚未完成 Windows clean-room 的 Ingest，Query 與 Lint first-success，因此目前不能替你保證安裝相容性，解析品質，查詢準確度，效能，隱私或長期穩定性。這是一篇依官方材料建立的評估指南，不是實測推薦或技術支援承諾。

來源與授權

LICENSE 檔案顯示 repository 採用 GNU General Public License version 3，並列出 Yong Su 為 2024 至 2026 copyright holder。實際模型，外部服務，輸入文件與產出內容仍有各自的權利與條款，不能只用 repository license 一概判斷。