系列:30 天用 Google AI 打造臺灣防災速報 App(Day 3/30)
昨天把資料源整理完,今天整理工具。Build on Google AI 組官方建議的產品有五個:Google AI Studio、Google Antigravity、Gemini Enterprise Agent Platform、Google Stitch、Firebase。本專案採用其中四個,加上 AI Studio 背後的 Gemini API,同樣湊成五種工具;沒採用的 Agent Platform 為什麼放下,文末交代。這篇講清楚它們在本專案的分工,以及免費方案的使用策略。
先看整體架構,5 種工具分工如下:

AI Studio 是瀏覽器裡的 Gemini 實驗環境:不寫一行程式就能測 prompt、調參數、比較模型,滿意之後一鍵匯出程式碼,API 金鑰也在這裡申請。本專案所有 prompt(速報摘要、警報分級、防災問答)都會先在這裡調校,再寫成正式程式。
我們會用到它四種能力,正好對應第二週的四個主題:
Cloud Functions 負責排程下載資料(解決昨天說的 429 限流問題:固定間隔輪詢+快取)、Firestore 存警報與狀態、FCM 做推播;前端則用 Flutter(同屬 Google 家)同一套程式碼同時出 Android 與 iOS App,FlutterFire 套件與上述服務原生整合。對單人 30 天專案來說,「不用管伺服器+不用寫兩套 App」就是最大的價值。
我不是設計師。Stitch 可以用自然語言描述生成 UI 設計稿與前端程式碼,第三週會用它產出警報總覽與問答介面的設計,作為 Flutter Widget 的對照稿。
Agentic 開發環境,讓 AI agent 直接參與寫程式、執行測試、改版面。2026 年 5 月發布的 2.0 版把它從單一 IDE 擴展成完整的 agent 開發平台:桌面 IDE、CLI(指令是 agy)、SDK(軟體開發套件)與 Managed Agents API 一應俱全;原本的 Gemini CLI 也已於 6 月退場、由 agy 接棒。本系列的用法:日常開發用 IDE,排程與自動化腳本用 agy CLI。我會在每週回顧裡記錄它在真實專案的表現,好用與不好用都照實紀錄。
官方清單裡還有 Gemini Enterprise Agent Platform,定位是多個 agent 協作、企業級治理與部署的平台。本專案的代理只有一個(Day 23 才登場)、工具只有三個,Gemini API 內建的 function calling 迴圈就足以應付;為了單一 agent 去上一個多 agent 平台,學習成本與治理開銷都划不來。取捨原則是先把單一 agent 做到可靠,規模需求出現再上平台。如果之後要加「志工調度代理」「資源媒合代理」這類第二、第三個角色,平台的價值才會浮現,Day 23 會再回到這個判斷。
30 天 side project 的原則:能免費就免費,量入為出。
明天 Day 4 正式動手:申請 API 金鑰、寫下第一支呼叫 Gemini 的程式,讓它讀懂第一則 CAP 示警。