之前分享過用 Claude Desktop 串接 Notion MCP (一開始本地，後來用官方)，
讓 AI 可以直接讀取我的 Notion 資料，這件事對我的工作流與知識管理帶來不小的幫助改變，
但用了一段時間後，發現一個讓我很在意的問題：
＊＊官方 Notion MCP，TOKEN 吃太兇了。
官方 MCP 的運作方式，是 Claude 每次回答問題之前，
先地毯式翻找我的 Notion 頁面，把找到的資料全部塞進對話，
問個幾次，對話長度就爆掉了，不是要求壓縮對話，就是 TOKEN 用量直接耗盡，
資料量越大，這個問題越嚴重。
以我的 Notion 來說，3,000 多頁的資料，問一個需要跨資料庫整合的問題，
光是搜尋和確認資料，就能把一大半的 TOKEN 配額吃掉，根本還沒開始回答問題。
我就在想，有沒有辦法讓 AI 在【回答之前就已經知道哪裡有相關資料】，別這樣亂撈，
精準拿到真正需要的那幾筆，而不是每次都需要翻遍整個 Notion？
為什麼官方 Notion MCP 不夠用？
官方 MCP 的搜尋邏輯是【關鍵字搜尋】，如果問「有沒有跟領導力相關的筆記」，
他找的是標題或內容裡有「領導力」這幾個字的頁面，
語意相近但用詞不同的內容，就很容易被漏掉，而且找到的資料量通常過多，TOKEN 消耗驚人。
我想解決的解決的正是這兩個問題，對策是：
＊＊問題一：搜尋太廣泛 → 本地 RAG 用語意向量搜尋，精準找出【最相關的幾筆】，不是全部倒出來
＊＊問題二：TOKEN 吃太多 → 每次只帶入真正需要的資料，TOKEN 消耗大幅降低，對話可以持續很久
＊＊先釐清一個重要觀念：Notion 是給人看的，不是給 AI 看的。
Notion 的頁面層次、資料庫視圖、屬性欄位——這些全是為「人類瀏覽」設計的。
打開 Notion，眼睛掃一下，大腦自動理解結構，知道去哪裡找什麼，
哪個資料表在哪一層，這筆資料是什麼顏色，對記憶與搜尋都有幫助。
AI 完全不是這樣運作的。
AI 沒有辦法「瀏覽」，欄位配置、表格對照、顏色屬性對他都沒有意義，
它只能接收你直接塞給它的文字。
每次問 AI 一個問題，它要先把相關資料找出來，全部塞進對話，才能開始思考回答，
這就是為什麼官方 Notion MCP 那麼耗 TOKEN：它把找到的頁面全塞進去了，
而通常我們需要的，只有其中一小部分。
＊＊RAG 解決的正是這個問題。
本地 RAG 是什麼
RAG（Retrieval-Augmented Generation，檢索增強生成）的核心做法是：
**先建好索引，問問題時只帶入最相關的資料，不是全部。**
具體流程是這樣：
1. 一次性把所有筆記「向量化」——把每篇筆記的語意轉換成一組數字，存起來
2. 以後問問題，把問題也轉成同樣格式的數字，用數學找出「意思最接近」的幾筆
3. 只把這幾筆帶進對話，AI 精準回答，TOKEN 消耗極小
這就是【語意搜尋】——比如問「領導管理的方法」，他能找到標題叫「帶人的藝術」的筆記，
因為他理解的是語意，不在乎文字有沒有完全吻合。
**但語意搜尋也有它做不到的事。**
如果問「閱讀清單裡，我最近看完，分類是商業書有哪些?」
書的分類是商業管理、書的狀態是 Finished ，純粹是Notion表格的屬性值，不涉及頁面內文，
這種問題需要精確的條件邏輯，不是「找意思相近的」，而是「找完全符合條件的」，
語意搜尋是做不到這件事的。
所以這套系統同時跑了兩個搜尋引擎：
＊＊Qdrant 向量資料庫（RAG 語意搜尋）——理解語意，適合模糊問題
「有什麼關於 XX 的筆記？」「部落格寫過什麼相關主題？」
＊＊SQLite 資料庫（SQL 精準篩選） ——精確條件，適合結構化查詢
比如「狀態是 Finished 的書」「金額超過 5000 的支出」
這個設計讓兩種查詢方式互補，覆蓋絕大多數可能問到的問題類型，
叫它【RAG + SQL 雙引擎知識庫】，可能更準確。
實際完成的架構與運作邏輯
整套系統用了 4 天多（利用下班時間）搭建完成。
做好後，先花時間跑一次同步程式（叫claude code幫忙執行），
幫每篇筆記建立「索引卡」（這就是「向量化」），
之後每次問問題，直接查索引卡，10 秒內找到最相關的幾筆，
只帶入這幾筆資料——精準、省 TOKEN、對話可以撐很久。
整套架構長這樣：
兩個資料庫，各有分工
光有一個資料庫是不夠的——語意搜尋和精準篩選是兩種完全不同的需求，各自需要不同的引擎。
＊＊Qdrant 向量資料庫——語意搜尋
把每篇筆記的「意思」轉成一組數字（向量），存起來。
你問「讀書方法」，它能找到標題叫「學習策略」、「如何有效閱讀」的筆記——不需要文字完全吻合，意思到就行。
這解決了官方 MCP 最大的痛點：用詞不同但意思相近的筆記，再也不會被漏掉。
＊＊SQLite 資料庫——精準條件篩選
把每篇筆記的屬性（狀態、分類、標籤、金額、日期、位置……）全部存進 SQLite，支援精確條件查詢。
你問「閱讀清單裡，分類是商業管理、狀態是 Finished 的書有哪些」，它直接給你完整清單，一筆都不漏。
這是語意搜尋做不到的事——要講精確條件，就得靠 SQL。
兩個資料庫同時在跑，Claude 根據你問的問題類型，自動判斷用哪個（或兩個都用）。
圖片，AI 也能「看懂」
Notion 裡的書封照片、截圖、手繪筆記……以前這些對 AI 來說是黑盒子，完全看不到。
要不是略過，不然就是解析後放入RAG ，RAG只能存文字、理解語意(但是不存原始圖)
但問題是，一個圖片能包含的資訊非常多，如果沒解析成文字的內容，就再也不會被知識庫找到
剛好我資訊同事之前有處理大量圖片的需求跟經驗，借鑒他的邏輯，
我安裝了一個叫 **Ollama + llava-phi3** 的本地端的圖像識別模型，專門負責「看圖說話」。
它幫每一張圖片生成一段文字描述，然後這段描述被存進向量資料庫，一起被索引。
這樣一來：
問「有藍色書封的那本書叫什麼」→ 找得到
問「有圖片的筆記有哪些」→ 找得到
叫 Claude「把這篇筆記給我看」→ 原圖直接顯示在對話視窗，圖文都能看
而且 llava-phi3 完全在本機執行，圖片不需要上傳任何伺服器，隱私有保障。
每天早上知識庫自動更新
Windows 工作排程器設定了凌晨 3 點自動執行，依序跑完五個步驟：
1. ＊＊同步 Notion — 抓取所有有變動的頁面（增量同步，沒改過的頁面不重複處理）
2. ＊＊同步 WordPress — 抓取新文章和更新過的文章
3. ＊＊擷取 PDF 文字 — 把附件 PDF 的文字內容提取出來
4. ＊＊AI 圖片描述 — 讓 llava-phi3 為新增圖片生成描述
5. ＊＊重建向量索引 — 把所有更新都納入 Qdrant
早上起來，知識庫已經是最新版本，不需要手動操作任何東西。
三個工具，各司其職
Claude Desktop 有三個工具可以呼叫，對應三種不同的查詢需求：
踩到的坑（不少）
以我這種coding門外漢程度來建構資料庫，當然不可能一路順暢。
分享一下我遇到的幾個問題:
坑一：WordPress 文章一開始只能找到 3 篇
好不容易把部落格 100 篇文章都同步進去，
但用 Claude desktop測試搜尋的時候，只找到 3 篇，
原來是向量資料庫的資料裡少存了「來源」這個欄位，
Claude 不知道哪些是部落格文章、哪些是 Notion 筆記，
所以我問他我最近部落格有哪幾篇文章，幫我摘要一下，他說我只有三篇，
加上這個欄位之後，搜尋結果現在會標示 📝 WordPress 或 📔 Notion，AI就能精確分辨。
坑二：每天同步會重跑 100 次 API
每天凌晨同步時，Notion 的同步腳本會清理資料，
結果連帶把 WordPress 的資料也清掉了，
下一個步驟的 WordPress 同步腳本就看不到舊資料，
只好全部 100 篇重新跑一遍 API，多花了不少時間，
後來 Claude code 加了幾行保護邏輯，讓 Notion 清理時繞開 WordPress 的資料，
才把這個效率問題修掉。
坑三：圖片格式問題
Notion 下載下來的書封圖片，明明副檔名是 .png ，但實際上是 WEBP 格式，
送給圖片理解 AI（llava-phi3）的時候，一直回報錯誤，
後來用 Pillow（圖片處理套件）偵測真實格式，統一轉成 JPEG 再送，才全部解決。
這種問題，我根本沒有能力可以處理，有 Claude code 幫忙偵錯，大概 10 分鐘就搞定了。
用起來的感覺
高速，有效率，而且很省Token!
之前一般會先看他使用fetching Notion (官方指令)
開始跑一連串指令，可能會先說，我找不到資料，我擴大範圍試試，
還是不行，我再試試另一個方法， 找到了! 資料很多，我看一下，
如果是大資料表，這時候可能就觸發了一次壓縮對話，
而建構完成後的資料庫，撈取資料會像是這樣：
整個過程只需要不到20秒，可以延伸運用的機會就類似，
「幫我整理一下我 Notion 裡面關於時間管理的筆記，跟我部落格寫過相關主題的文章」
ps: 這麼大規模的搜尋還是可能會觸發壓縮對話，與耗用較多的token
以前要做這件事，我要自己去 Notion 篩選、再去部落格翻文章，
合併整理可能要幾十 分鐘，現在 Claude 幾分鐘就能跨資料庫找到相關內容，整合成摘要，
人腦有容納的限制，讓AI幫忙對於延伸主題很有幫助，因為很多觀點我自己沒注意到有相關，
而且整個對話過程，TOKEN 消耗比官方 MCP 少得多，
可以問更多問題，並較少遇到對話被壓縮或 TOKEN 耗盡的狀況。
如果需要某張圖，claude desktop找到後，會直接點擊存在本機的圖片檔案，
就會用預設的圖片瀏覽器打開。
心得
語意搜尋跟屬性搜尋都算是很好用，只不過如果本來資料有好幾筆重複或很類似的，
還是會需要問精確一點的問題，比如迷霧之子這本書，
我在支出清單有一筆，在閱讀清單也有一筆，claude可能會找錯資料，
而即使有這個知識庫輔助，在Notion資料分類跟結構上，還是不能完全隨便亂放。
claude code跟一些vibe coding的工具非常有趣，
他讓沒有程式背景的人也能實現各種小工具，
不會coding的人以前無法建構程式工具，就像是不會外文的人無法跟外國人溝通，
不一定是沒有程式思維，而是coding這個進入門檻卡在那，
但vibe coding跟AI的進步其實是能力放大器，像我這種門外漢就是做基礎工具，
而本來就有coding大型專案能力的人，指揮AI就像給他5個10個聽話的碼農，
能夠建構出更為龐大複雜的系統架構。
萬事起頭難，AI與vibe coding讓很多事情起頭難度降低許多，
只要願意投入研究，知道自己要什麼，以及能判斷做出來的東西對不對。
就有機會實現很多以前從來沒想過的事。
建置懶人包
建置指南_本地RAG知識庫
可以大概看過整份指南（我放在hackmd.io），沒什麼問題的話，整份丟給AI ，
即使沒有claude code，Gemini CLI、Codex等完成這個專案應該都不困難，
不過要留意一下的是，我的顯卡是5060TI 16GB，跑本地圖像辨識模型負擔不重，
如果也有圖像辨識需求，可以自己跟AI討論一下適合的模型 (看要更強還是更弱)。
建構上需要【自己】注意的點是：
1. Notion Integration Token 已拿到（ 問AI如何取得Notion的API ）
2. .env 填好了 NOTION_TOKEN=secret_xxx…
3. 在電腦找到Claude Desktop config.json 的絕對路徑，並且做設定 (可以參考我這篇)
4. 圖像模型安裝 (claude code會指引安裝方式)
其他幾乎全部都是claude code能依序獨力完成的，
可以先請claude code列出ToDo list，
確認他的理解跟規劃正確後再開始實作。
2026/3/31補充
不少時候除了查找資料，也需要反向把資料寫進Notion，
尤其我自己做的支出清單，最近有些想要優化的部分，
但是1千多筆資料，涉及的屬性值 要改2千個以上，我就想讓AI協作(都丟給他)，
所以還是申請了一個有編輯權限的API，然後跟claude code討論skills製作，
用來專門對應Notion查找還有寫入，skills列出我主要常用的頁面號碼，
不確定的就語意搜尋，先去本地RAG撈頁面號碼 (會比API直接語意撈整個Notion精準)，
不論是claude code還是claude desktop，透過Skills的優化，
都能更為精準有效的工作，我的支出清單優化他大約10分鐘就精準完成，
如果我自己處理，至少得花上一兩個小時。
我的Notion skills參考 (我放在Gist分享)
相關文章：
Notion+Claude MCP AI煉成-與第二大腦對話
Claude code寫程式?我這個麻瓜竟然可以用魔法了?Vibe Coding
Notion模板分享－物品管理清單
Claude code skills小工具 – 截圖給它看