開發者私有影像生成指南

私有影像生成並不是單一功能。它是一連串的選擇。

從請求開始。把提示詞（prompts）、來源影像（source images）、遮罩（masks）、參考影像（reference images）、生成輸出（generated outputs）以及金鑰（keys）都視為使用者內容。這表示它們應該走比一般遙測（telemetry）更窄的路徑。它們不應該隨意出現在日誌（logs）、分析（analytics）、儀表板（dashboards）或客服支援畫面（customer support screens）中。

接著，把授權（authorization）與內容（content）分開。系統需要知道該帳戶是否能執行任務並為其付費。這並不代表計費層（billing layer）需要提示詞。內容盲（content-blind）的計費方式很「無聊」，但正是恰到好處：它只記錄使用量發生了，卻不記錄生成了什麼。

然後讓處理（processing）保持短暫。應該存在一個「生成會話（Generation Session）」，用來處理任務並回傳結果，而不是成為可持久化的工作區（durable workspace）。在任務執行期間可能需要暫存檔案（temporary files）。但任務結束後，它們不應該變成產品狀態（product state）。

保持可觀測性（observability）內容盲。你仍然需要指標（metrics）：佇列時間（queue time）、模型效能（model performance）、失敗類型（failure type）、容量（capacity）、成本（cost）以及健康狀態（health）。在多數作業事件中，你不需要原始使用者內容。如果你覺得需要，先問問自己：你是在除錯系統，還是在囤積客戶脈絡（customer context），因為後者通常更容易。

小心重試（retries）。失敗的任務不應把提示詞洩漏到日誌中，也不應把來源影像留在系統裡。重試系統很有用，但它必須像成功任務一樣，遵守相同的內容邊界（content boundary）。

決定你是否提供歷史紀錄（history）。如果你提供相簿（gallery），就要明說。如果你不提供，那就把它當作一項功能。沒有相簿的架構更容易符合零留存（zero-retention）的承諾，因為輸出會被回傳，而不是被保存。

為非專家撰寫文件（docs）。「封裝請求（sealed request）」只有在使用者能理解它保護了什麼、以及它不保護什麼時才有用。要說清楚內容會去哪裡、哪些會保留、以及操作人員（operators）能看到什麼。

開發者指南的核心其實就這一句：減少私有影像內容可能存在的地點數量，然後讓剩下的路徑變得容易解釋。

延伸閱讀：Getting started、How Unexposed works 與 Unexposed data storage。