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