自動化

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

用 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 看 這層是整個工具的起心動念 ...

颱風要來了，家裡的不斷電系統（UPS）剛好也在最近換了電池，順手把整套關機、開機的流程重新測了一遍，發現了一個藏很久的坑，就來記錄一下這個過程。 起點：一顆不會講話的 UPS 家裡的 NAS、跑虛擬機的 Proxmox 迷你主機（負責家裡路由器）、還有 Home Assistant，這些設備 2023 年底就接在一顆 APC BV1000-TW 上面了。它撐停電是沒問題的，但它是一顆「啞巴」UPS，沒有 USB，也沒有 SNMP（簡單講就是網路可以查詢的狀態訊號），沒辦法跟家裡任何系統說「我快沒電了，準備關機」。 結果就是，每次真的停電，這些設備只能等電池耗盡被硬生生斷電。NAS 這種有檔案系統的機器最怕這種粗暴關機，容易半夜出包。 買第二顆，不是為了多一份保護，是為了多一張嘴 2026 年 4 月又買了一顆 CyberPower CP1500PFCLCDa，接的是放在另一個房間的電腦。電腦本來就跟 NAS/PVE/HA 不同房間，本來就需要一顆自己的 UPS，這顆的存在本身不算意外開銷。但真正讓這篇文章成立的重點，是它剛好有 USB，電腦上可以跑它的管理軟體 PowerPanel Business Local，把 UPS 的狀態翻譯成區網看得到的 SNMP 訊號。這樣一來，Home Assistant 就可以直接去讀這個訊號，知道現在是不是在吃電池。 巧妙（也有點取巧）的地方：借別人的嘴講自己的事 家裡這兩顆 UPS 插在同一個電源迴路上，真的跳電的時候會同時斷電。我們沒有特地幫 NAS/PVE/HA 那顆啞巴 UPS 加訊號模組，而是讓 Home Assistant 去監控 CyberPower 那顆的 SNMP 狀態，當成整屋停電的「代理警報」。一偵測到它進入電池供電，就觸發自動化：兩分鐘後依序關閉 NAS → PVE，Home Assistant 自己則靠 APC 那顆的電池撐著繼續跑，電腦另外由 PowerPanel 在停電五分鐘後自己關機。等電力恢復，Home Assistant 再送 Wake-on-LAN（喚醒封包）把 NAS 跟 PVE 都叫醒。 這次真正的意外測試：換電池 這次不是真的停電，是計畫性地把第一顆 UPS（NAS/HA/PVE 那顆）整顆拔掉換電池。差別在於，平常真的停電時，Home Assistant 是靠 APC 那顆的電池撐著活下來的，這次是直接切斷電源，連 Home Assistant 自己都跟著斷電。 ...

前面分享的論文工具 paper-review-and-digest，開源上線沒幾天，就收到了第一個 GitHub issue！第一次收到 issue 其實蠻開心的，點開一看更驚訝：對方不只讀了我的 code，還精準講出設計裡我最得意的部分。 他說他欣賞「模型與確定性檢查的硬切分」：grade_judge.py 不信任模型自己回報的證據等級，而是從降級項重新計算；argdown_lint.py 會抓出「替代指標跳到硬終點」這類論證跳躍。然後說他幫我做了一個線上入口，訪客不用安裝 Claude Code，上傳 PDF 就能跑評讀流程，連宣傳圖都做好了： 哇，有人這麼認真讀我的專案，還幫我做了網頁版和這麼漂亮的圖？ 等等，這是真人嗎？ 開心之餘總覺得哪裡怪怪的。這網站有免費額度、有點數收費系統，商業模式完整得不像順手之作。想說反正有 Claude，就請他去查查這位熱心網友的底細。 結果一查，反轉來得比想像中快🤣。Claude 列出的證據： 兩分鐘內，這個帳號對 26 個 repo 發了 issue。全部都是論文閱讀工具：arxiv-summarizer、paper_agent、PaperAgent⋯⋯我的排第 13 個。前一天還有另一波，打的是 Claude Skills 類的 repo。 連結裡的追蹤參數直接寫著 campaign 名稱：20260708-paper-reading-comprehension-assistants。這是排程好的行銷批次，不是有感而發。 帳號今年三月才建立，0 followers，卻有 140 個 repo。 GitHub 的搜尋 API 拒絕搜尋這個帳號（user cannot be searched），這通常代表帳號已經被平台標記為 spam。 那段讓我心花怒放的技術讚美，是 LLM 逐一讀每個 repo 自動生成的。爬 repo 餵給模型很便宜，這正是它讀起來「像真人」的原因。 最後一句「Feel free to close this if it isn’t relevant」，是 spam 帳號降低被檢舉率的標準話術。 宣傳圖角落有小字標我的 repo，連 star 數都即時抓，做得很精緻；但點進他網站的頁面，作者欄掛的是他自己的名字。MIT 授權確實允許商用，不過這個掛名方式就有點微妙了。 認真想了一下，這個生意其實跑得起來 罵完之後認真想，這個模式其實蠻厲害的。我實際註冊進去看了帳務頁，整個商業模式就攤在眼前：註冊送 500 點，跑一次論文分析扣 38 點左右，換算大概不到台幣 2 塊。免費額度夠你跑十幾次，嘗到甜頭之後，Stripe、PayPal、微信、支付寶四種儲值管道排排站等你。 ...

前陣子分享了我自己做的論文讀書小站，收到不少訊息問「這個我也能用嗎？」、「到底怎麼運作的？」。這篇就好好把它講清楚，順便告訴你，我已經把它整理成開源版本放上 GitHub 了。 先講我想解決的問題。 身為復健科醫師，我想追的期刊有幾十本，還有幾位很想跟的作者、幾個一直在關注的主題。傳統做法是把一堆 RSS 訂閱倒進閱讀器或筆記軟體，結果每天累積上百篇，很快就變成一個「永遠讀不完、也不知道從哪讀起」的垃圾堆。最後不是焦慮，就是乾脆不看。 我要的不是「看更多」，而是一個會先幫我篩、幫我排序的雷達，讓我只把注意力放在真正該讀的那幾篇。於是有了這個小站，它大概分成這幾層在運作。 一、自動抓取：把幾十個來源收成一條河 每天清晨，主機會自動去抓幾十個來源：期刊的 RSS、還有用 PubMed 搜尋做的「作者追蹤」和「主題追蹤」。有些期刊的 RSS 很爛或根本擋機器人，我就改用 PubMed 的查詢繞過去，一樣抓得到，而且附帶 DOI 方便後面處理。全部抓回來後自動去重，變成一份乾淨的清單。 二、興趣評分，而且會越用越懂我 這是我最喜歡的一層。每一篇都會用一個「興趣模型」算分數，把我最可能有興趣的排到最上面，雜訊沉到下面。 更關鍵的是它會學。我在手機上滑的時候，看到喜歡的按個讚、沒興趣的略過，這些反應會回頭微調模型的權重。用得越久，它越懂我的口味，排序就越準。這種「你教它、它回饋你」的迴圈，是我覺得比單純 RSS 高明的地方。 三、全文三層：先幫我確認「拿不拿得到」 看到想讀的，最煩的往往是「找得到、但打不開全文」。所以每篇我都先自動幫它標好取得難度： 🟢 開放取用（Open Access）：直接幫我把 PDF 抓下來。 🏥 機構訂閱：自動去查我所屬圖書館有沒有訂閱這本期刊、這篇現在拿不拿得到。 📎 自己補：以上都沒有的，附上連結讓我自己抓，或直接把 PDF 丟上去。 這樣我在滑的當下就知道每篇「能不能讀」，不用一篇一篇點進去碰運氣。 四、一個只給自己看的私密小站 重點 整個站是鎖起來的，只有我進得去，沒有對外公開、也沒有署名。它是我一個人的閱讀桌，手機、電腦打開都是同一份狀態，昨天在捷運上勾過的、今天在醫院打開一樣看得到。介面就是一張張論文卡片，帶著上面說的徽章，還有幾顆動作鈕。 五、勾一勾，剩下的它包了 這是把前面所有東西串起來的閉環。看到喜歡的，我就勾「想整理內容」或「想評讀品質」，跟它說一聲，它就自動：幫我抓全文、把重點整理成筆記、做評讀，最後收進我自己的筆記系統裡。人在外面看到別人分享的好文章，也能直接丟進這個網頁，一樣幫我處理好。 於是我的閱讀從「被上百篇淹沒」，變成「每天滑一滑、勾幾篇、讀它整理好的重點」。省下來的時間跟力氣，比我想像的多很多。 開源出去，也歡迎你打造自己的雷達 我把自己的東西整理乾淨，放上 GitHub 了，附了中英文說明： 👉 https://github.com/drpwchen/paper-radar 它不只能用在醫學。任何有 RSS 的來源，論文、新聞、部落格，都能 fork 去改成自己領域的雷達。想自己架一個的人，可以照著說明走。 補充一下：雷達幫我挑出來的論文，下游是交給另外兩個負責「評讀」跟「整理」的工具去讀的，那部分我後來也整理開源了，寫在這篇。雷達管挑、skill 管讀，兩端接起來才是完整的讀論文流程。 最後講點私心。這個念頭其實在心裡很久了。還沒踏進 vibe coding 之前，我看到吳易澄醫師（運動醫學、復健醫學）做了一個類似的平台，那時候又羨慕又好奇，心想「要是我也有一個就好了」。沒想到現在真的能親手把它做出來，還能整理乾淨分享給大家。 從一個羨慕別人的念頭，到自己動手實現，再到開源分享出去，這種感覺真的很奇妙，也很開心 😊 如果你也常常被讀不完的資訊淹沒，歡迎來看看，也歡迎順手給顆星 ⭐，這對我會是很大的鼓勵。 如果這個工具有幫你省下時間，也歡迎請我喝杯珍奶，讓伺服器繼續轉下去 🧡 🧋請我喝飲料 — ...

📖 省 Token 系列（共四篇）：第一篇 為什麼你的 AI 越聊越笨 · 第二篇 能用算盤就別開超級電腦 · 第三篇 幫 AI 整理一張乾淨的工作桌 · 第四篇（本篇，完結） 來到系列最後一篇。前三篇我們從「為什麼 AI 越聊越笨」，一路講到「什麼時候別用 AI」「怎麼幫它整理桌面」。這一篇談的是錢真正花下去的那一刻：怎麼把每一塊錢花在刀口上。 第一件事：不是每件事都需要最聰明的腦袋（但省下來，就是為了負擔得起好的） AI 模型有分等級。以 Claude 為例，由便宜到貴大致是 Haiku、Sonnet、Opus 三級，價差很大。 如果你是按使用量付費的人，最直接的省法就是「派對的等級做對的事」：改格式、重新命名、簡單分類這種雜事，交給最便宜的 Haiku 就好；日常的寫作、查資料用中間的 Sonnet；只有真正需要深度推理的硬任務，才動用最強的 Opus。 這裡還有一個很多人都搞錯的觀念，特別講一下：「要看圖」不等於「要用最貴的模型」。 當你只是要 AI「看一張圖、認出裡面有什麼、把上面的字讀出來」這種辨識任務，最便宜的 Haiku 通常就完全夠用，便宜到一個誇張。只有要它「看懂一張複雜的醫學示意圖、解讀圖表背後的邏輯」這種需要推理的視覺任務，才值得升級。選模型的真正標準，是「這個任務需要多少思考」，不是「要不要看圖」。 不過老實說，我自己現在反而大多直接用最強的 Opus，XD。 為什麼？因為我發現，在目前的訂閱方案下，把前面三篇那些省 token 的功夫都做好之後，我的額度其實用不太完，而最強的模型品質又明顯比較好。所以對我來說，與其斤斤計較每件事該用哪一級，不如把省下來的額度，拿去讓最好的模型做每一件事。 我覺得這反而是整個系列最想講的一件事：省 token 從來不是為了小氣。 我把浪費擋掉、把該交給程式的交給程式、把桌面整理乾淨，省下來的這些，剛好讓我負擔得起「把最好的腦袋，用在每一個我在乎的問題上」。省，是為了能大方地花在刀口上。 最後補兩個進階的小心法： 讓 AI 少廢話，可以一勞永逸。 AI 的「輸出」比「輸入」貴上好幾倍（以 Opus 為例差到五倍），所以請它回答精簡就是直接省錢。而且這件事你不用每次重講，直接寫進給它的長期指令裡（就是第三篇那份常駐設定檔，或聊天版的「自訂指令」），叫它預設就講重點、不要長篇大論。一次設定，之後每次都省。 思考深度也能調。 同一個模型可以設定它「想多深」，簡單的事用淺一點、難的事才開深度思考。重點永遠是：把力氣花在真正難的地方。 第二件事：把吵鬧的雜事，丟到隔壁房間做 有些工作會吐出一大堆過程訊息：跑一輪測試、抓一份長文件、處理一堆紀錄。如果讓這些雜訊全部堆在主對話裡，桌面馬上被淹沒（回到第三篇，桌面一髒就又貴又笨）。 我的做法是派一個「分身」去隔壁房間做這件事。分身有自己獨立的工作空間，它的所有過程、雜訊、草稿都留在那個房間裡，只有最後的結論回到我的主對話。 這就像你請助理去查一整天資料，你不需要看他翻過的每一頁，只要他最後給你一頁重點。 注意 但這招有取捨，我必須老實說：派分身本身也要花錢，而且分身會自己燒一輪 token。官方就提醒過，大量用分身的工作流，總花費可能是單打獨鬥的好幾倍。所以原則是：當「保持主桌面乾淨」的價值，大於「多請一個分身」的成本時，才派。 不是什麼都丟分身。 （這篇從頭到尾，你會發現省 token 沒有一招是無腦的，每一招都在權衡。這正是它好玩的地方。） 第三件事：裝一個會對我跳表的儀表板 講了這麼多省法，最後一塊拼圖是：你得看得見自己花了多少。 看不見的支出最危險。所以我裝了一個開源小工具，叫 cc-budget（由 boyand 開發，在 GitHub 上找得到）。 ...

📖 省 Token 系列（共四篇）：第一篇 為什麼你的 AI 越聊越笨 · 第二篇（本篇）· 第三篇 幫 AI 整理一張乾淨的工作桌 · 第四篇 我幫 AI 裝了一個省錢儀表板 上一篇我們講到，跟 AI 對話越長越貴越笨，以及三個立刻能用的省法。這一篇要往前再走一步，談一個更根本的分水嶺： 有些工作，根本不該叫 AI 來做。 聽起來很反骨，但這正是我把 AI 用得省又準的關鍵心法。 兩種工具：算盤與超級電腦 把事情交給電腦處理，其實有兩條完全不同的路。 一條是寫死的程式（script）。你事先把規則想清楚、寫成步驟，之後它就照著跑。像一台算盤，撥珠的規則固定，算十次一百次答案都一樣。 另一條是叫 AI 動腦（LLM）。你描述需求，它「理解」之後生出答案。像一台超級電腦，什麼模糊的、需要判斷的都能接，但每開機一次就燒一次電。 很多人的直覺是：現在 AI 這麼強，什麼都丟給 AI 就好。 這恰恰是燒錢又燒時間的根源。 一張表，看懂兩者的取捨 面向 寫死的程式（算盤） 叫 AI 動腦（超級電腦） 精準度 100% 確定，同樣輸入永遠同樣結果 會漂移，同一個問題問兩次可能答案不同，還可能一本正經地胡說 模糊處理 只能做規則講得清楚的事 能處理語意、判斷、例外、「你懂我意思」那種模糊地帶 花費 幾乎是零 每跑一次都付一次 token 的錢 速度 毫秒級，眨眼就好 秒級，而且對話越長越慢 前置工 要先把規則想對、寫對 開口就能用，零設定 看懂了嗎？兩者沒有誰比較好，只有誰適合這個任務。 規則明確、會重複很多次的事，交給算盤：又快又準又免費。 需要判斷、模糊、每次都不太一樣的事，才值得開動超級電腦。 一個真實的例子：我怎麼讀我的醫學課本 PDF 我有很多教科書的 PDF，常常需要從裡面撈內容。 如果我每一頁都直接丟給 AI 看，那是把超級電腦當印表機用：每一頁都付一次「看圖加讀字」的錢，貴得嚇人（後面那篇會講，直接丟 PDF 給 AI 看，每頁可能燒掉一兩千個 token）。 ...

📖 省 Token 系列（共四篇）：第一篇 為什麼你的 AI 越聊越笨 · 第二篇 能用算盤就別開超級電腦 · 第三篇（本篇）· 第四篇 我幫 AI 裝了一個省錢儀表板 前兩篇都還停在「人人可用」的層次。從這篇開始，我帶你看我電腦裡那套被我折騰到很細的設定。 先說背景。我除了在手機上用 AI 聊天，更常用的是一個叫 Claude Code 的工具：它跑在電腦的終端機裡，可以直接讀我的檔案、改我的筆記、幫我自動化一堆事。你可以把它想成「一個住在我電腦裡、能動手做事的 AI 助理」。 正因為它能做的事多、跑的次數多（一個任務動輒呼叫 AI 幾十上百次），省 token 在這裡的回報會被放大很多倍。而省 token 的第一原則，跟整理書桌一模一樣： 桌面上只放現在用得到的東西，其他都收進抽屜。 常駐稅：有一種成本，你每一句話都在付 我有一個檔案叫 CLAUDE.md，裡面寫著我給 AI 的長期規則：筆記要用什麼格式、哪些資料夾不要碰、我的偏好是什麼。 這個檔案有個特性：它在每次開工的最一開始就被載入，而且整段工作過程都常駐在 AI 眼前，不會被收走。 意思是，如果這個檔案有 5000 個 token，那麼無論我今天只問兩句、還是聊兩百句，每一句的背後都在重複付這 5000 個 token 的錢。 我把它叫做「常駐稅」。每一行都是稅。 所以我刻意把它壓在 95 行左右，只留真正穩定不變、非寫不可的規則。會議記錄、設計過程、長篇說明，全部移到別的地方，要用的時候才叫出來。 順帶一提，這些「只給 AI 看」的設定檔，我一律用英文寫。因為中文在 token 計算上比較貴（同樣意思的中文通常比英文吃更多 token），而給人看的筆記我才用中文。給 AI 的省錢，給人的好讀，各得其所。 抽屜：讓記憶分層，不要全攤在桌上 我給 AI 做了一套記憶系統，但重點不是「記越多越好」，而是分層： 真正天天用到的，放在最上層，每次開工自動載入。 偶爾才用的，收進抽屜，需要時才拉出來。 很久沒碰的，直接封存。 我還做了一個「使用熱度」的計分：常被讀到的記憶分數高、留在桌上；冷掉的自動往下沉。這樣桌面永遠只有當下最相關的那幾張紙。 道理跟上一篇的算盤一樣：這套熱度排序是用程式算的，不勞駕 AI。 這對手機聊天版的人也有啟發：ChatGPT 的「記憶」和「自訂指令」功能不是免費魔法，它是每次對話前自動幫你貼上去的隱形內容，一樣佔空間、一樣每句重算。所以記憶要精簡，不是塞越多越好。 ...