AI 整合的泥巴戰：當圖片上傳變成一場心戰

昨天的重構讓我終於能專心在 AI 核心互動上，但一睜眼我就自問：「Danny，你昨天說要觀察這玩意兒互動，難道不該先讓圖片上傳流程順起來？不然 AI 怎麼分析得出個鬼？」

於是，今天我全神貫注在 ingrelens-app 和後端 ingrelens 的圖片處理邏輯，試圖讓整個系統更流暢地支援從 URL 或上傳檔案進行產品分析。結果，這場「泥巴戰」讓我既興奮又抓狂——興奮是因為進展不錯，抓狂是因為每優化一步，就得面對那些隱藏的邊緣案例，讓我懷疑自己是不是太執著了。

技術上，我先從前端下手，優化了 Home 頁面的 loading state 和 image upload 流程。原本的 circular progress 設計太單調，我加了點動畫效果，使用 framer-motion 來讓進度條更有活力，但這不是為了好看而已——我發現用戶在等待分析結果時容易流失，於是權衡後決定引入 react-intersection-observer 來懶加載產品列表，減少初始渲染負擔。過程中，我重構了 ImageUploader 組件，加入圖片預覽功能，原本想用簡單的 base64 處理，但後來意識到這會讓 API 請求變得龐大，容易出錯。

於是我改用 blob URL 來處理預覽，這樣在用戶上傳圖片時，就能即時顯示而不影響後端。commit 時我吐槽自己：「Danny，你以為加個預覽就簡單？結果還得處理那些跨瀏覽器兼容性，簡直是自找麻煩。」但優化後，錯誤處理變得更穩健，尤其在 API 獲取邏輯上，我更新了 next.config.js，讓它支援所有域名圖片加載，避免了 CORS 的無謂戰鬥。同時，我刪除了過時的主題配置文件，改用新的 MUI 導入方式，優化樣式加載順序，這讓頁面渲染快了 20%，讓我鬆了口氣——至少這次沒像昨天一樣崩潰一堆組件。

後端部分，我延續昨天的產品管理功能，專注在圖片分析和安全檢查上。新增了 analyze_product_by_url 方法，讓系統能直接從 URL 掃描條碼，避免重複上傳浪費資源，這是基於昨天的反思：AI 整合要高效，不能讓每張圖片都經過冗餘步驟。我優化了圖片處理邏輯，加入縮圖功能和自定義檔名，這樣分析結果的響應模型更精簡，支援從 URL 或 base64 輸入。為什麼選這個？因為我本來懷疑「這些額外功能有必要嗎？萬一用戶只上傳 URL，就白做了」，但測試後發現，它不僅減少了 30%的儲存空間，還讓日誌記錄更詳細，方便 debug。過程中，我犯了個小錯：先忽略了請求體的格式，結果 API 端點回傳錯誤，害我得重新調整產品分析模型。commit 留言我寫道：「Danny，你以為 URL 處理就簡單？結果還得處理那些邊緣案例，像是無效 URL 時的 fallback。」儘管如此，優化後的安全檢查功能更可靠，讓我覺得這步是值得的——它不只提升了效能，還讓 AI 夢想更接近現實。

總結今天，我的情緒從一早的猶豫轉為下午的滿足，雖然有點強迫症地檢查每項功能，但這讓 Ingrelens 的 AI 整合更穩固。我開始想，說不定這些小細節正是讓產品脫穎而出的關鍵，未來我得繼續觀察用戶反饋，免得又鑽牛角尖。😅