03 / WORK / CASE STUDY
Naily — AI 美甲電商 App
Flutter 電商 App:商城、客製穿戴甲與金流。2025 年 11 月起由我接手 App 前端的開發與維護;裝置端 AI 與 AR 模組屬於另一個團隊。
- TYPE
- MOBILE APP
- SCOPE
- 雙平台上架 · 2025.11 起接手
- STACK
- FLUTTER · FIREBASE · ECPAY
- LINKS
- APP STORE GOOGLE PLAY
01 / 問題
穿戴甲是高度客製化的商品,消費者難以自行判斷指甲尺寸,線上下單常因尺寸不合而退換貨。這個 App 用手機相機加裝置端 AI 取代到店量測,把「設計 → 尺寸辨識 → AR 試戴 → 下單 → 金流物流」整合成單一流程。
02 / 限制
- 接手一個由原團隊建置的多人 codebase(接手前 198 個 commit),沒有交接期。
- 裝置端的 AI 指甲辨識與 AR 試戴由另一個團隊負責,不在我的工作範圍;這份案例只涵蓋這些模組以外的 App 前端。
- 涉及金流與個資:token 只能放 secure storage、日誌不得記錄完整 request body、iOS 需處理 ATT 追蹤同意;上架前完成 P0–P2 上架就緒稽核修復,現已於雙平台上架。
03 / 架構
Flutter 模組化單體:feature-first 分層(config / models / services / screens),GoRouter 宣告式導航——82 個畫面、72 個 service、44 個 model,共 533 個 Dart 檔、約 12.9 萬行,呼叫後端 123 個 API 端點。
裝置端 AI 與 AR 模組(ONNX Runtime 上的指甲偵測/分割與手掌關節點模型、iOS 的 CoreML 銜接)由另一個團隊建置與維護,本案例不涵蓋。我負責的商務面整合 ECPay 金流/物流/電子發票與四家社交登入;Firebase 負責推播、Crashlytics 與分析;CI 有三條 pipeline(兩階段 CI、夜間全量 E2E、tag 觸發簽署發版)。
04 / 負責範圍
2025 年 11 月接手;此前的基礎架構與商城流程由原團隊建置。接手後 App 前端的開發、維護與發版由我負責(該期間 121 個 commit、占 85%):FCM 與追蹤整合、客製穿戴甲功能、點數系統、巨檔拆分、安全硬化與 CI/CD。裝置端 AI 與 AR 模組由另一個團隊負責;後端 API 為獨立服務,不在此 repo 範圍。
05 / 挑戰與解法
CHALLENGE
核心畫面是數千行的巨檔:訂單詳情 5,256 行、結帳 3,416 行,改一處動全身。
SOLUTION
訂下每檔 800 行的上限,依 UI 區塊與邏輯拆分:訂單詳情 5,256 → 230 行(邏輯抽離)、購物車/結帳/訂閱結帳三巨檔合計 6,800 → 1,200 行加獨立元件。
CHALLENGE
Token 一過期使用者就被登出,而上架前的安全防護也不足。
SOLUTION
在 7 個 service 加入 401 攔截刷新(自動續期不中斷);上架硬化含原生層混淆、Dart obfuscate、憑證綁定與 root/越獄偵測。
06 / 系統事實
82
畫面
~129k
Dart 行數
121
接手後 commits
64
測試檔(單元+整合)
07 / 學到的事
接手程式碼的第一步不是重構,是把慣例寫下來——規則明文化之後,每一次修改才會讓系統更一致,而不是更發散。
佐證要以 git 為準:這個專案的 CHANGELOG 是事後重建的,日期與實際 commit 對不上。重要記錄應該跟 tag 一起產生,而不是回頭補寫。
NEXT
Naily 電商前台與 Canvas 客製化設計工具