知識管理

2023 年 8 月，我在 Evernote 的社團裡發了一篇文，講我想搬家但卡住了。那篇沒什麼人看到，但它記錄了一個很多人現在正在面對的處境，所以我想先把當年的脈絡講清楚，再講三年後發生了什麼。 這篇的重點 當年我卡在哪、怎麼判斷、最後選了什麼 2026 年的轉檔工具現況：多了一條走 API、不走 .enex 的新路 標籤到底保不保得住（我當年保住了，但故事沒那麼簡單） 轉檔只是開始，真正的工作在轉完之後 搬過來之後，這些筆記能做到哪些 Evernote 時代做不到的事 當年我卡在哪 問題很具體：我的筆記本身只有 30MB，附件卻有 20GB。 5,000 多則筆記，文字轉成 Markdown 一點都不難。難的是那 20GB 要放哪、以及怎麼在 iPhone 跟 Windows 之間同步。我當年把三條路都試過，每一條都撞牆： iCloud：在 Windows 上不即時同步 官方 Obsidian Sync：當年一個月 8 美金但只有 10GB，我有 20GB Git：單檔不能超過 100MB，一次要上傳下載這麼大的量，電腦跟手機都動不了 如果你全套是 Apple，iCloud 就沒問題；全套是 Windows 加 Android，OneDrive、Dropbox、Google Drive 也都沒問題。我的麻煩就在於兩邊都有。 那時候我同時在評估 Heptabase。它的優點很明顯：不限檔案大小、上手容易、開發者是台灣人、跟社群溝通很積極。但我試著把資料搬過去的時候，附件上不去、原本的標籤也匯不進來，白板功能看起來也還不太支援匯出。 那才是讓我做決定的點。 我剛經歷完 Evernote 的興衰，最怕的就是再來一次：哪天這個服務又出事，我搬不搬得走？當年我寫下這句話： 現在特別重視 future-proof，希望能永遠用下去。 最後我選了 Obsidian，並且把 vault 拆成兩份來閃過 10GB 的限制：一份放全部筆記加比較小的附件，另一份放工作上要隨時取用的檔案，其餘附件丟雲端硬碟，真要用再搜檔名。 這個做法很土，但它撐過去了。 三年後，這個 vault 長成什麼樣子 項目 數量 Markdown 筆記 5,664 篇 附件（圖片、PDF） 16,769 個 醫學筆記（一個疾病一篇） 2,520 篇 vault 總大小 約 14 GB 當年搬過來的是 5,000 多則，現在多出來的是這三年新長的：復健科的疾病筆記、論文整理、演講轉成的筆記、專案紀錄。 ...

為什麼「太多筆記」跟「沒有筆記」是同一件事 先講一個我很早就認定、到現在也沒改過的規矩：我的筆記庫裡，一個主題只能有一則筆記。 不是因為潔癖。是因為同一件事如果有五個地方在講，我查東西的時候就得開五個檔案，還要自己判斷哪一版才算數。那個整理的工作沒有消失，只是原封不動地留給了未來的我。 而未來的我通常正在看診、正在趕投影片，沒空做這件事。資訊太多造成的混亂，跟資訊不足是同一種痛苦。 這條規矩在只有一個素材來源的時候很好守。難的是後來，來源越長越多，而且沒有一種會停下來等我： 教科書 → textbook-to-note，把自己的 PDF 教科書轉成有出處、有架構的筆記（repo） 論文 → paper-radar 追蹤、paper-fetch 抓全文、paper-review-and-digest 評讀與內容整理 演講 → 還沒整理好，是目前唯一還沒開源的一支 這些工具解決的都是同一件事：把外面的東西變成看得懂的素材。它們讓素材的產量變高了，但那條「一個主題一則筆記」的規矩沒有因此變好守，反而變難守。 所以整套架構是兩層，界線畫得很硬： 素材庫：外面進來的東西全部丟進去，原樣留著、隨時可以回頭溯源。它可以雜、可以重複、可以互相矛盾，因為它的職責只是「保存證據」。 主題筆記：屬於我自己的部分，一個主題永遠只有一則，放在獨立的資料夾、照同一份模板寫。它是我唯一信任、也唯一會拿去用的那一份。 素材不是筆記 這條界線一旦模糊掉，筆記庫就會退化成一個比較漂亮的下載資料夾。 而把素材的內容併回主題筆記的那個動作，就是這兩層的交界處。這篇要講的 note-supplement，做的就是那一件事。 那也是整條線裡我卡最久的一段。從零寫一份新筆記，AI 做不好你一眼就看得出來：架構亂、沒出處、內容空。但「把新素材補進一份已經存在的筆記」不一樣。我有幾千則筆記，每一則都是過去某個時間點的我認真查證過的結果。 為什麼「幫我更新筆記」這句話這麼危險 直覺做法是把新素材丟給 AI 說「幫我更新這篇筆記」。我吃過幾次虧才想清楚問題出在哪： AI 更新筆記真正的風險，不是它漏掉新內容，而是它會很安靜地改掉你舊筆記裡原本就對的東西。 而且你不會發現，因為輸出看起來仍然是一篇好筆記。 這兩種錯誤的代價完全不對稱： 漏掉新內容：可回復。下次讀到同一份素材、或同一個主題再出現，你還有機會補。 改壞舊內容：不可回復。因為那條內容你已經查證過了，你不會再去查第二次。它從此就以錯誤的樣子留在你的筆記庫裡，還帶著你自己給它的信任。 一旦看清這個不對稱，整個工具的設計就只剩一句話。 設計原則：新增很便宜，改動很昂貴 每一輪，note-supplement 會把素材跟既有筆記對三件事： 哪些是筆記沒有、可以補進去的 哪些是兩邊講得不一樣的 哪些是筆記本來就有、素材沒提到的（這些一律不動） 然後把每一項變更先分類，再決定誰有權限執行。 自動放行的：帶引用的新增 多一條有出處的內容，不會傷害筆記。所以「新增事實 bullet 且帶引用」這類變更直接寫入，記進 changelog。 （有一項後來被我從自動放行拿掉了：把散落的 bullet 收成表格。它看起來只是排版，實際上是把每個事實重新塞進欄位裡，這是改寫不是新增，而且欄位錯位這種壞法無聲無息，產出還比原本更整齊。現在它要問過才做。） 不做「破壞性」裁決的：事實矛盾 這一段是我改最多的地方，也是這個工具第一版最大的設計錯誤。 第一版的規則寫得很硬氣：只要有事實矛盾就送審，不管哪一邊的證據看起來多強，一律不自動裁決。 聽起來很負責。實際跑了一段時間，我發現兩件事： 一、待審清單不是安全機制，是拖延機制。 清單一長，人就會一路按過去，所謂「留給你判斷」，實際效果等於「自動套用，只是多按了幾下」。而且報告每一條後面都有一行「我的建議是⋯」，那行字會定錨，你多半就照著它按了。那不是我在判斷，是它在判斷，只是排版比較客氣。 二、不決定本身就是一種決定。 衝突躺在清單裡的那段期間，筆記裡那條可能已經過時的舊說法，仍然是唯一被寫在那裡、被我信任的版本。「不裁決」的實際效果是「舊的自動贏」，而這個政策我從來沒有主動選過它。 所以 v1.1 換了個立場：不是不裁決，是不破壞。 矛盾先分兩個軸分類： 類型：是同一本書、同一份 guideline 的新版取代舊版（那不是真的爭議）？是兩個各自可信的來源真的講不一樣？還是筆記那條根本沒出處、而素材那條有？ 風險：這個值弄錯了會怎樣。劑量、閾值、禁忌症、紅旗徵象算高風險；盛行率、命名沿革、背景知識算低風險。這個軸是一個可以調的旋鈕，不同領域刻度不一樣，醫學筆記只是刻度最嚴的那一端。 然後照分類路由：新版取代舊版直接更新，但舊的值用刪除線原地留著、附上原本的出處和日期，一個字都沒有消失；低風險的分歧，直接在筆記裡就地寫成一個區塊： ...

一個困擾我很久的小事 我是 Obsidian 的重度使用者，vault 裡躺著好幾千則筆記。 但有件事很不方便：Obsidian 內建的搜尋，只會找「你打的那幾個字」。 問題是，三年前寫的筆記，我哪記得當時用了什麼字？我心裡想的是「鬆弛性膀胱要怎麼處理」，筆記裡寫的卻是 Neurogenic Bladder → flaccid type → 間歇性導尿。字對不起來，搜尋就一片空白。最慘的是，有好幾次我以為自己沒寫過，結果重寫一遍，事後才發現早就有一篇更完整的躺在那裡 😅 所以我花了點時間，幫自己的 vault 裝上一套「用意思找筆記」的工具。用了大半年，現在把它整理乾淨、開源出來。 三套組 它不是一個大功能，而是三個各司其職、共用同一份索引的小工具。 🔍 Vault Search — 用一句話找到對的段落 最核心的一個。你用自然語言問一句話，它回傳語意上最接近的筆記段落，而不是關鍵字比對。 我打「脊髓損傷後的鬆弛性膀胱怎麼處理」，它直接翻出 Neurogenic Bladder 那篇，即使那幾個中文字一個都沒出現在筆記裡。它看的是意思，不是字。 結果還會自動分成「主要相關」跟「其他相關」兩層，並且可以折疊預覽，不用一篇一篇點開。 🔗 Related Notes — 替你的筆記接上神經 這是一個會即時更新的側欄。當我在讀某篇筆記、或選取一段文字時，它自動在旁邊跳出相關的其他筆記。 對我來說這是「驚喜製造機」。很多「我早就忘記自己寫過」的東西，就這樣被串了起來。寫一篇新筆記的時候，旁邊會冒出三五篇舊筆記提醒我「這裡其實可以連過去」，慢慢把零散的卡片織成一張網。 💬 Vault Chat — 直接跟自己的筆記對話 這就是大家熟悉的 RAG：它先搜尋相關筆記，再把內容餵給 AI 回答。但我刻意設計了三種模式： Vault 模式：只根據筆記回答，不用擔心 AI 自己生成內容。 Hybrid 模式：以筆記為主，不足時用 AI 自己的知識補充，並標明哪些是「補充」。 Free 模式：不搜尋筆記，純自由對話，還能查 PubMed 文獻。 每次回答後，它會列出引用了哪幾篇筆記，可以一鍵點開查證。對醫療這種「答錯會出事」的領域，可追溯來源這件事我很在意。 點開任何一個引用，還能看到它實際餵給 AI 的那段筆記原文，整條推理鏈是攤開可查的。 ...

背景：我本來就在用的東西 念專科考試的時候，我給自己弄了一套 RAG（Retrieval Augmented Generation），用「看相似度」的語意搜尋（semantic search）把幾百本復健科教科書跟我自己的筆記變成可以查、可以問的東西。一邊在 Obsidian 裡讀書用，一邊讓 Claude 透過 MCP 也能找到我要的東西。 它目前最弱的地方，就是「跨文獻把知識串起來」。所以前幾天看到有人分享一篇剛發表的論文 SAG（SQL-Retrieval Augmented Generation），說可以在語意搜尋之外加上結構化查詢語言（SQL）跟圖的概念，讓跨文獻搜尋更容易，效果類似 GraphRAG 但更好維護、更好建立，我整個眼睛一亮。 在這時代想當然爾，就是把論文連結丟給 Claude，請他去讀論文、抓原作者的 GitHub、讀懂作法，然後用我自己的資料把整條管線複現出來、實際跑 benchmark XD 論文：Wu et al., SAG: SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges, arXiv:2606.15971。程式碼：github.com/Zleap-AI/SAG-Benchmark 第一步：選模型（RTX-3070 的眼淚） 整條管線裡最關鍵的一步，是用 LLM 把每段文字抽成「事件 ＋ 實體」存進資料庫。原論文用 Qwen，我就比了本地的 Qwen（qwen3.5:4b）跟線上的 Claude Haiku。 結果 Haiku 萃取資訊的能力明顯比較好，實體圖更密、命名更一致（這對後面用 SQL 串很重要），而且看起來很便宜。這跟我先前的經驗相符，可能我的 RTX-3070 真的太弱了，稍微大一點的模型就跑不動（時代的眼淚阿），直接用 Haiku 又快又好！ 順帶一提，我沒有 API 訂閱也能用 Haiku：直接派 Claude 的 subagent 去做，跑在既有額度內就好。 教科書上的三個發現 我用神經復健的教科書當測試語料，設計了一批臨床問題，拿 SAG 跟原本的語意搜尋正面對決。結果分三關： 第一關，單一本書：打平。語意搜尋已經夠強，多跳機制沒用武之地。 第二關，跨書、但問題裡把關鍵字都寫白了：還是打平。因為問題裡已經把「中風、脊張力、步態」全寫出來，語意搜尋自己就把相關段落都撈回來了。 第三關，跨書、但只問一端、中間那跳故意不講（例如只問「馬蹄內翻足怎麼處理」，期待它自己連到背後的脊張力機轉跟治療）：SAG 終於贏了，而且贏很多。 ...