那次會議談的是別的事。散會前，資訊室的老周一邊收筆電一邊順口問了一句：
「你們品管室一個月到底要處理多少份文件？給我一個數字，我看能不能幫你們排個自動化。」
這是一句很善意的話。我卻在那裡站了三秒。
我一時答不出來，因為單位的工作量散在不同系統與不同同仁的待辦裡。稽核有排程，電子報告有截止日，通報系統則隨時有新案件。每條流程都有人處理，卻很難只靠其中一人的收件匣看見全貌。
用你的話講：單位缺的是跨流程的 queue depth，大家感受到的卻是各自清不完的待辦。電子病歷查核、通報追蹤、報告審閱各有畫面，合起來佔掉多少工時，沒有一個現成數字。
我當下只能講一個粗略估計。老周把它記進會議筆記，但那還不能拿來排需求：件數是否重複、經過幾次轉交、各環節花多久，都還沒對齊。
要把這個問題答完整，得請各流程承辦同仁一起盤點：對照作業排程、系統待辦與委員會年度計畫，列出每類紀錄由誰接手、需要哪些判斷，以及在哪一站等待。
這樣盤點會帶出兩個問題。第一個很直觀——總件數之外，還有跨單位來回確認的工時。第二個讓我想得比較久：
那位同仁問的不是對的問題。而我當時也不知道對的問題是什麼。
以下用一個品管單位參與的四條流程舉例，只寫量級。這是單位與跨部門小組共同承擔的負荷，不是某一位主管的個人收件量。
病歷品質審查: 醫院每個月出院的電子病歷以千計，稽核小組依權限調閱抽查紀錄，相關單位協助確認資料位置與例外情境。這裡看的不是醫療處置對不對，是紀錄完不完整、該做的評估有沒有紀錄、時序合不合理。這就是抽樣式 code review，但預告查核也會影響受查單位的準備方式（Day 1 那個悖論）。
品管圈報告: 品管圈是院內的小組改善活動：一個單位五到十個人，花幾個月做一個主題，最後交一份報告。它有固定格式、要上台報、而且分數會進單位的年度成績——所以評得準不準是有人在意的。全院一年以數十份計。
異常事件通報: 通報系統每個月累積數十件紀錄，已有類別、時間等欄位，但自由文字裡的情境仍要由病安承辦同仁判讀，必要時請通報單位補充，再交由相關小組討論。即使有 severity 欄位，也不代表通報者初填的分級已經過確認。昨天那篇談的就是這條線。
稽核與指標: 條文式稽核每季一輪；各單位按月在系統或電子報表填報指標，品管室彙整趨勢，異常值再由來源單位查證與說明。負荷常在不同系統數字對不起來、定義不一致、需要往返確認的時候增加。
份數差很多，節奏也差很多。但這四種東西有一個共同點，而那個共同點才是這篇的重點：
它們都已經是電子資料，但欄位之外的文字與情境，仍要由不同角色接續判讀。
處理跟評價的差別，是整篇的分水嶺。
一份表單有沒有在期限內送出，跟一份報告的對策算不算有效——前者是 lint，後者是 review。醫院也一樣，只是我們沒有這兩個字。
而 review 這一種，你得說得出理由，而且下一個人看同一份的時候，最好給出一樣的答案。
把各流程的清單放在一起，再帶回品管與資訊的討論，才看得出需求。
這時候，比「總共有多少」更有用的提問是：
「所以你要它做什麼判斷？」
這句話把整件事翻了過來。而後來我發現，這正是品管的人跟資訊的人第一次真正對話的那個位置——一邊在講吞吐量，一邊在講規格，兩邊都以為自己在講同一件事。
我建議把單位的任務按判準寫不寫得下來重新分成三級。每級要投入的人力不同，接手的角色也不同。
表單有沒有在期限內送出、必填欄位有沒有填、簽章存不存在、時間戳的先後順序合不合理、格式對不對。
判準早就白紙黑字寫在辦法裡，沒有歧義，而且大多可以直接對著欄位判。它的量最大，佔掉的是很零碎但加起來很可觀的時間。
這一層全部是本來該在寫入的時候就擋掉、結果變成事後用人眼補做的檢查。表單送出的當下沒有擋，所以三個月後要有人回到系統裡，一筆一筆調出來對。
而它不需要 AI。它需要的是有人去接資料庫、寫一個查詢、排一個排程。
那為什麼一直沒做？答案很掃興：
因為沒有人把它寫成一張工單。
品管的人不知道這件事三行 SQL 就結束了；資訊的人不知道有人每個月在用眼睛做這件事。兩邊各自很忙，中間沒有人負責翻譯。
醫院裡大部分「還沒自動化」的東西，卡的不是技術，是沒有人提出需求。
「這份改善報告的對策，算不算有效對策。」
這個你寫得出來。我可以列出十幾條可判定的檢查：對策有沒有指向前面分析出來的原因、有沒有指定執行者與期限、有沒有可量測的驗證方式、有沒有整份停留在提醒與宣導的層次（那是 Day 13 一整篇的主題）。
寫得出來，但寫完是一份很長的 spec 。而且大部分條目沒辦法變成布林運算式——它們長得像「讀完這一段之後，判斷它有沒有做到」。你沒辦法把那句話編譯成一個函式。
這一層就是 LLM 真正改變的位置。
十五條判準，用自然語言寫跟用程式碼寫，差的不是聰明，是價錢。 你現在可以用寫 acceptance criteria 的成本，得到一個會去執行那份 acceptance criteria 的東西。
便宜到你願意寫、願意改、願意在發現它判錯之後回頭再補第十六條。這是整條線鬆動的真正原因，跟模型有多聰明關係沒有大家以為的那麼大。
「這個單位今年的改善，做得算不算認真。」
單靠報告答不出來，還得請單位補充脈絡，再讓參與改善的同仁一起判斷。
這個單位今年三月換過主管，前任留下來的爛攤子有一半是他在收。那台一直出問題的設備上個月才換掉，而報告寫的是「持續監控」——因為報告是二月寫的。排班表上那個時段有兩個人，實際上只有一個，另一個固定被調去支援。去年被挑到的那個問題，今年一次都沒有再出現；報告裡沒有寫，因為沒有人會在報告裡寫「我們沒有再犯同一個錯」。
這些脈絡由誰提供？排班情形要由單位確認，設備變更要對照維護紀錄，改善是否持續則要回看追蹤資料。我可能在討論中聽過其中一部分，但不能代替各單位核實。模型拿到的那份電子報告，不一定包含這些資訊。
再強的模型也讀不到沒有提供的東西 。有些脈絡尚未記錄，有些在另一個系統；對模型而言，它們都還不是這次判斷的輸入。
要讓第三層變成第二層，唯一的路是把那些脈絡也變成輸入，而那等於要求上游補一整批埋點：改流程、改表單、改別人的工作習慣。那是很貴的事，而且不是技術問題。
三層分完，那個掃興的結論就浮出來了：
量大只決定「值不值得」，判準寫不寫得下來決定「能不能」。
我一直對第三層的東西喊「為什麼這個還沒自動化」，同時讓第一層的東西繼續用人眼在做。兩件事都很浪費，而且是同一個誤解造成的。
所以清點工作量的價值不在總份數，在於它逼你對每一類問一個問題：
如果我要把這個判斷交出去，我寫得出驗收條件嗎？
寫得出來，落在第一層或第二層，往下談。寫不出來，先別談自動化——先談能不能把判準寫出來。（怎麼把一個模糊的條目改寫成機器判得動的條目，是 Day 8 一整篇的事。）
第二層是接下來這 30 天的主戰場。
第一次把第二層的東西交出去的時候，我的做法跟大多數人的第一直覺一樣：把整份報告貼進對話框，打一句「幫我看這份報告有沒有問題」。那是我踩的第一個坑，明天整篇談。
這裡只留一件跟「量」有關的事：那次之後我才回頭想清楚，量大在這條線上的角色，跟我原本以為的完全不一樣。
回到標題那句話。既然量大不是自動化的理由，那量大是什麼的理由？
量大不是自動化的理由，但量大是把判準寫下來的理由。
一年只做一次的事，判準爛就爛了。你會用直覺把缺的那一半補完，而且沒有人會發現，包括你自己。就像那種一年只跑一次、從來沒有人核對過輸出的年度結算——它算錯在哪你不會知道，因為沒有第二次可以拿來對帳。
每個月都要做的事，判準爛會爛一整年。而且會爛得很一致——同一個模糊條目，每個月穩定地放過同一類問題。放到後來沒有人記得那是漏洞，大家以為那就是標準。
但反過來說，這也是好消息。穩定地錯，是最容易修的一種錯 。判準爛掉的那種錯不是 flaky，它每次都錯在同一條判準上，而且錯的方向一樣。
前提是你看得見。而看得見的前提，是你的輸出得逐條分開——不然它連錯在哪都不會告訴你。
於是這件事才從一次性的問答，變成一個會累積的東西：
判準寫下來 → 跑一批 → 看哪一條錯得最多 → 只改那一條 → 只重跑那一條 → 比較改前改後。
紅燈、改一行、再跑一次、看它變綠。
而這個迴路能不能轉，只取決於一件事：它判錯的時候，你定位不定位得出來是哪一條判準判錯的。
而「整份丟進去問一句」給你的，比 build failed 還糟——至少那個會停。
那是一個永遠 exit 0、log 裡什麼都沒寫的 CI。它給你一段像這樣的話：「本案分析尚稱完整，建議可再強化對策的可行性評估。」四十份報告它都可以這樣寫，而且每一份看起來都很中肯。你分不出來它有沒有失敗。改完判準再跑一次，你也不知道變好的是不是你改的那一條，只知道整體看起來好像順一點。
所以問題要問成什麼形狀，不是提示詞技巧，是這個迴路能不能存在的前提。明天那一篇整篇在講這件事。
這才是自動化跟「用 AI 做一次」的差別：一個可以被修的東西，跟一個每次都要重新碰運氣的東西。
最後，這張按單位與流程彙整的清單，不適合只叫做「可自動化清單」。
它比較像另一種東西：判準負債表。
上面列的是：我們每個月都在做、但從來沒有寫下依據的判斷。
而它會滾利息。資深的人退休，判準跟著走；新來的人重新長出一套自己的版本；而沒有人會發現標準已經換過了——因為那套判準從來沒有被 commit 過，沒有人看得見它什麼時候被改掉了。
每一個沒有被寫下來的判準，都是一筆會隨著人事異動蒸發的資產。
這就是為什麼我認為這 30 天做的事，即使 AI 全部失敗也還有價值。為了把判斷交給機器而被迫寫下來的那些判準，本身就是這份工作二十年來欠的帳。
明天講我第一次把 AI 放進來的時候，是怎麼把上面每一件事都做反的。
iThome鐵人賽
看影片追技術