越南的貼文定於 00:15 發布，而日誌記錄前一天的 UTC 時間為 17:15。預定時間過後，儀表板顯示 failed，但沒有人檢查公開帳戶。您應該立即建立一個新的預定貼文嗎？
否。首先確認您正在查看同一時刻、相同的content ID 與 job ID 以及正確的提供者帳戶。 ICT 和 UTC 之間的日期變更可能會使正確的 job看起來遺失。即使第一個請求已經到達提供者，在錯誤的日期重試也可能會建立重複的請求。
以下流程可協助操作員在四種操作中進行選擇：確認、等待、重試前協調或保留為未知。
ICT 和 UTC 的日期可能不同，但時間相同
越南時間使用ICT，即UTC+7，不隨季節變化。所以：
2026-08-15 00:15 ICT
= 2026-08-14T17:15:00Z這兩個值是不同的日曆日期，但時間相同。檢查超過 0 小時的作業時，不要單獨比較天數或小時數。也保存本地時間、時區和標準 UTC 值。
| 時間場 | 範例 | 目的 |
|---|---|---|
scheduled_at_local |
2026-08-15 00:15 ICT |
經經營者核准的文章 |
scheduled_at_utc |
2026-08-14T17:15:00Z |
用於比較系統之間日誌的公鑰 |
observed_at |
2026-08-15 00:23 ICT |
當原帖被檢查 |
如果這三個欄位不分開，那麼按時完成的工作可能會被標記為晚了一天。然而，改變時區只能修復比較；它並不能證明該文章已經發表。
追蹤現有的ID鏈而不是建立新的請求
每個階段可以產生不同的標識符。將它們放在同一條線上，看看證據在哪裡停止：
- content ID－已儲存的內容對象；
- 作業 ID — 正在處理排程或發佈作業；
- 提供者貼文 ID — 社群網路接收或建立的物件；
- 提供者原始 URL — 供觀眾檢查的公共介面。
Content ID 的存在並不表示作業已經運行。職位 ID 的存在並不意味著提供者創建了該職位。提供者貼文ID功能更強大，但您仍需要開啟原始貼文來檢查帳戶、內容和可見性。
取得作業 ID 後，再次閱讀正確的 job。僅僅為了「看看它們是否有效」而創建新的內容或工作會失去原始請求與公共結果之間的關係。
每個目標帳戶一份證據
不要將一堆通道組合成一個狀態。對於每個帳戶，至少儲存：
channel/account:
scheduled_at_local:
scheduled_at_utc:
content_id:
job_id:
last_state + observed_at:
provider_post_id:
provider_original_url:
public_outcome:僅記錄安全操作資料。請勿在事件面板中儲存密碼、存取權杖、簽章上傳 URL、隱私提示或客戶資料。
必須檢查每個組件的提供者原件
公開 URL 並不能證明整篇文章都是正確的。打開提供者的頁面並記下每個元件：
| 成分 | 需要回答的問題 | 建議值 |
|---|---|---|
| 帳號 | 文章是否位於已核准的個人資料/頁面上？ | 真/假/不清楚 |
| 根 | 原始貼文的文本和提供者 ID 是否正確？ | 真/缺失/假 |
| 回覆 | 回復是否存在，是否以正確的順序且在正確的根處？ | 完整/缺失/錯誤目的地 |
| 媒體 | 完全渲染的照片或影片？ | 顯示/處理/錯誤 |
| 連結 | 是否有可點擊錨點有正確 href 的點？ |
可點擊/只是文字/錯誤的目的地 |
根是公開的，但缺少回復是部分結果，而不是完整的錯誤。 URL 在標題中可見，但沒有錨點，也不是完整的點擊路徑。分離組件可以幫助您僅處理遺失的部分，而不是重新發布正確的部分。
比較後的四個決定
1. 確認
當 scheduled_at、ID 字串、最後狀態和原始貼文符合時，選擇 確認。帳號、root/回覆、媒體和連結均正確。儲存 URL 和觀察時間，然後關閉作業；不要重試更改過時的 API 回應。
2.等待並設定下次檢查時間
當作業為 scheduled 或 publishing、具有穩定的 ID 並且仍在合理的處理範圍內時，選擇 等待。指定下次檢查日期。等待時間限制是一種受控行為；不斷刷新或創造新的就業並不是證據。
3.重試前進行協調
當系統報告錯誤但提供者貼文 ID、URL 或公用帳戶上的貼文可能已存在時，請選擇「協調」。比較正確的 ICT/UTC 轉換時間段，保持舊 ID 不變，並確定實際遺失了哪些元件。如果三個通道正確而一個通道不清楚，則不要重新運行整個批次。
4. 保持狀態未知
當沒有穩定的ID且結果無法公開確認時，選擇未知。 Chưa rõ 與 failed 不是同義字。停止自動重試並在允許新請求之前找到最後一個有證據的點。
白班的現實範例
胡志明市的一個小組於 23:50 ICT 審查該文章，並製定了 00:15 ICT 的時間表。系統保存 2026-08-14T17:15:00Z。 ICT 00:17，作業轉移至 failed；ICT 時間 00:23，root 出現在正確的帳號上，但回覆包含不可用的連結。
正確結論：
- 時區和日期沒有錯誤：兩個時區時間相同；
- 需要保留作業，因為與根關聯的 ID 是公共的；
- 結果是部分失敗，而不是全部失敗；
- 重試整個執行緒有創建重複根的風險；
- 下一步是根據通道的功能比較遺失的回應。
此範例顯示 scheduled_at、ID 以及回答三個不同問題的原始貼文。只有將它們並排放置，操作員才能知道哪一部分已經完成。
使用checker分類，不改變provider原有
Checker 在瀏覽器本地運行，不需要登錄，並且不會發送或保存您輸入的資料。它有助於將五項證據組織成四項行動。 Checker 不會連接到社交網絡，也不驗證已發布的貼文；提供者原始 URL 仍然是測試的最終來源。
常見問題
ICT 是否隨季節變化如其他時區？
不會。越南的 ICT 全年都是 UTC+7。但是，請務必使用 scheduled_at 儲存時區，以便同時比較國際日誌和本機介面。
如果我有工作 ID 但沒有提供者職位 ID，該怎麼辦？
追蹤作業 ID 本身的最終狀態或設定檢查到期日。不要僅僅因為提供者 ID 沒有立即出現就創建新工作。
根是公開的，但缺少回應。這算成功嗎？
請按部分發表的方式撰寫。保留正確的根，分別比較回复；不要重新提交整個線程。
如果 URL 顯示為文本，觀看者是否可以隨時單擊它？
否。檢查原始貼文上的錨點和 href。沒有錨點的 URL 字串只是文本，而不是確認的運營商點擊。
Checker 是否建立內容或貼文？
不。 Checker 僅對瀏覽器中的證據進行排序。它不連接帳戶，不創建內容，不安排時間，也不發布。
ANKK 如何融入此工作流程
我是 ANKK 的經營者鄭珉豪。 ANKK 沒有內建的人工智慧內容產生器。 ANKK 將人類、外部人工智慧或腳本準備的內容與發佈時間表、頻道狀態以及提供者對原始貼文的驗證連接起來。
Free Checker 是一個獨立的決策工具。對於重複操作，ANKK 有助於將內容 ID、作業 ID、最終狀態和提供者原始 URL 保留在相同追蹤流中。