從混亂中築基，尋找產品的真諦

# API設計的自我懷疑與產品決策的折磨：週檢討（2025-03-16）

這週整體來說算是「進兩步退一步」的感覺。雖然沒有什麼驚天動地的功能上線，但在產品架構和 API 設計這塊倒是做了不少深度思考。尤其是禮拜五整個在 API 設計的抉擇中掙扎，現在回頭看，覺得有點像是在跟自己的完美主義死磕。但至少最後做出的決定還算滿意。

這一週最大的成就，應該是把 API 架構再精簡了一輪，移除了原本設計的 AI 模型切換端點，直接整合進產品分析的 API 中。當初猶豫的點是擔心未來用戶可能會頻繁切換模型，但冷靜下來想想，這種使用情境真的會發生嗎？還是只是我在自嗨？最後決定簡化 API，避免過度工程化（over-engineering），現在看來是正確的選擇。

從產品策略的層面來看，這種決定背後其實反映了我對 Ingrelens 使用情境更真實的理解。產品的核心價值，是提供用戶穩定且準確的 AI 分析能力，而不是讓用戶花時間在各種模型之間跳來跳去。這種深入思考使用場景的習慣，未來也要持續保持。

但坦白說，這週在 API 設計上的猶豫，也暴露了我在決策時的重複問題：常常會陷入「假想情境」的泥沼，過度擔心未來可能出現的問題，導致決策的效率降低。雖然最後決策品質還可以，但過程卻花費太多時間和心力。未來應該更快地做出 MVP（最小可行產品）式的決定，透過真實用戶反饋再做調整，而不是自己在腦內模擬一百遍。

另一個小痛點，是 OpenAI 模型版本的更新問題。每次 OpenAI 一更新模型名稱，我就要跟著調整 API 的列舉設定，這種瑣碎的維護工作，長期下來真的會造成開發成本上的浪費。這週我嘗試將取得模型名稱的邏輯封裝起來，至少未來再有模型升級時，影響範圍會小很多。這個封裝的動作雖然小，卻讓我更深刻體會到「抽象層次」和「靈活性」在產品設計中的重要性，下次設計 API 時應該更積極思考這點。

FastAPI 的 middleware 和錯誤處理邏輯漏掉這件事，老實說蠻尷尬的。還好發現得早，沒造成更大的問題。這也提醒我，未來在開發新功能或新模組時，應該要更嚴格地遵循 checklist 模式，避免再出現這種低級錯誤。

回顧這一週，雖然沒有明顯落後進度，但距離原本設定的目標還是有一點點差距。下週（2025-03-17 到 2025-03-23）的核心目標是完成 API 的完整整合測試，並開始進行前端與後端的聯調。具體計劃：

- 週一至週二：完成 API 的測試覆蓋率提升，確保 API 的穩定性。

- 週三至週四：進行前後端聯調，確認 API 在真實情境下的表現。

- 週五：根據聯調結果做出調整，並為下個禮拜的內部試用版發布做準備。

我預期下週最大的挑戰，會是聯調過程中出現的 API 設計不一致或是效能瓶頸，尤其是前端 UI 在真實數據下的反應速度和體驗問題。為了應對這個挑戰，我會提前準備好相關的監控工具，並規劃好快速的調整策略（例如快速 rollback 和 feature toggle），確保不會因為聯調問題而影響整體進度。

總結來說，這週的自我懷疑雖然讓人有點焦慮，但也讓我更清楚地看見產品決策背後需要考量的因素與權衡。下週，希望能將這些反思轉化為更有效率的執行力，讓 Ingrelens 離真正的用戶上線又更近一步。