DevProduct
Day:292 NEXT
第 292 天的年度檢討：從 Ingrelens 與 cosGlint 的基礎建設到架構解耦，LLM 與後端分離、Orchestrator 上線；經歷 11 月大流量的佇列塞車與 48 小時救火，補齊觀測與調度，cosGlint 用戶破兩千、內建 13k+ 商品，1.3.0 推出全方位部位檢測，持續迭代。
Tag
Dev
開發日誌
DevUI/UX
快與深同路：把「不打擾」與「有話想說」設計成同一個動作
cosGlint 的回饋介面最佳實踐：以「點分數即排程、30 秒自動送出」不打擾完成，同時保留文字框與清楚動效、撤回入口；透過時間感、因果感、掌控感的微交互與 A/B 測試，在單一路徑上兼顧效率與深度。
DevEngineering
cosGlint 打造可信的「天氣×保養」系統機制
把高溫、濕度、風速、UV 指數轉成可執行的日常保養：從保養品分析到成分分析，cosGlint 以可被解釋的訊號給出白天防曬、夜間修護、隔日預防的具體指引。
DevResearch
Termdock
Termdock：以終端為核心的開發環境，整合多工作區與多終端、AST深度搜尋與檔案/Prompt管理，提供不干擾終端的Git輔助與智能拖放，減少上下文切換、提升產出
DevEngineering
Vibe coding 你該知道的 api key 知識
有人把會計費的 API key 直接放到可分享的前端，誰用了都算你的錢。當事人用 Google AI Studio 的 Build/Canvas 做了一個可分享的 App，介面上叫使用者填「自己的」key，但流程其實鎖了開發者的 key。內容被大量轉傳，短期流量爆掉，帳單也跟著爆
DevResearch
cosGlint Android 封測結束
Android 封閉測試通過心得：規則、填答、與實務提醒
DevAI
OpenAI GPT5 推出後大家真的在懷念 GPT-4o ？
相信這幾天大家對於 GPT-5 最多的討論是「GPT-4o 消失了，還我 GPT-4o！」 坦白說我一開始也愣了一下。GPT-4o 雖然一路有在迭代，但效能本質上還是上一代：愛唬爛、幻覺多、討好傾向重。平常圈內多數人都是這個評價。 But…就是這個 But。 GPT-5 上線
DevEngineering
從技術債到戰略投資
這週從 SEO、Dockerfile/Supervisor、狀態管理、Tiptap + AI 到 環境變數，每天都有新坑。與其把它們當救火，我選擇把舊債系統性轉成投資，讓產品基礎穩固。 * SEO不是小事。重新設計 JSON‑LD 和 metadata，短期流量未必動，但可預
DevAI
SEO 跟使用者體驗的拔河
昨天猶豫了半天要不要接 Microsoft Clarity，今天早上看了幾段 session 錄影，心裡總算鬆一口氣——問題一目了然：搜尋輸入體驗太糟。輸入法組字的時機一錯，搜尋建議就瘋狂跳，整段流程像在考驗用戶耐心。 第一件事，我把搜尋輸入的 debounce 重寫：組字期間
DevEngineering
把專案清乾淨，讓產品走得動
今天把幾件拖很久的事一次處理掉，專案也順了不少。 先把不用的 sitemap.ts 和相關邏輯清掉。本來以為是單純刪檔，結果測試掛了——有個測試竟然跟 sitemap 的生成耦在一起。把測試拆乾淨、舊案例順手整理後，CI 回到綠燈。像清掉房間的舊雜物，空出腦袋。 真正影響使用
DevEngineering
軟刪除這件小事，背後的細節卻不小
軟刪除這件小事，背後的細節卻不小 原本只想補一個產品刪除 API。硬刪除直覺又乾脆，但總會有人手滑、客服就會來敲門。最後還是加了 deletedAt 欄位，用軟刪除留個回頭路。 一做下去才發現沒那麼單純：所有產品查詢都要顧到「未刪除」的狀態，沒有 WHERE deletedA
DevEngineering
為體驗與準確性重構一切
圖片輪播的坑，比我想的深得多。昨天把 .gitignore 的怪事整理完，今天回到產品開發，把待辦清單裡的圖片輪播放進度。原本估半小時的小元件，結果一做就發現邊界狀況一堆。 先是圖片 URL 的檢查，避免破圖。寫到載入狀態才真正頭痛——使用者網路慢，圖片還沒載好，輪播就先動，那
DevEngineering
中文用語統一大作戰：從小細節到底層穩定，這週我修了哪些坑
本來計畫把時間放在核心功能的優化，結果一打開產品分析服務的介面，先被一堆不一致的中文用詞刺了一下。看似微小的「上傳」「提交」「新增」差異，對品牌商用戶的專業感和信任度卻是很實在的扣分。想到我們的客群特別在乎質感，我還是把今天的重心從新功能挪開，展開一場用語清掃。 原本只想改幾個
DevEngineering
AI 分類越做越複雜，是在挖坑還是填坑？
AI 分類越做越複雜，是在挖坑還是填坑？ 這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。 先談分類。 起手式很直接：把產品名稱與描述丟給模型，取
DevEngineering
FindSkin：從命名到體驗，把混亂收回來
Ingrelens 這次整理 FindSkin，我不只做功能，而是回到產品要解決什麼：先扎實研究文獻、設計情境題，再用權重公式準確定位膚質類型，最後把結果落到五維雷達圖的可視化呈現。 命名統一為 FindSkin：語意是一切互動的入口 過去「膚質檢測／肌膚分析／問卷調查」
DevEngineering
看不見的細節，為什麼值得？
今天的開發原本很單純：做一個訪客帳號。實作後卻發現，真正的難題不在「能不能用」，而在「用起來是否一致、可信」。這一整天的折返，讓我更確定：產品的差異，往往來自那些用戶不會主動說出口、卻一直被感受到的細節。 一、身分與名稱的一致性不是錦上添花 一開始我以為 localStorag
DevEngineering
重構永遠不是「只是改一下」的事
今天原本只打算把產品頁改成 client-side component，改善 SSR 時卡卡的效能與 UX。結果一碰到 loading 與 error 處理，才發現 API 根本沒涵蓋這些情境，只好連同整包一起重整。有人會問：「真的有必要動 API？用戶會在意嗎？」我很確定，這種
DevEngineering
API 重構後的幾點實話：技術債、產品判斷與下一步
API 重構後的幾點實話：技術債、產品判斷與下一步 這週把 Ingrelens 的幾個老問題一次整起來：API 架構統一、環境變數管理自動化、會員系統與帳號刪除流程重構，還把 HTTP 全面升級到 HTTPS。Dockerfile 重新整理、部署腳本補上該有的保險，過去半年累積
DevEngineering
Email 驗證、會員系統與那些「看似簡單」的更新紀錄
今天幾乎都在跟會員系統纏鬥。Ingrelens 一開始只是做「註冊、登入」這種基本功能，結果一路長出資料更新、密碼修改、guest 升級成正式會員……每加一個需求，整體邏輯就再複雜一點。 先處理 email 驗證。以前的流程只是寄信、點連結，直到要支援 guest 升級與 em
DevEngineering
把炸彈拆完，才有力氣往前走
游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走 有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log
DevEngineering
Dockerfile、環境變數與 API endpoint：一次把坑補齊的週記
這兩天主要在補技術債、梳理架構，過程當然少不了自我懷疑，但也總算把幾個老問題收斂了。 先是 Dockerfile。昨晚就覺得哪裡怪，早上看 deployment log 才確認——前端 CORS 一直叫，後端 API 的 domain whitelist 根本沒吃到。追了半天發
DevEngineering
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應
成分搜尋與 API 整合的兩天修補：從資料庫到前端的連鎖反應 這兩天主要在處理兩件事：把成分搜尋做對、把 API 整合拉回穩定。結果一路從資料庫 schema、ORM、到前端路由和狀態管理，全都被牽出來重整了一遍。 先說成分搜尋。之前後端只有陽春 CRUD，前端要找成分時不是
DevEngineering
當重構像多米諾骨牌：從小修到整體優化的一週
延續昨天的 AI 整合反思，我原本只想讓產品分析結果更好讀。沒想到下去動了一個顯示細節，整個渲染邏輯就像多米諾骨牌一樣一路倒下：從前端元件、狀態流到資料處理方式，都被迫重新梳理。雖然頭疼，但結果讓我滿意。 先從「觀察互動」著手。我加了一個專門顯示成分的區塊，原本擔心資訊太細，使
DevEngineering
條碼的幽靈：安全與現實的角力
昨天把產品管理的 CRUD 骨架穩住後，今天直接把精力放在條碼掃描的擴展。理由很簡單：如果輸入數據不可靠，後面的分析再巧都只是表面工夫。 先整理了幾個後端細節，把多餘的 SQL 彈性收斂，移除那些看似靈活、實則增加風險的參數，順手解了一些依賴問題。結論很直白：簡化後更安全，查詢
DevEngineering
從技術細節到產品戰略的思考
保持戰略視野，別再陷入細節泥沼。技術重要，但方向更重要。維持彈性、快速迭代，讓 IngreLens 一步一步靠近理想的樣子。
DevEngineering
穩住掃描，補強地基：今天我為 IngreLens 做的兩件事
提升掃描可靠性、夯實產品管理
DevEngineering
做減法的 API 決策：把模型切換藏進產品分析，專注真實場景
關鍵調整是把「AI 模型切換」端點併入產品分析 API，回到穩定、準確的核心價值。處理 OpenAI 模型更新的封裝、補齊 FastAPI middleware 與錯誤處理；下週目標為完整整合測試與前後端聯調，並以監控與快速回滾機制降低風險。
DevEngineering
Day1 : 把 AI 成分分析的後端雛形搭起來
打造「保養品成分分析」後端原型：選用 FastAPI，以異步處理應對 AI 延遲，並設計可在多模型間安全切換的「逃生門」（含 Grok）。重點放在錯誤處理與降級邏輯，確保故障時介面穩定。下一步：基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性（metrics、tracing、告警）。