中文用語統一大作戰：從小細節到底層穩定，這週我修了哪些坑
本來計畫把時間放在核心功能的優化，結果一打開產品分析服務的介面，先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異，卻會讓品牌商覺得產品不夠專業，也影響他們的信任。想到我們的客群特別在乎質感，我還是把今天的重心從新功能挪開，展開一場用語清掃。 原本只想改幾
文章目次
文章。
寫過的文章都在這裡，從最近的一篇開始。
第 4 頁，共 5 頁
AI 分類越做越複雜，是在挖坑還是填坑？
AI 分類越做越複雜，是在挖坑還是填坑？ 這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、紀錄，到架構設計全被牽出來重整。 先談分類。 起手式很直接：把產品名稱與描述丟給模型，取
從「重構深淵」回到「產品價值」
這週又走進熟悉的重構循環：API 架構、頭像 URL 的 timestamp 快取、副作用處理、訪客帳號暱稱同步，以及 FindSkin 的命名與流程一致性。每個小改動都牽出更大的設計問題，讓人不免自嘲「又在自找麻煩」。但冷靜看，這些牽動其實都指向同一件事：早期設計沒有把未來使用
FindSkin：從命名到體驗，把混亂收回來
記錄 FindSkin 當時的命名、問卷與介面整理，補上 cosGlint 1.2.4 演算法與 10 種膚質分類的後續文章。
看不見的細節，為什麼值得？
今天的開發原本很單純：做一個訪客帳號。實作後卻發現，難的是讓它用起來一致、可信。這一整天的折返，讓我更確定：產品的差異，往往來自那些使用者不會主動說出口、卻一直感受到的細節。 一、身分與名稱要一致。一開始我以為 localStorage 放個暱稱就好。等到遇到「訪客是否能轉成正
重構永遠不是「只是改一下」的事
今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一碰到 loading 與 error 處理，才發現 API 根本沒涵蓋這些情境，只好連同整包一起重整。有人會問：「真的有必要動 API？用戶會在意嗎？」我很確定，這種
API 重構後的幾點實話：技術債、產品判斷與下一步
API 重構後的幾點實話：技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積
Email 驗證、會員系統與那些「看似簡單」的更新紀錄
今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 em
把炸彈拆完，才有力氣往前走
游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走 有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log
Dockerfile、環境變數與 API endpoint：一次把坑補齊的週記
這兩天主要在補技術債、梳理架構，過程當然少不了自我懷疑，但也總算把幾個老問題處理好了。 先是 Dockerfile。昨晚就覺得哪裡怪，早上看 deployment log 才確認：前端 CORS 一直叫，後端 API 的 domain whitelist 根本沒吃到。追了半天發
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應 這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是
當重構像多米諾骨牌：從小修到整體優化的一週
延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都得重新整理。雖然頭疼，但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使用