MenuGenie

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

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

另一個問題是，既有工具常只做到字面翻譯。遇到地方料理、特殊食材或不直觀的菜名時，使用者常常還得切到其他 App 查菜色、查食材或查過敏原，再回頭重新理解同一份菜單；有些工具甚至會讓 overlay 蓋錯位置，或在切出搜尋之後得重新上傳圖片。MenuGenie 的目標，是在同一個流程中提供 AI／LLM 翻譯，以及對菜色、食材與過敏原的延伸查詢，讓使用者能直接閱讀與判斷。

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

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

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

在系統端，最初版本原本採用 Java Spring Boot、獨立 Python OCR service、Cloud SQL 與 AWS S3 的混合工程結構。這套做法在早期 prototype 階段能運作，但進入後續獨立推進與長期維護後，就開始暴露出技術棧割裂、部署流程分散與月成本偏高等問題。後續我把後端重構為以 Python 為主的 FastAPI，並將雲端服務集中在 Google Cloud：以 Cloud Run 的無伺服器容器服務部署，搭配 Firestore、GCS 與 Google Document AI。這讓後端語言、雲端服務與外部 AI 服務集中在同一套平台，部署與維護路徑更一致，也降低了成本。

在後端效率上，我也處理了幾個直接影響使用者等待時間的問題。我先透過前後端時間線拆解定位 OCR 等待來源，確認瓶頸不在文字辨識本身，而是在圖檔雲端備份、縮圖生成與資料儲存等同步附帶工作；後續再調整任務順序，並把不影響第一波可讀結果的工作移到背景處理，實際把整個 AI／LLM 翻譯流程時間從 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 全地區上架
• 上架至今累積 150 次下載
• AI／LLM 翻譯與菜色、食材、過敏原延伸查詢
• AI／LLM 翻譯流程：10.21 秒降至 6.36 秒
• 每月成本：低於 3 澳元