社群影片已排程，時間到了卻沒有出現在公開頁面。這時應該立刻重新上傳同一個檔案嗎？
先不要。第一步是找出最後一個能證明完成的狀態。影片可能在送到社群平台前就停止、仍由供應商處理，或其實已公開但管理介面尚未更新。把三種情況都當成同一種「發布失敗」，很容易把一次事件變成兩篇重複貼文。
請依序檢查以下五項。
30 秒快速檢查
- 編輯器是否接受檔案與貼文設定？
- 上傳是否回傳穩定的媒體參照值？
- 是否已有 content ID 或 publish-job ID？
- 是否已有 provider post ID 或 permalink？
- 公開社群頁面實際顯示什麼？
遇到第一個無法證明的答案就先停下來，記為 未知，不要用推測補空白。
1. 編輯器是否接受影片？
從社群供應商之前的步驟開始。確認公開帳號、排程時間、時區、文案，以及排程工具顯示的媒體規格。
如果編輯器仍顯示缺少檔案、格式不支援、長度或容量超限，發布要求可能根本還沒有開始。先修正輸入，不要立即把問題歸因給 Instagram、TikTok、YouTube 或 Facebook。
只留下安全的證據：
- 頻道與公開帳號名稱；
- 排程時間與時區；
- 檔案大小、長度、解析度與 codec；
- 需要比較兩個匯出檔時使用的檔案指紋；
- 實際看到的驗證結果
事件記錄中不要放入密碼、access token、signed upload URL、私人 prompt 或客戶資料。
2. 媒體傳輸是否完成？
許多工具會先準備上傳位置，再建立社群貼文。準備要求可能成功，但後續位元組傳輸仍可能失敗。
尋找可追蹤的參照值，例如 asset_ref 或 media ID。如果傳輸以明確錯誤結束，而且沒有媒體參照值，應記為媒體上傳失敗。除非有證據顯示社群供應商已收到發布要求，否則不要稱為平台拒絕。
Timeout 更加模糊。即使客戶端沒有收到回應，媒體物件仍可能已存在 storage。再次傳送同一個檔案前，先核對儲存結果。
3. content ID 或 job ID 是否存在？
Content ID 與 publish-job ID 是「準備素材」和「開始發布」之間的界線。
兩者都不存在時，就沒有下游工作可輪詢。如果已有 ID，應追蹤同一個物件，而不是建立替代要求。accepted、scheduled 與 publishing 只是進度狀態，不能證明觀眾已經看到影片。
完整狀態模型請參考已排程不等於已發布：如何確認社群貼文。
4. 是否已有供應商 ID 或永久連結？
Provider ID 表示社群平台可能已經知道這篇貼文；permalink 更有力，因為它指向可直接檢查的特定原文。
任何 retry 之前都要：
- 保留原本的 content ID 與 job ID；
- 檢查同一個 ID 的狀態是否仍在變化；
- 有 permalink 時先開啟原文；
- 把每個頻道的結果分成獨立證據列
若三個頻道已發布、只有一個失敗，重送整批可能讓成功的三個頻道產生重複貼文。確認未完成頻道沒有既存貼文後，才考慮只處理該目的地。
5. 公開原文實際顯示什麼？
最後一步要離開排程管理介面，開啟供應商原文並確認：
- 公開帳號正確；
- 影片或縮圖存在；
- 文案符合已核准版本；
- 需要時 root 與 reply 結構正確；
- 顯示的網址確實可以點擊
系統內儲存的 public 設定並不足夠。若原文為私人、消失，或顯示錯誤內容，請記錄觀察結果，並只修正能證明錯誤的部分。
重試前的決策表
| 最後能證明的狀態 | 它證明了什麼 | 安全決策 |
|---|---|---|
| 編輯器驗證失敗 | 尚未通過本地輸入檢查 | 修正輸入，先不要調查供應商 |
| 傳輸失敗且沒有媒體參照 | 沒有已知媒體可附加到貼文 | 修好上傳路徑，再評估一次受控嘗試 |
| 上傳結果未知 | 媒體物件可能已建立 | 先核對 storage |
| 已有 content ID 或 job ID | 發布可能已開始 | 追蹤同一個 ID 到終止狀態 |
| 已有 provider ID 或 permalink | 社群平台可能已有貼文 | retry 前先開啟原文 |
| 公開原文正確 | 面向觀眾的結果已完成 | 不要重貼 |
一次四頻道影片事件的實際結果
2026 年 8 月 15 日，一位 ANKK 營運者為 Instagram、TikTok、YouTube 與 Facebook 準備同一支 10 秒直式影片。
第一次命令列操作完成上傳準備，但傳到 storage 時回傳 HTTP 403。當時沒有產生 asset_ref、content ID、job ID、provider ID 或 permalink，因此四個社群供應商的正確結果都是 尚未嘗試，不是「供應商發布失敗」。
之後，同一檔案指紋的影片透過另外驗證過的支援流程上傳一次。一個媒體參照值分別用於四個不重複的內容要求。四個要求都到達終止狀態 published，並逐一檢查各供應商的公開原文。
後來的成功不會改變第一次操作停止的位置。這個案例顯示，復原要從最後一個已證明的界線開始，而不是在結果模糊時盲目重傳。
每個目的地保留一列證據
channel/account:
scheduled_at/timezone:
media_reference_present:
content_or_job_id:
terminal_state:
provider_id_or_permalink:
public_outcome:
manual_retry_count:每個欄位標記為 已觀察、推論 或 未知。只有在各目的地資料都正確後，才彙總整批結果。
如果正在比較排程工具，可把這個復原測試加入更換社群排程工具前要檢查的 7 件事。
保留原本寫作工具，也能核對發布狀態
本文由 ANKK 營運者根據實際操作整理。ANKK 沒有內建 AI 寫作器；它把人員、外部 AI 工具或腳本準備的內容，連接到社群排程、各頻道狀態，以及供應商公開原文的驗證。