文章

文章。

依時間排序的完整文章封存。

第 3 頁，共 4 頁

2025/5/6 DevAI

SEO 跟使用者體驗的拔河

昨天猶豫了半天要不要接 Microsoft Clarity，今天早上看了幾段 session 錄影，心裡總算鬆一口氣——問題一目了然：搜尋輸入體驗太糟。輸入法組字的時機一錯，搜尋建議就瘋狂跳，整段流程像在考驗用戶耐心。第一件事，我把搜尋輸入的 debounce 重寫：組字期間

2025/5/1 DevEngineering

今天把幾件拖很久的事一次處理掉，專案也順了不少。先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔，結果測試掛了——有個測試竟然跟 sitemap 的生成耦在一起。把測試拆乾淨、舊案例順手整理後，CI 回到綠燈。像清掉房間的舊雜物，空出腦袋。真正影響使用

2025/4/29 DevEngineering

軟刪除這件小事，背後的細節卻不小原本只想補一個產品刪除 API。硬刪除直覺又乾脆，但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位，用軟刪除留個回頭路。一做下去才發現沒那麼單純：所有產品查詢都要顧到「未刪除」的狀態，沒有 WHERE deletedA

2025/4/27 DevEngineering

圖片輪播的坑，比我想的深得多。昨天把 .gitignore 的怪事整理完，今天回到產品開發，把待辦清單裡的圖片輪播放進度。原本估半小時的小元件，結果一做就發現邊界狀況一堆。先是圖片 URL 的檢查，避免破圖。寫到載入狀態才真正頭痛——使用者網路慢，圖片還沒載好，輪播就先動，那

2025/4/19 DevEngineering

本來計畫把時間放在核心功能的優化，結果一打開產品分析服務的介面，先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異，對品牌商用戶的專業感和信任度卻是很實在的扣分。想到我們的客群特別在乎質感，我還是把今天的重心從新功能挪開，展開一場用語清掃。原本只想改幾個

2025/4/14 DevEngineering

AI 分類越做越複雜，是在挖坑還是填坑？這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。先談分類。起手式很直接：把產品名稱與描述丟給模型，取

2025/4/12 EngineeringProduct

這週又走進熟悉的重構循環：API 架構、頭像 URL 的 timestamp 快取、副作用處理、訪客帳號暱稱同步，以及 FindSkin 的命名與流程一致性。每個小改動都牽出更大的設計問題，讓人不免自嘲「又在自找麻煩」。但冷靜看，這些牽動其實都指向同一件事：早期設計沒有把未來使用

2025/4/10 DevEngineering

Ingrelens 這次整理 FindSkin，我不只做功能，而是回到產品要解決什麼：先扎實研究文獻、設計情境題，再用權重公式準確定位膚質類型，最後把結果落到五維雷達圖的可視化呈現。命名統一為 FindSkin：語意是一切互動的入口過去「膚質檢測／肌膚分析／問卷調查」

2025/4/8 DevEngineering

今天的開發原本很單純：做一個訪客帳號。實作後卻發現，真正的難題不在「能不能用」，而在「用起來是否一致、可信」。這一整天的折返，讓我更確定：產品的差異，往往來自那些用戶不會主動說出口、卻一直被感受到的細節。一、身分與名稱的一致性不是錦上添花一開始我以為 localStorag

2025/4/7 DevEngineering

今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一碰到 loading 與 error 處理，才發現 API 根本沒涵蓋這些情境，只好連同整包一起重整。有人會問：「真的有必要動 API？用戶會在意嗎？」我很確定，這種

2025/4/6 DevEngineering

API 重構後的幾點實話：技術債、產品判斷與下一步這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積

2025/4/5 DevEngineering

今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 em