當災害發生時，我們能不能讓資訊更快被理解、更準確地被分派，最後抵達真正需要的人手上？這是這個系列從一開始就想解決的問題，也是這篇要拉遠視野、重新盤點的起點。

目前世界上的救災資訊系統已經累積了很多年的發展。從政府的災害資訊平台、NGO 的人道救援系統，到群眾回報地圖與開放資料專案，大家都在處理類似的問題：災情從哪裡來？誰正在處理？哪裡還缺資源？不同組織之間如何共享資訊？

把這些系統放在一起看，可以發現它們其實代表了幾個不同階段的演進。

從「災情地圖」到「協作系統」：國內外案例盤點

在談個別平台之前，先解釋一個貫穿這整段演進史的概念：群眾外包（Crowdsourcing）。它指的是把原本由單一組織（政府、企業、媒體）負責的資訊蒐集工作，拆解成無數小任務，交給大量分散在各地的一般民眾來完成——每個人只需要回報自己當下看到、聽到的片段，系統再把這些片段彙整成整體情勢圖。這個做法的優勢很直接：民眾往往比任何官方單位都更早抵達現場，也更了解在地細節；劣勢也同樣明顯：資訊真假、來源可信度、隱私與濫用風險都必須被額外設計進系統裡。救災與治安領域，剛好是群眾外包最早、也最具爭議的兩個應用場景。

Citizen App（美國）就是治安領域的代表案例。它整合警消無線電頻道、911 報案紀錄與使用者即時回報，把「犯罪、火警、車輛追逐、抗議、失蹤人口」等事件標示在地圖上，並在使用者所在區域附近發生事件時主動推播警示。使用者也可以在現場開直播，讓其他人即時看到事件發展，甚至協助辨認可疑車輛或人物。

Citizen 防止治安案件擴大的邏輯，主要來自三個機制：

1. 搶在傳統新聞與部分報案流程之前示警：因為資料直接接上警消頻道與使用者現場回報，許多警示能在事件發生的第一時間就推播給附近民眾，讓人可以提早避開危險區域，或在有需要時協助通報。

2. 群眾協尋與即時線索比對：遇到孩童失蹤、通緝車輛等案件時，系統會把關鍵特徵（車型、衣著、地點）廣播給鄰近使用者，曾有案例是民眾靠著這類即時線索，協助警方在短時間內尋回失蹤兒童。

3. 付費版 Protect 真人協助：訂閱用戶感到人身安全受威脅時，可以透過搖晃手機、按鈕或系統偵測到的異常訊號啟動「安全專員」，由專員視訊或簡訊確認狀況，必要時代為聯絡 911、通知緊急聯絡人，等於在民眾與正式報案系統之間多加了一層即時中介。

不過 Citizen 也一直伴隨爭議：它鼓勵的「公民警政（Citizen Policing）」模式，曾發生使用者僅憑片面回報就公開懸賞緝拿嫌疑人，事後證實抓錯對象；過度即時、未經查證的通知也可能讓治安狀況被放大解讀，造成不必要的恐慌。這其實正好呼應了群眾外包的老問題：資訊來得快，不代表資訊是對的，系統設計必須同時處理「速度」與「查證」這兩個互相拉扯的目標——這一點，之後在災害資訊系統上也會反覆出現。

Ushahidi（肯亞）長期發展群眾回報與 crisis mapping 的能力。使用者可以透過表單提交事件，再把資訊呈現在地圖上，並透過分類與篩選讓大量事件更容易被理解。它的價值很大一部分來自「把分散在不同地方的資訊集中起來」。

Sahana Eden 則更接近完整的人道救援管理平台。它涵蓋組織、志工、資產、物資、需求、倉儲與 4W（Who is doing What Where）等資訊，也強調讓政府、NGO、志工與其他組織共享資料，並透過 CAP 等開放標準與其他系統交換警報與情勢資訊。這已經從單純的資訊展示，往「跨組織協作」前進。

GDACS（Global Disaster Alert and Coordination System） 是聯合國人道事務協調廳（OCHA）與歐盟執委會自 2004 年起共同推動的全球合作框架，專門用來補足重大突發性災害初期的資訊落差。它會整合地震、海嘯、洪水、火山與熱帶氣旋等資料，自動計算災損衝擊等級，並透過限制存取的 Virtual OSOCC 平台，讓各國救災單位與國際組織即時交換情勢資訊。目前已有數萬名訂閱者，也累積了上萬份分析產品，可以說是目前最接近「跨國協定層」的實例。

One Concern（美國）走的是另一條路線：它用機器學習與物理模型建立城市的「數位分身」，預測地震、洪水等災害對建築、供應鏈與社區造成的衝擊時間與範圍，協助政府與企業在災前找出風險熱點、災後判斷該優先前往哪些區域派送物資與救援人力。

Humanitarian OpenStreetMap Team（HOT） 則展現了群眾協作的另一種可能：透過號召全球志工在災前、災中即時繪製受災地區的地圖細節（道路、建築、避難所），補足許多開發中國家長期缺乏的基礎地理資料，讓後續的資源調度與救援規劃有地圖可用。

台灣也有很強的災害資訊基礎。例如國家災害防救科技中心的 3D 災害潛勢地圖，可以整合淹水、坡地、斷層、土壤液化、海岸與火山等不同災害圖資，並提供警戒值查詢與資料下載。這類系統非常適合回答「這裡有什麼風險」，也建立了災害資訊標準化與空間化的基礎。

如果把這些案例放在同一張圖上，我會這樣理解：

這張表裡最值得注意的是 AI 程度與資源媒合這兩欄。現在很多系統已經可以把資料「收進來」，也可以把資料「放在地圖上」，甚至像 One Concern 這樣做出預測，但目前還沒有任何一個系統能同時把資訊彙整、資源媒合與 AI 判讀都做到位。下一個問題是，系統能不能理解這些資料之間的關係，進一步協助不同組織完成決策與協作？這正是 AI 真正有機會進入救災系統的位置。

AI 正在改變我們理解災情的方式

災害資訊學（Crisis Informatics）這幾年一直在處理一個核心問題：當災害發生後，資訊量會在極短時間內暴增，但其中只有一部分真正有助於決策。

社群媒體是典型例子。研究者已經長期研究如何從 Twitter、Facebook 等社群資料中辨識災害事件、位置、受災程度與民眾需求；同時，衛星影像也被大量用於災損辨識。相關研究已經將災害資訊分析分成文字訊號、社群影像與衛星影像等不同方向。

這個方向也開始在真實災害中產生實際價值。2025 年緬甸地震後，Microsoft AI for Good Lab 與 Planet Labs 使用衛星影像與 AI 模型協助判斷建築物受損程度，快速標出大量高度受損與中度受損建築的位置，讓救援團隊可以更快掌握需要優先處理的區域。不過這類結果仍需要現場人員驗證，因為雲層、影像品質與不同災害類型都會影響模型表現。

這讓我們看到 AI 在災害現場的一個實際角色：把人很難在短時間內閱讀的大量資料，轉換成可以進入決策流程的訊號。

同樣的邏輯也發生在預測上。台灣本身就有研究利用機器學習改善土石流預警，透過降雨資料預測特定時間內發生土石流的可能性，並討論漏報與誤報之間的風險取捨。國際上，One Concern 的洪水與地震預測、WMO 與 ITU 主導的「Global Initiative on Resilience to Natural Hazards through AI Solutions」也都在推動早期預警的 AI 標準化與跨國合作。

換句話說，AI 的使用時間點正在往前移：從災後的災損評估，到災害發生過程中的即時訊號整理，再往前一步，利用歷史資料、氣象、地理與資源分布，在災害發生之前就預測哪些地方可能需要支援。

下一代救災平台，我認為會出現三個轉變

第一個轉變，是從「平台」走向「協定」。

現在最大的問題之一，是每個政府機關、NGO、志工團隊可能都有自己的資料格式與工作流程。一個組織使用「物資需求」，另一個組織可能使用「資源請求」；有人記錄的是 GPS，有人記錄行政區；有人更新即時狀態，有人每天整理一次。

真正成熟的救災 AI 生態系，需要更標準化的資料交換方式。這也是為什麼開放標準會非常重要——Sahana 長期推動開放原始碼與開放標準，GDACS 也透過 CAP 等格式讓不同系統交換警報與情勢資訊。未來的救災平台可能不需要所有組織登入同一個系統，只要彼此遵循相同的資料協定，災情、需求、資源與任務就可以在不同系統之間流動。

第二個轉變，是從「災後回應」走向「災前預測」。

假設系統知道某個地區即將出現強降雨，同時知道當地有多少避難人口、醫療站、救援隊伍、飲水與發電設備，它就可以提前提出資源配置建議。

例如：「未來 12 小時內，A 區可能需要增加 3 組抽水設備，B 區的醫療資源可能不足，C 區目前有兩個 NGO 擁有閒置運輸能力。」

這時候 AI 的角色就從資訊整理，進入資源規劃。

第三個轉變，也是我覺得最有意思的方向，是 Agent-to-Agent 協作。

未來每個 NGO 都可能有自己的 AI assistant。它知道這個組織有哪些車輛、志工、物資與能力，也知道目前有哪些任務正在進行。當另一個組織提出需求時，兩個 AI agent 可以先交換資訊：

「我們目前有兩台卡車，今天晚上可以支援。」
「我們需要一台車前往 A 區，但需要四小時內抵達。」
「我們的車輛距離 A 區較遠，B 組織有一台車距離較近，我可以詢問他們是否能支援。」

這種架構已經開始出現在近期對 agentic AI 與 disaster management 的研究願景中。2025 年 10 月，Li、Ma、Yin、Xiao、Hsu 與 Mostafavi 等學者在論文〈Disaster Management in the Era of Agentic AI Systems: A Vision for Collective Human-Machine Intelligence for Augmented Resilience〉（arXiv:2510.16034）中提出了「Disaster Copilot」這個構想：由一個中央 orchestrator 協調多個專業 sub-agent，分別負責風險預測、情勢感知與災損評估，整合多模態資料後產出即時的災害情勢圖，並強調系統要能在資源受限的現場透過 on-device orchestration 持續運作。

如果這個方向真的成熟，人與人之間仍然需要協調，但很多資訊整理、需求比對、資源搜尋與初步協商，可以由 AI agent 先完成。人類最後處理的是更高層次的判斷、責任與價值取捨。

我更在意 AI 做不到的事情

談到下一代 AI，很容易陷入技術樂觀。但救災場景有一個很現實的問題：最需要系統的人，可能恰好最難使用系統。

長輩可能沒有智慧型手機，災民可能沒有網路，前線志工可能手機只剩 10% 電，甚至整個地區可能停電、基地台損毀。所以一個真正能在災害現場工作的 AI 系統，必須把離線能力、低頻寬、SMS、語音、簡化介面與紙本備援都放進設計裡。

資料治理也是另一個問題。當系統開始整合災民位置、醫療需求、家庭資訊、資源分布與志工資料，資訊的敏感程度會快速提高。AI 能不能使用這些資料是一回事，誰有權限使用、保存多久、誰可以查看、災後是否刪除，又是另一組必須被設計的問題。

因此，我認為下一代救災 AI 的核心競爭力，最後仍然會回到幾個很基本的設計問題：資料是否可信、資訊是否可追溯、決策是否能被理解、權限是否清楚，以及系統在基礎設施失效時還能不能繼續工作。

回到起點：我們真正想解決的是資訊流

Day 18 提出的問題是：為什麼救災現場明明有大量人力與資源，卻仍然可能出現「有人找不到物資、有人不知道哪裡缺人、有人重複做同一件事」的情況？

走到這裡，答案變得更清楚了：未來的救災 AI，需要逐漸成為一層存在於不同組織之間的「智慧協作層」——理解來自不同來源的災情，判斷資訊可信度，整理需求與資源，預測可能出現的缺口，再協助不同組織完成任務協調。

技術會持續改變。今天可能是 dashboard、明天可能是 copilot，後天可能是由多個 AI agent 組成的協作網路。但救災真正需要解決的事情，其實一直都很清楚：

讓對的資訊，在對的時間，到對的人手上。

這也是我做這個救災平台 prototype 之後，最想留下的一個設計命題。