如果預定的貼文仍未出現，暫時不要重新發送。將預定時間轉換為 Asia/Bangkok，收集 content ID 與 job ID，檢查 provider ID 或 provider original URL，並確認文字、媒體、根貼文和回覆是否完整。如果系統回應缺失，則將結果記錄為未知，然後再決定是否重試。
這不是一個簡單的成敗問題。排程工具與平台上的公開貼文可能會在不同時間更新。job 可能仍在排隊，貼文可能僅部分發布，或者即使回應從未到達工具，發布也可能已成功。每個發布目的地記錄一列證據，就能區分這些情況。
本指南適用於需要做出安全重試決定的泰國社群媒體營運商。它使用明確的泰語時間戳記、可追蹤 ID 以及提供者原始版本中可見的結果。
簡短回答：當預定的貼文沒有出現時，我該檢查什麼？
依序檢查 5 個主要群組：帳戶和頻道、設定為 Asia/Bangkok 的時間、content ID 或 job ID、最新狀態以及具有公開結果的provider original。然後檢查訊息、媒體、根連結的完整性，如果證據不夠就回覆。停止重新發送並選擇“等待”或“未知”。
重新發送不是診斷測試。它改變真實狀態並可能創建第二個提供者對象，在重試之前我們必須先確認第一個對像不存在。或它存在但缺少任何部分？
將時間統一為 Asia/Bangkok
泰國使用 Asia/Bangkok 時區，即 UTC+07:00。僅儲存單字「16:30」是不夠的，因為它不告訴日期、時區或系統記錄為 UTC 的值。
對於計劃於 2026 年 8 月 15 日下午 4:30 在曼谷發布的貼文，請保留至少以下兩種格式：
scheduled_local: 2026-08-15 16:30 Asia/Bangkok
scheduled_iso: 2026-08-15T16:30:00+07:00
scheduled_utc: 2026-08-15T09:30:00Z當一個螢幕顯示泰國時間而另一個螢幕顯示 UTC 時，請比較標準化時間，而不是確切的小時。 09:30Z 和 16:30+07:00 代表同一時刻。
至少應分隔四個時間值：
| 時間 | 用來回答什麼問題 | 還是無法證明什麼 |
|---|---|---|
scheduled_at |
應該什麼時候開始工作？ | 提供者收到郵件了嗎？ |
job_created_at |
出版工作是什麼時候創建的？ | 工作完成了嗎？ |
provider_published_at |
提供者表明其發佈時間 | 內容和連結是否正確顯示？ |
observed_at |
我們什麼時候檢查公開頁面？ | 兩次檢查之間會發生什麼事？ |
請勿以實際發佈時間覆蓋設定時間。將兩者分開，將“緩慢啟動”與“按時發布，但狀態返回較晚”分開。
單獨的內容 ID、作業 ID 和提供者 ID
三種ID類型不是同一個字。並且不應合併為單一註釋欄位。
內容 ID 是內容的範圍及其目的地
Content ID 標識核准的訊息、媒體、帳戶和時間。發生錯誤時，請先開啟原始內容，然後再建立新內容。查看傳送的目的地以及記錄了哪些值。
作業 ID 是一項發布工作，可以追蹤其狀態
作業 ID 用於追蹤從 scheduled 或 publishing 到目標狀態的作業，例如 published 或 failed。如果您已有作業 ID，請檢查原始作業，而不是建立新作業，看看會發生什麼。
提供者 ID 或永久連結是社交方面的對象
提供者 ID 連結到網路對象，而永久連結允許直接存取原始貼文。擁有此 ID 是提供者可能已接受該工作的重要證據。但您仍然需要檢查讀者看到的帳戶、訊息、媒體、連結和結構。
實用的錄音格式：
channel_account:
scheduled_local: Asia/Bangkok
scheduled_utc:
content_id:
job_id:
last_status:
provider_id_permalink:
text_outcome:
media_outcome:
link_outcome:
root_reply_outcome:
acknowledgement: confirmed | ambiguous
observed_at:
next_check_at:請勿在此記錄中包含密碼、存取權杖、私人提示、客戶資訊或簽署的上傳 URL。僅使用提供者提供的功能性且可驗證的元資料。
published 狀態並不能證明貼文已完成
目標狀態回答工作流程如何報告。但必須從原始貼文檢查完整性。將每一部分分開，以便一個部分的成功不會掩蓋另一個部分的失敗。
| 部分檢定 | 通過時間 | 樣本結果不完整 |
|---|---|---|
| 文字 | 內容與核准版本相符 | 剪下或使用錯誤語言的文字 |
| 媒體 | 可以顯示正確的圖片或影片 | root 有文字但缺少媒體 |
| 連結 | 有一個錨點，可以點擊並轉到正確的目的地 | 可以看到字母中的 URL，但無法點擊 |
| 根 | 位於正確的帳戶和線程中 | root 位於錯誤的帳戶中 |
| 回覆 | 數量、順序和完整內容 | root 只發布缺少連結的回應 |
如果 root 已發布但回覆消失，則正確的結果是 部分發布 並非全部成功。並不是所有的都失敗了。重新提交整個集可能會導致重複的根。
如果訊息和媒體完整，但 URL 只是無法按下的文本，則連結結果必須記錄為不完整，即使狀態為 published
當確認不清楚時，重試前該做什麼？
逾時、螢幕凍結或空白回應並不能證明提供者拒絕了該 job。請求可能已到達提供者，但確認從未到達客戶端。
儲存 acknowledgement: ambiguous。並按以下順序執行：
1.讀取原始content ID以驗證帳戶和內容。
2. 讀取原始作業 ID 直到達到目標狀態或排程下一次檢查。
3. 檢查是否已建立提供者 ID 或永久連結。
4.在正確期限內開立公眾帳號Asia/Bangkok
5. 訊息、媒體、根連結、回覆一一比較。
6. 僅重試已證明尚未發生的部分。並且不影響已經發布的部分
「模糊」一詞很有用，因為它可以防止系統自動將「未知」轉換為 failed。
重試貼文之前的決策表
| 所見證據 | 判決 | 下一個作品 |
|---|---|---|
| 工作已成功完成，帳戶正確，所有部件均與原始提供者完整 | 已確認 | 保留證據，請勿重新提交 |
| 客戶端報告錯誤或沒有確認，但提供程序物件可能存在 | 重試前檢查 | 讀取原有 ID 與 provider original並核對原件 |
狀態仍為 scheduled/publishing 並且檢查時間仍在框架內 |
等待 | 使用亞洲/曼谷設定 next_check_at |
| root 存在，但缺少一些媒體/連結/回應 | 發布部分內容 | 將已完成的部分和未完成的部分分開 |
| 沒有可追蹤 ID，或無法驗證公開結果 | 暫停——尚不清楚 | 停止自動恢復並收集更多證據 |
該表選擇下一步檢查。原因尚未診斷出來。如果您需要尋找原因，請新增更多日誌和提供者證據，而無需建立新貼文。
泰國時間範例：root 已到達但回覆尚未到達
假設線程設定為晚上 8:00。 Asia/Bangkok 或 13:00Z。content ID 與 job ID 已建立。晚上8點02分，root出現在正確的帳號中，但有連結的回覆還沒出現，客戶端顯示逾時。
該證據表明提供者至少已收到 root，因此不要重新發送整個線程。記下 root 的提供者 ID、時間 observed_at 和 root_reply_outcome: partial，然後檢查原始作業並尋找可能遲到的回應。
如果稍後出現回复，請新增回复 ID 並檢查實際連結。如果在視窗過期且作業完成後沒有出現，則恢復應僅限於回復部分，始終首先檢查冪等性和provider original。
在瀏覽器中使用免費檢查器作為工作表
社交發布證據檢查器 取得管道/帳戶資訊、content ID 或 job ID 設定時間、最新狀態、提供者 URL 以及公開結果。然後將決策分組。確定性 該工具不需要登入。帳戶未連接，且不發送從瀏覽器輸入的訊息
在泰國工作，請輸入 Asia/Bangkok 或 ISO 偏移量 +07:00。隨時準備好日期然後將結果複製到事件日誌中以便長期儲存。
常見問題
亞洲/曼谷與 UTC 有何不同？
Asia/Bangkok 這是使用泰國規則的時區，偏移量為+07:00。 UTC 是參考標準。曼谷時間 16:30 等於當天的 09:30Z。應保留當地時間和 UTC 以比較多個系統。
如果狀態已發布但連結無法使用是否算成功？
僅狀態成功但如果連結獲得批准，公共結果尚未完成。與終端狀態分開記錄 link_outcome，並且不要僅從綠色徽章就認為發布已完成。
如果狀態是 failed，我應該立即再試一次嗎？
否，直到檢查內容 ID、作業 ID、提供者 ID 和公用帳戶是否有衝突物件為止。遺失的回應可能與成功建立的提供者物件共存。
如果我沒有提供者 URL，該怎麼辦？
首先使用原始content ID 或 job ID 檢查狀態和提供者身分。如果 ID 和 URL 均不可用且無法驗證公開結果，請選擇「暫停 - 未知」而不是建立新貼文。
Checker 是否發布貼文或提交輸入的資料？
不，Checker 是一個在瀏覽器中計算的工作表。不建立內容不連結帳戶，不設定時間表，也不發布貼文。
ANKK 在這個工作流程中適合什麼位置？
我是 ANKK 的管理員 Minho Jung。 ANKK 不是內建的 AI 創作工具。該服務連接由人類、外部人工智慧工具或腳本準備的內容。與設定時間、頻道目的地狀態和原始提供者驗證相容
免費的 Checker 是一個在瀏覽器中運行的獨立決策工具，而 ANKK 是一個用於定期重新發布的工作層。必須在單一流程中追蹤內容、工作和提供者證據
查看 ANKK 的排程與 provider original 驗證流程
重試之前的最終清單
- 記錄日期、時間和
Asia/Bangkok是否完整？ - 轉換為UTC是否正確？
- 內容 ID、工作 ID 和提供者 ID 是否分開？
- 指定不清楚是否有歧義的確認。
- 是否單獨檢查訊息、媒體、根和回應連結。
- 提供者是否在正確的帳戶中開設了原始帳戶？
- 將恢復限制為僅那些已被證明尚未發生或尚未發生的部分。
如果您仍然無法回答所有問題。將狀態保持為已驗證或「未知」。最好等待證據，而不是基於猜測重新建立提供者物件。