場景：成果發表會一年後，那條指標掉回原處

某個單位做了一輪品管圈，題目挑得好，對策也做對了，指標在三個月內拉起來，成果發表會上大家都很高興。

一年後，單位在追蹤報表裡看到那條指標掉回原來的位置，品管團隊再與單位一起檢視。

問單位怎麼回事，答案通常是兩句話的其中一句：「那個做法後來就沒人做了」，或者「當初帶的那位學姊調走了」。

改善沒有失敗。改善成功了，然後蒸發了。

這是品管最常見的死法，常見到有經驗的圈長都會在成果發表那天就先講一句「接下來要標準化」。而我一直以為我很清楚這件事——直到我發現我自己在 AI 流程上，原封不動又做了一次。

我的版本：紀錄一條不缺，但一年沒有人讀過整份

某次調整之後，AI 跑出來的稽核結果團隊接受度變高，退回的比例降下來，會議上大家覺得這東西終於可以用了。

團隊共用的判準文件其實不亂。Day 8 就把判準寫成一條一條的條目，每一條都有變更紀錄：誰改的、改了什麼、為什麼改。那份紀錄的形狀跟一份 commit log 沒有兩樣，而且是這個專案第七天就做掉的事，各次修改也持續留有紀錄。

問題出在別的地方。

那天要跟委員解釋這一版判準到底比去年嚴格還是寬鬆，我打開變更紀錄往下捲。二十幾筆修改，每一筆都寫得清清楚楚，每一筆單獨看都合理：這個月發現某一類案例判錯了，補一句話擋掉；下個月又冒出另一類，再補一句。

捲到底的時候我發現一件事：我答不出來。

不是因為紀錄不夠。是因為沒有任何一個時刻，有人被要求把這份判準從頭到尾讀一遍。變更紀錄記得住每一次改動，記不住這些改動疊起來變成了什麼。

品管圈那條掉回去的指標，跟我這份說不清楚整體立場的判準，是同一種失效——都發生在 PDSA 的最後一個字母上。

品管的 A，動作只有兩個

PDSA 的最後一步是 Act，中文常翻成「行動」或「處置」。這個翻法害了很多人，因為它聽起來像一句開放式的鼓勵。

實際上這一步只有兩個分支，沒有第三個：

• 有效 → 標準化。寫進 SOP、改表單、改流程、改系統，讓它變成常規
• 無效 → 回到 P，重新規劃

「繼續努力」「持續推動」「加強落實」不在選項裡。它們是 A 的失敗形態，也是我看過最多的一種——成果發表完，對策就停在那份圈報告裡。

你們有一模一樣的東西：那份 incident 檢討做得很扎實、action item 列了六條，三個月後一條都沒有進 backlog。

A 不是繼續努力，是寫成 SOP。

而品管講的標準化，比大部分人想的嚴格。它不是「寫一份文件」。標準化的驗收條件是：

那個做法要變成不做才費力的預設。

這個門檻很高，高到可以拿 Day 13 那套行動強度去量它：一份純粹的 SOP 其實落在弱效那一格——它跟教育訓練、跟宣導同一級，因為它依賴人記得去讀、記得去做。真正的標準化落在強效那一格：把做法做進系統，變成護理紀錄表單上的必填欄位、變成流程的下一步、變成不填就送不出去。

醫院對這件事並不陌生，我們有龐大的 SOP 體系。問題是我們長期把「寫進 SOP」當成 A 的終點，而它其實只是 A 的最低標。

改善不寫進制度，它的半衰期就是人員異動週期。

醫院有一個東西，git 沒有

這一節是我覺得整篇最值得寫的一段，而且方向跟前面二十幾篇是反的——不是我從你們那裡借東西，是醫院這邊有一個現成的機制，而你們的版控系統剛好沒有。

醫院的文件管制制度長這樣：每一份 SOP 有版次、有生效日、有發行對象、有作廢章，還有一項——定期審閱。每份文件到期（通常是幾年一次）就必須有人整份讀過、簽署「仍適用」或提出修訂，沒簽的文件會在評鑑的時候被挑出來。

這件事醫院做了幾十年，做得很煩，而且大家都覺得它是形式主義。

但把它放到稽核判準那份檔案上，它剛好補掉一個 git 補不掉的洞：

git 記得每一次 diff，但它沒有任何一個機制，會強迫你回頭讀整份。

版本控管解決的是「這一行是誰改的」。定期審閱解決的是另一個問題：這些改動加起來，現在整份文件到底在說什麼。

而後面這個問題，正是判準真正的死因：

你的判準不會爛在某一次的大改，會爛在十次小補。

每一次都是合理的、局部正確的修補。補到第十次，那份判準變成一份自相矛盾的文件——早期寫下的一條原則，跟後來為了某個病房補上的一條特例，實際上互相牴觸。而模型不會跟你抱怨這件事：它會照自己的優先序處理掉，通常是偏向後面的、偏向最具體的那一條。

於是你的判準悄悄變成了「最近半年補丁的集合」，而不是「你原本想要的那套標準」。這是另一種漂移，來源是你自己，而且它沒有換版日期可以查（Day 26 那三種來源的第三種，就是它）。

明天上班就可以做的一件事：翻出你手上那份已經部署在正式流程裡的 prompt，在行事曆上給它訂一個「整份重讀」的日期。 不是提醒你去改它，是提醒你去讀它——讀的時候只回答一個問題：這半年補上去的東西，有沒有跟前面某一條打架。

這項檢視要排進品管與資訊的共同作業時程，跟盤點指標同一個週期，並指定彙整與核准的角色。它不產出任何東西，而它是這一篇唯一一件我很確定有用的事。

文件管制順便解掉的兩個問題

一、什麼算大改，什麼算小改。

文件管制本來就有這個分野：實質變更要重新核准並跳版次，編輯性修正不用。搬到判準上，界線非常乾淨，而且不是看改了幾個字：

這次改動，會不會讓同一份輸入得到不同的判定？

會，就是實質變更，哪怕你只動了一個字。不會，就是編輯性修正，哪怕你重寫了整段。判準條目的定義動了、閾值動了、例外條款動了，都是實質變更；把「應該」改成「須」、把段落順序調過來，不是。

版本號要跟著輸出行為走，不是跟著文字長度走。

二、生效日，以及舊版怎麼作廢。

SOP 改版有生效日，不是「改完就生效」。這件事在醫院是硬規定，因為現場同時流通兩個版本會出人命。

判準也一樣，而且問題更尖銳：這個月的稽核已經跑掉一半，改判準之後，剩下那一半算哪一版？兩半混在同一張報表上，那張報表就沒有意義了。所以生效日只能落在批次邊界，不能落在「我改完存檔的那一刻」——不然你拿到的是一張一半新版、一半舊版的報表，跟一次沒收乾淨的 deploy 是同一種東西。

作廢那一半更容易被跳過。電子文件改版時，文件管理系統要標明生效版本、停用舊版入口；但一個 prompt 檔改完之後，舊版還可能留在執行環境裡，而且它還跑得動——只要排程仍指向那個路徑。品管端的文件版次更新了，資訊端的執行設定也得同步核對。

判準是受版控的產出物，不是設定值

這件事我跟資訊室的老周談過。他管版控與部署，判準是品管室訂的，中間那條線從來沒有人畫過——而摩擦就發生在那裡：版控在他們眼裡是給程式碼用的，prompt 比較像「設定」或「文案」，於是它很自然地被放進一個不受版控的地方。

我用的說法只有一句：

這段文字決定了系統的輸出，那它就是程式碼。

它有版本、有相依性、有 breaking change、改壞了會出事、需要有人 review。它唯一不像程式碼的地方，是它長得像中文。

從這句話推下去，有一件事非做不可：每一筆輸出都要帶版本戳。

每一筆 AI 判定存下來的時候，要一起存：用的是哪一版判準、哪一個模型版本、跑的是哪一份資料快照。

為什麼？因為三個月後品質委員會會問：「上次那份報告是怎麼算出來的？」

那不是刁難，那是委員會的職責。而如果你答不出來，那份報告就不能拿來當決策依據——說不出用哪一版判準跑的結果，就沒有辦法對它負責。 Day 1 講的「可歸責」，技術前提就在這裡。

而 Day 1 的另一條「可重現」，答案也在同一個地方。要回答「為什麼這次結果不一樣」，你手上必須同時握著三樣東西：

三樣要一起，缺一樣整組就失效——因為它們的用途不是各自記錄，是互相排除。Day 26 那三種漂移來源要怎麼分辨？就是靠這個：把兩個固定住，剩下那個就是變因。

還有一件事要寫進驗收條件，而且要在上線前就講清楚：我們要的不是逐字重現，是判定重現。 同樣的輸入，判定結果要一樣；理由的措辭可以不一樣。不先講，第一次有人重跑、發現措辭不同，整套系統的信任就沒了——而那其實是預期行為。

三天串起來，才是一個圈

Day 25 的抽驗流程、Day 26 的基準集監測、今天的版本管理，單獨看都只是三個工具。串起來才是一條線：

改判準
  → 自動在開發案例池上重跑
  → 產出與前一版的差異報告
  → 人核准（誰簽名）
  → 訂生效日，登錄版次，舊版作廢
  → 之後每一筆輸出帶版本戳
  → 每週期重跑基準集，畫上管制圖
  → 超界 → 回到「改判準」
  → （另外，每半年一次：整份重讀）

重跑的是開發案例池，不是基準集。這條界線 Day 26 講過，這裡再說一次是因為它最容易在實作的時候被合併掉：改判準的時候手邊最順的那組案例，往往就是你拿來監測的那一組。合併的那一天，你的監測就變成裝飾了。

這條線畫出來之後，你會發現它繞成一個圈。

那個圈就是 PDSA。差別只在於，過去這個圈的每一步都靠人記得，現在有幾步可以自動跑了。

而這正是本篇一開始那個門檻的答案：

能被自動觸發的那幾步，才是真的被標準化了。其他的都還只是文件。

只有最後一步例外——那個「整份重讀」不能自動化，因為要判斷的正是這半年的補丁疊起來變成了什麼，而那件事沒有任何一個排程做得到。它唯一能被標準化的方式，是排進行事曆，然後有人簽名。

這就是為什麼醫院的文件管制到今天還是那麼土：它管的東西，剛好是自動化管不到的那一格。