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

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

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

先說分類。起初的做法很直接：把產品名稱與描述丟給模型，拿回分類結果就寫進資料庫。實際跑了才發現，回傳格式不穩定，JSON 有時多空格或斷行，parse 會炸。我先補了 try-catch、把原始回應與錯誤一併記錄，至少 debug 不再摸黑。更大的問題是分類的邏輯本身：現實裡很多產品會對應多個類別（保濕、防曬、抗老化），單一分類不合理。最後把產品與分類改成多對多關係，資料庫 schema 重構、API 路由也重排，分類功能的 URL 更直覺。趁勢把產品 ID 改成 UUID，雖然猶豫了一下，但考量未來分散式擴展，現在改掉，比之後補洞來得乾脆。模型也升級到 grok-3-latest，希望分類準確度能更穩。

文件與索引也跟著清理。舊的「手動分類」文檔已不合時宜，直接刪掉，架構概述的連結與描述更新。每次砍文檔都有點罪惡感，但留著反而更容易誤導自己和使用者。

在個人化分析 API 這邊加了訪客用戶的每日次數限制。一開始只是想做簡單計數，結果發現訪客與註冊用戶的分界不清楚，最後在認證服務補了 isGuest 屬性、加上當天次數的檢查，整體行為才變得一針見血。

再來是產品圖片。原本只有單張圖片顯示，錯誤處理也薄弱，對品牌商來說體驗不及格。我加了圖片輪播、URL 檢查與錯誤處理，列表與詳情的呈現乾淨多了。順手把縮圖（thumbnail）邏輯整個移除：以前為了省流量與儲存做的折衷，實際效益不高，反而增加複雜度。統一標準尺寸後，縮圖存在的理由不多，砍掉之後資料結構更單純、維護也輕鬆。

最花時間的是安全檢查服務的大改造。用戶回報邊緣成分被誤標黑名單，導致上傳受阻，這種錯誤會直接傷到信任。我把模型從 gpt-4o-mini 換成 gpt-4.1-nano-2025-04-14，搭配服務架構優化：資料庫連線改用異步以應對高併發；加入「臨時黑名單」儲存，遇到邊界案例先暫存，後續再人工確認；日誌重新整合，每次請求與回應都留完整記錄。說實話，模型升級讓我有點焦慮，因為升級常伴隨新坑，但安全檢查這類底層能力，寧可早點打磨扎實，也不要把風險留到最後。

最後把 FastAPI 的開發提示詞也更新，強調 TDD。以前覺得測試驅動像是繞遠路，最近幾次踩坑之後，越來越覺得值得：至少能讓改動有守備陣型，不至於每次重構都心裡發毛。

回頭看，這些調整帶來的不是「技術酷炫」，而是把基礎打厚：資料結構合理，API 清楚，日誌完整，模型選型有節制。中途的懷疑也還在——到底是在把產品推向更好的方向，還是在讓自己更忙？但創業的節奏大概就是這樣：邊做邊學，該砍就砍，該補就補。今天的進度不是一枝獨秀，但往後的坑，會少一點。