系列：30 天用 Google AI 打造臺灣防災速報 App（Day 7/30）

第一週結束，照慣例做週回顧：整理這週完成了什麼、資料流程最後的樣子，以及遇到的問題與解法。

本週完成

• Day 1–3：定題、整理資料源與工具，架構定案。
• Day 4：AI Studio 金鑰＋SDK，第一次讓 Gemini 讀懂示警。
• Day 5：NCDR 示警資料的解析與整理程式，去除重複、狀態標記（生效中或已結案）、六大類統一。
• Day 6：接上中央氣象署（CWA）開放資料，取得地震報告的完整細節。

資料流程定稿

這張圖是定案的設計。目前完成的是下載、解析、整理三段，三支程式都還是手動執行一次的腳本；「排程」和「儲存」兩段還沒有實作，之後接上 Cloud Functions 與 Firestore 時處理。

設計上的三個決定：

1. 定時輪詢（每隔固定時間主動去查一次），不做即時推送：NCDR 與 CWA 都沒有主動通知的機制，所以每 10 分鐘執行一輪，在不造成對方負擔與資訊即時性之間取得平衡。每一輪都會下載 NCDR 的示警資料與 CWA 的天氣特報；CWA 的地震報告只在 NCDR 出現新的地震示警時才查詢，用來補上完整細節。之後可以縮短地震類的間隔，但這仍然是官方報告發布之後的查詢，不等於地震發生當下的強震即時警報。
2. 原始資料與整理後的資料會分開存：原始示警內容保留（出錯時可以回頭查），前端與 AI 只使用整理後的事件。
3. 資料的下載與整理不交給 AI：這兩步全部是確定性程式（同樣的輸入一定得到同樣的結果），Gemini 只會讀取整理好、存進資料庫的事件，用來產生給人看的內容。先把資料格式固定下來，後面的摘要與分級才容易測試。

本週遇到的問題

開發環境備註

這週的程式都還是本機執行的 Python 腳本。我也試用了 Antigravity 2.0 的命令列工具 agy，請它的 agent（能依指示協助規劃或執行工作的 AI 程式）審查下載程式。它指出一個潛在問題：示警的 link 欄位有時是單一物件、有時是陣列，原本的寫法遇到陣列會出錯，後來補上了檢查。分類對照表這種需要領域知識的內容，還是得自己逐項核對。

下週預告

第二週進入 AI 核心：明天從 prompt 設計開始，看怎麼讓 Gemini 把地震報告寫成一般民眾也看得懂的速報。