AI 服務的初體驗：從命名混亂到功能雛形

昨天我畫好了產品的藍圖，決定從簡單的原型開始實作，核心是幫用戶分析保養品成分。

一早醒來後，我直奔開發這件事情，其實大概花費了幾個小時把核心服務的 AI 端都設計好了，接著就是實際開始建立開發專案，我習慣先從後端開始，確定好資料架構、Request / Response ... 等

我先從初始化FastAPI應用程式開始，因為它輕量、快速，適合快速搭建 API 原型。我選擇 FastAPI 不是隨便決定的：相比 Express 或 Flask，更能加速開發，尤其當我一個人扛所有事時。

我本來想用同步方式處理請求，但後來意識到AI調用可能有延遲，就切到異步處理，避免阻塞主線程。過程中，我自問自答：「你確定這樣不會讓冷啟動變慢嗎？」幸好，測試後發現效能還不錯，不過我還是記錄下這點，萬一以後優化時用得上。

然後是 AI 服務的部分，一開始就設計好逃生門機制，除了避免綁死單一模型之外也避免當模型服務掛掉的時候我的系統也會受影響，現在很多模型其實都可以基於openAI 的 library 套件，只要改 baseURL 基本上就可以切換 XD 於是加了服務切換功能，支持Grok（xAI的模型），讓系統能根據可用性和成本自動選用。

未來可能在評估把 AI 服務另外獨立出去另一個專案，但初期我想快速一點別這麼複雜!

這個決定背後的權衡是：彈性帶來複雜性，我花了不少時間調整錯誤處理邏輯，確保切換時不出現崩潰。 midway 我還吐槽自己commit留言：「為什麼每次AI更新都像追流行一樣？」事實上，這讓我更清楚，功能再炫也要考慮實用性——畢竟用戶關心的是分析結果，不是後台怎麼切換。

今天總算是完成了 API 雛形，還寫了技術文檔，詳細記錄端點和架構，算是對昨天「誠實回應用戶痛點」的延續。雖然有點卡住和改錯，但這過程讓我體悟到，創業不是直線前進，而是不斷校正方向。

未來我得更細心評估外部依賴，免得又踩坑——但也許這就是樂趣所在，對吧？ 😅