上線前：開發者應該先問的影像 API 問題

影像生成 API 最危險的地方，並不是端點名稱。真正危險的是：當沒有人在看時，這個端點默默做了什麼。

開發者可以在一個下午把模型呼叫接起來。這就是現代 AI 基礎設施令人驚喜、也略帶可怕的地方。示範能跑。影像出現。按鈕發光。創辦人也露出那種特定的笑——彷彿暫時忘了資料保護法的存在。

上線之前，先問：什麼會進入 API。提示（prompts）是內容。來源影像是內容。遮罩（masks）是內容。參考影像是內容。生成輸出也是內容。金鑰（keys）可能會解鎖內容。若這些物件被當成一般的請求中繼資料處理，產品就已經在往麻煩的方向滑行。

再問：這些內容會被送到哪裡？會打到你的應用程式伺服器？進入佇列？物件儲存？模型供應商？CDN？日誌處理器？錯誤追蹤器？客服看板？品質審查工具？把路徑畫出來。如果路徑看起來像是在偏頭痛中設計出來的地鐵圖，那就先在客戶使用之前把它簡化。

再問：哪些會被持久保存。實用的 API 可能需要帳戶記錄、帳單記錄、任務狀態、模型名稱、時間戳，以及作業事件。它不一定需要原始提示、來源影像、生成輸出或生成金鑰。保留必要的作業事實；除非產品明確承諾會保存歷史，否則不要保留創作證據。

再問：失敗時會發生什麼。失敗的任務（failed jobs）最容易讓團隊變得馬虎，因為除錯看起來很急迫。不要把請求內容（request bodies）傾倒到日誌裡。不要為了「之後再用」而保留來源影像。不要把私密提示送到錯誤工具。令人不快的路徑仍然是產品的一部分。

再問：刪除如何運作。若使用者能刪除上傳內容或輸出，請定義這在原件、輸出、縮圖、快取與相簿之間各自代表什麼。如果某些內容因備份或法律義務而無法立即移除，請說明。如果系統是為了避免持久保存內容而設計，那麼刪除就會更容易被清楚地描述。

再問：誰能看見客戶內容。客服存取是一個產品決策，不只是內部政策。若操作人員因為那些物件沒有保留在面向支援的系統中而看不到提示與影像，那比起「我們的團隊受過訓練」更有力。訓練當然很好，但架構不那麼健忘。

上線前的問題不是「API 能不能生成漂亮的影像？」而是「我們能不能在不冒冷汗的情況下說清楚資料路徑？」

延伸閱讀：開發者從影像生成 API 需要什麼、Unexposed 資料儲存，以及 OpenAI 的API 資料控管。