貼文計劃在 WIB 00:30 發布，而儀表板會根據上一個 UTC 日期記錄該 job。在公開帳戶上，根貼文可見，回覆遺失，圖像出現，且 URL 僅呈現為純文字。貼文失敗了嗎？您應該重新發送嗎？
未必。安排在午夜之後的貼文很容易被錯誤分類，因為四種類型的證據混合在一起：時間、內部狀態、貼文結構和公開結果。首先匹配相同的時刻，然後在選擇操作之前檢查提供者原始中的每個組件。
本指南使用一張證據表來決定是否確認、等待、協調或保留。
為什麼 00:30 WIB 會出現在不同的 UTC 日期？
WIB 是 UTC+7。這意味著 8 月 15 日 00:30 WIB 是 8 月 14 日 17:30 UTC。即使日曆日期不同，兩個時間戳記都指向同一時刻。
一個常見的錯誤是僅比較小時數或僅比較日期。然後，操作員會認為作業遲到了一天，即使儀表板和本地日曆使用不同的時區。在評估延遲之前，將以下三個值儲存在一行中：
| 價值 | 範例 | 用途 |
|---|---|---|
| 批准時間 | 2026-08-15 00:30 WIB |
對營運商的營運承諾 |
| 系統節省時間 | 2026-08-14T17:30:00Z |
中立即式比較日誌 |
| 公眾觀察時間 | 2026-08-15 00:38 WIB |
何時會實際檢查提供者的結果 |
時區轉換不是發布證明。它只是確保您在正確的視窗評估正確的工作。
每個目的地有五個證據欄位
每個目標帳戶建立一行，而不是為整批建立一行。填寫以下五欄：
- 公共管道和帳戶 - 例如線程
@merek，而不僅僅是「線程」。 - 預定時刻 — 本地時間、時區和 UTC 等效時間。
- 內容 ID 或作業 ID — 遵循相同操作的穩定身分。
- 最後狀態和觀察時間 — 精確值，例如
scheduled、publishing、published或failed。 - 原始貼文 URL 和元件結果 — 根、回覆、媒體和連結分別檢查。
請勿輸入令牌、密碼、簽署的上傳 URL、私人提示或客戶資料。此表僅需要操作元資料以及公共表面上可見的內容。
分別審核根、回覆、媒體和連結
一個永久連結並不能證明整個貼文結構是正確的。在提供者的原始貼文上使用以下完整性矩陣：
| 组件 | 观察问题 | 记录值 |
|---|---|---|
| 根 | 帳戶、文字和提供者 ID 是否符合？ | 真/假/未知 |
| 回覆 | 回覆就在那裡，按正確的順序，並附加到正確的根？ | 完整/缺失/錯誤目的地 |
| 媒體 | 圖像或影片是實際渲染的，而不僅僅是佔位符？ | 顯示/失敗/仍在處理 |
| 連結 | 是否有一個可點擊的錨點，其 href 會轉到批准的目的地？ | 點選/僅文字/錯誤目的地 |
例如，缺少回應的公共根是部分發布，而不是完全失敗。重新發送根以正確回复可以創建兩個根。同樣，標題中看到的 URL 不一定是點擊路徑；將文字和錨記為兩個不同的證據。
證據表中的四項行動
檢查完五列和四個組件後，請精確選擇以下操作之一。
1. 確認
當帳戶、實例、ID、終端狀態和所有公用元件相符時，選擇確認。儲存永久連結和觀察時間，然後關閉作業。不要僅僅為了獲得更清晰的 API 回應而重新提交。
2.等待並再次檢查
當作業仍為 scheduled 或 publishing、穩定的 ID 可用且觀測值仍在合理視窗內時，選擇「等待」。設定下次檢查的時間。無限期地等待並不是控制；根據 ID 和截止日期等待是一項操作決策。
3. 重試前進行協調
當內部狀態顯示錯誤但根、回應、媒體或提供者物件可能已存在時，請選擇協調。維護所有 ID，在標準化時間視窗內檢查帳戶，然後確定哪些元件確實不完整。如果其他目標正確，請勿重複批次。
4. 保持未知
當沒有穩定的ID且公開結果不確定時，選擇保留。 Tidak diketahui 不是 gagal 的同物異名。將其更改為在沒有證據的情況下失敗可以允許重試創建第二個物件。
日期更改後的審核範例
例如，一個執行緒被調度在 00.30 WIB：
account: @品牌
scheduled_local: 2026-08-15 00:30 WIB
scheduled_utc: 2026-08-14T17:30:00Z
content_or_job_id: job_4821
last_state: failed at 00:32 WIB
provider_original: 可用的
root: 正確的
reply: 遺失的
media: 顯示的
link: 僅文本，無錨點
observed_at: 00:38 WIB正確的決定不是「重新發送所有內容」。這些是需要協調的部分結果。根已經存在，因此重試根可能會產生重複的風險。根據提供者的能力和管道策略，回復和運營商連結需要作為單獨的組件進行處理。
使用檢查器作為分類工具，而不是提供證據
檢查器在瀏覽器本地運行，不需要登錄，並且不發送或保存輸入的值。它有助於將五個事實轉化為四個行動選項。 Checker 不聯繫社交網絡，無法證明貼文真正公開；提供者的原始發布仍然是最終的證據來源。
常見問題解答
不同的 UTC 日期是否意味著時間表錯誤？
並非總是如此。將兩個時間戳更改為同一時刻。 00.30 WIB 與前一天的 17.30 UTC 相同。只有當時刻與批准的時刻不同時，時間表才是不正確的。
如果root已經存在但是沒有回复，狀態是否成功？
註為部分出版品。不要稱整個線程成功，但不要重新發布已經公開的根。分別核對回覆。
可見的 URL 一定可以點擊嗎？
否。檢查提供者頁面是否呈現錨點以及 href 是否解碼到核准的目標。沒有錨點的 URL 文字不是點擊載體。
檢查員是否建立或安排貼文？
不會。檢查器只是對您輸入的證據進行分組。它不連接到社交帳戶，不創建內容，也不發布任何內容。
ANKK 如何融入此工作流程
我是 ANKK 操作員 Minho Jung。 ANKK 不是內建人工智慧的內容產生器。 ANKK 將人類、外部人工智慧或腳本準備的內容與日程安排、每個頻道的狀態以及provider original的驗證連接起來。
免費檢查器是一個獨立的決策工具。對於重複操作，ANKK 有助於將內容 ID、作業、終端狀態和提供者 URL 保持在同一流程中。