AI 工作流

在花東跨院支援門診，最花心神的其實不是看診，是回程的火車票。下診時間不固定，玉里、關山、臺東各有各的班次窗口，加上夏天傍晚的花東線，坐錯邊就是整路被太陽曬🥵 這種事就該交給 Claude。這幾天我們把「訂票祕書」做起來了，今天真的用它訂了回花蓮的票。 這篇的重點 為什麼一張車票會需要一個系統：門診表、停診公告、台鐵訂票紀錄三份資料要對得起來 門診行程 × 車票總覽：哪一天缺哪一段車票，打開一眼看出來，勾一勾批次訂完 座位側別是推算出來的：環島路網的海側是不變量，配上各車種的座號餘數表就能判定曬不曬 不只避曬：邊緣列、輪椅座正後方的桌板位、到站出口最近的車廂，全部進同一個評分 建置用到的工具：本機瀏覽器自動化、交通部 TDX 開放資料、Cloudflare Tunnel、DPAPI、ntfy 有人問了一句「這樣用可以嗎」，於是我把台鐵條款、鐵路法修法沿革和 32 件相關判決全部讀完，並據此改掉了訂票邏輯 為什麼這個專案不開源：自我約束只存在於我這台電腦上，工具放出去就管不到別人拿去做什麼了 一張車票，為什麼會需要一個系統 我的支援門診固定在幾條路線上：週一玉里來回，隔週三花蓮到關山、關山再到臺東、傍晚回花蓮。看起來規律，實際訂票時要同時記住三件事： 哪幾天要去哪裡：門診是規則排的，但會有停診 哪幾段已經訂了、哪幾段還沒：台鐵的訂票紀錄頁面預設只顯示最近幾筆，一次要訂一個月的票就得自己數 那一班的座位坐哪邊：這是最後才想得到、卻最影響搭車體驗的一件事 以前是靠記憶加上翻訂票 App。做成工具之後，這三件事變成一個畫面。 門診行程 × 車票：先對帳，再訂票 打開祕書站的第一個畫面不是班次表，是未來四週的門診行程，每一段旅程旁邊掛著它的車票狀態。 這一頁背後接了三份資料： 門診日由排班規則生成（週一玉里、隔週三關山與東基，錨定在一個已知日期往後推） 停診直接讀我自己門診資訊頁背後的同一個 API。同一份資料兩個用途：對外公告停診，對內就不會排出一段不存在的行程 已訂車票去台鐵會員的訂票紀錄掃，把每筆訂單拆成「日期＋起站＋迄站」，跟行程比對 對得上的顯示 ✅ 加車次、訂票代碼與付款狀態；對不上的就是一個空的勾選框，寫著「未訂（預設 441 次）」。 缺的票勾一勾，丟進購物車，按一次全部訂完。 批次訂票的順序是嚴格排隊的：後端有一把工作鎖，一筆訂完才開始下一筆。原因很單純，訂票是操作同一個瀏覽器分頁，兩筆並行只會互相踩到。 要自己挑班次時，還有一個班次看板：選日期、看時刻、點「訂」，跳出張數、靠窗或走道、要不要避曬的選單。 座位：曬不曬是可以算出來的 這是整個專案最好玩的部分。訂票網站不會告訴你這個座位在哪一側，但這件事其實可以推。 海側與山側是不變量 台鐵環島路網是一個環。固定編組的列車兩端都有駕駛室，中途從不調頭，而環島線的「海」永遠在外圈。所以一個座位是海側還是山側，全線、雙向都不會變。 會變的是方位：花東線的海側朝東，南迴線的海側朝南，屏東與縱貫線南段的海側朝西。所以只要知道「海側」，再知道現在走到哪一段、幾點，就能判斷太陽在不在你這一邊。 座號的餘數決定一切 台鐵的座位編號有規律，座號除以 4 的餘數是 1 或 2 就是靠窗，3 或 0 是走道（例外：EMU3000 第 6 車騰雲座艙是 2+1 配置，餘數 0 才是那排單人靠窗座）。再往下一層，餘數也決定左右： ...

前陣子在臉書分享過用 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 方式彙整進入資料庫嗎？」這個問題剛好戳中我卡最久的一段，值得展開講。 ...

之前分享過幫 AI 裝省錢儀表板，那時候主要在看「花了多少錢」。用到現在，我發現真正會痛的其實不是錢，是額度：Claude Code 的訂閱制有 5 小時和 7 天兩個滾動視窗，用滿就是停給你看。 這篇來分享我們為此做的開源小工具：claude-pacer（github.com/drpwchen/claude-pacer）。 為什麼會想做這個？ 起點是好幾次的半夜斷頭。 我很常睡前丟一個長任務給 Claude：批次整理講座逐字稿、跑論文雷達、掃描教科書轉筆記。想說睡醒收成果，結果凌晨兩點撞到 5 小時上限，任務被硬生生停掉，隔天起來看到的是做一半的殘局，還要幫它收拾。 AI 工作起來不知道累，但它完全沒有「額度快用完了，該先存檔」的概念。 另外還有幾個多工時的日常小困擾： 開了四五個視窗，忘記哪個在做什麼：每個終端長得一模一樣，切過去要先滾一下對話才想起來。 不知道還剩多少可以跑：現在派一批 agent 下去，會不會跑到一半全家斷頭？ 忘記模型切在哪一個：早上開 Opus 處理難題，下午拿它跑雜事，額度就這樣蒸發了。 市面上不是已經很多狀態列工具了嗎？ 對，而且都很好！ccusage、ccstatusline、CCometixLine 都是很成熟的作品，用它們完全沒問題。自動續跑的腳本也找得到，不過它們的做法是盯著畫面等「撞到上限」的訊息出現，再自動幫你按 continue：任務死在哪就斷在哪，檔案改到一半也照斷。 但我想要的多一點：狀態列是做給「人」看的，人半夜在睡覺；真正需要看到警戒的，是還在跑的那個 AI。撞牆之前它的行為就該先改變：85% 起不再開新的大工程，93% 把手上的步驟收乾淨再停，然後自己排好額度恢復後從同一個對話接續。所以 claude-pacer 是三層設計： 第一層：狀態列，給人看 一行看完所有狀態： 對話主題 │ 5h ▓▓▓┃░░ 42%·剩2h13m │ 7d ▓▓▓▓┃▓░ 71% │ Ctx ▓▓░░░░ 34% │ Fable 5·high 對話主題：用 Claude Code 自己生成的 session 標題，多開視窗每個都有名牌。 用量長條上疊一個時間記號 ┃：實心條超過記號，代表你燒得比時鐘快，該收手了；還沒到記號，就可以放心繼續派工。 Ctx：context window 滿度，快被 compact 之前先心裡有數。 模型＋推理強度掛在最右邊，忘記切回來之前就會先看到。 寬度是自適應的，終端變窄會自動換緊湊版，手機上看也不會爆版。 第二層：budget-guard，給 AI 看 這層是整個工具的起心動念 ...

為什麼「太多筆記」跟「沒有筆記」是同一件事 先講一個我很早就認定、到現在也沒改過的規矩：我的筆記庫裡，一個主題只能有一則筆記。 不是因為潔癖。是因為同一件事如果有五個地方在講，我查東西的時候就得開五個檔案，還要自己判斷哪一版才算數。那個整理的工作沒有消失，只是原封不動地留給了未來的我。 而未來的我通常正在看診、正在趕投影片，沒空做這件事。資訊太多造成的混亂，跟資訊不足是同一種痛苦。 這條規矩在只有一個素材來源的時候很好守。難的是後來，來源越長越多，而且沒有一種會停下來等我： 教科書 → 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 的方式在本機執行。 ...