最初的旅程：一個人，也能啟動一個世界
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 一步一步靠近理想的樣子。
Dev
提升掃描可靠性、夯實產品管理
Dev
關鍵調整是把「AI 模型切換」端點併入產品分析 API，回到穩定、準確的核心價值。處理 OpenAI 模型更新的封裝、補齊 FastAPI middleware 與錯誤處理；下週目標為完整整合測試與前後端聯調，並以監控與快速回滾機制降低風險。
Dev
打造「保養品成分分析」後端原型：選用 FastAPI，以異步處理應對 AI 延遲，並設計可在多模型間安全切換的「逃生門」（含 Grok）。重點放在錯誤處理與降級邏輯，確保故障時介面穩定。下一步：基準測試冷啟動與延遲、明確 SLA/降級策略、補齊觀測性（metrics、tracing、告警）。
Renew: Day 0