昨天在決定下一步的瞬間，我就把藍圖畫出來，今天直接從最簡單的原型開始。核心目標很單純：幫用戶分析保養品成分，並且讓後端能在不同 AI 模型之間安全切換。

為何先從後端？ 我習慣先確定資料結構與介面（Request/Response、DB、目錄與模組邊界），確保之後前端與服務整合能穩定推進。這套系統我選擇 FastAPI，輕量、快速，上手成本低。

同步改異步：效能與冷啟動的拉扯 原本打算用同步請求，但想到 AI 調用常有延遲，最後切到異步以避免阻塞主線程。過程中我也擔心冷啟動變慢，還好初步測試效能不錯；我把這個風險記下來，以後做基準測試再驗證。

AI 服務的「逃生門」：別把自己綁死 我一開始就設計服務切換機制：不綁死單一模型、模型掛了系統不至於跟著倒。現在很多模型能共用 OpenAI 的 library，只要改 baseURL 就能切換，因此我加了可用性/成本導向的選擇邏輯，支援 Grok（xAI 的模型），讓系統能自動選用合適的供應。初期不把 AI 服務拆到獨立專案，先把核心跑起來，再看負載與維運需求。

錯誤處理：彈性會增加複雜度 最大的時間花在錯誤處理與切換邏輯：如何在模型降級或供應端故障時保持介面穩定、避免崩潰。今天總算把 API 雛形跑起來，中間也有卡住和改錯，但這種持續校正的過程，才是創業的日常。

下一步

• 做冷啟動與延遲的基準測試，評估異步的實際收益
• 明確定義 SLA 與降級策略（如：切換門檻、重試次數、超時上限）
• 加上觀測性（metrics、tracing、告警），避免外部依賴的坑重演

創業不是直線前進，而是不斷校正方向。也許這就是樂趣所在。😅