排程工具顯示 published，不代表每個公開元素都符合預期。貼文可能已經存在，但網址只是一串文字；root 已公開，reply 卻沒有出現；文字正確，媒體仍缺少。這時直接重送，最容易把「部分完成」變成重複貼文。

安全的做法不是先猜原因，而是把終端狀態、供應商永久連結、公開原文結構與實際可點擊連結拆開核對。每一項都留下可觀察的結果，再決定是否需要等待、對帳或停止自動重試。

先回答：什麼情況不能直接重試？

只要符合以下任何一項，就不應直接重送整篇內容：

  1. 已有 provider post ID 或永久連結。
  2. 公開帳號上能找到相同時間、文字或媒體的貼文。
  3. root 已存在，但 reply、媒體或連結狀態尚未確認。
  4. 畫面看得到 URL 文字，卻不知道是否有真正的 href。
  5. 儀表板與公開原文的結果互相矛盾。

這些狀況代表「可能已有供應商物件」，而不是「確定沒有發布」。先核對既有物件，才能避免第二次建立同一內容。

published 只回答工作狀態

published 通常表示發布工作已到達終端狀態。它不會自動證明以下事項：

  • 貼文出現在正確的公開帳號；
  • root 與必要的 reply 都已建立；
  • 圖片或影片確實呈現在原文；
  • URL 被轉成可點擊的連結；
  • 連結導向預期的最終目的地；
  • 沒有多出第二個供應商物件。

因此，營運完成條件應寫成兩段：先確認終端狀態，再確認 provider original。若內容本來包含多個組件，還要逐項確認完整性。

4 層原文證據

第 1 層：工作與供應商物件

先保留同一筆操作的 content ID、job ID、provider post ID 與永久連結。讀取既有 ID 的最新狀態，不要先建立新工作。

若只有 accepted、scheduled 或 publishing，這仍是進行中的工作。若顯示 failed，但已有 provider post ID，仍要先開啟公開原文。錯誤可能發生在回傳或對帳階段，不能據此推定貼文不存在。

第 2 層：root 與 reply

多段貼文要把 root 和 reply 當成不同物件。root 公開，不等於整個串文完成。

逐項記錄：

組件 要保存的證據 常見誤判
root provider ID、帳號、文字、時間 root 存在就算整串成功
reply reply ID、順序、文字、父層 reply 缺少時重送 root
thread 關係 root 與 reply 的連結方式 兩篇獨立貼文被當成串文

在一次已觀察的日文 Threads 發布中，root 已公開，但 reply 因 provider unavailable 沒有建立，因此預計放在 reply 的連結也不存在。這是部分結果，不是完整成功；也不能藉此推定未觀察到的根因。

第 3 層：媒體與公開呈現

文字正確，不代表圖片、影片或縮圖正確。檢查：

  • 媒體數量是否符合預期；
  • 圖片順序或影片是否正確；
  • 公開權限是否允許未登入者看到；
  • 縮圖與替代文字是否合理；
  • root 與 reply 的媒體是否放在正確位置。

如果媒體缺少，先確認 asset reference、media ID 與供應商原文。不要因為文字已公開，就把整篇貼文重新送出。

第 4 層：URL 文字、href 與目的地

看到 https:// 文字，不等於存在可點擊連結。至少分成三項：

證據 問題 可記錄的結果
URL 文字 原文中看得到完整網址嗎？ 是／否
anchor / href DOM 或可存取結構中有實際連結嗎？ 是／否／未知
解碼後目的地 連結最後導向預期網址嗎？ 正確／不同／未測試

同一輪實際發布曾出現兩種結果：Facebook 原文有可點擊並能解碼到預期網址的連結；Bluesky 原文顯示完整 URL 文字，卻沒有對應的 anchor / href。兩筆工作都顯示 published，但只有前者是已驗證的點擊載體。這裡只記錄公開結果，不推測平台內部原因。

一列就能保存的核對欄位

每個頻道各用一列，避免把多頻道結果壓成單一「成功」：

channel/account:
scheduled_at/timezone:
content_id/job_id:
terminal_state:
provider_post_id/permalink:
root_result:
reply_result:
media_result:
url_text_present:
clickable_href_present:
decoded_destination:
observed_at:

每個欄位只用 已觀察、推定 或 未知 標示證據層級。不要在紀錄中放入密碼、token、簽名網址、私人 prompt 或客戶資料。

檢查器的 4 種結果

1. 已確認

終端狀態、帳號、原文、root/reply、媒體與連結都符合預期。保存證據列，結束這次操作，不要重送。

2. 等待

同一 job 仍在 scheduled 或 publishing，而且有穩定 ID 可以追蹤。設定下一次檢查時間，不要重複按發布。

3. 重試前先對帳

儀表板顯示失敗或完成，但公開原文是部分結果，或已有 provider ID 尚未核對。開啟原文，把缺少的 reply、媒體或 href 單獨列出，再選擇只修復必要範圍。

4. 暫停：證據不足

沒有穩定 ID，也無法可靠判斷公開結果。停止自動恢復，找出證據在哪一層中斷。未知 不能直接改寫成 failed 或「沒有貼文」。

60 秒重試前流程

  1. 複製頻道、帳號、排程時間、content ID、job ID 與最新狀態。
  2. 若有 provider ID 或永久連結，直接開啟同一個公開物件。
  3. 分別核對 root、reply、媒體與帳號。
  4. 對 URL 做文字、href、解碼後目的地三段檢查。
  5. 從已確認、等待、重試前先對帳、暫停四種結果中選一個。
  6. 保存觀察時間，只執行下一個必要動作。

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

檢查器只在瀏覽器內運作，不需要登入，也不會傳送或儲存填入的資料。它不會連接社群帳號、建立內容或替你發布。

常見問題

顯示 published，但沒有可點擊連結，算失敗嗎？

不能只用一個詞概括。貼文本身可能已發布，但點擊載體未完成。分別記錄公開內容與 href，不要因連結缺少就重送整篇貼文。

root 有了、reply 沒有，該重送哪一段？

先確認 reply 是否真的未建立，並保存 root ID。不要重送已公開的 root；只針對缺少的組件進行經過確認的修復。

有永久連結，就代表媒體和文字都正確嗎？

不代表。永久連結證明有一個可定位的物件，仍需打開原文逐項比較文字、媒體、結構與連結。

檢查器會用 AI 產生內容嗎？

不會。它是依輸入證據分類下一步的確定性工具，不會產生文案，也不會把資料送到 AI 模型。

ANKK 在這個流程中的角色

我是 ANKK 營運者 Minho Jung。ANKK 沒有內建 AI 寫手，也不是 AI 內容產生器。它把人員、外部 AI 工具或腳本準備的內容，連接到多頻道排程、終端狀態與供應商原始貼文驗證。

免費檢查器是重試前使用的獨立判斷工具。需要持續管理時，ANKK 可讓內容、工作 ID、各頻道結果與 provider original 留在同一個發布流程中。

了解 ANKK 的排程、狀態與原文驗證流程

發布契約

  • 內文 H1：0
  • 免費檢查器乾淨連結：1
  • zh-Hant campaign CTA：1
  • Create、update、publish：各最多 1 次
  • Retry、模糊結果後編輯、IndexNow、合成點擊、付費曝光：0