你也想做 Side Project，但想到前後端串接、API 設定、響應式設定就覺得心累嗎？從前的我也是如此，因此從來不敢想像有一天會有辦法親手打造屬於自己的 App，但在密集的使用了 Google Antigravity 一週後，我成功辦到了，打造出一款包含 AI 搜尋功能的「Veggie Finder 素食地圖」。這不是未來的科幻電影，這是現在就能做到的開發新模式。在這篇文章中，我將完整的分享我是如何利用Google Antigravity，在極短時間內從構想到上線。如果還不了解 Google Antigravity 的朋友，可以參考「Google Antigravity 簡介：Google 最新多代理 AI 開發工具。」
Veggie Finder 開發緣由
這個 App 的起因是，身為素食者且長期在推廣素食的我，一直很希望讓大家知道素食其實有很多好吃的餐廳，能夠零門檻的嘗試素食的美妙。但使用現有的素食餐廳 App 或將自己儲存的 Google map 餐廳分享給別人，也等於是將整份清單丟給他人而已，他們還是要自己找餐廳、自己篩選餐廳，也從而降低了大家想要嘗試的意願。
「所以我決定自己做一個可以『用說的』找餐廳的素食地圖。」Veggie Finder 這是一個我從零開始打造的素食餐廳探索平台，結合了 AI 智慧推薦與地圖視覺化，直接跟 AI 對話，就可以請他為你推薦適合的餐廳，旨在為使用者提供最流暢的素食餐廳探索體驗。
核心功能介紹
AI 聊天機器人
這是 Veggie Finder 最亮眼的功能！透過 Google Gemini AI 打造的智慧助手可以：
- 理解自然語言問題（例如：「中壢附近有沒有韓式的素食餐廳？」）
- 餐廳類型推薦：可以推薦使用者想要的特定類別的餐廳
- 捷運站定位：自動識別捷運站名稱，推薦捷運站附近的餐廳
- 距離排序：結合使用者位置，依照遠近排序推薦結果
- 營業時間識別：主動提醒使用者提問時的餐廳營業狀態
Veggie Finder 詢問 AI 特定餐廳資訊
Veggie Finder 詢問 AI 捷運站附近餐廳
互動式地圖與列表
使用者可以在地圖上直觀地瀏覽所有素食餐廳位置。支援：
- 即時定位：授權後可顯示離你最近的餐廳
- 地圖視野篩選：列表內自動顯示目前地圖範圍內的餐廳
- 「營業中」即時篩選：只顯示地圖範圍內目前正在營業的餐廳
- 多元餐廳分類與篩選：包含：小吃、日式料理、義式料理、韓式料理、火鍋、咖啡廳、吃到飽餐廳等，讓使用者能快速找到想吃的風味。
Veggie Finder 電腦版頁面
雙模式智慧搜尋
- 餐廳搜尋：直接輸入餐廳名稱快速定位
- 地址搜尋：輸入地標或地址（如台北車站），自動列出附近的素食餐廳
Veggie Finder 餐廳搜尋
Veggie Finder 地址搜尋
收藏清單
登入後可將喜愛的餐廳加入收藏，資料與 Firebase Auth 帳號綁定，跨裝置同步。
Veggie Finder 收藏清單
實戰開發流程：從 0 到 1 的五個階段
第一階段：需求規劃與初始化 (Planning)
我首先先與 AI 對話，告訴他我對這個 App 的想像，進可能的詳細列出 App 的介面、功能，以及開發技術組合（剛好前幾天在臉書社團上有人分享就直接抄過來用了），以及我目前有的資料類型。當時我手上有一份 Excel，裡面收集了從 Google Map 清單匯出的近千家素食餐廳的 Google Maps 連結，但它只是一堆「連結」——沒有結構化的餐廳名稱、地址、營業時間，更別提在地圖上視覺化呈現了。
接著 AI 就跟我列出了我這個 App 會使用的的技術框架，當然我是完全不理解的，因此我就直接請他一個一個解釋給我聽，並且也請他推薦常用的或是好用的。經過一番討論，AI 產出了一份 Implementation Plan，規劃好每個階段要做什麼，就準備開始實作了。
一開始的 Implementation plan
一開始的 Implementation plan
開發技術組合
第二階段：核心功能實作 (Execution)
規劃完成後，接下來就是實際的開發工作。這個階段我會詳細說明每個核心功能是如何透過外部工具與 API 連接來完成的。當然不會的部分我也是靠問 AI 來解決問題的。
1. 與 AI 的互動模式
AI 開始依據討論好的結果生成可以在本地運行的網頁，並且在過程中會同時請我去外部資源設定（二～四）並且回傳他需要的資料給他，每當他跑完後，他就會給我一串 localhost 的網址，這時後只要把網址複製貼上到任何一個瀏覽器就可以進行測試了。測試的過程中一定會遇到許多問題，這時我一貫的做法就是給 AI 文字描述、錯誤狀況截圖、 瀏覽器開發者模式中 Console 欄位的錯誤訊息截圖（快捷鍵 F12）。有時候簡單的問題他可以直接解決，或是他會請我到外部資源做更多的設定，如此一直重複，如果突然想到有什麼可以優化的地方我也是直接文字描述給他，多數情況下他都可以很快的達到我的需求。不過還是有幾個真的調整了非常久的問題，但因為我也完全沒有程式基礎，所以我也只能一再的貼資訊給他、或是換個模型問看看、或是開起新的對話再重複一次問題，這些問題將在除錯環節詳細描述。
Google Antigravity AI 回覆結果範例
向 Google Antigravity 提問範例
2. Firebase 設定
Firebase 是這個專案的後端核心，負責資料庫和使用者認證，以下是 Firebase Console 設定步驟
建立專案
- 前往 Firebase Console
- 建立新專案
- 啟用 Google Analytics（可選，但我有啟用來追蹤使用者行為）
啟用 Firestore Database
- 選擇建構 → Firestore Database
- 選擇 「測試模式」 — 這會允許所有讀寫操作，方便開發階段測試
- 之後上線前再調整 Security Rules 限制存取權限
- 選擇區域（我選
asia-east1台灣）
啟用 Authentication
- 選擇建構 → Authentication → 登入方式 → 新增供應商 → Google 登入
- 設定授權網域（本機
localhost以及正式部署後要再回來新增正式的網域）
取得設定檔
- 專案設定 → 一般設定 → 新增應用程式 → 網頁
- 複製
firebaseConfig設定 - 回到 Google Antigravity 貼上給 AI
權限設定（Firestore Security Rules）
- 在貼上給 AI 後，因為我有後台介面希望只有我可以進去，因此我就請他撰寫程式碼，讓後台登入的 Google 帳號必須是我的帳號才可以存取
- 接著在 Firestore Database 的「規則」頁面，貼上他寫好的程式碼。這樣就能確保只有管理員能新增、編輯、刪除餐廳
Firebase Authentication 頁面
3. Google Cloud Console API 設定
這個專案用到多個 Google API，需要在 Google Cloud Console 進行設定。
建立專案
- 前往 Google Cloud Console
- 建立新專案或使用 Firebase 自動建立的專案
啟用必要的 API
- Maps JavaScript API — 顯示 App 中的地圖及標記
- Places API (New) — 當我後台貼上 Google Maps 連結後，系統會自動透過 API 抓取座標、地址、評分、營業時間等資訊
- Geocoding API — 當使用者在 AI 聊天中提到具體地址時，系統會呼叫 Geocoding API 將地址轉成座標，再計算附近的餐廳
建立 API 金鑰
- APIs & 服務 → 憑證 → 建立憑證 → API 金鑰
- 設定限制：
- 應用程式限制：只允許自己的應用程式類別，選跟 Firebase 一樣
- 網站限制：只允許你的網域（本機 localhost 以及正式部署後要再回來新增正式的網域）
- API 限制：選限制金鑰，只允許上述三個 API
OAuth 同意畫面設定（正式部署後）
- APIs & 服務 → OAuth 同意畫面 → 品牌 → 授權網域（新增正式的網域）
- APIs & 服務 → OAuth 同意畫面 → 用戶端 → 用戶端 ID（直接選系統自動建立的） → 已授權的 JavaScript 來源（新增正式的網域）
地圖樣式自訂
- 在 Google Cloud Console 的「地圖管理」中建立 Map ID，以及在「地圖樣式」建立新的地圖樣式
- 將地圖樣式連結到建立好的 Map ID 並回傳 MapID 給 AI 請他套用
- 這時調整地圖樣式後就可以時時顯示在 App 的地圖上了（我是請 AI 寫 json 來快速調整全局，然後再手動調整自己不滿意的地方，像是整張地圖的標籤、顏色顯示都調整了色調跟飽和度，以及隱藏了大部分的標籤，調整了文字的大小，以優化視覺體驗）
注意事項：需要在 Cloud Console 啟用計費（綁信用卡），不過有免費額度（90 天內），否則 API 會被停用。
建立 API 金鑰
啟用必要的 API
地圖樣式自訂
4. Gemini AI 聊天機器人
設定 API
- 進入 Google AI studio → projects → create project → 複製 API key 給 AI
- 選擇適合的語言模型，請 AI 撰寫對應的程式碼讓你可以調用 AI，也可以直接請他測試
- 回到 Google AI studio → 剛剛建立的 project → view usage 看看有沒有成功調用或是是否出現錯誤代碼（可能要等個兩分鐘才會刷新）
Prompt Engineering（透過與 Google Antigravity 的 AI 對話調整）
- 為了讓 AI 聊天機器人更精準推薦餐廳，我設計了「兩階段處理流程」：
- 第一階段（意圖解析）：先讓 AI 聊天機器人分析使用者問題，提取出關鍵資訊（想找的區域、料理類型、特定餐廳名稱等）
- 第二階段（智慧篩選）：根據解析結果，用程式邏輯篩選符合條件的餐廳（包含捷運 站距離計算、區域比對等），再交給 AI 聊天機器人生成最終回覆這樣做的好處是 AI 聊天機器人不需要每次都處理所有的餐廳資料，只需要專注在已篩選的 15-20 間，大幅提升回應品質和速度。
- 處理營業時間的判讀邏輯
- 一開始 AI 聊天機器人會把「超過營業時間」誤判成「今天公休」，因此我在 Prompt 裡寫了詳細的判斷規則：有時段但現在超過 → 「今天有營業，但已打烊」完全沒時段、只寫休息 → 「今天公休」
- 防止 Prompt Injection
- 我先請 Google Antigravity 的 AI 生成幾個 Prompt Injection 常用的手段，並且測試目前的 AI 聊天機器人是否會被攻擊成功，將測試的結果回報後，請 Google Antigravity 的 AI 加入安全規則，避免用戶誘導 AI 聊天機器人說出系統提示，或是讓 AI 回答跟完全無關的問題
- 捷運站定位
- 我希望 AI 聊天機器人能自動識別捷運站名稱，推薦捷運站附近的餐廳，因此我建立了一份涵蓋北台灣所有捷運站的座標資料庫給 AI 參考，並讓他自己寫判斷邏輯並重複測試。因此當使用者問「板橋站附近有什麼？」，系統會自動辨識「板橋」是捷運站名，取得對應的經緯度座標，再計算資料庫中每間餐廳與該捷運站的距離。
5. 距離排序
- 我希望結合使用者位置，依照遠近排序推薦結果，因此我請 AI 當偵測到捷運站或使用者授權 GPS 定位後，系統會計算每間餐廳的距離，並自動篩選出 2 公里內的餐廳，按照由近到遠排序。如果 2 公里內沒有結果，會自動擴大到 5 公里範圍。這樣使用者收到的推薦就會從最近的開始，而不是隨機排列。
Google AI Studio 查看 API 用量
調整 AI Chatbot 的部分 Implementation Plan
5. UI/UX 設計細節
所有相關的設計都是經由與 Google Antigravity 的 AI 對話後完成的，個人覺得他算是很有美感，只要下簡單的指令就可以自行達到完成度八成左右的設計。
- 品牌設計
- 全介面以 Sage Green 主色貫穿，呈現一致的視覺感受
- 互動回饋採用脈衝式動畫，增加動態感
- 篩選與切換按鈕皆使用圓潤的膠囊造型，提升親和力
- 視覺更柔和，符合品牌調性
- 手機版設計
- 下方面板可拖曳調整三種高度，兼顧功能與靈活性
- 當滑動地圖時面板會自動收合，點擊餐廳則自動展開，操作更直覺
- 浮動導覽按鈕在使用者滑動時暫時隱藏，不干擾視野
CleanShot 2025 12 26 at 21.36.32
- 電腦版設計
- 採用左右分欄的版面配置，資訊分層清晰
- 支援展開式聊天面板，方便查看 AI 對話
- 加入滑鼠懸浮效果，增強互動感
- 提供資訊卡片顯示詳細內容
Veggie Finder 電腦版介面
6. 後端安全設計
關於這部份我也是請 Google Antigravity 的 AI 協助檢查目前的程式碼是否有安全漏洞，而其中他發現最重大的問題就是當時的 API 金鑰是曝露在前端的，代表任何人都可以看到你的 API key 並且拿去直接用（如果沒有在 Google Cloud Console 做任何限制性的設定的話），這樣是非常危險的，因此這部份我也請他一併調整，方法如下：
- 將敏感的 API key 都存放在 .env 環境變數內，而不是直接寫在程式碼當中
- 由於我後續要使用 GitHub 與 Netlify 進行部署，因此兩者都必須做對應的設置，在下方部署章節中會解釋
- 設定前端透過 Netlify Serverless Function 呼叫 API。這樣 API Key 只存在伺服器環境變數中，前端程式碼完全看不到金鑰，即使有人查看網頁原始碼也無法取得。
第三階段：除錯與優化
開發過程中，除了功能實作之外，效能優化和問題排除也佔了相當大的時間。以下分享幾個讓我印象深刻的問題與解決方案，當然基本上都是 AI 協助我解決的，我主要都是負責發現問題以及選擇解方而已。
1. AI 模型選擇
問題
一開始我想使用 Gemini 1.5 Flash 作為聊天機器人的語言模型，因為越低階的 AI 的免費額度越多，但 API 持續回傳錯誤訊息表示找不到該模型。於是後來改用 Gemini 2.5 Flash，雖然可以正常運作，但很快就遇到了配額限制的問題：
- TPM (Tokens Per Minute)：每分鐘可處理的 Token 數量上限（250k/min）
- RPM (Requests Per Minute)：每分鐘可發送的請求次數上限（5/min）
- RPD (Requests Per Day)：每日可發送的請求次數上限（20/d）
當多位使用者同時使用 AI 聊天功能，很容易就會觸發這些限制，導致 AI 暫時無法回應。
解決方案
取捨後，我最終選用 Gemma-3-27b 模型。這是 Google 開源的語言模型，免費額度較寬裕（主要是考量到 RPM 與 RPD，不過 TPM 反而下降了），且測試後的回應品質足以應付餐廳推薦的場景。雖然不是最新最強的模型，但在成本和穩定性之間取得了平衡。
2. Token 限制下的架構設計
問題
Gemma-3-27b 的 Token 限制為 15,000 TPM。我的資料庫有近千間餐廳，如果每次都把全部資料丟給 AI，光是餐廳清單就會吃掉大量 Token，根本不夠用，遑論還要處理使用者的問題。
第一次嘗試：純程式碼解析（失敗）
一開始我想完全不用 AI 來解析使用者問題，而是用程式碼規則來拆解。例如：偵測到「中山區」就篩選該區餐廳、偵測到「日式」就篩選日式料理類別。這樣可以省下解析意圖的 Token 消耗。但實際測試後發現這個方法太死板，只要使用者打錯字或用不同說法，程式碼就無法正確識別，因為自然語言的變化太多，純程式碼規則根本無法涵蓋所有情況。
最終解決方案：兩階段 LLM 架構
最後採用折衷方案，使用了先前提到的兩階段 LLM 架構，讓 AI 負責理解問題及最後的答覆，篩選餐廳的工作交給程式碼，這樣既保留了 AI 理解自然語言的能力，又大幅減少了傳入的餐廳資料量，並且搭配其他優化策略，成功維持 Token 的使用量不會超標
- 對話記憶限制：只保留最近 2 輪對話（4 則訊息），避免歷史訊息累積消耗過多 Token
- 推薦數量限制：在 Prompt 中明確告訴 AI 每次最多推薦 5 間餐廳
- 回答格式限制：要求 AI 簡潔回答，每則回覆控制在 2-3 句話
Google Antigravity 生成的兩階段 LLM 實作報告（部分）
3. 手機版地圖滑動卡頓
問題
地圖上有近千個餐廳標記，在手機上滑動地圖時明顯感受到卡頓和延遲。
解決方案
改為視野範圍動態載入：只渲染目前地圖可視範圍內的餐廳標記，而不是一次載入全部。當使用者滑動地圖到新的區域時，再動態補上該區域的標記。這樣大幅減少了同時渲染的數量，滑動體驗變得流暢許多。
Google Antigravity 生成的手機介面操作改進實作報告（部分）
4. 首次載入速度優化
問題
第一次開啟網頁時，需要等待 Firebase 連線並下載餐廳資料，畫面會有一段時間是空白的，使用者體驗不佳。
解決方案
採用混合式載入策略：
- 骨架畫面 (Skeleton Screen)：在資料載入期間顯示灰色佔位區塊，讓使用者知道內容正在載入中，而不是看到空白畫面
- 靜態 JSON 快取：將餐廳資料預先匯出成靜態 JSON 檔案，部署在 CDN（離使用者最近的快取伺服器）上。網頁載入時先讀取這份靜態資料，讓使用者立即看到內容
- 背景同步：靜態資料顯示後，再於背景連接 Firebase 取得最新資料並更新
這樣使用者的體感載入時間縮短，同時又能保持資料的即時性。
Google Antigravity 生成的載入速度優化實作報告（部分）
5. 地圖標記定位與脈衝動畫
問題一：標記位置會亂跑
我設計了自訂的水滴形標記，但放大縮小地圖時，標記不會乖乖待在正確的位置，而是會往旁邊偏移。
解決方案
問題出在標記的「對齊點」設定錯誤。想像標記是一根圖釘，圖釘的尖端應該插在餐廳的座標上，但預設是用圖片的左上角對齊，當然會跑掉。我請 AI 調整 CSS，讓水滴形標記的尖端剛好對準座標點，這樣不管怎麼縮放地圖，標記都會穩穩地釘在正確位置。
問題二：連續點擊時動畫消失
如果上一個標記的脈衝動畫還沒結束，就點擊另一個餐廳，新的標記不會有動畫效果。
解決方案
問題是舊的動畫還在執行中，程式沒有正確清除。我請 AI 加入邏輯：每次點擊新餐廳時，先把前一個標記的動畫強制停止並恢復原狀，再啟動新標記的動畫。
問題三：只有第一個餐廳有動畫
在電腦版，點擊列表中的餐廳時，只有最上面的那間會有脈衝動畫，其他的都沒反應。
解決方案
問題出在程式找標記的方式有誤。原本是用餐廳在列表中的順序來找對應的地圖標記，但列表順序會隨著篩選條件而改變。後來改成用餐廳的座標來比對，這樣不管列表怎麼排序，都能正確找到對應的標記並觸發動畫。
第四階段：部署與上線
當本地開發測試完成後，下一步就是把網站部署到網路上讓所有人都能使用。這個專案我選擇使用 Netlify 作為部署平台，搭配 GitHub 進行版本控制。
1. 本地測試 Netlify 環境
在正式部署之前，我先請 Google Antigravity 的 AI 在本地模擬 Netlify 的運行環境進行測試。因為專案有用到 Netlify Functions（處理 Gemini API 呼叫，使 API key 不會曝露在前端），這些功能在一般環境下無法測試，必須使用 Netlify CLI 才能模擬。
2. 建立 GitHub Repository
為了讓 Netlify 能夠自動部署，需要先把程式碼上傳到 GitHub：
- 在 GitHub 建立一個新的 Repository
- 請 AI 協助我把本地專案連結到這個 Repository
- 請 AI 將.env 檔案放入 .gitignore，避免 API Key 被上傳到 GitHub
3. 設定 Netlify 專案
- 前往 Netlify 註冊或登入帳號
- 選擇「Add new site」→「Import an existing project」
- 連結 GitHub 帳號，選擇剛剛建立的 Repository
- Netlify 會自動偵測專案類型（Vite），並填入預設的建置指令
- 設定環境變數
- 點選「Show advanced」→「New variable」
- 把所有原本在 .env 的 API Key 都貼上
- 點選「Deploy」開始部署
部署完成後，Netlify 會給你一個隨機的網址（可以再自行調整），這時候就可以在網路上看到你的網站了！
發佈網站的部分 Implementation Plan
4. 設定正式網域後的調整
網站上線後，需要回到各個平台更新授權網域，否則部分功能會無法正常運作：
- Firebase Console
- Authentication → 設定 → 授權網域 → 新增 Netlify 的網址
- Google Cloud Console
- 憑證 → 你的 API Key → 網站限制 → 新增 Netlify 的網址
- OAuth 同意畫面 → 授權網域 → 新增 Netlify 的網址
第五階段：後續版本更新
設定完成後，之後的更新就非常簡單：
- 在本地修改程式碼
- 請 AI 把更新推送到 GitHub（
git push） - Netlify 會自動偵測到 GitHub 有新的提交，自動觸發部署
- 幾分鐘後，網站就會更新完成
這樣的流程讓我可以隨時修改、隨時上線，不需要手動上傳任何檔案。
心得
這是我第一次完整使用 AI 協助完成一個相對成熟的專案成果。整體過程中，我深深感受到 AI 所帶來的效率提升，許多看似難以突破的問題，往往能在 AI 的輔助下快速獲得可行解法；但在實際開發與決策過程中，人類仍需扮演關鍵的判斷與整合角色。以下整理幾點我在實務操作中的具體體會：
- 當遇到複雜錯誤、需要多步判斷的 bug 時，將問題完整描述並交由 AI 協助分析，常能幫助釐清可能的解法路徑，而不必急著直接請他動手修改程式碼
- 個人認為在需求規劃（Planning）或生成圖片等階段，Gemini Pro 整體效率較高；而在程式碼撰寫與除錯方面，Claude Opus 4.5 的表現相對更為穩定且易於理解
- 當某個問題一直無法解決時，可以嘗試開啟新的一輪對話或是替換其他模型進行提問，有機會困難馬上就迎刃而解
- 當想要優化某個功能時，可以請 AI 先列舉有哪些可以提整的方向，經過通盤的考量再做決策
- 對於尚未具備明確視覺概念的情境，可先請 AI 協助生成示意圖片，藉此快速建立整體風格與方向，並且一直請他生成圖片調整，直到滿意後再開始撰寫程式碼
從一個想解決生活中實際問題的想法出發，到真正完成並上線，這段過程本身就是最珍貴的收穫。AI 讓這條路走得更快，但每一個選擇與調整，仍然來自人的判斷，也希望大家都能夠有機會開發屬於自己的小小專案！
常見問題
Q1：我不是資訊相關科系，也沒有寫過程式，真的能照這篇文章做出 App 嗎？
A：可以，而且這正是 Google Antigravity 最有價值的地方。
這套工具的重點是能幫你把「想法」一步步轉成「可以運作的東西」。即使你不懂全端架構，也可以先從描述需求、功能邏輯開始，再讓 AI 協助產生對應的程式碼。過程中你學到的，反而是「怎麼把問題說清楚」，而不是硬背語法。
Q2：如果我看不懂 AI 產生的程式碼，會不會很容易卡關？
A：一開始看不懂很正常，而且不需要全部看懂。
對我來說，我其實從頭到尾都沒有完全理解程式碼再寫什麼，但是我可以隨時請 AI 解釋給我聽，或是看他檔案的命名邏輯或是當下再問的問題，其實久而久之也可以大概知道目前的程式碼跟哪個功能是相關的，個人覺得這樣對於非專業背景的人就很足夠了。
Q3：這樣做出來的作品，對學生或斜槓者真的有幫助嗎？
A：非常有幫助，而且我認為是非常難得的經驗。
一個完成度不必完美、但能實際運作的小專案，本身就是很好的學習成果。它能幫你確認自己對產品、設計或技術的興趣，也能成為未來申請計畫、面試或展示能力的素材。比起只停留在「想法」，真正做出來一次，收穫會大很多。
