系列：30 天用 Google AI 打造臺灣防災速報 App
組別：Build on Google AI ｜ 子題：科技永續與社會創新（AI for Social Goods）

從一個做研究的人說起

我的興趣是高層大氣研究，特別是地震與電離層之間的關聯。做這個題目久了，有兩件事體會很深：

第一，臺灣的災害資料其實非常豐富。中央氣象署的地震報告、颱風警報，水利署的水庫放流與淹水感測，消防署的火災通報……政府各單位透過開放資料平台，每天發布大量即時的防災資訊。

第二，這些資訊離一般人很遠。CAP 格式的示警電文、REST API 回傳的 JSON、專業術語寫成的地震報告：對工程師來說是資料，對一般民眾來說是天書。災害來臨時，真正需要資訊的人，往往是最難消化這些資訊的人。

生成式 AI 恰好補上這個缺口：它最擅長的事情之一，就是把機器格式與專業語彙，改寫成一般人看得懂的文字。這就是這 30 天要做的事。

這 30 天要做什麼

我要打造一個叫「防災速報」的 App（英文名 AI Watchtower），功能包含：

1. 警報總覽：自動彙整國家災害防救科技中心（NCDR）、中央氣象署等單位的示警，每 10 分鐘更新一輪。
2. 口語化速報：用 Gemini 把地震報告、颱風警報摘要成一般人一看就懂的短訊。
3. 防災知識問答：以 RAG 架構掛上官方防災指引，回答「地震時在浴室該怎麼辦」這類問題。
4. 多語言警報：中、英、日、韓四語，服務在臺的外國朋友。
5. 推播通知：重大示警主動推到使用者手上。

先說明一件這個 App 不做的事：地震發生當下的強震即時警報（Earthquake Early Warning）。那是接氣象署測站資料、需要正式授權的基礎建設，市面上「台灣地震速報」這類 App 已經做得很好。本系列做的是警報發布之後的事：把資料改寫成一般人看得懂的文字、回答問題、在人最慌的時候提供求助的途徑。定位是與速報 App 互補，不是競爭。

技術選型：Build on Google AI

這個系列參加的是 Build on Google AI 組，使用的工具以官方建議的產品為主：

選這套組合的原因：Gemini API 有免費額度、Firebase 免費方案足以應付 side project 的規模，而且這些服務彼此原生整合。從資料抓取、AI 處理到 App 上架，30 天內的完整開發流程，靠這一套工具就能完成。

30 天路線圖

• 第一週（Day 1–7）打地基：整理防災開放資料、認識 Google AI 工具箱、建立資料抓取與儲存的流程。
• 第二週（Day 8–14）AI 核心：prompt 設計、structured output、function calling、RAG 知識庫、多語言。
• 第三週（Day 15–21）上線：Firebase 全套服務、Stitch 設計 UI、Flutter 同一套程式碼做出 Android 與 iOS App，並製作 Web 版當產品介紹網站，雙平台 MVP 上線。
• 第四週（Day 22–30）進階與收尾：FCM 雙平台推播（含 iOS APNs 實戰）、Agent 化、歷史資料視覺化、兩篇地震科學科普（聊聊「AI 能不能預測地震」）、評估、成本管理與資安檢查，最後 Demo 與雙平台發布。

為什麼你可以追這個系列

想學 Gemini API 與 Firebase 的實戰整合，這裡每天都有可以跑的程式碼。在意「AI 該不該替人做判斷」的話，本系列在每個設計決策處會補一段人機互動研究的依據，把工具串起來只是基本功。關心防災科技的人，可以在這裡拿到臺灣防災開放資料的完整整理；好奇「AI 預測地震」到底是科學還是玄學的人，第四週的科普專欄會給你研究圈的第一手觀點。

明天 Day 2，我們從資料下手：把臺灣所有防災開放資料源一次整理，並實際取得第一批示警資料。

我們明天見。