一批安排5個社會崗位。儀表板顯示兩個為 published，一個為 failed，兩個為 scheduled。您應該重新運行整個批次嗎？不需要。為每個管道建立一個單獨的證據列，並將其content ID、job ID 與 provider ID 與provider original相匹配。

IST 和 UTC 之間有五個半小時的偏移，加上午夜前後的日期變化，使得這一點在印度尤其重要。例如，00:05 IST 對應於上一個 UTC 日期的 18:35Z。如果僅比較顯示的時鐘時間，則正確的job 可能會遺失或延遲。

安全重試的規則是：

  1. 每個通道都有單獨的一行。
  2. 在單獨的欄位中寫入內容 ID、發佈作業 ID 和提供者貼文 ID。
  3. 保留完整的 ISO/UTC 時間以及 IST 時間。
  4. 如果您找到永久鏈接，請打開同一個provider original貼文。
  5. 如果結果不清楚，請勿建立新的內容物件。

批次摘要 3/5 published 很有用，但它無法確定哪個目標可以安全重試。決策應始終在一線層級進行。

三個ID並不能說明同一件事

content ID

內容 ID 指定正在追蹤哪些核准的內容和頻道指令。改變它並創造新的內容可能會打破舊的努力的歷史。

職位編號

作業 ID 標識特定的發布嘗試或計畫的作業。一項內容可能有一個或多個job 記錄，因此請勿將最新作業與較舊作業混合。

提供者貼文 ID 或永久鏈接

這是社交網路可能具有公開物件最強烈的跡象。如果存在提供者 ID 或永久鏈接，則有必要在盲目重試之前打開相同的物件。

將這三項寫在一列 ID 中是不夠的。獨特的標誌可防止重複恢復。

正確匹配 IST 和 UTC

全年 IST 至 UTC+05:30 保持领先。然而，由於日期的變化，視覺比較可能很困難。

例如：

|印度時間表時間 相同 UTC 時間 注意事項 |---|---|---| | 2026 年 8 月 15 日，23:50 印度標準時間 | 8 月 15 日，18:20Z |同一日期 | 2026 年 8 月 16 日，00:05 印度標準時間 | 8 月 15 日 18:35Z | UTC 上一個日期 | | 2026 年 8 月 16 日，00:20 印度標準時間 | 8 月 15 日，18:50Z |也請保持 UTC 格式的批次訂單清晰。

不要只在工作表中鍵入 00:05。包括日期、Asia/Kolkata 或 IST 以及 UTC 時間戳記。這減少了在錯誤的日期午夜後找到貼文的問題。

每個通道的安全重試工作表

為每個目的地填寫此行：

channel/account:
scheduled_at_ist:
scheduled_at_utc:
content_id:
job_id:
latest_state:
provider_post_id:
provider_permalink:
public_original_result:
text_media_link_result:
observed_at:
next_action:

在 public_original_result 中，只需輸入 Correct、partial、Not found 或 haven't checked yet。將每個結論分隔為 seen、Estimate 或 unknown。請勿在此工作表中包含密碼、存取權杖、已簽署的上傳 URL、私人提示或客戶資料。

例：一批 IST，三個不同的決策

這是一個說明性範例，並非任何實際效能或流量的聲明。

|行|最終證明 安全決定 |---|---|---| | Instagram，23:50 IST | published，提供者 ID 和正確的公共來源。確認;無需重試。 |臉書， 00:05 IST | scheduled，相同的作業 ID，截止日期仍懸而未決。等待 |主題，00:20 IST | failed，但提供者永久連結存在。先與原文相符。

如果發現 Threads 的原始貼文是正確的，則儘管處於失敗狀態，但不應重新發布。如果 root 存在但回覆遺失，重新傳送整個 root 並不是一個安全的解決方案；只需檢查缺失部分的位置即可。

在provider original中檢查什麼

在儀表板和 API 狀態之後開啟提供者原始版本。至少看以下幾點：

  • 正確的公眾帳號；
  • 接受的文字；
  • 所需的影像或影片；
  • 完整的根和回應結構；
  • URL 文字和實際可點擊的連結；
  • 不存在重複的提供者物件。

永久連結只是證明某個位置可用。它不會自動證明文字、媒體、回覆和連結都是正確的。同樣，published 作業狀態未經完全驗證的公開渲染。

結果不明確時的四種安全結果

1. 已確認

貼文的內容、職位、提供者 ID、帳戶、時間和公共來源相互匹配。關閉該行並且不要重試。

2.等待

作業目前為 scheduled 或 publishing，穩定 ID 存在且未過期。輸入下次檢查時間。

3.重試前匹配

狀態 failed 或不一致，但提供程式 ID、永久連結或潛在公開物件存在。打開同一個物件並僅隔離缺失的部分。

4. 停止：證據未知

沒有穩定的 ID 或可信的公開結果。停止自動恢復。不要將 unknown 與 failed 或「未發布任何內容」混淆。

60 秒的工作流程

  1. 為批次中的每個頻道/帳戶建立單獨的行。
  2. 寫入 IST 和 UTC 時間。
  3. 讀取相同content ID和job ID的最新狀態。
  4. 如果您找到提供者 ID 或永久鏈接，請開啟公共來源。
  5. 分別檢查文字、媒體、根/回覆和可點擊連結。
  6. 選擇四種結果之一併僅採取必要的後續步驟。

開啟免費社群發布憑證檢查器

檢查器在瀏覽器本地運行。不需要登錄，並且不會發送或儲存輸入的資訊。它不連接到任何社交帳戶，不創建內容，也不發送發布請求。

常問問題

一次重試整批是否安全？

僅當每個目標行確認未建立提供者物件並且相同的更正適用於所有目標行時。如果部分成功，則重複整批可能會產生重複。

如果 failed 可見，那麼為什麼要開啟提供者根目錄呢？

因為錯誤可能發生在請求或回應的不同階段。如果提供者 ID 或永久連結存在，則公開物件可能已建立。查看原始結果而不猜測原因。

IST 哪裡可以找到午夜郵報？

首先將整個 IST 時間戳記轉換為 UTC。 00:05 IST 通常是前一個 UTC 日期。使用帳戶和小時間視窗。

這個檢查員會用AI寫字幕嗎？

不會。這是一個確定性工具，根據現有證據採取下一步行動。它不會複製數據，也不會將數據發送給任何人工智慧模型。

ANKK 如何融入此工作流程

我是 ANKK 的鄭珉豪。 ANKK 沒有內建的 AI 編寫器，也不是 AI 內容產生器。它將人們、外部人工智慧工具或腳本創建的內容與多個社交管道的調度、終端狀態和提供者原始驗證連接起來。

免費檢查器是一個在重試之前進行決定的免費工具。在一致的操作中，ANKK 幫助將每個管道的內容、工作和公共結果連接到單一發布流程。

參見ANKK的調度、狀態和提供者-原始流程

發布清單

  • 身體H1：0
  • 清潔檢查器連結：1
  • 獨特的 HI 活動 CTA：1
  • 建立、更新和發布：每次最多 1 次
  • 重試、歧義後編輯、IndexNow、合成點擊和付費分發：0