同一個坑掉三次之後，我把驗收標準搬到最後一哩

我們有一條每天自動跑的日記發布線：AI 團隊寫稿、過審稿閘門、產生封面圖、部署上線。這週它用同一種方式停擺了三次——

• 日記寫好了，本地檢查全過，但沒有進入審稿閘門，也沒有任何人發現它停了
• 沒有錯誤訊息、沒有警報、沒有交接訊號，就安靜地停在那裡
• 每次都是人工巡到才發現：「咦，今天的日記怎麼沒出來？」

最諷刺的是：本地檢查清單每一項都是綠的。「做完」這個詞，騙了我三次。

第一次發生，我當操作失誤處理。第二次，我開始懷疑執行的 agent 不穩。第三次同樣的停擺出現，我的判斷變了：

問題不在執行的人，在流程把終點畫錯了地方。

我們的「完成」定義是「本地產出 + 本地檢查通過」。但這條線的終點不是本地——是線上讀者看得到那篇日記。終點畫錯了， checklist 再綠都沒有意義。而且停擺本身是靜默的：流程卡住時沒有留下任何訊號，監控看起來一切正常。

1. 驗收標準搬到最後一哩。部署完成不算交付；必須在線上 URL 實際抓到今天的頁面標記、比對內容指紋，才算。本地全綠但線上沒變 = 未交付，沒有例外。
2. 閘門退回必須留訊號。任何環節卡住或退回，必須主動發出通知並寫明卡點，不允許「安靜地停著」。
3. 把這兩條寫回流程文件，不是口頭提醒。下一次同樣狀況，系統自己會叫。

同一週稍晚，審稿閘門真的攔下三張不合格的日記首圖（圖片內容跟日記主題對不上），退回重產後才發布。這次閘門有留下明確的退回理由和重產記錄——證明改版後的閘門有牙齒，而且「卡住」不再是靜默事件。

• 「做完」要定義在客戶看得到的地方。本地完成、內部完成、機器完成都不算，終端可驗證才算。
• 同樣的錯第三次，改流程，不換人。前兩次是人的問題的機率很高；第三次還一樣，是系統在告訴你終點畫錯了。
• 靜默失敗比大聲失敗貴十倍。大聲的錯誤自己會被發現；靜默的錯誤靠運氣被發現。所有關鍵環節都要回答一個問題：它壞掉的時候，誰會知道？