今天的重點全都集中在產品分類的 AI 自動化功能上。原本以為只是單純把 OpenAI API 接上去就搞定了，結果一開始測試就發現分類的準確度根本沒達到預期。

你到底是哪來的自信覺得 AI 分類一次就能搞定啊？🤦‍♂️

一開始分類的邏輯很簡單，直接丟產品名稱跟描述給 OpenAI，回傳的分類結果再更新到資料庫就好。然而，實際跑起來才發現問題不少：首先是 API 回應的格式問題，原本以為 AI 回傳的 JSON 應該很穩定，實際上卻發現有時會多出莫名其妙的空格或斷行，導致 JSON parse 直接炸掉。只好再加一層 try-catch，並在日誌中記錄原始回應和錯誤訊息，這樣至少 debug 的時候不用再「盲人摸象」了。

然後又發現產品分類的架構設計有點奇怪，原本的設計是每個產品只能有一個分類，但現實情況下很多產品本來就可以對應多個分類，比如保濕、防曬、抗老化等等。想了一下，乾脆就把產品跟分類的關係改成多對多，這樣未來的產品搜尋或推薦功能也更彈性一點。當然，這也意味著資料庫 schema 需要重構，然後 API 路由也得跟著調整，心裡默默吐槽

Danny，你又給自己找麻煩了吧？」但想想，還是咬牙改了下去。

順便把產品 ID 改成 UUID，這個決定其實猶豫了很久，畢竟原本的自增 ID 已經用了好一陣子，突然改成 UUID 會不會影響太多地方？但考慮到分散式架構未來可能的擴展性，還是決定現在就改掉，以後就不用再回頭搞這種麻煩的遷移了。趁這機會順便更新了一下 API 的路由，讓分類相關功能的 URL 更直覺，也把 AI 模型從舊版升級到 grok-3-latest，希望能帶來更好的分類效果。

講到這裡，又想到文件的問題。原本產品分類有一個獨立的文檔，但現在都改成 AI 自動分類了，這個文檔似乎沒什麼存在的必要，乾脆直接砍掉，然後再把索引跟架構概述裡的連結和描述更新一下就好。雖然只是小細節，但每次砍文檔的時候，總覺得有種奇怪的罪惡感，Danny，你是不是太懷舊了？🤷‍♂️

另外，今天也順手在個人化分析 API 加上訪客用戶的分析次數限制，避免被濫用。原本只是想加個簡單的計數邏輯，結果一寫下去才發現，訪客跟註冊用戶的區分邏輯還不夠清楚，於是又回頭在認證服務裡加了 isGuest 屬性，這樣 API 處理起來才更直覺。順便加上了當天分析次數的檢查

Danny，你終於意識到免費資源不是無限的了吧？😂

最後，今天把 FastAPI 的開發提示詞也更新了一下，特別強調了 TDD 的重要性。說實話，以前總覺得測試驅動開發有點浪費時間，但最近幾次踩到坑後，越來越覺得這種方法還是很值得的，至少能避免未來自己挖坑給自己跳。

工程師的成長就是在無數次踩坑跟填坑之間逐漸體會出來的啊。