如果要快速總結我這幾年的工作，我會說：我持續地在設計那些不能輕易犯錯的系統。
過去幾年，我的工作橫跨 HCI（Human-Computer Interaction）研究、產品設計、數據與 AI Prototype。

我參與過國家級的運動科學平台，導入 AI labeling system，協助教練從大量數據中快速找到真正影響表現的關鍵；參與醫療藥品管理系統，思考如何降低藥師與護理人員在高壓工作流程中的認知負荷；也投入過災害應變相關的人機協作研究，探索不同角色如何共享資訊、協調資源。

另一方面，商業上我也設計過服務數百萬使用者，高流量、高轉換的即時互動產品，持續研究 AI 如何降低資訊摩擦力，幫助用戶在幾秒內做重要的決策。

這些專案看似來自完全不同的領域，但回頭看，我發現它們始終圍繞著同一個問題：

如何運用科技，幫助人在資訊過載、時間有限且充滿不確定性的情境下，做出更好的決策？

而為什麼我特別關注高風險場域的 AI 應用？
高風險場域與其他領域又有什麼不同？

要從一場災害設計與人道救援的工作坊說起。

一場工作坊，改變了我看待產品設計的方式

時間回到 2019 年。那一年，我第一次參加 Open Up Global Summit。其中一場由人道救援組織 Ushahidi 的 UX Designer Eriol Fox 帶領的工作坊，至今仍深深影響著我在應用 AI 到高風險場域時的思路。
Ushahidi 是一家非營利性技術公司，在九個國家擁有員工，其使命是幫助邊緣化群體提高發言權，為那些服務他們的人提供更好的傾聽和回應。它有助於創建肯尼亞科技生態系統，他們的員工已經創建了 iHub，Akirachix 和 BRCK。Eriol Fox 擔任這個組織的設計開源項目主要負責人。

我原本以為，工作坊會從功能發想、流程設計或介面開始，但第一個環節卻是這個起點：Eriol Fox 邀請了當年尼伯特風災真正經歷過災害的人，分享自己的故事。其中有受災居民、有第一線救援人員，也有第一線負責調度資源的救援組織管理者。他們面對的是同一場災難，卻描述著截然不同的世界。從平衡這些混亂複雜的需求開始，我們拼湊出事情的全貌，才去發想能夠平衡各方的解法。

受災居民希望有人知道自己還在等待救援。第一線志工希望快速掌握哪些地方最需要協助。管理者則必須在有限的人力與物資下，了解熱心的志工的技能、擁有的工具，以及決定這些資源該優先送往哪裡。

在這之中，管理者雖然希望整合、共享資源，然而同性質的救災團體，也可能會害怕政治、意識形態立場不同，而不敢公開部分資料。每一個人的需求或多或少有衝突，也有從各自的視角下去的不得已之處。

到底誰是對的？其實兩邊都沒有錯。

如果我們完全貼近管理者的「公開、共享資源」去設計，這些團體就會不敢交出真正的資料，因為有可能被對手攻擊。如果我們完全貼近這些希望資料具有壟斷性的架構去設計，管理者就會永遠無法整合資源，做即時且正確的任務分派。如果我們先上線了具有隱私的版本，卻突然迭代成公開，那將會是一次嚴重的「用戶信任受損」，這也意味著用戶不再信任這個就救災資訊共享服務。這些並不像有些低風險的商業產品，能夠透過下次迭代去挽回的。

那一刻，我突然意識到：
有時候在高風險領域急著 deliver 很多 feature，但也有可能需求之間彼此衝突，毀壞用戶信任。而這將會是一場產品災難。

好的產品，是從理解限制開始

每一位使用者，都站在不同的位置，看見不同的現實。設計，不只是提出一個很有創意的答案，更重要的是理解每一個人為什麼會做出現在的選擇。

當時討論的主題是災害救援當中的 Open Design（設計開源）。開源，就是讓一個問題能夠被了解跟廣泛的討論，而「開源貢獻」，就是當有不同能力的人看到這個需求了，問題就比較能夠經由設計思考產生的Solution 去解決。這就是「開源貢獻」的力量。

當不同背景的人開始一起討論同一個問題，就更有機會找到單一專業看不見的解法。創造也就此誕生。

Eriol Fox 透過 Github Open Issue 去詳細記錄每一個 feature 需要考量的各方角色、他們各自限制、想法，讓。在 Design Open Source 專案中，需求從 GitHub Issue 開始被定義。開源社群會先將遇到的問題、使用情境與改善方向公開整理成 Issue，讓參與者能理解背後的需求脈絡。設計團隊會先閱讀 Issue 內容，釐清使用者、情境與限制條件，再從中挑選適合深入探索的 Design Challenge。透過這樣公開透明的流程，需求不只是由單一團隊決定，而是由社群共同討論、補充與驗證，最後轉化為可被設計與開發解決的問題。

一個有趣的例子是 Tenfour.com 面臨志工分組管理的問題。當災害發生時，管理者需要快速組織志工，但目前系統必須人工建立群組，效率有限。因此有人在 GitHub Issue 提出：「能不能讓系統自動依照地區（location data）或農場位置建立群組？」這個開放問題讓設計師不只是思考「新增一個按鈕」，而是進一步探索如何利用地圖、位置資料與資訊架構，改善整個志工管理流程。

透過不同觀點的設計開源，我們在創造 feature 之前有了更細緻的產品討論與規劃，其中包括資料隱私權限、分享期效、數據精簡的設計，Deliver 的方向也獲得更多現場利益關係人的認同。

我在當時有了一個初步的認同：

一個好的產品跟 deliver 了多少 feature 無關，而是正確理解問題的多面性，想出精確的解法。
這個 Mindset 可以說是在高風險領域發展 AI 應用很關鍵的基石。

這些經驗，最後都指向同一件事情

在災害應變裡，真正困難的，其實不是沒有人願意幫忙，而是資料隱私、如何讓不同組織有限度的共享資訊、避免重複投入、把有限資源送到最需要的人手上。同樣，在運動科學裡，真正困難的並不是沒有數據，而是數據太多，教練很難在有限時間內找到真正重要的訊號。在醫療照護中，真正困難的並不是缺少資訊，而是資訊散落在不同系統裡，每一個操作都可能影響病人的安全。

甚至在商業產品中也是如此。有很多功能固然已經難得，但在 AI 能夠更快開發功能的時代，人腦能消化的資訊仍然有其上限，整合破碎資訊、降低認知負荷，才能讓使用者更容易理解資訊、更快完成決策，更好的去使用產品團隊準備的功能。

我慢慢發現，不同領域遇到的問題其實驚人地相似，真正稀缺的，是關鍵時刻能夠支持用戶決策的資訊。這部分接下來我會在 30 天裡面細談。

AI，讓決策支援進入新的階段

AI 出現，讓過去一直想解決的問題，多了一個前所未有強大的工具。

生成式 AI 讓我們第一次有能力快速整理龐大的資訊、串聯不同知識來源、建立共同語境，也讓跨領域合作變得比過去更加容易。站在用戶需求透明化、限制透明化、使用者研究資料的肩膀上，AI 能夠快速整合出可行的方法，提示用戶資料有支持的部分與可以參考的推論，並提出更多人腦極限沒有想到的提案。有了基礎建設，AI 的算力能夠幫助人們在複雜的世界裡，做出更好的決策。

我始終認為，AI 真正的價值，是讓專業者把更多時間留給真正重要的判斷。
在醫療裡，它應該幫助醫護人員更快掌握病人的狀況，而不是替醫師做診斷。在運動科學裡，它應該幫助教練看見數據背後的模式，而不是決定訓練策略。在災害應變中，它應該加速資訊流動與跨單位協作，而不是取代現場指揮官。

AI 最重要的角色，不是替人做決定，而是幫助人做出更好的決定。

我有了一個更明確的想法：

從正確理解問題本身，想出精確的解法出發。然後，有了這些資料後，AI 會是最強力的助手。

為什麼我要開始寫這個系列？

這幾年，我有機會在研究與實務之間來回切換。我看見許多很棒的 AI 技術，也看見不少無法真正落地的產品，為之嘆息。我突然意識到，相較於以成長與轉換為目標的商業產品，在從事高風險領域的產品設計時，並不是所有錯誤都能用下一版修正。

在社群產品，一個錯誤可能只是降低轉換率；在醫療、災害應變、運動訓練等場域，一個錯誤可能影響病人的安全、救援效率，甚至人的生命。我開始發現，我真正感興趣的不是「做更多 AI 功能」，而是如何設計一個能在人命關天或高壓決策情境中，被人真正信任與使用的 AI 系統。

也是從那時候開始，我開始持續關注高風險場域的人機協作與 AI 應用。這也是我深入的投入 AI for Social Good 的子領域：高風險場域智慧系統設計的原因。

我越來越相信，一個成功的 AI 系統，關鍵從來不只是模型有多強，而是我們是否真正理解人的工作流程、決策方式，以及真實世界的限制。

因此，接下來的 30 天，我想分享的不只是 AI 工具或最新技術。我更想分享的是，在醫療、運動科學、災害應變等高風險場域中，我如何思考人機協作、決策支援，以及 AI 如何真正成為值得信任的合作夥伴。

如果這個系列有一個核心信念，那就是：AI 的下一個階段，如何增強人的能力。我希望，未來能有更多 AI，不只是回答問題，而是真正幫助人們在複雜的世界裡，做出更好的決策。