03 / WORK / CASE STUDY
Naily — AI 美甲電商 App
Flutter 電商 App:裝置端 AI 指甲辨識、AR 試戴與客製穿戴甲。2025 年 11 月起由我接手全部開發與維護。
- TYPE
- MOBILE APP
- SCOPE
- 上架準備 · 2025.11 起接手
- STACK
- FLUTTER · ONNX · FIREBASE · ECPAY
- LINKS
- 公司內部專案(不公開)
01 / PROBLEM
穿戴甲是高度客製化的商品,消費者難以自行判斷指甲尺寸,線上下單常因尺寸不合而退換貨。這個 App 用手機相機加裝置端 AI 取代到店量測,把「設計 → 尺寸辨識 → AR 試戴 → 下單 → 金流物流」整合成單一流程。
02 / CONSTRAINTS
- 接手一個由原團隊建置的多人 codebase(接手前 198 個 commit),沒有交接期。
- AI 推論必須在裝置端執行,受手機算力限制——接手時的 AR 試戴只有 1 FPS。
- 涉及金流與個資:token 只能放 secure storage、日誌不得記錄完整 request body、iOS 需處理 ATT 追蹤同意;目前處於上架準備階段(P0–P2 上架就緒稽核修復中)。
03 / ARCHITECTURE
Flutter 模組化單體:feature-first 分層(config / models / services / screens),GoRouter 宣告式導航——82 個畫面、72 個 service、44 個 model,共 533 個 Dart 檔、約 12.9 萬行,呼叫後端 123 個 API 端點。
裝置端 AI 拆成 6 個職責分離的 AR/CV 套件,以 ONNX Runtime 執行 4 個模型(YOLO11 指甲偵測/分割、手掌關節點),iOS 另以 platform channel 銜接原生 CoreML。商務面整合 ECPay 金流/物流/電子發票與四家社交登入;Firebase 負責推播、Crashlytics 與分析;CI 有三條 pipeline(兩階段 CI、夜間全量 E2E、tag 觸發簽署發版)。
04 / RESPONSIBILITIES
2025 年 11 月接手;此前的基礎架構與商城流程由原團隊建置。接手後的開發、維護與發版由我負責(該期間 121 個 commit、占 85%):FCM 與追蹤整合、客製穿戴甲功能、點數系統、AR 架構重寫、iOS CoreML 原生層、安全硬化與 CI/CD。後端 API 為獨立服務,不在此 repo 範圍。
05 / CHALLENGES → SOLUTIONS
CHALLENGE
接手時的 AR 試戴只有 1 FPS,偵測時設計圖還會閃爍漂移。
SOLUTION
汰換三代舊實作,重寫為五個職責分離的套件(偵測、渲染、傳統 CV、遮罩重上色、手動工作室),iOS 改走原生 CoreML 偵測;再加跨幀遲滯消除閃爍。FPS 從 1 提升到即時,核心偵測頁從 3,051 行減到 1,356 行。
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 / SYSTEM FACTS
82
畫面
~129k
Dart 行數
121
接手後 commits
64
測試檔(單元+整合)
07 / LESSONS
接手程式碼的第一步不是重構,是把慣例寫下來——規則明文化之後,每一次修改才會讓系統更一致,而不是更發散。
佐證要以 git 為準:這個專案的 CHANGELOG 是事後重建的,日期與實際 commit 對不上。重要記錄應該跟 tag 一起產生,而不是回頭補寫。
NEXT
Naily 電商前台與 Canvas 客製化設計工具