在我們本月初發布的熱門教學《擺脫分頁焦慮！打造完全掌握資料自主權的個人知識庫，Wallabag + Obsidian + QNAP NAS 實作教學》中，CyberQ 帶領大家利用 QNAP NAS 部署 Wallabag，成功搭建了一道資訊防波堤，將網路上龐雜的文章剝除廣告後，以純淨的 Markdown 格式自動匯入 Obsidian 筆記庫中。
然而，許多讀者在跟著實作後，寫信來問我們，很快就面臨了下一個真實的問題，資料確實都全自動抓進來了，但我根本沒時間看、更沒時間整理怎麼辦呢 ?
面對資料夾內成百上千篇的待讀筆記，我們往往從分頁焦慮淪為單純的數位囤積者。近年來，業界習慣依賴 RAG（檢索增強生成）技術，讓 AI 幫忙在海量筆記裡找答案。但傳統 RAG 有一個致命傷，它只是在查資料，並沒有幫助你沉澱、重構與融合知識。 每次問問題，它都要重新大海撈針，一旦對話結束，你的知識庫依舊是一盤散沙，沒有產生任何更好的效用。
AI 大神 Andrej Karpathy 日前提出了 LLM Wiki 的顛覆性概念，加上近期開源社群（如 obsidian-llm-wiki 專案）將其完美落地於 Obsidian，這是一個值得實作的解法，讓本地端 AI Agent 成為你的全職知識管家，打造一個會自動生長的個人維基百科。
CyberQ 觀點：什麼是 LLM-Wiki？它憑什麼取代傳統 RAG？
在 LLM-Wiki 框架與最新市場的 AI 知識管理（如本地端 GraphRAG）實踐中，其核心哲學非常迷人，主要是將我們的原始筆記當作原料（Source Material），而不是最終的產物（Artifact）。
傳統 RAG 模式（Read-on-Query）是這樣，你發問 ➡️ AI 去檢索原始筆記片段 ➡️ 整理出一次性的答案。你的筆記沒有結構化，也不會互相連結。對話視窗一關，知識庫再次清空。
LLM-Wiki 模式（Compile-on-Write）則改變為，系統自動丟入一篇新文章 ➡️ 駐守在背景的 AI 自動完整閱讀、萃取核心概念與實體 ➡️ 尋找 Obsidian 現有關聯頁面 ➡️ 自動更新、擴寫或建立新的 Markdown 頁面，並加上 [[雙向連結]]。
換句話說，Obsidian 變成了你的 IDE（整合開發環境），LLM 是你的編譯器（Compiler），而你的知識庫就是持續迭代、不斷產生複利效應的程式碼。
獲得資料與算力的主導權
站在 CyberQ 一貫堅持的資料自主權視角，這套工作流帶來了三個無可取代的優勢。
首先是 100% 在地化與零隱私外洩（Local-First），支援 Ollama 等本地模型。商業企劃、私人日記全在本地 NAS 或 AI PC 處理，無需上傳給雲端大廠。知識整理與 LLM 編譯可 100% 在地化，不過如果有採用 Jina Reader，網頁前處理會經過第三方服務。對內部文件、登入後頁面、機密資料，建議改用 Wallabag、Obsidian Web Clipper、Markdownload 或自建解析流程。
人機協作的防覆蓋機制則是一個可考量的點，系統內建手動編輯保護（Manual Edit Protection）。你手動修改的 Wiki 區塊會被鎖定，逐步可建立人類主導、AI 輔助的共創模式。
最後就是銜接 NAS 自動化收集流，補齊了 Wallabag 教學的最後一哩路。前端無腦剪藏，後端交給地端 AI 批次重構。
階段一：捨棄手動剪藏，改成自動餵食模式
既然要讓 AI 幫我們整理，連收集資料這一步都應該盡量懶人化。CyberQ 建議，這裡可以分成四種路線，從最簡單到最自動化。
方案 A：Obsidian Web Clipper / Markdownload 入門流
這是 CyberQ 最推薦給新手的方式。當你在瀏覽器看到一篇值得保存的文章，只要用 Obsidian Web Clipper 或 Markdownload 將文章另存成 Markdown，直接放進 Obsidian Vault 的 /raw 資料夾即可。
這個方案的好處是最少依賴外部服務，也最容易除錯。你可以清楚看到每一篇文章何時被存進來、內容是否乾淨、格式是否正常。
適合情境是你還在測試 LLM-Wiki 效果，不想一開始就導入 n8n、RSS 或 API 串接。
日常體驗方面，我們只要看到好文章，按一下剪藏，文章就會進入 /raw，等待 AI 編譯。
方案 B：手機為主用戶的 iOS 捷徑分享流
這適合通勤時大量滑手機的使用者。
實作方式可以是：
在 iPhone 捷徑中建立新腳本，設定接收分享選單中的 URL。
讓捷徑使用「取得網址內容」動作，將分享網址送到指定轉換流程。
如果是公開網頁，可以用 Jina Reader：
https://r.jina.ai/https://example.com/article
Jina Reader 會回傳較乾淨、適合 LLM 讀取的 Markdown 或純文字內容。它的官方用法就是在網址前方加上 https://r.jina.ai/ 來轉換網頁。
接著，將回傳內容儲存成 .md 檔，存到 iCloud、Qsync 或其他會同步到 NAS 的 Obsidian Vault /raw 資料夾。
日常體驗是看到好文章，點擊分享，傳送給大腦，一秒搞定，連 App 都不用開。
但請再次注意，Jina Reader 適合公開網頁，不建議拿來處理公司內部頁面、會員登入內容、客戶文件或私人資料。
方案 C：Wallabag 自主剪藏流
如果你已經跟著 CyberQ 先前教學在 QNAP NAS 上部署 Wallabag，那麼 Wallabag 仍然是最適合 Local-First 思維的剪藏核心。
Wallabag 的定位不是 AI 工具，而是「可自主管理的稍後閱讀與文章保存系統」。它可以把網頁正文保存下來，減少日後原文消失、網站改版或搜尋不到的風險。
在這套 LLM-Wiki 流程中，Wallabag 可以扮演資料入口，將文章轉成 Markdown 或透過 API 匯出，再放入 Obsidian Vault 的 /raw 資料夾。
這個方案最適合重視資料留存與長期可控性的使用者。
方案 D：RSS + n8n 全自動訂閱流
如果你固定追蹤特定媒體、部落格、資安公告或 GitHub release，那就可以進一步導入 n8n。
在 QNAP NAS 上透過 Container Station 啟動 n8n，然後在 n8n 中建立 RSS Read 節點，訂閱指定網站。當有新文章發布時，n8n 會自動抓取連結，送到 Jina Reader、Wallabag API 或自建解析服務，最後將 Markdown 寫入 NAS 上的 Obsidian Vault /raw 資料夾。
日常體驗是你什麼都不用做。追蹤的媒體一發文，你的 NAS 就會自動抓取全文，乖乖躺在資料夾裡等待 AI 消化。
階段二：建立雙軌制資料夾結構
在 Obsidian Vault 中，建議建立兩個核心資料夾，畫出嚴格邊界。
ObsidianVault/
├── raw/
│ ├── 2026-04-25-example-article.md
│ ├── 2026-04-25-security-news.md
│ └── …
│
├── wiki/
│ ├── AI代理.md
│ ├── RAG.md
│ ├── QNAP自動化.md
│ └── …
│
└── wiki/.drafts/
├── 待審核條目.md
└── …
/raw 是原始素材區。所有剪藏、RSS、Wallabag、Jina Reader、n8n 匯入的文章都應該先放在這裡。這個資料夾最好視為唯讀證據庫，不要讓 AI 任意改寫。它的任務是保留原始脈絡與來源。
/wiki 是知識百科區。AI 會在這裡生成概念條目、技術條目、人物條目、事件整理與主題總結。
/wiki/.drafts 則是審稿暫存區。第一次導入時，強烈建議所有 AI 產出都先進草稿區，確認品質後再發布到正式 Wiki。這樣可以避免 Prompt Injection、錯誤摘要、概念混淆或來源誤讀污染正式知識庫。
這個分層設計的精神是：原始資料不能丟，AI 結論要可審，人工修訂要優先。
階段三：部署你的 LLM-Wiki 編譯引擎
搞定資料匯入後，接下來就是讓本地 AI 大腦開始運作。
這裡我們採用 obsidian-llm-wiki 作為示範。它的目標是把原始 Markdown 筆記轉換成會自我成長的互連 Wiki，並預設支援以 Ollama 作為本地 LLM Provider。
你可以把它想像成 Obsidian Vault 裡的「知識編譯器」：/raw 是原始碼，/wiki 是編譯結果，人類審稿就是 code review。
步驟一：準備 Ollama 與模型
如果你要跑本地模型，最簡單的方式是使用 Ollama。
在 AI PC、Linux 主機或 QNAP NAS 上啟動 Ollama 後，建議採用雙模型架構：
Fast Model：負責快速分類、路由、初步實體辨識，CyberQ 建議可以是從 Google 釋出的 Gemma4:e4b 開始入手。
Heavy Model：負責深度萃取、知識融合、條目改寫與衝突處理，CyberQ 建議可以選 14b 以上的模型，算力夠的設備可以用29b、31b來跑。
不要一開始就迷信大模型。CyberQ比較務實的建議是這樣：
CPU-only NAS，使用 1B～4B 小模型，只做低頻批次整理。
RTX A2000 12GB / RTX 3060 12GB，從 4B～8B 模型開始測試，必要時再挑戰 14B 量化模型。
RTX 5060 Ti 16GB / 更高階 GPU，可嘗試 14B 級模型作為 Heavy Model。
24GB VRAM 以上 AI PC、Mac 筆電或 Mac 電腦，可評估 32B 級模型，但要注意上下文長度與量化格式。
雙 DGX Spark、雙 DGX Spark 或更高階環境，這種才適合把 Heavy Model 拉到更大規模，並搭配 vLLM 或其他推理框架測試。
以實務來說，我們在實作時，一開始不需要去追求最強模型，要先確認工作流能跑通，產出的 Wiki 條目結構合理，來源能追溯，再來調整模型大小與品質。
步驟二：安裝 obsidian-llm-wiki
如果你是在 AI PC 或一般 Linux 主機上執行，可以直接使用 Python 環境安裝。
建議使用 Python 3.11 以上版本，並盡量建立獨立虛擬環境：
python -m venv olw-env
source olw-env/bin/activate
pip install -U pip
pip install obsidian-llm-wiki
進入你的 Obsidian Vault 根目錄：
cd /path/to/ObsidianVault
olw setup
設定精靈中，Provider 選擇 Ollama，API URL 可以填：
http://127.0.0.1:11434
如果 Ollama 跑在另一台 AI PC 或 NAS 上，就填該設備的 IP：
http://192.168.2.50:11434
接著綁定 Fast Model 與 Heavy Model。
第一次設定完成後，先執行檢查：
olw doctor
再跑一次完整流程：
olw run
確認輸出品質 OK 後，再考慮長期監控：
olw watch
這裡建議文章中特別提醒：第一次不要直接開全自動批准。先讓 AI 產生草稿，再由人類審核，才是比較安全的知識庫治理模式。
階段四：更簡單的 QNAP NAS 實作方式
很多讀者會問：能不能全部都放在 QNAP NAS 上跑？CyberQ 依據實作的經驗，答案是可以，但不一定是最簡單。
QNAP Container Station 本身支援 Docker、LXD 與 Kata 等容器技術，適合在 NAS 上部署獨立服務，不必污染 QTS 或 QuTS hero 的系統環境。QNAP 官方也將 Container Station 定位為輕量化 Linux 與應用程式虛擬化方案，可從 Docker Hub / LXD Image Server Registry 下載與部署容器。
因此，若要在 QNAP 上實作，CyberQ 建議使用容器化路線，而不是直接在 NAS 系統層安裝 Python 套件。
推薦架構一：NAS 儲存，AI PC 運算
CyberQ 建議有 QNAP NAS 的人，這是還滿完整的做法，也可以把你不要的項目跳過去掉，再整合過。如果你本來就有 AI PC，搭配 NAS 是很不錯的組合方式。
QNAP NAS：
負責 Obsidian Vault、raw、wiki、Wallabag、n8n、備份
AI PC：
負責 Ollama、模型推理、obsidian-llm-wiki
優點是：
效能最好
除錯最簡單
不會污染 NAS 系統環境
GPU 支援最穩定
適合長期使用
推薦架構二：NAS 自己跑 Ollama + olw-worker
如果你希望 NAS 自己完成所有工作，可以使用兩個容器：
ollama：負責模型服務
olw-worker：負責監控 raw/ 並編譯 wiki/
先建立資料夾：
mkdir -p /share/Container/ollama
mkdir -p /share/Container/olw
mkdir -p /share/ObsidianVault/raw
mkdir -p /share/ObsidianVault/wiki
啟動 Ollama 容器：
docker run -d \
–name ollama \
–restart unless-stopped \
-p 11434:11434 \
-v /share/Container/ollama:/root/.ollama \
ollama/ollama
如果你的 QNAP 已正確支援 NVIDIA GPU 並完成容器 GPU 指派，則可以使用 GPU 版本啟動方式。Ollama Docker 也提供 NVIDIA GPU 的 –gpus=all 啟動方式。
docker run -d \
–name ollama \
–restart unless-stopped \
–gpus=all \
-p 11434:11434 \
-v /share/Container/ollama:/root/.ollama \
ollama/ollama
下載模型：
docker exec -it ollama ollama pull gemma4:e4b
docker exec -it ollama ollama pull qwen3.5:9b
接著建立 olw-worker 容器：
docker run -it –name olw-worker \
–restart unless-stopped \
-v /share/ObsidianVault:/vault \
-v /share/Container/olw:/root/.config/olw \
python:3.12-slim bash
進入容器後安裝：
pip install -U pip
pip install obsidian-llm-wiki
初始化：
cd /vault
olw setup
如果 Ollama 與 olw-worker 都在同一台 NAS，但不是同一個 Docker network，通常可先用 NAS 的 LAN IP：
http://192.168.2.x:11434
設定完成後先檢查：
olw doctor
第一次執行：
olw run
確認草稿品質後，再進入監控模式：
olw watch –vault /vault
推薦架構三：n8n + Wallabag + LLM-Wiki 完全自動化
這是最完整的版本，但建議等前兩階段都跑穩後再導入。
RSS / 手機分享 / 瀏覽器剪藏
↓
n8n / Wallabag
↓
/raw
↓
olw watch
↓
/wiki/.drafts
↓
人工審稿
↓
/wiki
這個架構可以做到：
RSS 自動收文
公開網頁自動轉 Markdown
NAS 自動保存
本地 AI 自動整理
Obsidian 自動生成 Wiki
人工審核後發布
CyberQ 指出，這種架構的價值不只是自動摘要，而是讓你的 NAS 變成一座會持續進步的私人研究中心。
階段五：正式啟動自動編譯管線
當 /raw、/wiki、Ollama 與 obsidian-llm-wiki 都設定完成後，就可以開始測試。
建議先放入 3～5 篇文章，不要一次丟幾百篇。
例如：
/raw/2026-04-25-ai-agent.md
/raw/2026-04-25-qnap-automation.md
/raw/2026-04-25-zero-trust.md
然後執行：
olw run
接著檢查輸出結果：
/wiki/.drafts/
和
/wiki/
如果你看到 AI 自動產生主題條目、概念條目、交叉連結與來源回溯，就代表流程已經跑通。
確認品質穩定後，才改用：
olw watch
之後，只要新的 Markdown 檔案被放進 /raw，AI 就會開始處理，並逐步更新你的 Wiki。
此時再切換到 Obsidian 的 Graph View，就會看到原本散落的文章逐漸變成彼此連結的知識網路。
從搬運工躍升為個人知識庫的知識策展人
CyberQ 認為，在 AI Agent（代理）時代，我們對知識管理的思維自然可能會同步跟著升級。傳統的筆記軟體需要極強的自律，多數人其實都會卡在整理這一關。
如果透過 Jina Reader + 自動化捷徑/n8n（消滅手動收集的阻力），加上 Obsidian LLM-Wiki（消滅手動整理的痛苦），我們把繁雜的歸納、下標籤關鍵字、建立雙向連結等苦差事徹底外包給了地端 AI。
我們可以做的，就是保持品味與好奇心，不斷地把優質的素材餵給系統。看著 Obsidian 關係圖裡那些由 AI 幫你自動生長、實體緊密交織的知識星系，你將深刻體會到，這才是一顆真正活著的專屬知識庫。
