# 如何在暫時下載連結到期前保存 AI 生成的影片？ > 應將供應商 URL 視為短期傳輸憑證，而不是資產位置。工作完成後立即排入下載佇列，將影片串流寫入持久物件儲存空間，驗證大小、類型與校驗和，並在將製作工作標記為完成前記錄永久 URI。 # 如何在暫時下載連結到期前保存 AI 生成的影片？ 生成完成並不等於已取得持久資產，只有位元組真正存在於你控制的儲存空間中才算完成。許多影片 API 傳回的簽署或暫時下載 URL 是為了傳輸，而不是長期播放。如果只保存 URL，已核准的影片可能在數小時或數天後從應用程式中消失。 應建立獨立的資產擷取步驟，並在生成完成時啟動。它領取下載工作、取得目前有效的 URL、將媒體串流寫入暫存物件、完成驗證，再提升到確定性的永久鍵。只有此時，製作工作才應變成完成。 ## 將 URL 視為憑證 簽署 URL 經常不需額外授權 header 就能暫時存取物件，因此屬於敏感資訊。除非存取受到嚴格控制，否則不要將它暴露在分析系統、客戶可見日誌、支援單或永久資料庫欄位中。 應該保存： * 供應商工作 ID； * 可取得時的供應商輸出識別碼； * URL 簽發時間與觀察到的到期時間； * 下載嘗試記錄； * 最終物件儲存鍵； * 驗證中繼資料與校驗和。 如果供應商傳回明確到期時間，應在此前保留充足餘裕安排第一次下載。如果沒有公布有效期間，就假設連結是暫時的，並立即排入傳輸佇列。 ## 將生成與資產擷取分開 生成完成與持久保存是不同狀態。工作可以在遠端成功，但在本機下載失敗。 | 狀態 | 意義 | 下一步 | |---|---|---| | `generating` | 供應商正在建立影片 | 輪詢或等待 webhook | | `output_ready` | 供應商回報輸出已完成 | 排入下載佇列 | | `downloading` | Worker 擁有本次傳輸嘗試 | 串流寫入暫存空間 | | `verifying` | 位元組已到達 | 檢查並計算校驗和 | | `stored` | 已確認持久物件 | 保存永久 URI | | `complete` | 中繼資料與資產皆已提交 | 交付給使用者 | | `download_retry` | 傳輸發生暫時故障 | 重新整理 URL 並重試 | | `needs_attention` | 無法自動復原輸出 | 附帶證據升級處理 | 不要在 `output_ready` 時將工作標記為完成。這個捷徑正是系統日後發現資料庫指向到期連結的主要原因。 ## 下載前先確認 webhook Webhook 處理器應驗證事件、持久化事件、排入輸出工作，再快速回應。在 webhook 請求內下載大型影片，容易逾時並導致供應商重複傳遞。 可依事件 ID 去重，或使用供應商工作 ID 與輸出 ID 的組合。透過以下唯一鍵讓排入佇列的操作具備冪等性： ```text download_key = provider + provider_job_id + output_id ``` 重複 webhook 會匯聚到同一個下載工作。輪詢和 webhook 也可呼叫同一個冪等 `ensure_download_task` 操作。 ## 串流寫入暫存物件 避免將完整回應讀入應用程式記憶體。應將資料區塊串流寫入暫存檔案或物件儲存空間分段上傳，同時計算加密校驗和。 安全傳輸順序如下： 1. 使用會到期的租約領取下載工作。 2. 如果 API 支援，取得新的 URL。 3. 使用有上限的連線與讀取逾時傳送請求。 4. 依政策拒絕重新導向到非預期主機。 5. 一邊串流資料區塊，一邊統計位元組並計算 SHA-256。 6. 關閉並完成暫存物件。 7. 驗證媒體。 8. 將它提升或複製到最終鍵。 9. 提交持久 URI 與中繼資料。 使用背壓，避免 worker 的緩衝速度超過儲存服務接收速度。並行傳輸上限應由頻寬、檔案大小和儲存服務容量共同決定，而不只是工作數量。 ## 驗證真實位元組而不只看回應 header HTTP `200` 仍可能包含 HTML 錯誤頁面、JSON 訊息或截斷檔案。`Content-Type: video/mp4` 是有用證據，但不是證明。 | 驗證項目 | 能發現的故障 | |---|---| | 非零位元組數 | 空回應 | | 預期或合理長度 | 截斷傳輸 | | 檔案簽章 | 將 HTML 或 JSON 存成影片 | | 容器剖析 | 損壞的媒體結構 | | 時長大於零 | 無效或不完整影片 | | 尺寸與編碼 | 輸出不符合交付契約 | | SHA-256 校驗和 | 位元組改變或重複 | | 必要時抽樣解碼 | 能剖析但無法播放的媒體 | 將觀察到的中繼資料與物件一同保存。使用適合模型與容器的容許範圍，和請求時長及解析度比較。除非交付契約要求精確計時，否則不要只因容器時長相差幾個影格就拒絕有效影片。 ## 使用確定性的持久鍵 可預測的鍵讓重試具備冪等性，並使資產可追蹤。鍵中應包含穩定的業務識別、輸出變體，以及版本或校驗和。 ```text videos/{account}/{operation_id}/{attempt_id}/{output_id}-{sha256_prefix}.mp4 ``` 先寫入暫存命名空間。驗證後，將物件提升到最終位置，或把資料庫指標提交到依校驗和定址的已驗證鍵。如果另一個 worker 已為同一工作儲存相同校驗和，應重複使用該物件，而不是建立無關複本。 除非經過清理，否則不要把使用者提供的檔名直接放入儲存路徑。可以將原始顯示名稱存為中繼資料。 ## 從到期與傳輸中斷中復原 將錯誤分類，讓重試有明確目的。 * 連線重設與暫時性儲存錯誤通常可以退避重試。 * 授權或到期回應可能需要重新整理 URL。 * 找不到回應可能表示供應商已刪除資產。 * 重複出現校驗和或媒體驗證失敗時，應停止自動重試。 * 本機配額或權限故障需要營運處理，而不是再次呼叫供應商。 保留供應商工作 ID。即使第一個 URL 已到期，許多 API 仍可為既有完成工作傳回新的簽署 URL。應核對目前端點行為，而不是自行假設。 只有來源與目的地都支援經驗證的位元組範圍，且物件識別未改變時，才恢復部分下載。否則應將傳輸重新開始到新的暫存物件。拼接兩個版本的位元組，可能產生看似完整但實際損壞的檔案。 ## 選擇尊重到期時間的重試計畫 一般指數退避可能等待到 URL 超過剩餘有效期。應使用已知到期時間限制延遲： ```text next_delay = min(exponential_backoff, time_until_expiry - safety_margin) ``` 如果 URL 已接近到期，重試前應重新整理它。加入隨機抖動，避免供應商恢復後所有失敗 worker 同時重新連線。 分別限制傳輸嘗試次數與 URL 重新整理次數。持續收到無效檔案的工作不應無限消耗新 URL。 ## 保護儲存路徑 永久物件應遵循自己的存取政策。預設使用私人 bucket，在適當情況下使用伺服器端加密、最小權限的 worker 憑證，以及面向觀看者的短期交付 URL。 不要把來源 URL 查詢字串複製到中繼資料，因為其中可能含有簽章。日誌中的 URL 應去識別化，或只儲存主機、路徑雜湊、簽發時間和到期時間。 當產品需要時，執行惡意軟體掃描或內容審核。在物件鍵與授權檢查中維持租戶邊界，但不要只依賴路徑名稱執行存取控制。 ## 制定保留與衍生資產政策 持久並不等於永久。應為原始檔、核准母版、預覽和遭拒絕的嘗試定義生命週期規則。 | 資產類別 | 政策考量範例 | |---|---| | 已核准母版 | 客戶合約與重新生成成本 | | 交付衍生檔 | 可以從母版重新建立 | | 遭拒絕的生成 | 較短的稽核或爭議窗口 | | 暫時上傳 | 驗證窗口結束後自動刪除 | | 審核代理檔 | 保留到核准後再到期 | 記錄刪除狀態與原因。如果資產必須可重現，應保存提示詞、來源雜湊、模型 ID、參數和來源素材權利，同時承認非確定性生成不一定能重建完全相同的位元組。 ## 監控達到持久狀態所需時間 衡量從供應商完成到驗證儲存之間的間隔。這個窗口內，暫時連結可能是唯一複本，也是風險最高的階段。 有用的指標包括： * 等待下載的輸出數量； * 最早的 output-ready 等待時間； * 完成到儲存時間的百分位數； * URL 到期回應數量； * 傳輸重試與重新整理 URL 數量； * 校驗和或媒體驗證失敗； * 已下載與儲存的位元組數； * 沒有持久 URI 卻標記完成的工作。 最後一項應永遠為零。在積壓年齡接近觀察到的最短 URL 有效期前發出警示。 ## 明確模型存取與儲存責任 [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=save-ai-videos-before-download-links-expire) 可以提供一個用於文字、圖像與影片模型存取的 OpenAI 相容平台。統一平台可以簡化工作中繼資料與帳單，但應用程式仍需負責將輸出複製到符合自身保留與交付要求的儲存空間。 核對目前模型端點具體的輸出與重新整理行為。不要編造到期時間，也不要假設每個模型都使用相同下載機制。應透過設定與能力檢查處理這些差異，而不是讓假設散布在程式碼各處。 ## 結論 保存 AI 生成影片時，應將暫時 URL 視為會到期的傳輸憑證。生成完成後立即排入下載佇列，將內容串流寫入暫存物件、驗證真實媒體，再提升到確定性的持久鍵。只有記錄永久 URI 與校驗和後才宣布工作完成，並設計 URL 重新整理、重試、保留和監控機制，讓供應商連結即使到期，也不會帶走你唯一的影片複本。 ## FAQ ### 我可以將供應商下載 URL 保存為最終影片位置嗎？ 不可以。簽署或暫時 URL 可能到期、遭撤銷或改變。應保存持久物件鍵與供應商工作 ID，並只在需要時取得或使用新的傳輸 URL。 ### 下載 worker 應該把整支影片載入記憶體嗎？ 通常不應該。應將回應串流寫入暫存檔案或物件儲存空間的分段上傳，同時計算校驗和，以免大型檔案耗盡記憶體。 ### 將影片標記為已保存前應該驗證什麼？ 驗證 HTTP 回應、可取得時的內容長度、檔案簽章、預期容器、非零時長、尺寸或編碼要求、校驗和，以及持久儲存寫入成功。 ### 暫時 URL 在下載期間到期怎麼辦？ 保留製作工作與遠端工作 ID，丟棄或隔離未完成物件；如果 API 支援就申請新 URL，並根據是否確認支援範圍請求，決定繼續或重新下載。 ### 原始生成影片應保留多久？ 依客戶需求、法律與隱私要求、重新生成成本和儲存預算設定保留期。使用生命週期政策，而不要意外依賴供應商 URL。 ### Webhook 可以直接下載影片嗎？ Webhook 處理器應快速確認並排入下載工作。獨立 worker 可以安全重試、驗證資產，並避免長時間網路傳輸造成事件遺失。