前幾篇文章談了很多觀念——Trust、Risk Management、Human-in-the-loop、Cognitive Load。但觀念如果只停留在文章裡，它就只是觀念。

所以這一篇，我想把視角拉回我自己的實作：我如何在設計醫療人員的 Decision Support System（DSS）時，把 AI 同時當成「研究工具」、「溝通工具」與「原型工具」，並且在過程中實踐前面四篇談到的設計原則。

醫藥領域的未來，除了「AI 幫醫護人員做判斷」，還有更前面的一層：「AI 幫助設計者理解醫護人員，再幫助醫護人員理解自己的決策情境」。這兩層協作，缺一不可。

第一層協作：用 NotebookLM 消化訪談與現場觀察，讓研究資料自己說話

設計 DSS 的第一個難題是理解，畫面反而是後話。

醫療現場的工作流程極度複雜：藥師的處方核對有多重確認機制、護理人員的給藥流程夾雜大量任務切換、醫師的決策情境隨科別與病況變動。要理解這些，唯一的方法就是訪談與現場觀察。但研究做完之後，真正的挑戰才開始——訪談逐字稿、觀察筆記、流程照片的文字紀錄，加起來是一座資料山。

我的做法是把所有訪談逐字稿與現場觀察紀錄餵進 NotebookLM，並且刻意限制它只能使用 RAG（Retrieval-Augmented Generation），不允許它引用來源以外的知識。

這個限制非常重要，原因有二：

第一，醫療領域是幻覺（Hallucination）代價最高的領域之一。如果 AI 在整理訪談時「腦補」了一段藥師沒說過的話，而我基於這段話做了設計決策，那麼錯誤會一路傳遞到最終產品。限制 RAG 之後，NotebookLM 的每一個回答都必須附上來源段落，我可以隨時點回原始逐字稿驗證。這其實就是 Day 13 談的 Trust 原則，只是這次的使用者是我自己：AI 的建議從哪裡來、有哪些證據支持，必須永遠可以被追溯。

第二，RAG 讓我可以跨資料源提問。例如我問：「藥師與護理人員對於警示訊息的抱怨，有哪些共同點？」NotebookLM 會從不同場次的訪談中撈出相關段落並列給我看。這種跨來源的模式比對，靠人工翻筆記可能要花上好幾天，而且很容易漏掉。AI 在這裡承擔的是資訊聚合，判斷仍然留在我身上。

這正是 Day 16 談的認知負荷原則的自我應用：讓 AI 降低「找資料」的成本，把省下來的注意力花在「理解資料」上。

第二層協作：把複雜的用藥基準，轉化成看得懂的設計參考文件

理解使用者之後，下一個難題是理解領域知識本身。

DSS 要處理的核心內容之一是用藥相關基準：劑量上下限與調整規則、交互作用等級、高警訊藥品（High-Alert Medications）的特殊流程。這些知識散落在藥典、院內規範與醫囑系統的邏輯文件裡，格式生硬、彼此交錯，連我這個設計者都需要反覆查閱才能建立完整的心智模型。

我把這些基準文件也放進 NotebookLM，請它將複雜的觀念轉化成結構清晰的簡報，作為系統設計說明的參考文件。例如把「劑量調整邏輯」整理成一頁決策樹，把「交互作用嚴重度分級」整理成分級對照表。

這份簡報有兩個用途。對內，它是我和藥師、工程師、設計師等溝通系統邏輯的共同語言——大家看的是同一份被整理過的知識，避免各自解讀原始文件產生落差。對外，它在與藥師確認需求時，成為快速驗證「我理解的規則是否正確」的工具。藥師看一頁決策樹，十秒鐘就能指出「這裡不對，我們院內的門檻不一樣」。

這裡有一個微妙但關鍵的態度：AI 整理出來的領域知識，永遠停留在「待驗證的草稿」階段。 每一份由 NotebookLM 產出的簡報，都必須經過領域專家核對後，才能進入設計規格。這就是 Human-in-the-loop 在設計流程裡的版本——人介入的時間點被提前到知識固化成系統邏輯之前，遠早於最後那一下 Confirm。

設計決策一：Dashboard 除了呈現資料，還要教人怎麼用它

進入介面設計之後，我做了一個看似很小、實際上改變產品定位的決策：

每一張 Dashboard 圖表，都加上「如何使用這張圖表」的提示。

例如一張顯示病人近七日檢驗數值趨勢的圖，旁邊除了圖例，還有一段情境化的說明：這張圖在什麼時候應該看、趨勢下降到什麼程度需要考慮劑量調整，以及這張圖「看不到什麼」。

這個決策的背後，是 Day 13 與 Day 16 的交會點。

一個只呈現資料的 Dashboard，是把「解讀」的認知成本全部留給使用者；而醫護人員在時間壓力下，最缺的就是解讀的餘裕。當圖表本身能夠說明自己的用途、適用情境與限制，它就從一個「資料視覺化元件」變成一個「決策支援元件」——這正是 Dashboard 成為 DSS 的分界線。

同時，「這張圖看不到什麼」的提示，是 Uncertainty Communication 的具體實作。與其讓系統看起來全知全能、誘發 Automation Bias，不如誠實地標出邊界，讓使用者知道什麼時候該回頭查原始資料。

設計決策二：用 Antigravity 快速產出 Prototype，讓設計啟示進入 A/B 測試

觀念要被驗證，就需要可以被測試的東西。

過去，從「研究啟示」到「可測試的原型」之間有一段漫長的路：畫 Wireframe、做 Mockup、串 Prototype，每一個設計假設都要花上數天。這導致一個常見的妥協——我們只測試「最有把握的那一版」，放棄了「最值得比較的那幾版」。

其實可以改用 Antigravity，針對每一個從研究資料中提煉出的設計啟示，直接生成對應的互動 Prototype，拿去做 A/B 測試。

例如，訪談資料顯示藥師對警示的抱怨集中在「打斷工作節奏」，由此產生兩個對立的設計假設：警示應該即時彈出（確保不遺漏），還是應該聚合在核對節點統一呈現（保護工作節奏）？過去這種假設之爭，往往在會議室裡靠嗓門決勝負；現在我可以在很短的時間內產出 A、B 兩版可操作的原型，讓真實的藥師在模擬情境下各走一次流程，用行為資料說話。

AI 在這裡真正改變的是驗證的密度。當產出原型的成本趨近於零，設計決策就可以從「經驗與直覺」逐漸移向「證據」。對高風險場域來說，這件事的意義遠大於省時間——因為每一個沒被驗證就上線的設計假設，都是一個潛在的風險點。

設計決策三：把所有警示排進一張大表，做重要性排序

最後，回到 Day 13 提過的 Alert Fatigue 問題。

多數醫療系統的警示，是隨著功能一個一個長出來的：交互作用警示、劑量警示、過敏警示、重複用藥警示、給藥時間警示……每個警示在被加入的當下都有正當理由，但沒有人從整體的角度問過：當它們同時存在時，使用者一天到底會被打斷幾次？哪些警示值得打斷，哪些不值得？

所以在設計 DSS 的警示機制之前，我做了一件很土法煉鋼、但我認為必要的事：

把系統內所有可能出現的警示，全部排進一張很大的表格，逐一做重要性排序。

表格的欄位包含：警示觸發條件、對應的臨床風險等級、誤報的可能性、遺漏的後果，以及它應該以什麼形式呈現（阻斷式彈窗、非阻斷提示，還是聚合到核對清單）。排序的依據只有一個：如果這個警示被忽略，最壞會發生什麼事。

這張表本身就是一份 Risk Management 文件。它逼著整個團隊面對取捨：只有極少數警示配得上「阻斷式彈窗」這個最昂貴的注意力貨幣；大多數警示應該退到背景，聚合呈現。而這張表也成為日後審視系統的基準——每當有人想新增一個警示，就必須回到這張表，回答它排在哪裡、憑什麼打斷使用者。

把四個原則，落回四個實作

回頭看，這次的實作其實就是 Day 13 到 Day 16 四個觀點的落地：

Trust 落在 RAG 的來源限制與 Dashboard 的邊界提示——每個 AI 產出都可驗證，每張圖表都誠實說明自己看不到什麼。

Risk Management 落在那張警示排序大表——在設計介面之前，先設計風險的優先順序。

Human-in-the-loop 落在整個設計流程——AI 整理的知識必須經過藥師驗證，AI 產出的原型必須經過真實使用者測試，判斷永遠留在人身上。

Cognitive Load 落在圖表使用提示與警示聚合——系統的真正目標，是降低做出高品質決策所需的認知成本。

而貫穿這一切的，是一個我越來越確信的觀點：設計醫療 AI 產品的人，自己就是第一個 Human-AI Collaboration 的實驗場。 如果我在設計流程中都無法建立與 AI 之間可驗證、可質疑、可推翻的協作模式，我又憑什麼相信自己能為醫護人員設計出這樣的系統？

小結：從醫療走向災害應變

醫療給了我一個協作模式的雛形：AI 負責聚合與生成，人負責驗證與決定；系統則負責讓每一次介入都可以被追溯—— AI 看到了什麼、建議了什麼、人做了什麼、哪些資訊影響了最後的決定。

醫療只是高風險場域的其中一種。下一章，我想把這套思路帶進一個更極端的情境——災害應變。

當時間以分鐘計算、資訊永遠不完整、決策的代價以生命衡量，人與 AI 的協作還能怎麼設計？

第四章｜災害應變：當 AI 成為協作的基礎設施，下一篇見。