左邊是筆記模板,右邊是這套系統依模板產出的實際筆記,每條主張都標了出處

跨教科書 自動筆記生產流程:專科考試下的產物

緣起 我從醫學生時代就很愛做筆記,這些年累積了幾千份醫學筆記。但老實說,在資訊取得這麼容易、要學的東西又這麼多的現在,已經很難再把每一份筆記都按照自己的架構做到相同品質了。 另一方面,在現代資訊越來越多的時代,能信任的高品質來源反而變得珍貴,這時教科書就是很好的資訊來源。不過復健科專科考試指定參考書就有四十多本,同個概念可能散在好幾本書的不同章節裡。要真的把它們都念過,幾乎是不可能的事。 很幸運這年代有了 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 的方式在本機執行。 ...

July 19, 2026 · 1 分鐘 · 160 字 · 陳柏威 Po-Wei Chen
夜晚的書房裡,一個人平靜地檢查一串發光的鑰匙,旁邊有友善的 AI 小幫手與微微發光的家用伺服器

當 AI 無所不能,我回頭確認一遍家裡的鑰匙

這陣子我越來越依賴 Claude Code 幫我打理數位生活,從整理我的 Obsidian 筆記庫,到維護家裡自架的一堆服務(OpenWrt 路由器、AdGuard Home、Synology NAS、Oracle 雲端主機、Home Assistant),再到各種半夜自己跑的自動化,幾乎都交給他。他能做的事愈來愈多,我有一天就認真想了一件以前沒細想的事:我把一個「能讀我電腦裡的檔案、能執行指令、又能連上網路」的 AI 幫手,給了這麼大的權限,那萬一哪天出錯,會錯到哪裡去? 先搞清楚:權限這麼大,可能出什麼錯? 於是我請 Claude 陪我,把這件事從頭查一遍。查下來,AI 幫手(agent)的風險大致歸成幾類: 致命三要素(lethal trifecta):能讀檔案、能執行指令、能連網路,這三件單獨都還好,但湊在一起,一旦 AI 被騙,它就有能力把你的祕密讀出來、再送到外面去。 間接提示注入(indirect prompt injection):白話說,就是一段藏在網頁或某個檔案裡的惡意指令,可能在 AI 幫你讀資料時,偷偷叫它去做你根本沒交代的事,比如翻出你的金鑰再傳出去。 對話會留存:你順手貼進對話框的東西,其實會被記在某個地方。 老問題的放大版:密鑰散得到處都是、權限給太大、不小心把祕密存進了 git。 查完我的感想是,這些都不是假設性的學術風險,是真的會發生的事。再加上身邊愈來愈多同好也開始玩 AI agent、也在自架自己的服務,我想說乾脆把我查到的、做過的都記下來分享,希望也幫到正走在同一條路上的大家。 我們做了哪些檢查與掃描 方向定了,我跟 Claude 就一項一項盤: 數清楚我到底有多少把「鑰匙」跟 token,各自散在哪。不數還好,一數有點尷尬,原來比我想像中亂。 用一個叫 gitleaks 的工具,掃我自己筆記庫跟所有專案的 git 歷史,看有沒有哪次手滑把金鑰存了進去。 把家裡每一台主機之間「誰可以登入誰」的關係攤開來看(這在資安上叫橫向移動 lateral movement,意思是攻擊者攻破一台之後,能不能再跳到下一台)。 檢查我給 AI 的權限設定,跟過去那些對話紀錄到底留了什麼。 找到的問題,跟我們怎麼補 這段有點像在自首😅,但我覺得誠實把坑寫出來,比假裝自己一開始就做得很好有用多了。 問題一:一把沒上鎖的萬能鑰匙 我有一把 SSH(Secure Shell,遠端登入主機用的)金鑰,居然沒設密碼,而且同一把幾乎能打開我家所有主機。等於一把沒上鎖的萬能鑰匙,誰撿到誰就開全家。 我們的處理是:幫它加上密碼(passphrase),再用一個叫 ssh-agent 的機制,讓我只要輸入一次、之後自動化照樣順順跑,安全跟方便都顧到。然後把它從「一把開全家」改成「一把鑰匙只能做一件事」(這招叫 forced command,指定這把金鑰登入後只能執行某個預先設定的指令,而不能取得一般 shell)。 問題二:順手貼進對話的密碼 注意 我以前圖方便,曾把 token 直接貼進跟 AI 的對話框,那它就被留在本機紀錄裡了。這種「已經外洩過」的東西,與其一個一個追副本,最乾淨的做法是直接把舊鑰匙作廢(rotate),重發一把新的,舊的當場失效,外面那些副本就全變廢紙。 問題三:筆記裡躺著兩個忘記的金鑰 這是這次最有感的。我用 gitleaks 掃自己的筆記歷史,竟然挖出兩個我幾年前順手記下、早就忘得一乾二淨的真實金鑰。原來最大的洞,常常不是什麼高深攻擊,而是「過去那個貪方便的自己」。 ...

June 28, 2026 · 1 分鐘 · 137 字 · 陳柏威 Po-Wei Chen