Obsidian

前陣子在臉書分享過用 AI 整理課程影片的成果，收到超乎想像的迴響，也一直有人問工具什麼時候放出來。整理了一陣子，今天正式開源：lecture-to-notes。 這篇的重點 為什麼課程錄影大家都在錄，卻沒有人回去看完 筆記不必是「文字＋圖」的形狀：影片、逐字稿、總整理同步在一頁 手上有什麼就帶什麼來：錄影、錄音、投影片、照片，全部接上同一條時間軸 技術上堅持的幾件事：逐字稿永不自動改字、對時用證據不用猜 為什麼只有 OCR 不夠：沒有字的流程圖與超音波，怎麼判斷它重不重要 沒有 NVIDIA 顯卡也能跑的退階方案 教室後面的腳架森林 從以前就覺得復健科的課程很難做筆記。徒手治療、超音波掃描這種課，知識藏在「動作」裡，文字怎麼抄都抄不起來。所以現場永遠是滿滿的腳架，大家都在錄影，打算回去配飯複習。 但幾小時的影片，實際上根本不會回去看完。 想通的一個轉折：筆記不必是「文字＋圖」的形狀 有了 AI 之後，我原本的思路是教它精準截圖，把影片塞回傳統「文字＋圖片」的筆記形式。後來想通了：筆記不必拘泥於那個形狀。 直接做一個網頁，把影片跟逐字稿對上，想看哪段就跳到哪段。畢竟真正想知道的，是那個動作到底怎麼做——那只存在於影片裡。 所以最後的成品是三個層次疊在同一頁： 總整理拿來讀：結構化的重點筆記，配上當時的投影片 逐字稿拿來驗證：每句話都有時間戳 影片永遠在一鍵之外：影片播到哪，筆記自動高亮；點筆記的時間戳，影片直接跳過去 同一份內容還會輸出 markdown 進 Obsidian 筆記庫（之後語意搜尋找得到），以及 PDF 給不用這些工具的人。一堂課，三種耐久形態。 （截圖是一場頸椎超音波工作坊的實際輸出，日期與講者已馬賽克。） 手上有什麼就帶什麼來 真實的課程從來不會只有一支乾淨的錄影：有的講題錄了影、有的只錄到音、有的只用手機拍了投影片，會後主辦單位又補發一份 PDF 講義。 這個工具把資料夾原樣吃進去，自動判斷每個檔案扮演什麼角色，再把所有來源接上同一條時間軸——就算某張投影片從頭到尾沒出現在影片畫面裡，筆記引用到它的那一刻仍然指得回正確的時間點。 技術上堅持的幾件事 這個工具的設計目標不是「摘要一支影片」，而是可回溯（traceability）：筆記裡每句話都要能指回逐字稿的某個時間點、以及當下螢幕上那張投影片。幾個為此堅持的設計： 貴的事情全部在本機跑 Whisper 轉錄、抽幀、OCR、投影片語意判讀，全部在自己的 GPU 上跑完，零 API 費用。大型語言模型只在最後一步負責「寫」，而且只能根據前面各階段已經組好的證據寫。就算不跑最後一步，你也已經拿到逐字稿、去重後的投影片集、和兩者的對應關係。 逐字稿永遠不自動改字 自動改錯字聽起來很誘人，我們實際做了兩版、量測、然後全部退役。現在可疑的詞只會被「標記」出來，逐字稿本身一個 byte 都不動。每個標記是一個問題，不是一個替換——因為改錯了你永遠不會發現。 對時：檔案時間是假說，交叉比對才是證據 一場演講常常不只一個裝置在錄：主錄影、手機片段、照片。要拼回同一條時間軸，最直覺的做法是相信每個檔案自己的拍攝時間——而手機時鐘會漂移、有些檔案只剩修改時間、按過暫停的錄影會謊報自己的開始時間。 所以管線把兩件事分開：拍攝時間當「主張」，重疊音訊的交叉比對當「證據」。兩者差超過 5 秒，就標記衝突並停下來問人，絕不自動修正。這擋掉的是「44 分鐘對錯位、但每一頁輸出看起來都很正常」的災難。 缺工具就大聲說，不悄悄降級 選用的模型都經過自己資料的評測（repo 裡附了 OCR 引擎的 A/B 測試架）。可選的套件沒裝，功能會關掉並明講你少了什麼——絕不悄悄換一個比較差的方法。悄悄降級產生的是「錯的輸出」而不是「少的輸出」，那是最貴的一類 bug。 那張投影片上沒有半個字，怎麼辦？ 貼文發出來之後，有位朋友留言問：「請問您是把螢幕上的 PPT 以 OCR 方式彙整進入資料庫嗎？」這個問題剛好戳中我卡最久的一段，值得展開講。 ...

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 的新版取代舊版（那不是真的爭議）？是兩個各自可信的來源真的講不一樣？還是筆記那條根本沒出處、而素材那條有？ 風險：這個值弄錯了會怎樣。劑量、閾值、禁忌症、紅旗徵象算高風險；盛行率、命名沿革、背景知識算低風險。這個軸是一個可以調的旋鈕，不同領域刻度不一樣，醫學筆記只是刻度最嚴的那一端。 然後照分類路由：新版取代舊版直接更新，但舊的值用刪除線原地留著、附上原本的出處和日期，一個字都沒有消失；低風險的分歧，直接在筆記裡就地寫成一個區塊： ...

緣起 我從醫學生時代就很愛做筆記，這些年累積了幾千份醫學筆記。但老實說，在資訊取得這麼容易、要學的東西又這麼多的現在，已經很難再把每一份筆記都按照自己的架構做到相同品質了。 另一方面，在現代資訊越來越多的時代，能信任的高品質來源反而變得珍貴，這時教科書就是很好的資訊來源。不過復健科專科考試指定參考書就有四十多本，同個概念可能散在好幾本書的不同章節裡。要真的把它們都念過，幾乎是不可能的事。 很幸運這年代有了 AI，這類大型語言模型 (LLM) 擅長處理的就是這樣的長上下文處理，可是一次丟給他幾百本教科書也不切實際。這時就搭配好的內容搜尋與資料庫管理，並且把我做筆記的流程講清楚、調教給 AI，能夠避免幻覺下，確保AI有根據、有架構地產出筆記，我只要用心把整理好的高密度資料吸收進腦袋就好。 於是這變成了一個大型的教科書 LLM Wiki 專案：把書本轉成 AI 容易讀取的格式、精準找到目標章節、按照我的架構整理呈現、從教科書把重要圖片抓進筆記，最後還能跟既有筆記整合。 今天把它開源了，這篇來講講中間過了哪幾關。 第一關：把書轉成 AI 適合讀的格式 直接把 PDF 丟給大模型有幾個坑：又慢又貴（上千頁的書逐頁讀，token 開銷很可觀）；掃描頁和字型編碼壞掉的頁面，他會若無其事地跳過，你不會發現筆記裡少了東西；圖片則是直接消失。 我的解法是把重活全部留在本機：文字抽取用 PyMuPDF，每頁約 0.13 秒、0 token。掃描頁走本地 OCR 階梯（Surya → PaddleOCR-VL → 本地視覺模型），真的都失敗才輪到大模型親自看。比較特別的是兩個細節： 靜默失敗偵測：用字型風險、字元密度等規則，抓出「看起來有抽到字、其實是亂碼」的頁面 雙欄排序：教科書常是雙欄排版，直接抽會把左右欄句子交錯在一起，而且亂碼偵測抓不到這種錯。我們做了欄位偵測，確保閱讀順序正確 第二關：把書切成可搜尋的單位 書轉好了，AI 要怎麼找到內容？傳統的目錄（index）不夠用，因為一個主題常散在好幾章；自己上 tag 也不實際，維護不完也切不夠細。答案是語意搜尋（semantic embedding）：把內容變成向量，用意思找而不是用關鍵字找。 這裡有個容易被忽略的設計：chunk（切塊）不是無腦固定字數。切太小會失去脈絡，切太大會稀釋語意。我們選擇照標題結構切塊，並保留每塊的上層章節脈絡，讓搜尋結果撈回來的每一塊都是有頭有尾的完整概念。 第三關：在幾十本書裡找到對的那本 跨書搜尋的底層，就是我之前開源的 vault-search 那套方法（那篇的介紹在這裡），本地 LanceDB 加 bge-m3 embeddings，資料不出自己電腦。 在這之上我們還加了一層：重點書目加權。考試指定用書、學會官方教科書，搜尋時分數會被調高，另外也有依出版年份的新舊加權。同一個主題，AI 會優先引用你最信任的來源。 第四關：建立寫筆記的 algorithm 與原則 工具都有了，真正決定筆記品質的是流程設計： 先盲寫：AI 先不看我的既有筆記，獨立從教科書查完完整資料寫草稿，最後才合併。這是為了避免被舊筆記的結構和內容干擾 Template 是抓取的依據：每種主題有固定模板，這個設計很重要，AI 知道該去書裡找哪些東西，我每次閱讀也知道會有哪些段落，吸收速度快很多。repo 裡直接附上我每天在用的五套模板（中英雙語），可以照著改成自己的 為理解而設計的段落：像是開頭的 Summary、結尾的 management algorithm，這種段落的存在本身就是在協助理解，不只是資料的堆放 沒有引用就不算數：每條主張都標到書名＋章節，AI 用自己知識補的內容一律標記為推論 第五關：從書裡抽出圖片 這是整套系統最難的部分，因為每本書的排版邏輯都不一樣。我們的做法是先有一套通用方法（幾何比對：圖說跟最近的圖像互相認領），配上決定論的 audit：留白檢查、文字滲入檢查，規則過了才算過，AI 說了不算，而且全程用省 token 的方式在本機執行。 ...

一個困擾我很久的小事 我是 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 終於贏了，而且贏很多。 ...