大多數醫療 AI 的方向
2026 年，任何一家醫療 AI 供應商的 demo 流程大致相同：醫師對著麥克風說話，AI 轉譯、結構化成 SOAP（Subjective／Objective／Assessment／Plan，病歷四段式：主觀／客觀／評估／計畫），AI 草擬醫囑、帳單碼、出院摘要，AI 寫進 EHR（Electronic Health Record，電子病歷）。醫師離開去吃飯。
這個流程的價值訴求是效率。背後的假設是：只要模型「夠準」，醫師就可以脫離 loop。
iRehab Doctor AI 技術上做得到每一個步驟。我們選擇不這樣接——不是因為技術不成熟，而是因為這個流程所交付的東西，其實不是醫師真正需要的。
真正的臨床需求：壓縮問診，不是整合表單
醫師能開始寫任何文書之前，得先把眼前這位病患「解碼」。病患很少帶著結構化的主訴走進診間。他們帶進來的是一段洪流——這邊痛、那邊麻、上次的藥不知道有沒有效、女兒提過他睡不好、順便擔心一下另一邊膝蓋。
每一個次專科都有自己壓縮過的 schema，指向真正重要的那幾件事。骨科大致收斂到四格：哪個部位、症狀多嚴重、是外傷還是退化、持續多久。家醫科是主訴、發作時間、嚴重度、紅旗警訊。腫瘤科是腫瘤型別、分期、治療史、目前走勢。欄位不同，模式一致。這幾格一填上，診斷的假設就在醫師腦海中自己成形，下一步的處置——影像、打針、轉介、衛教——幾乎是自動地長出來。
門診 15 分鐘裡，前面 5 分鐘通常不是臨床推理，是翻譯——把病患口語的洪流，壓縮成該科真正在用的那四、五格。
這個翻譯步驟，才是 AI 應該承擔的事。不是幫忙寫出院摘要，不是產出帳單碼。而是把病患過去兩週的回報——VAS（Visual Analog Scale，視覺類比疼痛量表 0-10）趨勢、傷口照、運動紀錄、PROM（Patient-Reported Outcome Measure，病患自述結果量表）分數——在病患坐下前的那兩分鐘裡，壓縮成一段該科相關的摘要。
在 iRehab 上，醫師螢幕上看到的會是這樣（POD＝Post-Operative Day 術後第 N 天）：
POD 14，右膝。VAS 6 → 3。家屬 3 天前拍的傷口照——輕微紅腫。昨天完成 70% 的運動處方。
四格，五秒讀完，診斷成形。剩下的十分鐘屬於病患。
iRehab 實際蓋了什麼：翻譯機，接上確認者
iRehab Doctor AI 是兩層架構，順序明確。
翻譯機層。看診前，系統把病患過去兩週的 longitudinal（縱向）回報資料——症狀日誌、VAS 趨勢、傷口照、運動完成率、PROM 分數——壓縮成該科相關的摘要。我們不整合表單，我們整合上下文。醫師打開 Doctor PWA（Progressive Web App，漸進式網頁應用）看到的不是 37 個欄位的模板，而是一張四格臨床圖，再加上以它為基底的 AI 建議 SOAP 草稿。
確認者層。醫師讀 draft、改需要改的字、按確認。只有這一次確認，才能把 draft 變成 record。
翻譯機承載 user value（使用者價值）——五秒讀完，取代掉要花五分鐘解碼病患口語的那段時間。確認者承載 accountability（問責）——最終的臨床判斷還是由人做出。兩層都是承重牆，拿掉任何一層，這個產品在臨床上就不合理了。
產業的習慣反射是把這件事講成一個 tradeoff：自動化程度 vs. 安全性。我們不這樣看。翻譯機的存在理由是把起點抬高，確認者的存在理由是把終點留給人。兩層做的是不同的事，不是彼此的摩擦。
Draft-Only Enforcement——翻譯機的護欄
翻譯機既然這麼有用，合理的下一個問題是：AI 能不能把確認步驟也省掉？我們的答案是硬性的不行。這條限制在產品層以強制規則實現，我們稱之為 Draft-Only Enforcement（草稿限定原則）：
任何由 AI 產出的醫療文書都標記為 draft。除非具執照的醫師手動按下確認，draft 永遠不會進入病人的 official record。
實際意義：
- AI 可以產生評估、處方、手術記錄、帳單——但不能送出。
- AI 可以填欄位、整理上下文、提供最佳起點——但不會自己寫進 EHR。
- 文書不能一步存檔。Draft → Confirm 是兩個動作，不能合併。
技術上這是一條微不足道的限制。困難不在工程，在每一季模型變得更準、每一個產品直覺都想把第二步拿掉的時候，我們能不能堅持留著。
因為當 Draft → Confirm 被合併成單一動作的那一刻，臨床責任鏈不是被弱化，是被切斷。而臨床系統的韌性，完全活在那條鏈的完整性裡。
這條規則背後還有一層原則。如果有一天 AI 能完全取代醫師寫病歷、開處方、動手術——那就不只是技術的進展，還意味著「醫師」這個受執照、受問責的職業本身正在被重新定義。我們不認為技術已經到了那一步。我們也希望，那一天不要太快到來。
「整合」可能指的三種事
醫師要求「文書整合」時，通常是三種意思中的一種。看清楚這三種都不是真正的答案，「翻譯機＋確認者」這個形狀反而會自己浮現出來。
整合 = 自動化。「全部幫我寫，我完全不碰。」最後那份文件上掛著醫師的名字，醫師卻沒讀過。責任鏈名義上完整，實際上已斷。
整合 = 單一表單。「把所有欄位放在一個畫面，我不必切 tab。」Cerner 和 Epic（美國兩大 EHR 系統）做了 30 年。欄位數增加，打字時間沒下降。真正的挑戰——每一次看診的認知負荷——不是 UI（User Interface，使用者介面）排版能解決的。
整合 = AI 寫完 = 完成。最深的一層想像。醫療文書不是交付物，是一次臨床判斷的證據記錄。「medial meniscal tear post-repair（內側半月板撕裂修復後），考慮 MRI follow-up」這句話的價值，在於一位具名醫師把自己的執照放進去了。如果 AI 寫、醫師沒讀就簽，這段紀錄剩下的只有字句，沒有證據重量。
醫師真正需要的不是合併表單，是五秒抓到重點。翻譯機，接上確認者。
過度生成：真正的失敗模式
看夠多臨床 AI 的 demo，會發現一個模式。大家焦慮的通常是模型「還不夠準」。實際在臨床現場浮現的失敗模式卻是反方向的：過度生成 (over-generation)。病患丟進來一段碎語——三個不同主訴、家屬順口提的一句、關於另一個關節的離題——模型把它擴寫成流暢、結構完整、文法漂亮的散文。產出讀起來很美，卻浪費醫師的時間。
門診的節奏不獎勵作文。15 分鐘的診，醫師沒有空在優雅段落裡挖「推進決策的那三四格」。資深主治在病歷邊角寫的那種縮短、夾雜縮寫的短句——不是寫作風格的偏好，是受過訓練的臨床眼睛最快能讀進去的格式。
iRehab 的看診前草稿因此以雙格式輸出，電報體 (telegraphic shorthand) 為預設。通順版保留給文件匯出。病患坐下前醫師真正用的那個畫面，第一眼載入的是電報體——四格、一行、enum 代碼原樣保留，讓醫師讀的是臨床訊號，不是完整句子。
過度生成是 AI 產業的自然反射——對不在診間旁邊的產品團隊來說，輸出更長等於更有價值。在臨床上，這個反射是錯的。壓縮問診不只是把輸入縮短。是拒絕在輸出端又鋪開。
把原則往上游推
Draft-Only Enforcement 本來是為了保護醫師。它正在變成對病患也成立的保護——同一條「AI 未經醫師確認就不能送出病歷」的規則，同時也意味著「AI 未經病患確認就不能送出代他寫的問診摘要」。
責任鏈不是只保護醫師。它保護系統裡的每一個關節。
結語
醫療 AI 的主流方向是把醫師的工作壓成一步：AI 寫完，人類簽名。iRehab 把同一件事拆成兩層，各司其職。翻譯機的職責是在看診前幾分鐘，把幾週的病患回報資料萃取成該科相關的訊號。確認者的職責是把最終的臨床判斷——以及背後那張執照——留給人。
AI 翻譯。人類確認。第二步不是摩擦，是第一步得以安全的原因。
這篇以術後追蹤為主——病人有多週 longitudinal 資料可供壓縮。初診的 case——沒有歷史、只有一句口語主訴、而且不能問臨床訓練才能答的題——寫在姊妹篇：診前簡報：當病人答不出「是肌腱還是神經」。