醫療 AI 的可靠，取決於它出錯時能不能停下來
前幾天在看 OpenClaw 2026.6.6 的 release notes，很多人在討論 OpenRouter 的整合和新功能。但從臨床的角度來看，我反而更在意幾個看起來沒什麼的細節：fail-closed 邊界、authorization timeout、malformed input 的處理，還有 Telegram unauthorized DM 不進 prompt context 這些東西。
這些看起來像小修補，我更把它們當成系統壞掉時的防線。
我在醫院跑的那套邏輯是這樣的：任何高風險流程，我都會先問兩件事，它能做到什麼，它出問題的時候傷害有多大。後者通常更重要。
舉三個這次更新裡具體的設計，給大家感受一下。
第一個是 transcript、sandbox、MCP、browser 這些路徑，全部 fail closed。意思是只要碰到不確定的邊界狀況，它會直接停下來，不會先猜一個繼續跑。這個看起來很理所當然，但其實很多系統做不到。很多系統的預設行為是 fail open，也就是邊界模糊的時候先放行，之後再說。在一般軟體場景這或許 OK，但如果你想把這套東西接到任何跟病人資料有關的系統，fail open 就是一個根本性的問題。
第二個是 exec approval timeout 走 safer path。就是你給了授權，但授權超時了，它不會繼續執行，會退回比較保守的路徑。這個邏輯在臨床裡叫做「最小授權原則」，授權是有時效的，逾時就要重新確認，不能因為「以前准過」就永遠都准。醫院裡開刀授權書每個術式都要重新確認，精神是一樣的。
第三個是 Telegram unauthorized DM 的文字，不進 cache，也不進 prompt context。這個設計的意義在於：就算有人試圖從側邊管道注入資訊，這條路是堵死的，不會變成「先警告一下，內容照樣讀進去」。在醫療資訊系統裡，這類設計對應的是「未授權的外部輸入不得污染主流程」，聽起來廢話，但做到的系統真的不多。
這三個設計放在一起，我看到的是一套「出錯的哲學」。
社群上有人在討論 2026.6.5 stable 不 stable 的問題，有個觀點我覺得抓得很準：stable 不只是少 crash，而是「錯誤可預期，邊界清楚」。這個定義放到醫療場景，差距就更大了。
我來做一個具體的比較：模型答錯，vs 系統邊界失守，哪個在醫療場景裡更嚴重？
大部分人的直覺是「模型答錯更嚴重」，因為那是看得到的錯誤。但我認為系統邊界失守才是真正危險的那個，原因很簡單：模型答錯你可以稽核，可以設計 double-check 機制，可以要求人工確認。但如果系統邊界失守，你連「哪裡出問題了」都不一定知道，因為它可能靜默地做了一個看起來沒錯但實際上越界的事。
在臨床裡這叫做 latent failure。它不會立刻爆開，而是累積在系統裡，等著某一天被觸發。一個護理師輸入錯誤劑量，系統沒攔，紀錄進去了，幾個小時後才發現，但流程記錄已經是「正常執行完成」。這類事故的根源，很多時候是邊界沒守住，不只是模型判斷錯。
這也是為什麼我對 fail-closed 設計這麼在意。聰明的模型很多，但「壞掉的方式可預期」的系統很少。如果哪天真的要在高風險醫療流程裡部署 AI，我第一個看的不會是 benchmark，是它的 error handling 設計。
不過老實說，2026.6.6 這些安全邊界的設計，現在對大多數使用者的日常體感影響不大，因為你很少真的碰到那些邊界。但這個邏輯跟我們在臨床評估設備安全性時一樣：平常用不到應急機制，不代表應急機制不重要。那些設計是在你最需要它的時候才會出現的東西，而那個時候通常就是你最不希望它出問題的時候。
有在做高風險 AI 應用的人，醫療、法律、金融都算，這次更新的安全邊界設計值得認真看一下。它反映的是一套對「可靠性」的定義，跟單純堆功能的邏輯差很多。
作者：陳逸 Dr.