AI 分類越做越複雜，是在挖坑還是填坑？

AI 分類越做越複雜，是在挖坑還是填坑？

這幾天把重心放在兩件事：產品分類的 AI 自動化，以及安全檢查服務的重構。原本以為只是把 API 接上、模型升級一下，結果一路從資料結構、路由、日誌，到架構設計全被牽出來重整。

先談分類。

起手式很直接：把產品名稱與描述丟給模型，取回分類結果後寫進資料庫。實際跑才發現兩個問題

1. 回傳格式不穩：JSON 偶爾多空格或斷行，導致 parse 失敗。我先加上 try-catch，並把原始回應與錯誤完整記錄，至少 debug 不再摸黑。
2. 分類邏輯不合理：現實中同一產品常對應多個類別（如保濕／防曬／抗老化），單一分類會誤導。

因此進行重構：

• 將「產品—分類」改為多對多，重整資料庫 schema；
• 重新排 API 路由，讓分類功能的 URL 更直覺；
• 順勢把產品 ID 改成 UUID，雖然猶豫了一下，但基於未來的分散式擴展，現在一次到位比事後補洞來得乾脆。

在個人化分析 API，我加上訪客的每日次數限制。原本打算做簡單計數，但發現「訪客 vs 註冊」邊界不清楚，最後在認證服務補了 isGuest，並加上「當天次數」檢查，行為才真正到位。

接著處理產品圖片。單張顯示加上薄弱錯誤處理，對品牌商的體驗不及格。我改成圖片輪播、加 URL 檢查 與錯誤處理，列表與詳情都乾淨許多。順勢把 thumbnail 邏輯整個移除——統一標準尺寸後，縮圖的效益不高、卻提高複雜度；砍掉資料結構更單純、維護更省力。

最花時間的是安全檢查服務的大改造。用戶回報邊緣成分被誤標黑名單、上傳受阻，這種錯誤會直接傷信。所以我調整了模型和改進服務架構：資料庫連線改用異步以應對高併發；加入「臨時黑名單」機制，邊界案例先暫存、再人工確認；整合日誌，把每次請求與回應都記完整。

回頭看，這些調整長期來看都是把基礎打厚：資料結構合理、API 清楚、日誌完整、模型選型節制。

是在把產品推向更好，還是讓自己更忙？但創業節奏本就如此：邊做邊學，該砍就砍、該補就補。

今天的進度或許不亮眼，但往後的坑，會少一點。