文章

門診遇到一個有意思的個案，想查一下教科書怎麼講、想跟 AI 對一對自己的鑑別診斷有沒有漏掉什麼。這件事我幾乎每週都在做。 但病歷不能就這樣貼上去。 這跟「我信不信任那家 AI 公司」是兩回事。資料一旦離開這台電腦，它去了哪裡、留多久、被誰看過，就不再是我能決定的事。所以我想要的不是一個更好的承諾，是一個機械上的動作：在資料離開之前，先把身分拿掉。 我把自己在用的那套整理乾淨、開源了，叫 chart-scrub。 程式碼：github.com/drpwchen/chart-scrub 線上試用：drpwchen.github.io/chart-scrub（整頁在你的瀏覽器裡跑，什麼都不會上傳） 它做什麼 一筆門診紀錄丟進去： 病歷號碼：1234567 姓名：王大明 出生：1971/03/05 主訴：右肩痛三個月，夜間痛醒。王大明表示上個月在李阿嬤介紹的推拿館推過。 電話 0912-345-678，住新北市板橋區文化路一段100號5樓。 出來變成： [代號 PT-0001，55歲] 病歷號碼：PT-0001 姓名：PT-0001 出生：[55歲] 主訴：右肩痛三個月，夜間痛醒。PT-0001表示上個月在[稱謂]介紹的推拿館推過。 電話 [電話]，住[地址]。 臨床內容一個字沒動，身分不見了。 為什麼不是直接遮成「[姓名]」就好 這是整件事我最先想通的地方。 如果只是把名字換成 [姓名]，那同一個病人下次回診、下下次回診，三筆紀錄之間就沒有任何東西把他們串起來了。可是「這個人三個月前打過針、當時有效、這次又痛回來」，這種前後對照本來就是臨床判斷的一部分，弄丟了，剩下的資料就沒什麼討論價值。 所以第一層做的是定向抽換：這個人變成 PT-0001，下次回診他還是 PT-0001。代號對回真名的那張表，只存在我自己電腦上的一個 SQLite 檔，不進雲端、不進筆記庫、也不會給任何 AI 讀。 生日也一樣：直接刪掉可惜，換算成年齡剛好。臨床要的是「55 歲」，不是那個日期。 第二層：一張寧可多遮的網子 定向抽換只能處理「我知道他是誰」的那個人。紀錄裡還會有一堆我事先不知道的東西：電話、身分證、地址、順口提到的其他人。 第二層就是一組正規表示式規則，把這些東西通通遮掉。設計取向很單純：寧可多遮。偶爾誤遮一個醫學名詞，代價是我重看一次；漏掉一個名字，代價大得多。 有一個順序上的細節，是實作時才想清楚的：定向抽換一定要在通用規則之前跑。反過來的話，名字已經先被遮成 [姓名] 了，代號就再也接不上去，跨次就診的那條線也就斷了。 機器自己驗自己 寫完之後我最不放心的是：它到底有沒有真的遮乾淨？ 所以最後一步是殘留檢查：程式跑完，拿它自己知道的每一個真名、每一個病歷號，回頭搜自己剛產出的那份輸出。只要有一個活著，這筆就判定失敗、離開碼給 2，我不會拿去用。 另外還有兩個訊號是抓「漏網」的形狀：一個中文姓名黏在已經被遮掉的身分證旁邊、以及長得像身分證卻沒被遮的字串。這兩種都不是「我知道他叫什麼」，而是「這個位置本來就該有東西被處理掉」。 這件事的通則 自動化最怕的不是失敗，是安靜地成功。所以每一段自動化的最後，都值得補一個「回頭檢查自己」的動作，而且要讓它有辦法大聲喊失敗。 開源的過程中，抓到自己三個 bug 這部分我覺得比工具本身有意思。為了公開，我補了測試、逐條檢查，結果揪出三個原本在用的版本就有的問題，而且三個都是那種不會報錯的失敗。 第一個：我習慣的手寫格式是「身分證號＋姓名」擠在同一行。但實際的紀錄常常長這樣： 陪同者 A123456789 李小華 程式抓到的姓名是 「陪同者」，不是李小華。因為規則寫成「身分證號旁邊的 2 到 4 個中文字」，而「陪同者」剛好也是三個中文字，還排在前面。結果就是：一個角色詞被登記成病人，真正的名字反而漏掉。修法是要求姓名的第一個字必須是常見姓氏。 第二個：醫院系統匯出的文字檔編碼很雜，UTF-8、UTF-16、Big5 都遇過，所以程式會一個一個試。問題是一個 Big5 檔用 UTF-16 去解，不會出錯，會解出一堆亂碼。而亂碼不會命中任何一條規則，所以程式一路跑到底、印出「全數通過」，實際上它什麼都沒遮到。修法是：只有在檔案真的帶著 UTF-16 的標記時才用 UTF-16 去解。 ...

前幾天一個剛開始用 AI 寫程式的學妹問我一個很好的問題：她讓 AI 直接開她的瀏覽器做事，可是密碼都存在瀏覽器裡，這樣到底安不安全？ 我覺得這個問題值得拆成兩層來看，因為大家常常把它們混在一起擔心。認真查完之後，我把答案做成了一個開源工具，文末會介紹。 第一層：密碼存在哪裡 這層其實好解決。不管你是用 Apple 鑰匙圈還是 Bitwarden，只要是專門的密碼管理器，加上重要帳號都開了兩階段驗證（2FA），密碼本身就是安全的。別把密碼記在記事本、別用同一組打天下，這層就過關了。 順帶一提，如果你是把密碼存在 Chrome、靠 Google 帳號同步，要小心：只要有人能登入你的電腦帳號，就能把你存的密碼全部看光，這其實滿危險的。學妹用的是鑰匙圈，這層沒問題。 第二層才是重點：你讓 AI「控制」了你的瀏覽器 這代表它是用你已經登入的身分在操作。你的網銀、你的信箱、你的券商，對它來說都是開著的門。 我用的那套是 Kimi WebBridge。工具本身通常是乾淨的，我實際查過它的控制端：daemon 只綁在本機 127.0.0.1，區網或外網的其他機器連不到；沒有任何對外連線，不會把資料往外送；帶惡意來源的網頁想從瀏覽器裡偷呼叫它，會被擋掉。這部分可以放心。 真正的風險是另一件事，叫 prompt injection：AI 拿著你的登入身分，萬一去讀到一個藏了壞指令的網頁，有可能被牽著鼻子走。它不是被駭，它是太聽話。而它手上握著你所有登入中的網站。 平心而論，這類 AI（像 Claude）本身對 prompt injection 是相當警覺的，最近甚至容易反過來疑神疑鬼、動不動覺得自己被下指令了。但與其把要害帳號的安全全押在它每次都判斷正確，不如多加一道機械上的鎖：把最要命的幾個網站（網銀、券商、Gmail）直接擋在 AI 碰不到的地方，讓它就算被騙也走不進去，其他日常網站照常幫我做事。 直覺的做法沒有用：網站存取權白名單 瀏覽器的擴充套件設定裡有一個「網站存取權」，可以把擴充限制成「只能在特定網站」運作。直覺上把它設好就安全了。 實測結果：攔不住。設好白名單之後，叫 AI 開一個清單外的網站，它照樣進得去、讀得到內容、跑得了 JavaScript。 原因在技術層：這類 AI 瀏覽器控制工具走的是瀏覽器的偵錯介面（chrome.debugger API）在驅動頁面，而「網站存取權」那層設定只管一般的內容注入，管不到偵錯介面。所以那個設定頁面會讓你以為有圍籬，實際上這類工具根本不從那道門走。 順帶說明一下，不是每套工具都這樣：像 Claude in Chrome 是逐個網站問你同意的設計。但只要擴充的權限清單裡有 debugger（WebBridge 這類全站授權的工具就是），逐站白名單就是裝飾品。 真正有效的那道鎖：瀏覽器政策層 往下挖一層，答案在企業環境常用的瀏覽器政策（policy）：ExtensionSettings 裡的 runtime_blocked_hosts，可以對指定的擴充封鎖指定的網站。 這道是真的擋得住的。我把自己的網銀、券商、Gmail 一共 13 個登入網址設進去實測：AI 一碰被封的網站就直接吃到 Cannot attach to this target，連頁面都讀不到；沒被封的網站則完全不受影響，日常那些自動化照常跑。兩個方向都要測，這道鎖才算數。 兩個實作上的細節： 只封精確的網址，不用 *.整個網域 這種萬用字元。 封 *.esunbank.com.tw 會連信用卡活動頁一起封掉，而信用卡活動頁、線上表單這類，往往正是你想留給 AI 幫忙的地方。要封的是「登入後能動錢的那個網址」，不是整家銀行。 macOS 有一個陷阱：defaults write 寫進去的政策沒有用，而且是無聲失敗。 實測它在 chrome://policy 會顯示「有效」，但等級只是「建議採用」，AI 照樣進得去；政策要放在 /Library/Managed Preferences 底下、等級顯示「強制」，才真的擋得住。驗證標準要看等級，不是看政策有沒有出現。 做成開源工具：kimi-webbridge-lockdown 這個設定要手動改登錄檔（Windows）或系統政策檔（macOS），有點門檻。所以我把它做成了一鍵設定的工具，開源出來： ...

前一篇信貸投資的模擬放出來之後，最常被問到的不是模型，而是這句：「那我剛出來工作，是不是也該借一筆？」 這題其實我七年前就寫過一半。2019 年剛開始自行理財的時候，我寫了六篇投資理財筆記，講資產配置、保險、薪水怎麼分。那六篇裡沒有一個字提到槓桿，不是因為那時候沒想過——PGY 的時候我就在 Excel 上算過這題了——而是因為順序不對。 所以這篇是把兩件事接起來：剛出社會那幾年真正該做的事，以及做完哪些之後，才輪得到借錢投資這個選項。 七年前那六篇，結論其實只有一句 先快速把舊系列的骨架擺出來，因為後面每一道門檻都從這裡長出來： 第一篇：出社會開始自行理財的起點 第二篇：唯一目標是避開風險——單一公司會倒，所以買整個國家；單一國家會衰弱，所以買全球；只有股票會蕭條，所以搭配債券 第三篇：ETF 省掉基金管理人的風險，保險「保大不保小」 第四篇：領到薪水後把錢分進七個虛擬帳戶 第五篇、第六篇：通膨、低保費高保障，以及該保哪些險 六篇拉到最後，其實就是一句話：把每一筆錢，放到符合它「什麼時候要用」的位置上。 這句話同時也是槓桿這題的全部答案。 剛起步的時候，複利不在市場上 第四篇裡我寫過一段，現在回頭看還是同一個判斷： 撇開父母很有錢的人後，剛出社會的我們無法用資產配置來達到所謂財富自由，可是我們能透過投資自己把本金不斷拉升。 這不是勵志話，是算術。年報酬率和本金是相乘的關係，剛出社會的時候本金那一項小到什麼程度呢？假設存了 30 萬，一年多賺 5% 是一萬五；同一年去上一門幾萬塊的課、考一張證照、換到一個薪水高兩成的位置，那個增幅是本金的好幾倍。 但醫師這行不太一樣 這裡要誠實講一個限制：醫師在前期，其實很難靠「投資自己」讓收入立刻跳上去。 實習、PGY、住院醫師這幾年，薪水是照制度走的，你多讀一本書、多學一項技術，當年的薪水不會因此變多。 不過換個角度看，這件事反而是這一行最大的財務優勢：收入曲線是可預期的。 只要照著走完訓練，薪水會在幾個固定的節點往上跳，而且幅度不小、時間點也大致算得出來。 這正是財務理論上「適合開槓桿」的條件。穩定而且可預期的薪水，在人力資本（human capital）的框架裡等同於你持有一張巨大的、與股市低相關的「債券」——年輕的時候，你的總財富幾乎全部是這張債券，金融資產那一小塊反而可以、甚至應該更積極。Ayres 與 Nalebuff 在《Lifecycle Investing》裡講的「跨時間分散」就是這個意思：與其把市場曝險全部集中在資產最多的晚年，不如年輕時適度借一點，把一生的曝險攤平。 他們給的建議上限是 2:1，不過這個數字要看清楚它在防什麼：2:1 是為了「會被追繳的融資工具」設的。券商融資在帳面跌到一定程度時會強制平倉，所以帳面回撤本身就是一個獨立的風險來源，倍數必須壓在斷頭線之外。 信貸沒有這個機制。沒有人會因為你的部位跌了就叫你補錢或賣股，所以真正的限制不是倍數，是還款現金流——只要月付繳得出來，帳面跌多深都不會強迫你在谷底離場。這也是為什麼後面門檻三談的是繳款能力，不是比例。 所以對醫師來說，起步那幾年的本金成長主要來自兩件事：時間，以及一條可預期的薪水階梯。槓桿的正當性也是從這裡來的——不是因為勝率九成，是因為你對未來的還款能力有把握。 反過來說，如果你的收入型態不是這樣（接案、拆帳、創業、收入隨景氣波動），這一段就不適用於你，那些勝率數字建立在「每個月都繳得出來」上面。 回到順序。剛出社會那幾年的優先級，跟七年前寫的一樣： 日常生活的錢先拿出來，這個月就只花這些 投資自己——課程、年會、證照，這是未來薪水成長的關鍵 緊急預備金、長期支出、資產配置三個帳戶 請客捐獻 玩樂休閒至少留 5～10%，不然全部存起來會感受不到自己真的在賺錢 槓桿在這張清單上的位置，是第 3 項的內部細節，不是新的第 6 項。它不會讓你跳過前面任何一項。 四道門檻：這才是「能不能借」的真正判準 模擬跑出來的勝率是 89.6%，但那個數字有一組很硬的前提：十年不中斷、不賣出、每個月都繳得出來。真實世界的失敗，幾乎都不是市場造成的，是這三個假設被打破。 所以順序長這樣——下面四關全過，才輪到看利率和勝率。 門檻一：緊急預備金存滿，而且不能來自投資部位 四關裡面，這一關是最重要的。 抓 3～6 個月的生活費，這筆錢的用途不是投資，是讓你在失業、生病、家裡出事的時候，不必在最糟的時點把部位賣掉。（第四篇當年寫的是 6～12 個月，那是更保守的版本；收入越不穩定就越要往上加。） 信貸投資會讓它的重要性再放大一個層級：你多了一筆每個月固定要繳的月付，卻少了一份「大不了先不投了」的彈性。定期定額可以暫停，貸款不行。所以帶著槓桿的人，緊急預備金不是「有存一點」就好，而是要能明確講出它能撐幾個月的月付加生活費——講不出這個數字，就還沒過這一關。 門檻二：十年內要用的錢，不進市場 這是舊系列的老規矩：1～10 年內要用的錢（買車、旅遊、頭期款、結婚），放定存或其他能抗通膨的低風險項目；10 年以後才要用的錢，才進全球股債。 ...

先說結論 我們自己的做法是：月薪 5 萬的人，借 100 萬、10 年期、利率 2.5%，一次全部投入，配置抓 80:20 股債比，其中 0050 佔總資產一成，其餘是全球股債 ETF。假設是這樣抓的：這個配置的歷史序列（1997 年起、含亞洲金融風暴與網路泡沫，後面方法段會講）實質年化報酬是 5.72%，我們抓 6%，比歷史略高一點；通膨歷史平均 1.4%，我們抓 3%。這兩個假設各自把勝率往哪邊推，文章後面會誠實拆開來給你看。評估年限跟貸款年限一樣，10 年。 用真實市場資料模擬兩萬條路徑，結果是： 89.6% 的路徑，最後贏過「不借錢、把同樣月付金拿去定期定額」 中位數淨賺 83 萬，最好的 5% 淨賺 241 萬，最差的 5% 是倒賠 7 萬 而最值得看的是這個：就算落到最差的 5%，也只比定期定額少 10 萬；而最好的 5% 是多 145 萬 下檔輸的幅度很小，上檔贏的幅度很大——這才是這件事真正的樣子，不是「勝率九成」四個字。 先講清楚這個 89.6% 該怎麼讀 它是兩萬條隨機路徑跑出來的估計值，本身帶有抽樣誤差：二項標準誤約 ±0.2 個百分點，95% 區間大約是 89.2% 到 90.0%。換一組亂數種子，小數點後那一位就會跳動。所以請把它讀成「約九成」，不要讀成精確到 0.1%。這篇文章後面所有的數字都適用同一句話。 以下先把完整的報告講完（我們的條件、結果全貌、方法與前提、誰不該做），最後再講這題我是怎麼用 AI 算了三遍、又怎麼發現 AI 算錯的。 完整報告 結果全貌：從最好到最差，一次攤開 先看這筆交易到底賺不賺。下圖的淨損益 ＝ 期末實質資產 − 你為貸款付出的實質成本，從最差的 5% 到最好的 5% 整個範圍攤開（都是換算成今天購買力的實質金額）： ...

在花東跨院支援門診，最花心神的其實不是看診，是回程的火車票。下診時間不固定，玉里、關山、臺東各有各的班次窗口，加上夏天傍晚的花東線，坐錯邊就是整路被太陽曬🥵 這種事就該交給 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 方式彙整進入資料庫嗎？」這個問題剛好戳中我卡最久的一段，值得展開講。 ...

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 多則，現在多出來的是這三年新長的：復健科的疾病筆記、論文整理、演講轉成的筆記、專案紀錄。 ...

用 AI 工作一陣子的人，大概都遇過這件事：同一個錯，你講過了，規則也請它記下來了，過幾天它又犯一次。 而且我不是沒有防：規則寫進了它的記憶檔、違規有計數器、還有每月的定期檢視，該有的機制都在。但七月底，我看著我的 AI 助理第三次犯下同一個錯（最後兩次只隔一天），才認真面對一個事實：「記得」跟「會做」是兩回事。而更意外的是，後來的調查發現，問題甚至不在它不記得，是我們整套「記錯誤」的系統，量尺本身壞掉了。 這篇想分享的，就是我們最後長出來的一套「AI 自我糾錯系統」的設計，以及中間最有趣的一段：我讓 AI 自己調查自己，還特別交代它「不要相信寫交班單的那個 AI」。 事情是怎麼爆開的 這陣子我陸續把一些自己做的工具開源（工具箱總整理裡的那些）。發布開源軟體有一套禮儀：改了什麼要寫進更新紀錄（CHANGELOG）、打版本標籤（tag）、在 GitHub 上建立正式的發布頁（release）。這些規則早就寫在 Claude 的記憶檔裡。 七月底某天，我點開一個剛發布新版的 repo，首頁看起來什麼都沒有。我第一反應是「你沒寫 CHANGELOG」。它查了之後回報：CHANGELOG 其實寫了，tag 也打了，漏的是最後一步「建立 release」，而那恰好是訪客唯一看得到的一步。回頭一查，前兩個版本也都一樣。 隔天我請它把我全部十三個公開 repo 掃一遍，結果挖出十五個同樣的缺口。更妙的是，就在稽核到一半的時候，它又犯了第三次同型的錯。規則就寫在它的記憶裡，它也讀得到，然後照樣犯。 關鍵的一問:「你以後真的會用嗎？」 它的第一個提案很自然：寫一支腳本，把正確的發版流程整個包起來。 我問了一句：「你以後會固定呼叫這支腳本嗎？」 它想了一下，誠實地說：不會。腳本跟記憶檔的失效模式一模一樣，都要它先「想起來」才有用。這個答案讓我們改變了做法：與其多一個要記得的東西，不如加一道攔截（hook，上手系列第二篇講過的關卡概念）：只要它想手動跑發版指令，動作會在當下直接被擋下來，只剩包好的正確流程能走。從「請你記得」變成「你想錯也錯不了」。 讓它調查自己，但不准相信自己 前面說過，揪錯的零件一直都在。所以問題比「沒有機制」更刁鑽：零件都在，錯還是溜過去了，到底卡在哪？ 這裡我們用了一個我很喜歡的設計。當天犯錯的那個 AI session 把來龍去脈寫成一份調查交班單，但裡面明白寫著一條： 交班單裡的自我迴避條款 「不要把我的假設當成計畫——這份文件是犯錯者本人寫的，幾乎必然被它的立場影響。請先獨立驗證診斷，再決定要不要建任何東西。」 接著換一個全新的 session 接手調查，手上只有可以重跑的驗證指令，沒有前一位的結論。 做過品質改善的人應該覺得眼熟：根本原因分析（root cause analysis）的調查，本來就不該由事件當事人自己主導。當局者迷這件事，對 AI 一樣成立。 調查結果：推翻了兩個前提 獨立調查翻出來的東西，跟交班單猜的不一樣。 第一，AI 並沒有隱瞞錯誤。我原本合理懷疑：違規次數是它自己記的，它會不會少記？結果翻遍紀錄，低報只有零星幾筆，而且是「自首了但記錯地方」。其中一個規則檔裡，它老老實實記了十二次違規，好幾次我根本沒發現。誠實度不是問題。 第二，問題出在量測層。幾個具體的發現： 計數無法歸屬：違規次數記在「檔案」上，但一個檔案裡合併了十幾條規則。帳面上的「違規 4 次」，追不回是哪一條規則的 4 次，這個數字沒有行動意義。 偵測器本身有 bug：負責從歷史對話裡撈「使用者糾正過什麼」的程式，寫死了只看最近二十筆，而且漏看一整類訊息格式。回頭驗證時發現，最關鍵的那筆證據，它從結構上就不可能抓到。 記錯帳本：有三筆真正的違規，被寫進了另一本記「工具摩擦」的帳，正好躲過所有檢查。 還有一個反轉：交班單斷言「這些計數完全沒有版本紀錄，無從稽核」。錯了——記憶目錄其實一直有自己的 git 版本庫，一千多筆自動存檔，稽核軌跡從頭到尾都在，只是被上層設定蓋住，連 AI 自己都不知道。 換句話說：這個系統不缺零件，缺的是接線。計數器沒有人讀、偵測器壞著、帳本記錯棚。在量尺壞掉的情況下加更多自動化，只是把錯的數字算得更快而已。所以後面的修法幾乎沒有新建什麼大東西，都是把既有的零件接起來。 最後的設計：四條原則 修完之後，整套系統收斂成四條原則。它們不是 AI 專用的，你會發現每一條在醫院的品質管理裡都有對應物。 一、錯誤要記成「可歸屬的事件」，不是一個數字。每次違規記一行：日期＋哪一條規則＋一句事實。計數是用數的，不是用手改的。（對應：異常事件通報寫事件經過，不是只在統計表上加一。） ...

這是 AI 上手系列的第三篇。第一篇講怎麼裝起來，第二篇講怎麼跟它講話、怎麼設關卡。 第二篇的結尾我說：難的從來不是「怎麼問」，是「怎麼設計流程」。 這篇要把那句話收掉。答案可能跟你想的相反：流程不是設計出來的，是長出來的。 最常見的卡點：「我不知道要怎麼開始規劃」 我被問過很多次類似的問題：「你那套自動化好厲害，我要怎麼規劃我自己的？」 老實說，我從來沒有規劃過。我三月的時候只做了一件事：挑了一件每週都在重複的小事，叫它做一次。 今天回頭看，我的規則檔、十幾個 skill、一堆自動排程，沒有一個是事先設計的。每一個都是同一件事重複了幾次之後，才「升級」成現在的樣子。 所以如果你卡在「不知道怎麼開始」，好消息是：你不需要想清楚才開始，你只需要開始得夠小。 起手式：五件事講清楚，其他都不用 挑好那件小事之後，交代它的時候把這五件事講清楚。這不是我發明的，是把官方 best practices 濃縮成非工程師版本： ① 目標講清楚：你要什麼、給誰用、拿去做什麼。「幫我整理逐字稿」不如「整理成 SOAP 格式，這是要放進病歷系統的」。 ② 只補它不知道的：你們科的慣例、單位的格式、只有你知道的眉角。模型已經會的不用教：SOAP 是什麼不用解釋，你們科的 SOAP 長什麼樣才要講。每一句廢話都在稀釋它的注意力（原因寫在第二篇「為什麼它會越聊越笨」那節）。 ③ 界線先講：哪些檔案不准動、哪些事要先問過你。而且真正的紅線不要只用嘴巴講，第二篇的三層機制（hooks / permissions / CLAUDE.md）就是拿來放這個的。 ④ 訂「怎樣算做完」：這條是官方排第一優先的建議，也是我覺得投資報酬率最高的一條。給它一個它能自己跑的檢查： ❌「幫我整理這些逐字稿」 ✅「整理完自己檢查一遍：每一份都要有四段、每段都要有內容，缺的標出來給我」 ⑤ 先跑一個爛版本：不滿意再一句話改。迭代永遠比一次寫滿快。 就這樣。不用畫流程圖、不用寫規格書。 流程怎麼長大：重複第三次，就升一級 真正的重點來了。你的「流程」不是某天坐下來設計的，它是照一個很簡單的規則長出來的： 同一件事重複到第三次，就往上升一級。 你發現自己在… 升級動作 成本 同一句話講第三次（「回我繁體中文」） 寫進 CLAUDE.md 一行字 同一套多步驟流程做第三次（先轉檔、再整理、再歸檔） 包成 skill：跟它說「把剛剛這整套存成一個 skill」 一句話 發現某件事絕對不能出錯（改到原始檔、送出病人資料） 交給程式關卡（hook / permissions） 要動手設定，但一勞永逸 三層的差別在第二篇講過了，這裡只補一句：寫在規則裡是建議，做成機制才是保證。 界線越重要，就該住在越下面那層。 這個階梯還有一個隱藏的好處：每一級都是你已經驗證過的東西。你不是在憑空設計一個 skill，你是把一套「已經手動跑成功三次」的流程存起來而已。設計可能會錯，重複不會。 驗收的習慣：這篇最重要的一節 起手式的第④點（訂「怎樣算做完」）值得單獨拉出來講，因為它不是五件事之一而已。它是整套方法裡唯一「做與不做會決定你能走多遠」的習慣。 驗收有三個層次，照順序養成： 層次一：單次驗收。 每個任務交代時就附上檢查方法，讓它做完自己查（「每一份都要有四段、缺的標出來給我」）。這是起手式教的。 層次二：可重跑的驗收。 把檢查存下來，變成隨時可以再按一次的按鈕。差別很大：單次驗收保證「這次做對了」，可重跑的驗收保證「以後改東西也不會弄壞它」。工程師管這個叫回歸測試（regression test），但概念本身跟程式無關：哪怕你的檢查只是「數一數每份紀錄都有四段」，能重跑，就有資格叫驗收。 層次三：驗收先行。 這是官方 best practices 裡明講的工作流：先寫檢查、確認它現在會失敗，再叫 AI 做到通過。聽起來像工程師的儀式，翻成白話就是：開工前先給它看一個「做對了長這樣」的具體例子。它有目標可以自己迭代，你也不會做完才發現彼此想的不一樣。 ...

之前分享過幫 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 看 這層是整個工具的起心動念 ...