本機函式通常回應快、格式穩定；真實 API 會超時、限流、改版，也可能回傳缺欄位或錯誤狀態。今天為任務追蹤 App 加入一個可替換的外部整合情境：依任務標題取得建議分類。是否採用哪個服務，要等實作時確認文件、費用與資料政策。

先定義 API 失敗時產品怎麼辦

分類建議是輔助功能，不應阻止使用者建立任務。成功時顯示建議，使用者可接受或忽略；超時、限流或服務錯誤時，畫面顯示簡短訊息，任務仍能保存。外部回應必須驗證，不能因為服務回傳 JSON 就假定欄位和型別永遠正確。

傳送資料前要確認最小化原則。若只需要標題，就不送任務識別碼、使用者資訊或其他清單內容。文章與 Demo 使用測試資料；若服務會保留或訓練傳入內容，必須在選型時查清並寫入決策。API Key 只留在伺服器端，不暴露給瀏覽器。

工程上要處理的五種情況

至少測試成功、無效回應、逾時、限流和一般伺服器錯誤。請求設定合理 timeout，對可重試錯誤採有限次數與退避，不重試明確的輸入錯誤。若外部服務失效，系統應留下可診斷但不含敏感內容的 Log，並回傳一致的內部錯誤格式。

交給 Codex 的任務

「根據指定 API 的官方文件，先整理請求、回應、驗證方式、timeout、限流、費用與資料處理限制。提出一個隔離外部服務的介面，使任務建立流程在服務失敗時仍可用。實作成功與失敗案例的測試；不得把 Key 放到前端、Repository 或 Log。」

我會檢查 Codex 是否只照 Happy Path 抄範例、是否自行假設欄位、是否無限重試，以及測試能否用 mock 或測試替身穩定重現錯誤。真正連線測試要和單元、整合測試分開，避免每次測試都產生成本或依賴網路。

今天的結果與限制

本文定義了外部整合的產品行為與工程驗收，但尚未選定或呼叫真實 API，因此沒有費用、延遲或錯誤率數據。選型時必須重新查閱當時的官方文件，不能沿用本文假設。

今天學到什麼？

串接 API 的工作量主要不在第一個成功回應，而在資料邊界和失敗行為。明天把同樣的謹慎帶到資料庫 Schema 與 Migration。