有人問了我一個答不好的問題

那是一場院外的分享，台下大多是工程師。

Q&A 的最後一個問題，一位年輕的開發者舉手，語氣完全沒有惡意，就是真心好奇：

「你講的這些驗證、判準、共識會議，聽起來很費工。可是模型每半年就強一次。等它夠強了，這些是不是就不用做了？」

我當下給了一個標準答案，講了幾句「人還是要在迴路裡」之類的話。台下點頭，時間到，散場。

同一天上午，我在自己的品管圈開年度審視，翻著小葉整理的複核紀錄——那份紀錄就是這段時間留下來的所有東西的縮影：哪幾條稽核條目一直被單位申復、哪幾條 AI 判得比人穩、哪一份病歷的判定跟半年前那一版判準對不上。回程飛機上想起那位開發者，我意識到那個答案為什麼爛：他問的是「AI 夠不夠強」，而我腦子裡那份紀錄，講的每一件事都跟 AI 強不強無關。

回程的路上我一直覺得那個答案很爛。爛在它是一句立場，不是一個論證。

同樣的問題會出現在每個做內部工具的人身上：下一版 framework 出來、CI 換了 runtime、linter 升級了預設值——那我原本這些手寫的檢查是不是可以拆一半？回答的形狀總是一樣的：不是那些檢查不用做，是「你到底想擋什麼」這件事，沒有一個模型能力升級會替你回答。

這一篇是那個問題的完整版回答。

這個系列前面 29 篇寫的都是細節：怎麼拆流程、怎麼寫判準、怎麼驗、它在哪裡壞掉。最後一天，我想把它收到三件事上。

這三件事不是我發明的，是品質管理這個領域用幾十年、還有一些不該發生的事故換來的。這段時間把 AI 放進來實際跑過之後，我的結論是它們一件都沒過時。

而且不只是沒過時——模型越強，這三件事越重要。這一篇要論證的就是這個「越」字。

第一件：先定義，再測量。沒有定義的測量是裝飾

品質管理裡有個東西叫操作型定義。意思是任何指標的第一步都不是去量，是先寫清楚：分子是誰、分母是誰、什麼狀況要排除、時間點怎麼算。院內每一份稽核條目、每一張評鑑指標卡、每一次品管圈的成果指標都要先寫這幾行，才准開始收資料。

這在品管是常識，因為沒有它，兩家醫院的同一個指標不能比，同一家醫院的這個月和上個月也不能比。你量到的東西會動，但你不知道是現場動了還是定義動了。這跟 CI 上一條 flaky test 是同一件事：昨天過、今天不過、下次跑又過了——你不知道是被測的東西壞了、還是測試自己壞了。指標抖動也一樣，你分不出是現場動了還是尺動了。

它在 AI 時代的技術命題

評估先於模型選擇。

這件事現在已經是共識了，但我想指出它跟操作型定義是同一件事：你的評估集就是你的操作型定義。

沒有評估集的團隊換模型，是擲骰子——你只能靠感覺說「這個好像比較好」。有評估集的團隊換模型，是一次實驗——你知道哪幾類變好了、哪幾類變差了，而且下次還可以再跑一遍。

同一個動作，有沒有定義，性質完全不同。

這個動作在你們那邊有個更陽春的名字，叫寫 spec——差別只在寫 spec 常被當成寫作業，寫判準常被當成累贅。而 unit test 存在的理由，也不是為了每次都跑一遍，是為了讓「這個 function 該幹嘛」這件事被固定下來。沒有它，這個 function 到底幹嘛，只住在寫的那個人腦子裡。跟稽核判準住在資深稽核員腦子裡，是同一種住法。

系統層次的形態

這段時間做過的三件事，其實是同一件事的三種形態：

• 把稽核條目寫成可判定、無歧義的敘述（Day 8）
• 把評分尺度寫成錨點，讓「3 分」有一段可以指的文字（Day 21）
• 自己造一批有問題的案例，拿來測一個沒有標準答案的系統（Day 22）

三件事都在做同一個動作：把「好」的定義，從某個人的腦子裡，搬到一個可以被重跑的東西上。

Day 29 講到，這段時間留下來最有價值的產物其實是一份文件，不是一個系統。原因就在這裡：那份文件不是給人讀的、是給流程 diff 用的——它是這條 pipeline 的 spec，你動了模型、動了判準、動了資料，它都是唯一那個沒動的參照。

從一個參與過的案例回看

回看過去參與的預警系統，當時注意的模型指標是——87%，ROC 曲線下面積超過 95%。那個數字是真的，量法也沒有問題。

問題出在更前面一步：我們定義的「準確」，是「預測得準不準」。

而現場真正要問的是另一件事：這個預警出現之後，有沒有改變任何人的動作？護理師看到警示、提前處置了，那筆算「準」；她看到警示、判斷不需要處置，那筆算什麼？她根本沒看到呢？

我們量的是模型的表現，不是這套系統的表現。這個區別在你們那邊有個乾淨的對應：測 unit 和測 integration 是兩件事。 unit test 全綠不代表 request 到得了資料庫；一個模型的 F1 很高，也不代表它會真的改變床邊的動作。

這件事後來變成品質委員會上一個固定會被問的問題。任何一份要進委員會的指標，第一關不是問值多少，是問它的分母是什麼樣的人：全院都在看的那位護理師、還是我們自己模型的輸出？分母是誰，決定了那個數字到底是這條流程的效能，還是這個模型的自我評分。

這就是操作型定義沒有寫完的樣子——分子分母都定義了，但「這個指標到底要回答什麼問題」那一層沒有。而那一層沒定義，後面每一個小數點都很精確地在回答一個錯的問題。

你量得準，不代表你量對了東西。

Day 19 完整講過這件事。這裡只補一句我當時沒想通、現在想通了的：那個 87% 不是錯的，是不完整的——它是一個模型指標，而我把它當成一個系統指標在用。

順帶一提，Day 1 開頭列的三件事裡，「可重現」就住在這一節：判準搬到定義裡，這個月和下個月才比得起來。 它不是第四件事，它是第一件事做完之後才會出現的性質。跨月比較做不到，你就沒有辦法在委員會上說「這半年 7B 病房的紀錄有變好」；連自己的稽核小組上個月看的和這個月看的算不算同一種嚴格，也講不清楚。

為什麼模型變強反而更需要它

直覺上，模型變強應該可以少寫一點判準——它比較懂了嘛。這在你們那邊有個好懂的對照：新版 compiler 更聰明了，是不是可以少寫幾條 warning 規則？答案幾乎每一次都是相反的——編譯器越懂你的意圖，你越容易寫出「編得過但完全不是你要的」那種 code。強模型跟強編譯器有同一個副作用。

實際上反過來。

模型變強，變的是「執行你的指令」這件事的能力。它不會因為變強就比較知道你要什麼。 「你要的是什麼」這個問題，沒有任何模型能力的成長會替你回答。

同樣地，一個更聰明的 static analyzer 不會替你想清楚「這條 lint 規則要不要 enable」；一個更完整的 code review bot 不會替你決定「哪一種 anti-pattern 是我們這個 repo 不接受的」。工具越強，選擇越明確地變成一個要你自己承擔的決定。

而更麻煩的是代價的變化。弱模型的好處是它錯得很明顯——你一眼就看得出這個答案不對，於是你回頭把判準寫清楚。強模型錯得很有道理：格式漂亮、理由完整、引述具體，只是它做的不是你要的那件事。放進醫院的例子裡：弱模型會把不合格判成「病歷欠簽」，你一看就知道那不是重點；強模型會判成「未依單位標準完成再評估流程」，理由段落引到病歷第三頁那一句話，看起來完全站得住——你要看到第三次同樣的判定用在完全不同的臨床情境，才會意識到它其實只是把「看起來不太完整」講得比較華麗。

模型變強不會讓你的問題變清楚，只會讓你更快拿到一個看起來很好的錯答案。

這件事你們有一個熟悉的形式：一個 regression test 全綠不代表你的功能對，只代表你寫的 assertion 全過了。assertion 寫錯了、寫得太寬、漏了一個邊界條件，test 越綠，你越安心，也越危險。

所以第一件事不但沒過時，它的投資報酬率還在上升。

第二件：任何會出錯的系統，都必須看得見自己出錯

這是 Day 2 講過的品質定義，也是 Day 16 那個維度：偵測性。一句話帶過就好——重點是它在 AI 上長什麼樣。

它在 AI 時代的技術命題

LLM 系統的可觀測性，不是 log。

你可以把每一次呼叫、每一個 token、每一次延遲都記下來，然後發現自己還是不知道哪一次判錯了。因為沒有標準答案可以對。

這是 LLM 系統跟一般系統最大的差別之一：一般系統的錯誤會自己冒出來——例外、逾時、狀態碼。判斷型系統的錯誤不會，它會安安靜靜地產出一個格式完全正確的錯答案。

log 完整不等於可觀測。可觀測的意思是：錯了，發得出聲音。

系統層次的三個做法

這段時間下來，我認為可觀測性要靠三個地方一起撐：

一、把可以被便宜檢查的東西，寫進輸出格式裡。
依據落在原文哪一段、結構化的欄位、模型自己的把握程度。這些不是給人看的裝飾，是給人查的把手。護理紀錄那些必填欄位為什麼要存在，是同一個道理：不是要為難第一線，是讓下一個人接手的時候有東西可以指。可觀測性是設計進輸出格式裡的，不是事後加監控加出來的。

二、讓系統定期對已知答案自我測試。
就像每年一次的稽核小組抽樣，只是這一次抽的對象不是單位，是我們自己的模型。Day 22 那批自己造的案例，加上 Day 26 的定期重跑，形狀就是你們的 regression test：一組固定輸入、一組固定的期望輸出，任何 diff 都只能來自被測的東西自己變了——換模型、判準改一句話、供應商靜默升級，它都要挑得出來。它不產出成果，它產出「還沒壞」這個資訊。

三、把人的分歧記下來。
Day 28 談的覆蓋紀錄。小葉每複核一批，退回一筆就要選一個理由分類（Day 25 那三個桶）——那些選擇累積下來，就是這條流程最誠實的一份 issue tracker。人每一次推翻系統，都是一次免費的錯誤偵測。不記下來就浪費掉了。

三個做法有一個共同點——它們都不住在模型裡，住在模型外圍那一圈：輸出的 schema、排程與 golden dataset、以及那份 override log。你們熟悉的產線監控是同一個結構：Prometheus 不改 kernel、alerting 不改 handler；它們貼在被監控的東西旁邊，就地讀那些本來就該存在的訊號。

偵測性不是模型的屬性，是系統的屬性。

講具體一點。同一份稽核判準，跑在只輸出「不合格」三個字的系統裡，小葉複核完那一批之後就沒有第二次；跑在會輸出「依據落在原文哪一段」的系統裡，她每退回一筆，那一筆就變成下一版條目的材料——三個月之後，品質委員會拿到的是一份看得見漲落的判準修訂清單，而不是一份說「這半年 AI 判得還可以」的月報。模型完全一樣，差別在輸出格式留不留得下把手。

同一個模型放進兩個不同的系統，一個看得見自己出錯，一個看不見。差別完全不在模型，在你有沒有留下可以比對的東西。同一支 service 也是這樣：deploy 到有 log／trace／metric 的環境跟 deploy 到什麼都沒有的環境，程式碼一模一樣，但只有一個可以被 debug——沒有人會說那支 service 比較差，只會說那個環境沒法用。

所以「這個模型可靠嗎」其實是問錯的問題。該問的是：這套系統，在它不可靠的時候，會不會有人知道。

同一句話在醫院已經被講過幾十年，只是主詞不同：這位護理師值得信任嗎——這問錯了；該問的是這條交班流程在她漏掉一件事的時候，會不會被下一班接住。單一個體的可靠性從來不是重點，補位機制才是。

為什麼準確率上升會讓監測更重要

這一段是我最想寫的。

直覺會說：模型越準，越不需要監測。

反了。錯誤率下降的同時，錯誤的可偵測性也在下降。

機制很簡單：錯得少 → 大家更信任它 → 更少人真的去查 → 而剩下那些錯誤因為稀少、而且看起來很合理，反而更難被發現。這是 SRE 那條老規矩「a healthy system needs unhealthy tests」的另一種說法：一個 alert 從來沒觸發過，多半不是因為東西沒壞，是因為那個 alert 本身壞了——只是這一次，被監測的對象是模型的判斷品質。

品質管理對這件事有一段很老的經驗：低發生率的失效最難管理。 不是因為它不重要，是因為沒有人在等它。整個系統的注意力都撤走了，剩下那幾次就直接穿過去。

醫療業對這個機制付過學費。一個一年只發生一兩次的失效——罕見藥物交互作用、跨科交班時漏掉的一項禁忌症、非慣用給藥途徑的錯誤——往往比每週都發生的那種更致命，因為每週發生的那種，病房早就長出防禦了。真正咬人的，一律是那些「不會吧、我做這行 20 年沒看過」的事。

你不能要求模型不出錯。你只能要求系統在它出錯的時候發得出聲音。

第三件：判斷可以交出去，說明責任不能

Day 1 我寫過一句話：這份工作真正的重量不是權力，是得說得出理由。

當時我以為那是一句關於醫院文化的話。做完這段時間才發現，它是一句關於系統設計的話。

它在 AI 時代的技術命題

Day 28 整篇在講這個，這裡只補最後一塊：責任鏈是系統設計的一部分，不是上線前補的一份文件。

你把簽名欄放在哪裡、輸出寫成結論還是證據、推翻要不要留紀錄——這些都是設計決策，而且它們決定了這套系統出事的時候有沒有人接得住。

一個我認為很值得帶走的重新定義

「可解釋性」這個詞在研究上跟在現場，指的不是同一件事。

研究問的是：模型內部發生了什麼。

現場問的是：

有人不服的時候，你拿得出什麼。

這個定義很土，但它有一個巨大的好處：它是可以工程化的。

「模型內部發生了什麼」是一個尚無解的科學問題；「三個月前那一份判定當時看到什麼」是一個 schema 問題——你設計 schema 的時候有沒有把它存下來而已。前者要等技術突破，後者是明天可以做的事。

單位針對一筆病歷判定提出申復時，討論畫面上需要一起調出的有三樣東西：

1. 當時用的是哪一版判準（Day 27 的版本控管）
2. 當時的輸入長什麼樣（快照）
3. 判定所依據的原文落在哪一段（Day 28 的硬規則）

這三樣，沒有一樣需要打開模型。

也就是說：現場要的可解釋性，是一個資料保存問題，不是一個模型詮釋問題。 而資料保存問題你們會解——你們每天都在解：request log、audit trail、git blame、每一個 event 的 correlation id。

我認為這是這 30 篇裡對 IT 讀者最實用的一個轉換。很多團隊卡在「LLM 是黑盒子，沒辦法解釋」，然後就停在那裡——就像早期分散式系統的人卡在「網路不可靠所以什麼都做不了」，一直等到有人發明 tracing 為止。真正的移動不是把盒子打開，是在盒子外面把足夠多的痕跡留下來。現場需要的那種解釋，從來就不在盒子裡面。

為什麼它不會過時

因為簽名這件事沒有 AI 版本。

模型再強，判定被質疑的時候，還是要有一個人出來說明。這件事不會因為模型準確率上升而消失，只會因為系統跑得更多、影響的人更多而變得更頻繁。

而那個人能不能說明，取決於當初有沒有留下上面那三樣東西。那是設計時的決定，不是出事時的決定。出事的時候才想留，已經來不及了。

三件事其實是同一件事

排在一起看：

• 先定義 → 你得把判準寫下來
• 看得見出錯 → 你得留下可以比對的東西
• 說得出理由 → 你得留下版本與依據

三行寫成兩邊的行話就是：你們叫它 spec / logging / owner，醫院叫它稽核條目／護理紀錄／誰簽名——差別只在字面。

三件事在要求同一個動作：把原本只存在於某個人腦子裡的東西，搬到系統外面，變成看得見的東西。 這句話你們也講——只是講的時候用的字是 externalize state：一個服務把狀態放在記憶體裡，跟把狀態寫進 log／DB／event stream，本質上是同一支服務——差別在於它出事的時候有沒有人接得住。判斷這件事一樣。

品質管理這幾十年一直在做這一件事。它處理的對象本來是人——人會不一致、人會忘記、人會離職、人說不清楚自己為什麼這樣判。所以品管圈才要開共識會議，稽核判定才要送品質委員會核定，判準才要有版次、有生效日、有作廢章——這一整套機制的功能，跟你們的 config management、CI 上的 approval gate、release 前那份 changelog，一模一樣。都是把個人腦子裡的決定，變成有 diff、有簽名、有時間戳的產物。

現在對象換成模型。模型也會不一致、也會漂移、也會說不清楚自己為什麼這樣判——差別只在於它不會離職，但會靜默升級，而升級的效果跟離職差不多。

工具沒變，因為問題沒變。

品管圈為什麼要開年度審視、稽核小組為什麼要每季重看一次條目、品質委員會為什麼要有外部委員——理由都在這一句裡。而這些機制的技術版本，你們每天也在跑：每季的 architecture review、on-call rotation 的交接會、換 vendor 之前那份風險評估。名字不同，處理的都是「一群會出錯的東西一起工作」這件事。

回到那位開發者的問題：等模型夠強了，這些是不是就不用做了？

不會。因為這三件事處理的從來不是「模型不夠強」。它們處理的是「判斷這件事本身，需要被寫下來、被看見、被負責」。這個需求跟模型的能力無關，跟有人會因為這個判斷受影響有關。這也是為什麼你們那條 code review 的規矩、那份 postmortem 的模板、那個 PR 上必須要有 approver 的機制，模型再強都不會廢掉——它們處理的一直不是「工程師夠不夠強」，是同一個問題的另一種形狀。

只要還有人會因為這個判斷受影響，這三件事就不會過時。

如果你只帶一句話走

Day 1 的最後我留了一句話：

你會做的自動化，處理的是規則寫得下來的事。這 30 天談的是規則寫不下來的那一半。

到最後一天，我想修正它。

那一半不是「規則寫不下來」。是「規則沒有被寫下來」。

差一個字，差很多。

「寫不下來」聽起來像能力的極限，像是一件沒辦法的事。但這段時間實際去撞過之後我發現，大部分寫不下來的判準，並不是真的寫不下來——是從來沒有人被要求把它寫下來。

因為一直有人可以直接做出那個判斷，所以不用寫。這個判斷靠的是資深、是經驗、是那句「這個要老手才看得出來」。稽核小組裡最資深的那位護理師打開一份病歷、指著紀錄裡某一句說「這樣不行」的時候，她不是在讀條目表，她是在對一個從沒被寫下來的規則。Day 1 我說過，你們叫它靠 sense，我們叫它專業判斷，是同一件事：判準存在，但沒有被寫下來。

而更精確的機制，我後來才想通：

你給 AI 的判準，永遠比你以為的少。你以為你講清楚了，其實你只講了最後想到的那一條。

這件事你們比誰都清楚——寫 prompt 是這樣，寫 spec 是這樣，寫 issue 給另一個團隊也是這樣。你在腦子裡跑過 20 條規則，寫下來的只有 3 條，剩下 17 條你以為「這應該不用講吧」。收到指令那一端不管是模型還是新來的同事，都會拿著那 3 條做出你完全沒預期的東西——然後你才想起第 4 條、第 5 條。判準從來沒少過，只是每次都要撞過才會浮出來。醫院裡帶新人也一樣：新人做錯一件事，你才想起來自己從來沒告訴過他這件事該怎麼做，而過去二十年你都是「順手就做了」。

那 LLM 到底做了什麼？

它沒有讓判斷變得不需要。它做的是一件更小、但影響大得多的事：

它第一次讓「把判準寫下來」這個動作有了回報。

以前你把判準寫得再清楚，最後還是人在讀、人在判。寫下來只是多做一份文件，放進資料夾，沒有槓桿。

現在寫下來的判準會被執行、會被重跑、會被驗證、會在模型換版的時候告訴你標準悄悄位移了。它像 CI 一樣，在每次 commit 上生效；它像一份 test suite，跑得越勤，越接近你腦子裡真正的規則。這是我做這行以來第一次，寫判準的人的工作是有槓桿的。

所以如果這 30 篇你只帶一句話走，我希望是這一句：

AI 沒有替你做那些規則寫不下來的判斷。它只是讓你第一次有理由，把它們寫下來。

順帶一提，這段時間下來，我在自己的品管圈開會、跟稽核小組討論條目、跟單位主管解釋為什麼那份稽核判定要那樣寫——這些會議的內容都變了。不是因為 AI 讓我們變聰明，是因為它逼我們把過去只在會議室裡口頭達成的共識，變成一份可以指的文字。走廊上那句「這個要老手才看得出來」，第一次有了讓後面接手的人也看得出來的可能。

最後，一個順序

如果你正要把一段靠人判斷的流程交給模型，順序是這樣：

先寫得下來 → 再跑得動 → 再驗得了 → 最後才是團隊敢用。

失敗的專案順序幾乎都是反的：先做一個很好看的 demo，再回頭補判準，最後發現沒有人敢在上面簽名。這種順序你們也見過——POC 先跑起來、之後 spec、之後 test、最後補 SRE runbook。「敢在 prod 用」永遠是最後一步，而它取決於前三步做的紮不紮實。

四個階段，只有第二個是技術問題。而失敗幾乎都發生在另外三個。

三十篇到這裡結束。

醫院的品質管理累積了很多方法：電子查檢表、共識會議、簽核流程，以及跨單位的改善追蹤。但它處理的問題——一群必然會出錯的東西一起工作，要怎麼讓錯誤在造成損害之前被看見，而且不要吵到讓人把警報關掉——正好是你們現在在處理的問題。

而這些工具沒有一樣是醫院發明的。我們是從製造業借來的，只是借過來之後，被一種「判錯了會有人受傷」的壓力磨過一輪。

如果這 30 篇裡有任何一篇，讓你想起自己系統裡的某一段流程，那它就達成目的了。而如果你正好是那位開發者——那個問我「模型夠強了這些是不是就不用做了」的年輕人——這 30 篇就是那個答案的完整版：不會，因為那些規則從來沒有真的寫下來過。你會做的自動化，會逼我們去寫；而我們寫的每一條，會讓你的自動化第一次有一份可以對得回去的規格。

謝謝你讀到這裡。