Claude Code

之前做了心肺運動測試（cardiopulmonary exercise testing, CPET）自動判讀的工具，做得有點慢🤣，但也因為慢，有些事情想得比較清楚。這篇把整套做法攤開來講：AI 在哪裡、程式在哪裡、醫師在哪裡，還有為什麼這三個位置不能換。 先講清楚：它產出的是參考稿，不是自動判讀 無氧閾值（AT／VT1）、呼吸代償點（RCP／VT2）、peak 的時間點，由醫師標，程式不猜 AACVPR 風險分層的紅綠燈沒圈完，程式擋住不讓產生報告；真的判不出來才走頁內二次確認，而且會記進稽核 結論是照院內模板的六選一固定選單加一項「都不適用」，引擎只給建議、理由和出處，醫師可以覆寫 報告上每一個欄位都可以手動修改。機器負責把數字備妥，判讀的還是人 第一條原則：AI 不進醫院的電腦 跟醫院的資料對接，第一件要想的事情是病人安全。 我的做法是：用 AI 來設計程式，再用程式去跑醫院的資料，而不是把 AI 直接接到醫院的電腦裡面，讓它自己去讀。畢竟那台電腦裡有太多不該被讀到的東西。（病歷要貼給 AI 之前該先做什麼，之前在《病歷不能就這樣貼給 AI》寫過一篇。） 所以我給 AI 的，是「報告做完之後會產出哪些資料」這件事本身。CPET 儀器匯出時會同時吐出幾份表格檔，肺功能一份、體組成一份，都是能快速讀取的純文字或 CSV。把這些檔案的結構、我自己判讀過程的筆記、還有科內既有的報告模板一起給它，它就能把「這份報告到底是怎麼判讀出來的」重建成一支程式。 規則講清楚，電腦就有機會替我們跑完。這其實就是把我們平常在腦子裡做的資料判讀，外部化成一份看得見的東西。 一個插曲 一開始以為只能靠 OCR 讀 PDF 報告，操作者要手填 18 個欄位。後來發現儀器匯出時其實同時產生了一份純文字的 .xls，改成直讀之後，需要人工填的欄位剩 5 個。工具做慢一點的好處之一，就是有時間回頭看資料源。 每一條切點都要指得出出處 外部化的好處是，規則被攤開來看，就會發現有些地方需要對答案。 引擎裡每一條判讀切點，我都要求指得出來源：這條印在哪份報告模板的第幾節、那條出自教科書哪一版。科內五份報告模板（心肌梗塞、心衰竭、COPD、氣喘、心臟移植）是所有切點的唯一真相源。像是 AACVPR 的風險分層切點，有新舊兩版，過程中就要每條確認好是使用 2021 年第六版。 還有一條原則我覺得比切點本身更重要：算不出來的欄位就留白，不猜，也不預設為正常。空著的欄位人看得到，會去補；自動填成「正常」的欄位，沒有人會再看第二眼。 （規則先寫清楚再叫 AI 做，跟《先講清楚，再叫 AI 做：規格驅動開發》講的是同一件事，只是這次的規格是醫學上的切點。） 機器出的錯，常常很安靜 同一套匯出格式，不同單位吐出來的檔案，實測值跟預測值的欄位順序居然是相反的。程式一開始寫死讀第一欄，就把預測值當成了實測值。breathing reserve 從 −62% 變成 +41%，整份報告的結論會翻面。 這種錯不會跳出紅字，它會安安靜靜地產出一份看起來很正常的報告。所以人必須留在迴圈裡：判讀表單上每一個欄位都可以手動修改，機器只負責把數字備妥。 讓每一次判讀都留下紀錄 上面那件事讓我想到一個問題：安靜的錯，要怎麼被發現？ 靠人記得是不行的。所以我把整套系統加了一層稽核紀錄：每產生一份報告，就在本機留下一行，記錄這一次判讀的完整經過。 不只是記「人改了什麼」，我最後記了七件事： 人工修改：哪一欄、機器判什麼、人最後填什麼，還分成「改值／補填／清空」三種動作 資料來源與備援：這次的 MVV 是用實測還是 FEV1×35 推的？HR recovery 是機器給的還是我自己從原始表算的？肺功能檔的欄位順序判成哪一種？ 警示有沒有被理會：跳出來一百次都沒人動的警示，其實應該刪掉，這份紀錄就是刪它的依據 無氧閾值的判定：機器標的位置，跟我最後選的時間點差多少 留白的欄位：某一欄如果十份有九份都是空的，那是資料來源缺了，不是技師偷懶 解析失敗與不認得的檔案：以前這些只閃在畫面上，重整就消失了 當下的程式版本：這條我覺得最容易被忽略。沒有版本號，半年後回頭看那些修改紀錄，會不知道當時的規則長什麼樣，整份紀錄就等於作廢 紀錄留在本機，跟病人資料同一個等級，不進版本控制也不外傳。要拿出去討論的時候，另外有一個匯出指令，產生的摘要只有次數和比率，沒有病歷號、沒有姓名、也沒有任何生理數值。連警示文字裡技師手打的那一段都會被截掉，因為那裡可能出現人名。 ...

教科書、演講、論文三條產線各自寫過了，這篇講它們合起來是什麼：一個 AI 讀得動的知識庫。庫建好之後，門診遇到的病人狀況經過去識別化轉譯，就能拿來跟 AI 討論，把讀到的接到看到的病人身上。最後講用 AI 學習的那條界線：哪些可以外包、哪些不能，該記什麼、怎麼跟它一起維護筆記。

東西大到一句話交代不完，開工前要先寫好什麼？什麼時候不用寫、需求的三個必填零件、含糊一句對上清楚五句、一份可以直接複製的規格範本、改需求先改規格、用程式把這條擋成硬規則，還有為什麼錯的規格錯得很有權威。

備課的步驟跟沒有 AI 的時候一模一樣，差別是每一步多了一個會做事的同事。這篇把七個步驟攤開來講：對象、元素、排序、大綱、簡報、互動、回饋，每一步我做什麼、他做什麼。最後講上完課之後的事：錄音讓他聽、抓我講錯的地方、算語速、數贅字，然後把這堂課拆成下一場的零件。

這個題目是訂閱區的歐陽醫師許願的。他說得很準：認真看 AI 運行的資料夾，好像都才幾十 MB，但是電腦容量就是被吃掉一大半。 這件事我自己也遇到很多次了。我的 C 槽 953 GB，過去一個多月每隔幾週就快滿一次，每次都是跟 Claude 說「幫我清理」，清完過陣子又滿回來。這次我們不清了，改成把一個多月來每一次清理的對話全部翻出來對帳，算清楚是誰一直長回來。 查出來四層，照體積排序。其中一層是我們自己開源出去的工具，這個下面會老實講。 一、雲端同步：檔案被讀一次，就永久回到你的電腦 這台電腦的 OneDrive 雲端有大約 400 GB。檔案設成「僅雲端」之後，檔名在、圖示在，不佔空間。但只要有任何程式打開那個檔案，同步軟體就會把它下載回本機，而且除非你自己把它釋放回雲端，它就會一直佔著空間。 八月十七號那次大掃除清出 382 GB。四天後回頭看少了 56 GB，其中課本 PDF 那幾個資料夾自己回到本機 45 GB。 這件事的怪，怪在因果被切斷了。吃掉容量的那個動作，跟長出來的那些檔案，看起來完全沒關係。你翻遍 AI 的資料夾，當然只有幾十 MB。 我們怎麼把它抓出來的 這一段是這篇最想分享的：不是我自己會查，是我跟 Claude 一起把範圍縮小的過程。 第一步，先問清楚機制。 我請他上網查「OneDrive 在什麼情況下會自動把僅雲端的檔案下載回本機」。查回來的答案是：只要有程式開啟那個檔案就會，不必真的讀內容。這一句話後來就是破案關鍵。 第二步，一個一個排除。 每關掉一個嫌疑犯就重新量一次本機佔用： Windows 搜尋索引：停掉六分鐘，佔用沒變化 檔案總管縮圖、防毒掃描、Google Drive、iCloud、Synology Drive：都排除 OneDrive 自己重抓：手動把二十個檔案標成「釋放空間」，六分鐘內一個都沒有被抓回來 排到這裡，OneDrive 本身的嫌疑就洗清了。它只是執行者，不是發動者。 第三步，我提了一句話，方向就轉了。 當下我們一直在找「現在正在跑的東西」，可是我想到：這些下載搞不好是幾個小時前下的指令留下來的，那支程式可能還活著，只是沒人注意。 我把這句話丟給他，他回頭去翻還在執行中的舊程序，當場抓到兩支： 下午五點二十某個 AI session 下的 find 指令，尾巴接了 head，本來只要前二十筆。head 拿夠了自己結束，前面的 find 卻沒有跟著死，一路跑了五個小時，回抓 19 GB 抓它的同時，另一個 session 又下了一支掃全機的 find，三分鐘再吃掉 6 GB 兩支都殺掉之後，回抓當場歸零。 ...

上週幫一群麻醉科的醫師朋友上了一堂 AI agent 上手課。課後回饋很有意思：「權限框與 auto mode」同時出現在兩張名單的前段，投「最有收穫」的人很多，投「沒聽懂」的人也很多。代表這東西重要，但一堂課的節奏講不完。這篇把它一次講完整。 還沒裝起來的朋友，可以先看從零開始用 AI agent那篇，裝好再回來。 權限框是什麼：它動手之前，先舉手 第一次叫 Claude Code 或 Codex 整理資料夾，最不習慣的就是它一直跳框問你「可以嗎？」。 這個框其實是整套系統最重要的安全設計：AI agent 要動你電腦裡的東西之前，必須先讓你點頭。框裡通常有三個部分： 它想跑的指令：一行終端機指令，像 ls、mkdir、rm 它自己的白話解釋：指令下面那一兩行，說明它想做什麼、為什麼 你的選項：同意這次、同意以後都不用問、拒絕 你不需要會終端機指令。你只需要看得懂那行白話解釋，然後判斷「合理嗎」。看不懂的時候有兩招： 看不懂它想幹嘛的兩招 直接回它：「用五歲小孩能懂的方式解釋你現在要做什麼」（英文縮寫叫 ELI5，Explain Like I’m 5，AI 都看得懂） 把那行指令複製，貼給網頁版的 AI 問「這個指令會做什麼？有風險嗎？」 四種模式：按 Shift+Tab 切換 每一步都問你，等它做完一件事你可能按了二十次同意。所以 Claude Code 提供好幾種模式，按 Shift+Tab 就能輪流切換，畫面上會顯示目前在哪個模式。日常用得到的是這四個： 模式 它會怎樣 什麼時候用 default（預設） 每個會改到東西的動作都先問你 剛開始建立信任的階段 plan mode 只能讀、不能寫，先研究再給你一份計畫 想先看它打算怎麼做；要碰重要資料的第一步 accept edits 檔案編輯自動放行，跑指令仍會問 改稿、寫筆記這類編輯密集的工作 auto mode 系統自動判斷每條指令危不危險：安全的直接放行，危險的攔下來問你 日常主力 （Claude Code 其實還有更多模式，像給無人值守環境用的 bypass permissions，那些跟日常上手無關，先不用管。） auto mode 為什麼反而比較安全：警報疲勞 臨床的人對 alarm fatigue 都不陌生：monitor 什麼都叫，叫久了大家聽到聲音只是伸手把它按掉。權限框也一樣。當每一個框都要你同意，你很快就會停止閱讀，變成反射性按同意。這時候「每步都問」給你的不是安全，是安全感。 ...

前幾天一個剛開始用 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），有點門檻。所以我把它做成了一鍵設定的工具，開源出來： ...

在花東跨院支援門診，最花心神的其實不是看診，是回程的火車票。下診時間不固定，玉里、關山、臺東各有各的班次窗口，加上夏天傍晚的花東線，坐錯邊就是整路被太陽曬🥵 這種事就該交給 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 工作一陣子的人，大概都遇過這件事：同一個錯，你講過了，規則也請它記下來了，過幾天它又犯一次。 而且我不是沒有防：規則寫進了它的記憶檔、違規有計數器、還有每月的定期檢視，該有的機制都在。但七月底，我看著我的 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 專用的，你會發現每一條在醫院的品質管理裡都有對應物。 一、錯誤要記成「可歸屬的事件」，不是一個數字。每次違規記一行：日期＋哪一條規則＋一句事實。計數是用數的，不是用手改的。（對應：異常事件通報寫事件經過，不是只在統計表上加一。） ...