Sign in Subscribe

YI

Taiwan

中文用語統一大作戰：從小細節到底層穩定，這週我修了哪些坑

本來計畫把時間放在核心功能的優化，結果一打開產品分析服務的介面，先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異，對品牌商用戶的專業感和信任度卻是很實在的扣分。想到我們的客群特別在乎質感，我還是把今天的重心從新功能挪開，展開一場用語清掃。原本只想改幾個明顯錯誤，一搜 repo 才發現同一概念居然有十幾種搭配方式。最後我從使用情境與用戶習慣出發，整理了一份用語表，將「提交資料」「新增商品」一律統一為「上傳產品」。順手檢查之前的 log，也驚覺開發初期為了快，留下了 test.log、debug.log、temp.log 等臨時檔，甚至沒被 .gitignore 排除。這些東西被 commit 進 repo，真的不行。於是我把怪異的日誌檔案全數加入忽略規則，清乾淨殘留檔案，整個專案視覺與結構都清爽許多。如果說這天的成果看起來不炫炮，那這週整體就是一場「挖坑與填坑」的連續劇：AI

AI 分類越做越複雜，是在挖坑還是填坑？

AI 分類越做越複雜，是在挖坑還是填坑？這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。先說分類。起初的做法很直接：把產品名稱與描述丟給模型，拿回分類結果就寫進資料庫。實際跑了才發現，回傳格式不穩定，JSON 有時多空格或斷行，parse 會炸。我先補了 try-catch、把原始回應與錯誤一併記錄，至少 debug 不再摸黑。更大的問題是分類的邏輯本身：現實裡很多產品會對應多個類別（保濕、防曬、抗老化），單一分類不合理。最後把產品與分類改成多對多關係，資料庫 schema 重構、API 路由也重排，分類功能的 URL 更直覺。趁勢把產品 ID 改成

從「重構深淵」回到「產品價值」

這週又走進熟悉的重構循環：API 架構、頭像 URL 的 timestamp 快取、副作用處理、訪客帳號暱稱同步，以及 FindSkin 的命名與流程一致性。每個小改動都牽出更大的設計問題，讓人不免自嘲「又在自找麻煩」。但冷靜看，這些牽動其實都指向同一件事：早期設計沒有把未來使用情境想清楚。短期看不痛不癢，長期就是技術債，會拖慢產品節奏。具體進展： * FindSkin 流程重新梳理，命名與 API／資料表／UX 一致；問卷輸入驗證補強，並在 API 層加上日誌，預防異常輸入。 * 個人化分析的動線重做：由「用戶要自己回到歷史紀錄找結果」改成系統主動引導，看得到、看得懂、看得快。這種體驗上的「短路」比功能多十個更有價值。最大感受：我常把重構當成一次解決所有問題的機會，結果每次都把事情做大。工程師的完美主義很好，但要分清楚「

FindSkin：從命名到體驗，把混亂收回來

這兩天都在跟「膚質分析」這件事纏鬥。原本系統裡有「膚質檢測」、「肌膚分析」、「問卷調查」三種叫法，越看越不順，乾脆全部統一成 FindSkin。結果一改名才發現，牽一髮動全身：API 路徑、資料表、前端組件、token 邏輯都得一起動。commit 的時候我一直在念自己：「當初命名到底在趕什麼？怎麼會放著這麼不一致的東西不管。」還好順手把 API token 的處理重構掉，意外抓到一個埋在 URL 裡的空格，難怪之前測試總有股不對勁。回頭看問卷流程，沒有進度條這件事說不過去。現在誰還做問卷不給進度？所以加了狀態管理跟進度顯示，提交後自動跳結果頁。前端則把標語做成堆疊，抓重點字句，層次清楚很多。這段時間確實花在 CSS 和排版上不算少，我也不免自問：「是不是又過度設計了？用戶真的在意透明度 0.6 跟 0.7

訪客帳號到底該怎麼設計？我有點後悔了 🤔

今天原本只是想「順手」把訪客帳號做起來，結果整個上午都被 AuthProvider 綁住。昨天還天真以為用 localStorage 放個暱稱就好，實作下去才知道麻煩在細節：訪客要不要能轉正式帳號、名稱怎麼同步、初始化狀態怎麼顯示，這些都不是一兩行就能搞定。名稱同步最卡。一開始打算在 ProfilePage 處理，但切頁時會閃一下，整個很不專業。最後把邏輯拉回 AuthProvider，用 isInitialized 管初始化，至少不會再出現奇怪的名稱閃爍。只希望不要再冒出什麼邊界情況，真的拜託。下午切到產品評論功能。訪客能不能留言這題，暫時定案：訪客不能直接留言，但會有「訪客資訊提示框」引導註冊，保留互動性，又不怕被 spam 灌爆。一起做了 @ 提及功能，本來 API 只存使用者名稱，後來想到改名就會爆，改成存使用者 ID，資料一致性才算穩。晚上塞進去一直想做的膚質檢測。通知用了

重構永遠不是「只是改一下」的事

今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一動到 loading 與 error 處理，才發現 API 壓根沒把這些場景算進去，只好整包重整。有人會問：「真的有必要碰 API？用戶會在意嗎？」我很清楚，這種邊角不處理乾淨，之後一定回來咬人。另外，之前為了避快取加的 timestamp 參數也被我拆了。看似能解快取問題，實際上讓圖片 URL 每次都不同，反而破壞瀏覽器快取。最後改成在上傳或刪除頭像時主動重置預覽 URL，用戶看到更新更即時、更順。順手把顏色生成函式也修了一下，避免測到那種詭異的橘綠色組合。下午做產品評分與評論時，又卡在「要不要開放訪客留言」。直覺是開放，互動會增加；但想到 spam 防治與認證成本，最後先保守，暫時只給登入會員評論，之後再看情況調整。這種決定難免自我懷疑，

API 重構後的幾點實話：技術債、產品判斷與下一步

API 重構後的幾點實話：技術債、產品判斷與下一步這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積的技術債至少清了一大段。從工程面看，收益很明確。環境變數的自動化腳本雖然寫起來不輕鬆，但部署的穩定度立刻提升，手動改錯的風險幾乎清零；API endpoint 統一後，前端開發少了不少「猜測」與重複修正，後端安全性也更乾淨。這些是值得記上一筆的地方。但回過頭來，技術債的代價比想像中高。像 endpoint 不一致、URL 寫死在 component、會員系統初期規劃不足，當下看都不急，累積到這週就一次爆掉，時間與心力都被吃掉。結論很直接：之後每次上新功能，都要把「技術債清單」列入例行工作，而不是等到事情變大再處理。