您的自動化歷史記錄顯示一次成功的運行和一個輸出包。 Facebook 顯示兩個貼文。
該證據排除了一些簡單的解釋，但它並不能證明哪個系統重複了寫入。不要再次運行自動化。保留兩個提供者的原始數據，並為可能已到達 Facebook 的每個寫入建立一個證據列。
此清單涵蓋了 Airtable、Make、n8n 或自訂工作流程在 Facebook 主頁收到重複貼文時似乎運行一次的特定情況。
簡短的回答
在更改場景之前，記錄：
- 自動化執行ID和確切的開始/結束時間
- 每個輸入包或來源記錄 ID
- 重試、未完成執行和逾時歷史記錄
- 每個 Facebook 貼文 ID 和永久鏈接
- 每個貼文的公開時間戳記和渲染內容
如果兩個 Facebook 貼文具有不同的提供者 ID，則即使自動化 UI 將工作總結為一次運行，也會有兩個提供者端建立。剩下的問題是第二次建立的起源：另一個觸發器、自動重試、逾時復原、提供者端重複或使用相同來源記錄的單獨用戶端。
在證據區分這些路徑之前，不要標記原因。
1. 首先保留公共原件
在刪除或編輯任一貼文之前，先開啟這兩個 Facebook 貼文。對於每個貼文，捕獲：
- 頁面標識
- 提供者貼文 ID
- 永久連結
- 發佈的時間戳
- 準確的標題和媒體
- 任何可見的作者或出版歸屬
比較文字和媒體指紋。兩個相同的標題並不能證明相同的請求被重播；兩個獨立的客戶端可以發送相同的來源記錄。兩個不同的提供者 ID 確實證明提供者接受了兩個創建。
如果只有一個永久連結可用，而第二篇文章仍然可見，請在調查時保留螢幕截圖和公共時間戳記。將遺失的 ID 標記為 unknown。
2. 將場景運行與提供者寫入分開
綠色自動化運作意味著編排是在該平台的規則下完成的。這並不一定意味著發生了一次外部寫入。
制定文檔，說明連接、速率限制和逾時故障可以透過不完整的執行和指數退避來重試。其文件也指出，非事務性外部應用程式中的操作無法回滾。因此，即使稍後的客戶端步驟逾時或遺失回應，提供者建立也可能成功。
分別檢查這些：
| 層 | 收集證據 | 能證明什麼 |
|---|---|---|
| 觸發 | 計劃/webhook 時間和觸發器 ID | 已啟動多少次運行 |
| 來源 | Airtable 記錄 ID 和輸入包計數 | 有多少記錄進入流程 |
| 建立模組 | 模組操作、開始/結束時間、原始輸出 | 平台記錄了多少個提供者通話 |
| 重試系統 | 不完整的執行、自動重試、退避歷史記錄 | 是否再次運行失敗或不明確的呼叫 |
| 臉書 | 每個貼文 ID 和固定連結 | 有多少個公共提供者對象 |
不要將這五行折疊成「運行成功」。
3. 檢查隱藏的第二個觸發器
在指責 Facebook 之前，先消除您可以控制的原因：
- 使用同一頁面的另一個預定場景
- 即時網路鉤子加上每小時搜尋
- 第二個工作空間、環境或舊場景
- 兩個內容相同的來源記錄
- 從主頁或商務套件手動發布的貼文
- 在狀態更新可見之前再次選擇記錄的輪詢窗口
使用穩定的標識符，而不僅僅是時間戳。將自動化場景 ID、來源記錄 ID、內容指紋和目標頁面 ID 記錄在同一行中。
如果兩個工作流程共用一個來源表，請在提供者建立之前新增特定於目標的聲明或鎖定。單獨的時間緩衝區並不能保證冪等性。
4. 將緩慢的反應視為模稜兩可
長期運行的 Facebook 模組是重要的證據，但它本身並不能確定原因。
如果提供者接受該貼文並且客戶端在收到回應之前逾時，則自動重試可能會建立另一個貼文，除非整合協調第一個結果。如果模組返回一個提供者 ID，同時存在兩個貼文，則保留不匹配的貼文 ID 並詢問哪個參與者創建了它。
安全的規則是：
在檢查目的地之前，逾時或遺失回應為
unknown，而不是failed。
當任何提供者 ID 或符合的公開貼文已存在時，暫停該目標的自動恢復。
5. 建立兩站證據帳本
每個提供者物件使用一行：
destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknown對於兩個 Facebook 貼文，即使自動化平台公開了一次運行，分類帳也應包含兩行。無與倫比的領域顯示調查需要更有力的證據。
6. 新增目標範圍的恢復門
在建立或重試之前，請檢查該頁面的現有記錄：
- 是否已有提供者貼文 ID？
- 是否有儲存的永久連結？
- 公開頁面是否在預期時間視窗內包含相符的內容指紋？
- 未完成的執行是否仍有資格重試創建模組？
當結果不明確時，請將項目移至手動調節，而不是再次建立。當多通道批次部分成功時，在檢查其自身的提供者狀態後僅重試未解析的目標。
該閘並不保證每個提供者都公開冪等性金鑰。它可以防止您的恢復邏輯將遺失的客戶端確認視為沒有創建任何內容的證據。
來自另一個網路的真正部分成功警告
在另一起 ANKK Threads 事件中，發布了一個計劃的根，並且回應步驟遇到了提供者不可用的結果。即使操作員沒有進行手動重試，自動恢復也會產生兩個相同的公開回應。保留提供者的原始內容以及穩定的content ID 與 job ID，以供產品調查之用。
Threads 事件並不能證明 Facebook 重複事件的原因。它演示了一般故障邊界：一旦任何段可能到達提供者，恢復需要該段的提供者協調，而不是盲目重播整個操作。
來源和後續步驟
我經營ANKK。 ANKK 不包含內建的 AI 編寫器。它將人們準備的內容、外部人工智慧工具或腳本連接到社交調度、頻道級狀態和提供者原始驗證。