前面幾章，先從「為什麼高風險場域需要 AI」談起，再走過運動科學裡資料如何成為決策而不只是報表，接著進入醫療照護，討論如何設計一套值得信任的 AI 系統。這一次，想把視角轉向另一個同樣高風險的場域：救災。

會開始談這個主題，一部分是因為我實際參與了光復救災平台討論的初版，在現場親身感受到資訊協作的真實困難；另一部分，則要回到 Day 1 提過的那場 workshop，當時邀請了尼伯特風災的災民來分享他們的經歷，那段對話讓我對資訊落差如何影響救援，有了更具體也更貼近現實的想像。

災難發生之後，最先出現的往往是大量的人與資源

一場大型災害發生後，我們通常會看到非常強烈的社會動員。地震、颱風或土石流發生後，大量志工開始尋找可以幫忙的地方，民間團體募集物資，企業提供設備與運輸，政府則啟動各種應變機制。從外部看起來，整個社會正在快速聚集大量的人力、物資與服務。

然而，真正進入災區之後，情況往往會變得複雜許多。某個避難所可能同時收到大量飲用水，另一個地區卻還在尋找基本生活用品；有些地方志工已經超過現場可以負荷的人數，另一個地方卻找不到足夠的人手清理環境；倉庫裡堆滿了物資，前線卻仍然持續回報「缺東西」。

這種現象在大型災害後尤其明顯。以花蓮地震、颱風災後的志工動員為例，社群平台上會快速出現大量「需要物資」、「徵求志工」、「募集捐款」、「需要車輛」等資訊。大家都在努力提供協助，但當資訊量快速增加之後，另一個問題也開始浮現：究竟哪裡真的需要？現在需要什麼？需要多少？誰已經送過去了？誰正在處理？

當資源大量湧入，資訊落差反而開始放大

救災現場最大的困難之一，是需求本身一直在變化。

災害剛發生時，可能最需要的是飲用水、食物、醫療用品與緊急安置。幾個小時後，需求可能轉變成清理工具、抽水設備、發電機、交通運輸與人力。再過一天，現場可能開始需要修繕材料、心理支持、長期安置與生活物資。

問題在於，這些需求的變化速度，往往比資訊系統更新的速度更快。

一則 Facebook 貼文可能在早上發布，到了下午已經有不同團體送完物資，但原本的貼文仍然持續被轉發。LINE 群組裡有人說某個地點缺水，另一個群組可能已經完成配送，卻沒有任何機制把兩邊的狀態同步。Google 表單可以收集大量需求，卻未必能即時知道哪些需求已經被處理。政府系統則可能掌握另一套資料，民間團體又有自己的名單與紀錄。

當這些資訊彼此沒有連接時，每一個人都可能掌握一小部分真實情況，卻很難看到完整的災情。

同一個需求被看見十次，現場可能真的只需要一次

這會產生一個很有意思的資訊問題：需求的「曝光量」與實際需求量開始脫鉤。

假設某個偏遠地區發布了一次「需要 100 箱礦泉水」。消息被 A 志工團體看到，轉貼到自己的 LINE 群組；B 團體又分享到 Facebook 社團；C 團體再整理進 Google Sheet。幾個小時之後，可能已經有十個不同團體認為「這裡缺水」，最後同時把水送過去。

從資訊流的角度來看，原始需求只有一筆，但經過多次轉發之後，它看起來像是十筆甚至更多需求。

這也是救災協作中非常關鍵的問題：我們需要掌握的，是這個需求目前還存在多少。如果系統無法持續更新需求狀態，資訊越多人傳遞，反而可能讓資源配置變得越混亂。

每一個角色看到的，都是救災系統的一小部分

把救災現場的角色分開來看，可以發現不同角色其實都掌握著不同的資訊。

災民最清楚自己缺少什麼，但未必知道可以向誰提出需求；志工知道自己可以提供多少人力，卻可能不知道哪個地區真正需要幫忙；NGO 通常具有組織、物資與調度能力，但需要可靠的現場資訊才能決定資源送去哪裡；政府掌握較完整的行政與災情資料，卻未必能即時掌握每一個民間協作網絡；捐贈者願意提供資源，卻很難知道自己的資源最後去了哪裡。

因此，救災現場其實存在大量「資訊斷點」。

每個角色都在做事，每個角色也都可能非常努力，但不同角色之間缺少共同的資訊語言。當大家使用不同的平台、不同的表單、不同的群組與不同的資料格式時，協作成本就會快速增加。

把「救災協作」看成一個資訊系統問題

從產品設計的角度重新檢視這件事，救災協作其實可以分成三個非常核心的系統問題。

第一個是供需媒合。系統需要知道「哪裡需要什麼」以及「哪裡有哪些資源」，再將兩者有效連接。例如 A 災區需要 50 台抽水機，而 B 組織正好有設備與運輸能力，系統應該能協助兩者快速建立連結。

第二個是狀態同步。需求不能永遠停留在「待處理」。它應該有清楚的狀態，例如待確認、已確認、處理中、部分完成、已完成，並且讓所有相關角色看到最新狀態。這會直接影響資源是否重複投入。

第三個是信任驗證。災難期間資訊流動速度非常快，也因此更需要確認資訊來源與真實性。誰提出這個需求？現場是否真的存在？最後一次確認是什麼時候？是否已經有人接手？這些資訊都會影響其他人是否應該採取行動。

這三件事情放在一起，就形成了一個完整的「救災資訊協作系統」。

當我們開始管理資訊流，AI 才有真正可以發揮的空間

那 AI 在救災場景中的角色應該是什麼呢？

如果現場連需求在哪裡、誰正在處理、資訊是否過期都無法掌握，那麼加入一個 AI 助理，很可能只會讓資訊產生得更快，變成更多的雜訊。真正有價值的 AI，需要建立在一個可信任的資訊協作架構上，協助人們整理大量訊息、辨識重複需求、追蹤狀態變化、找出資源缺口，甚至協助不同組織理解彼此正在做什麼。

這和前面幾篇談到的醫療 AI 有一個很重要的共通點：高風險場域真正困難的地方，經常發生在「資訊如何進入決策」以及「不同角色如何共同理解資訊」。

到了救災現場，這個問題變得更加極端。時間更短、資訊更碎片化、環境更不穩定，也有更多不同組織同時介入。

所以，如果我們真的想設計一個 AI 救災平台，第一步並不是急著決定要加入哪一個 AI 功能。

我們需要先回答一個更基礎的問題：
當災害發生之後，如何讓「需求、資源、狀態與信任」在不同角色之間持續流動？

這會成為下一篇的起點。

Day 19，我會從需求訪談與利害關係人開始，實際分析一個救災協作平台應該如何被定義，看看當我們真的把這個問題當成產品來設計時，第一個應該解決的核心任務到底是什麼。