這份報告記錄了我高二的一年之中，開發「食決 Foodie Choice」App 遭遇高昂 API 費率、AI Agent 刪庫、多端競態等瓶頸，如何在限制中突圍，找到獨立工程解法。
高一時，我聽到台灣駭客協會理事長說：「在座各位的密碼，我都可以調出來。」 這句話徹底擊中了我，點燃了我對自動化與程式的渴望。
隨後我曾想開發「智慧醫療 AI」，但缺乏專業醫學知識與訓練資料，遭遇首次失利。進入高二，我決定腳踏實地，做一個能真正解決生活痛點（午餐吃什麼的選擇困難）的 App ── 「食決 Foodie Choice」。
模擬駭客在座談會上，如何在極短時間內對常見帳戶安全漏洞完成暴力破解：
為了載入美食地圖與精準搜尋，我引入了業界標準的 Google Places API。但在實際運作中，這並非單次請求那麼簡單：Places API 的 Place Autocomplete（輸入提示）與 Place Details（詳細資訊）採二階段收費，一次搜尋往往觸發多次 API 計費，使得開銷呈指數型放大。
在缺乏快取優化的前期，僅是幾位好友日常測試，短短幾週我就面臨了高達 NT$12,000 元 的天價帳單。這面高昂的資金巨牆，逼得我必須從底層重新思考系統資料流。
拖動滑桿，模擬每日餐廳載入次數對開發預算的劇烈衝擊：
醒來後我靈感爆發：「為什麼要每一次都向 Google API 直連？既然網友都聚在一起吃，當一個人在 App 查了某間餐廳，直接把它快取回我們自建的雲端，其他人查的時候讀我們的快取不就免費了？」
我利用 Supabase 做為雲端中心，並以 PostgreSQL PostGIS（地理資訊系統擴充）進行半徑 500 公尺內的餐廳快取搜尋（ST_DWithin 座標比對）。當使用者定位時，App 優先調用本地與雲端快取的「共享美食庫」，查無資料時才直連 Google API 並以 UPSERT 原子操作寫回雲端。這套眾包快取架構讓費用徹底歸零！
在精神與課業雙重夾擊的技術深水區中，各種難題接連爆發。除了一次 AI Agent 重構規則失誤、一鍵將整個專案執行檔全部抹除的驚險場面外，最難纏的是多人即時投票房的多端狀態同步與競態條件 (Race Condition)：多人同時修改狀態常導致狀態被覆蓋或重複打勾。
對此，我深入研讀 GitHub 開源專案與 Websocket 機制，在資料庫端設定 Row-Level Locking (行鎖) 確保併發寫入安全，並透過 Riverpod 拆分數據流以隔離狀態。而資料庫 Trigger 因發信 Edge Function 逾時導致交易連鎖回滾報 500 錯誤，則以 EXCEPTION WHEN OTHERS THEN 捕捉容錯解決。
獨立開發真的很累，也很貴。一邊兼顧課業一邊寫涉及即時同步、雲端觸發與安全防禦的 App，有數不清的夜晚想要放棄。但看到投票房能 0 毫秒極速同步、看到精緻的小工具完工、看到自建眾包資料庫把 API 帳單歸零，這些都磨練出我不畏挫折的工程師思維。