MenuGenie

MenuGenie 是一款已上架 App Store 的 iOS 菜單翻譯產品。我把一個原本停留在課程合作階段的 AI 菜單翻譯 prototype，持續推進成能在真實旅遊情境中使用的產品，讓使用者能在餐廳現場更快看懂外語菜單，而不只是拿到一段脫離原始版面的翻譯文字。

外語菜單的困難，不只是把文字翻成另一種語言，而是在餐廳現場，使用者通常沒有時間慢慢比對一份複雜菜單。真實菜單常同時包含直排與橫排文字、多欄排版、價格緊貼菜名，以及不同字體與尺寸混用；如果翻譯結果脫離原始版面，使用者仍然得自己重新對位置、價格與說明，理解成本沒有真正下降。很多時候，使用者只是想盡快知道自己能不能吃、該點什麼，而不是把整份菜單當文件慢慢讀。

另一個問題是，既有工具常只做到字面翻譯。遇到地方料理、特殊食材或不直觀的菜名時，使用者常常還得跳去別的 app 查菜色、查食材或查過敏原，再回頭重新理解同一份菜單；有些工具甚至會讓 overlay 蓋錯位置，或在切出搜尋之後得重新上傳圖片。MenuGenie 要補的，就是這段在點餐現場被反覆打斷的理解流程，讓使用者能在同一個產品裡完成閱讀、判斷與延伸查詢。

這個專案分成兩個階段。前期它是在課程合作專案中成形的產品 prototype，我在那個階段擔任 iOS 前端總負責人，負責把相機拍攝、翻譯頁面、overlay 呈現、多種閱讀模式與核心互動流程做成可操作的 iOS 產品雛形。

後期則由我持續獨立推進，把它從可展示的 prototype 做成已上架、可部署、可維護的產品。這一段不只包含功能延伸，也包含後端架構收斂、效能診斷、Cloudflare 邊緣流量處理、成本防護，以及 iOS 端的穩定性與排查能力補強。

早期我先把後端能力落成為完整的 iOS 使用流程，讓使用者能從拍照進入翻譯頁，再透過 overlay 疊字與多種閱讀模式理解菜單內容。後續我把這條流程往產品化方向繼續推進，補上多頁菜單操作、歷史回放、地圖探索與菜色補充資訊，讓 MenuGenie 從一次性的拍照翻譯畫面，變成一個能支撐重看、比對與延伸查詢的產品流程。

在系統端，最初版本原本採用 Java Spring Boot、獨立 Python OCR service、Cloud SQL 與 AWS S3 的混合工程結構。這套做法在早期 prototype 階段能運作，但進入後續獨立推進與長期維護後，就開始暴露出技術棧割裂、部署流程分散與月成本偏高等問題。後續我把它整合到 GCP 為主的平台上，收斂成以 FastAPI、Cloud Run、Firestore 與 GCS 為主的部署形態，並同步補上雲端清理與成本控制機制，讓這個 side project 的維運開銷能被實際壓低。

在後端效率上，我也處理了幾個直接影響等待體感的問題。我先透過前後端時間線拆解定位 OCR 等待來源，確認瓶頸不在 Document AI 本身，而是在 GCS 上傳、縮圖產生與 Firestore 寫入等同步附帶工作；後續再調整任務順序，並把不影響第一波可讀結果的工作移到背景處理，實際把 OCR 流程時間從 10.21 秒壓到 6.36 秒。為了讓後續排查與中斷情境也更可控，我之後再補上 OSLog 結構化紀錄、task cancellation / interruption cleanup 與 CameraService 模組化，把效能、穩定性與維護基礎一起補齊。

前端是 iOS 原生 app；後端以 FastAPI 為主，搭配 Google Document AI 做 OCR，並以 Firestore 與 GCS 承接狀態與儲存。為了應對多區域使用，我把服務部署在澳洲與新加坡兩個 Cloud Run 區域，並以 Cloudflare Worker 做地區分流，讓 app 端只面對單一入口。

• App Store 全地區可用
• 已上架 App Store
• OCR 流程時間：10.21 秒 -> 6.36 秒
• 預估每月成本：70 澳元 -> 不超過 3 澳元