Dev
AI 分類越做越複雜，是在挖坑還是填坑？ 這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。 先談分類。 起手式很直接：把產品名稱與描述丟給模型，取回分類結果後寫進資料庫。實際跑才發現兩個問題 1. 回傳格式不穩：JSON 偶爾多空格或斷行，導致 parse 失敗。我先加上 try-catch，並把原始回應與錯誤完整記錄，至少 debug 不再摸黑。 2. 分類邏輯不合理：現實中同一產品常對應多個類別（如保濕／防曬／抗老化），單一分類會誤導。 因此進行重構： * 將「產品—分類」改為多對多，重整資料庫 schema； * 重新排 API
Dev
Ingrelens 這次整理 FindSkin，我不只做功能，而是回到產品要解決什麼：先扎實研究文獻、設計情境題，再用權重公式準確定位膚質類型，最後把結果落到五維雷達圖的可視化呈現。 命名統一為 FindSkin：語意是一切互動的入口 過去「膚質檢測／肌膚分析／問卷調查」並列，容易讓溝通產生分岔，統一命名，等於把概念收攏成一條路，API、資料表、前端組件與 token 邏輯一起對齊，降低學習與維護成本，讓產品後續能長在同一根骨架上。 加上進度條與狀態管理：用可預期感建立信任 FindSkin 設計成 1 分鐘輕量工具，核心價值在「我知道還要多久、接下來會發生什麼」。進度顯示與提交後自動跳結果頁，是把不確定感清掉，讓人更願意完成。前端把標語做成層次分明的堆疊，哪怕是透明度 0.6 與 0.7 的選擇，都是在調整注意力，讓理解更快。 重寫首頁與介紹：
Dev
今天的開發原本很單純：做一個訪客帳號。實作後卻發現，真正的難題不在「能不能用」，而在「用起來是否一致、可信」。這一整天的折返，讓我更確定：產品的差異，往往來自那些用戶不會主動說出口、卻一直被感受到的細節。 一、身分與名稱的一致性不是錦上添花 一開始我以為 localStorage 放個暱稱就好。等到遇到「訪客是否能轉正」「名稱如何同步」「初始化狀態怎麼顯示」這些情境，才知道「一致性」是一個系統性問題。把名稱同步拉回 AuthProvider，用 isInitialized 管初始化，表面上只是消除 UI 的「閃一下」，本質上是在建立信任：系統不跳針、狀態不自打臉，用戶願意繼續投入注意力。 二、互動設計的邊界：保留動機，拒絕濫用，產品評論的設計，我刻意不讓訪客直接留言，而是用「訪客資訊提示框」引導註冊。這個取捨看似保守，目標卻很清楚：
Dev
今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一碰到 loading 與 error 處理，才發現 API 根本沒涵蓋這些情境，只好連同整包一起重整。有人會問：「真的有必要動 API？用戶會在意嗎？」我很確定，這種邊角不處理乾淨，之後一定回頭咬人。 另外先前為了避快取加上的 timestamp 參數也拆掉了。看似能解決快取，實際卻讓圖片 URL 每次都不同，反而破壞瀏覽器快取。最後改成在上傳或刪除頭像時主動重置預覽 URL，用戶看到更新更即時、更順。同時也把顏色生成函式修了一下，避免測到那種詭異的橘綠色組合。 下午做產品評分與評論，又卡在「要不要開放訪客留言」。直覺是開放能提升互動，但想到 spam 防治與認證成本，最後先保守，只開放登入會員評論，後續再看數據調整。這類決定難免自我懷疑，但先把基礎守住更務實。 在
Dev
API 重構後的幾點實話：技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積的技術債至少清了一大段。 從工程面看，收益很明確。環境變數的自動化腳本雖然寫起來不輕鬆，但部署的穩定度立刻提升，手動改錯的風險幾乎清零；API endpoint 統一後，前端開發少了不少「猜測」與重複修正，後端安全性也更乾淨。這些是值得記上一筆的地方。 但回過頭來，技術債的代價比想像中高。像 endpoint 不一致、URL 寫死在 component、會員系統初期規劃不足，當下看都不急，累積到這週就一次爆掉，時間與心力都被吃掉。結論很直接：之後每次上新功能，都要把「技術債清單」列入例行工作，而不是等到事情變大再處理。
Dev
今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 email 更改，原本設計就撐不住，尤其 verification metadata 完全不夠用。我改成以一個簡單的 JSON 欄位記錄驗證類型與必要資訊，流程比較有彈性。 接著踩到 profile_data 的坑：它不是每次都能穩定解析成字典，偶爾還會冒出 500。原因是某些地方沒做好 JSON parse 的錯誤處理。最後我強制所有 profile_data 至少回到 dict 型態；parse 失敗就回空字典，
Dev
游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走 有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log 清一輪，才發現 ingredient 的 fetching 端點之前居然不一致，害某些成分 ID 會查不到。笑不太出來，只能重構，把 URL 結構對齊、確認每個 ID 都能讀到資料，附帶補上 error handling。下一次出問題至少能快速定位，而不是盯著螢幕問號連發。 API URL 收拾好後，回頭看最近做的游標分頁，總覺得哪裡卡卡。先前只有單向 next，自己測一測發現使用者一點「上一頁」
Dev
這兩天主要在補技術債、梳理架構，過程當然少不了自我懷疑，但也總算把幾個老問題收斂了。 先是 Dockerfile。昨晚就覺得哪裡怪，早上看 deployment log 才確認——前端 CORS 一直叫，後端 API 的 domain whitelist 根本沒吃到。追了半天發現是啟動命令寫法有問題，環境變數沒進去，CORS 就默默回到 localhost。這種低級錯誤不是第一次發生，每次都要再問自己一次：「你到底什麼時候才會記住？」好，這次除了修指令，乾脆把環境變數管理自動化，一個 bash script 負責切換 beta、dev、prod，順手把環境特定的 .env 加進 .gitignore，避免哪一天不小心把敏感資訊推上去。這種看起來小事，但出包就會後悔到爆。 API 這邊也趁機整理。把 api-client 的
Dev
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應 這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是一次吐一大坨資料，就是用 JavaScript 自己過濾，效率慘不忍睹。這次把品牌 API 重寫後，順手把成分關鍵字搜尋補齊，採用 PostgreSQL 的 ILIKE + %keyword% 做模糊查詢。pg_trgm 有想過，但成分名稱不如品牌那麼複雜，現在用 ILIKE 就夠。測 API 時踩到 Windows 的 multiprocessing 老問題：spawn 啟動方式和 Linux 的
Dev
延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都被迫重新梳理。雖然頭疼，但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使用者不一定在意，但測試下來，這一層補充反而讓分析更完整、點擊更少。順勢把整頁重構一輪，告別以前那種直接堆原始 JSON 的做法，資料管線變得順暢許多。commit 的時候我自嘲：「Danny，你以為加個屬性顯示就好？結果還是得把渲染邏輯全部理一遍，免得狀態打結。」好在錯誤率降了 25%，至少沒有再重演昨天的 CORS 驚魂。 後端我延續安全檢查的思路，改了 API 和資料庫的幾個環節。新增了不帶參數的產品建立與清單路由，讓系統自動處理預設值，不必每次請求都塞一堆冗餘資料。這個改動讓錯誤請求少了約三成，也減輕前端在弱網環境下的負擔。同時加上重複產品檢查與原始 SN 的取得邏輯，解掉之前條碼重複的麻煩。過程中我也踩到坑：
Dev
昨天把產品管理的 CRUD 骨架穩住後，今天直接把精力放在條碼掃描的擴展。理由很簡單：如果輸入數據不可靠，後面的分析再巧都只是表面工夫。 先整理了幾個後端細節，把多餘的 SQL 彈性收斂，移除那些看似靈活、實則增加風險的參數，順手解了一些依賴問題。結論很直白：簡化後更安全，查詢也不再繞路。 真正的麻煩在測試。新增了無效檔案類型、空檔案、損壞圖片、過大檔案等案例，還做了並發掃描的壓力測試。因為 CRUD 調整後，條碼必須唯一，不然產品建立會互撞。我把條碼欄位拉到 50 個字元以支援更多格式，結果第一輪就被並發情境打臉：同時掃描時資料庫鎖衝突，只好重做索引與鎖機制，半天就這樣沒了。 不過調整之後，建立流程穩定許多。我也把分析摘要的 API 從圖片上傳改成用產品流水號生成，少了上傳複雜度，JSON 結構更一致，回傳格式就不再時好時壞。文檔同步更新，錯誤碼與備援機制一並寫清楚。 情緒上還是會懷疑「這樣折騰值不值？」但這些看似瑣碎的調整，確實讓系統更結實。
Dev
保持戰略視野，別再陷入細節泥沼。技術重要，但方向更重要。維持彈性、快速迭代，讓 IngreLens 一步一步靠近理想的樣子。