02 / WORK / CASE STUDY
AI 美甲平台
AI 指甲辨識、AR 試戴、設計師平台到 CRM 與 POS 的完整商業系統。
- TYPE
- FULL STACK
- SCOPE
- AI × AR × 商城 × POS
- STACK
- AI · AR · DJANGO · REACT · B2B
- LINKS
- 公司內部專案(不公開)
01 / PROBLEM
同一個平台有兩張面孔:對消費者是 AI 指甲辨識與 AR 試戴;對商家與內部團隊,則是一套涵蓋商品、訂單、庫存、B2B 報價結算、促銷與財務的營運後台。這份 case study 聚焦目前可公開的部分——約 50 個業務模組的營運後台前端。
02 / CONSTRAINTS
- 公司商業專案,程式碼與業務細節不公開。
- 業務範圍極廣且持續擴張:單一 SPA 要同時守住 bundle 體積、一致性與可維護性。
- 前後端不共享型別:API 契約靠慣例與集中式的錯誤標準化來維持。
03 / ARCHITECTURE
平台由多個服務組成:主業務 API(Django REST Framework)加上獨立的審批微服務;營運後台是 React 18 + Ant Design SPA,約 60 萬行程式碼,service 層依業務領域拆成 128 個檔案、共 1,951 個 API 呼叫點,元件層依模組切成 50+ 個資料夾。
橫切關注全部收斂在單一 Axios 攔截層:JWT 自動附加、401 刷新佇列、403 全域權限廣播、錯誤 toast 去重、json-bigint 處理大數精度。瀏覽器內以 TensorFlow.js 做影像物件辨識,認證支援 WebAuthn/Passkey,30+ 個 feature flag 控制功能開關,CI 設有 bundle 體積閘門。
04 / RESPONSIBILITIES
營運後台前端:2025 年 9 月起接手為唯一貢獻者(330 個 commit、佔全庫 72.8%),初版骨架由原團隊於 2025 年 8–9 月建立;接手後統一響應式與錯誤處理架構、重建深色模式與 design token,並執行四輪跨模組稽核與修復。另負責平台後端(Django)API 的設計與開發。
05 / CHALLENGES → SOLUTIONS
CHALLENGE
JWT 過期的瞬間,數十個進行中的請求會同時觸發 refresh。
SOLUTION
401 一律進入刷新佇列:只發一次 refresh,成功後重放所有排隊請求。同一個攔截層順帶標準化後端的逐欄位驗證錯誤,表單層直接顯示、不再各自解析。
CHALLENGE
50+ 個模組全部打包,首屏會被拖垮。
SOLUTION
路由層級懶加載搭配 feature flags 控制功能面;CI 以 bundle 體積閘門把關,讓體積成長永遠是「被看見的決定」而不是意外。
CHALLENGE
一輪涵蓋工作流程、表單、權限、無障礙與效能的企業級稽核,產出 163 筆原始發現;其中最高槓桿的一類,是跨 4 個以上模組重演的「假成功」反模式——表單顯示儲存成功但沒有真正寫進後端、按鈕顯示成功但功能早已被靜默停用。
SOLUTION
163 筆先去重為 49 筆;21 筆 Critical/High 逐一交叉驗證(21/21 確認為真)後才投入修復,對應 18 個批次的系列 commit——含修正假成功動作、讓 8 個佣金相關檔案改回統一的 errorHandler。其餘 28 筆 Medium/Low 如實列管、未虛報進度。
CHALLENGE
庫存尺寸頁的表格與提示框會不斷向下延伸、撐爆容器——而且只在有實體捲軸的瀏覽器重現。headless 測試用的是不佔空間的 overlay 捲軸,自動化截圖完全看不出異常,一度被誤判為「已穩定」。
SOLUTION
根因是表格自帶 scroll 與 fixed 首欄,和全域的 overflow-x:auto 疊成兩層水平捲動容器,fixed 欄再觸發 Ant Design 的 ResizeObserver 反覆重量測,形成「捲軸出現 → 容器變窄 → 再量測」的迴圈。移除該表格自己的 scroll/fixed、交給全域 wrapper 做單層捲動,並以 Playwright 在 1280/900/600/375 四種寬度驗證穩定不溢出。
06 / SYSTEM FACTS
91
管理路由
~600k
前端程式碼行數
1,193
測試案例(Jest + E2E)
72.8%
個人 commit(330/453)
07 / LESSONS
前後端沒有共享型別時,最划算的契約投資是在攔截層統一錯誤格式——比逐表單處理省下數十倍的重複工作。
技術債要掛編號才會被還:有編號、有優先級的稽核項目會被逐一清償;「有空再修」的那個「有空」永遠不會來。
「操作顯示成功」和「資料真的被寫入」是兩件要分開驗證的事:這輪稽核重複率最高的反模式就是假成功——toast 亮了,資料卻沒有持久化。寫入類操作上線前,要同時確認使用者看到的回饋與後端的資料狀態一致。
NEXT
Naily — AI 美甲電商 App