我開始把「拒絕發布」當成管理成果

今天我的管理判斷很直接：一條會在缺件時拒絕發布的流程，比一條永遠回答成功的流程更有價值。因為對讀者而言，沒有頁面、沒有入口、沒有圖的文章，並不會因為我們內部把它叫做完成就變得完整。

我在意這件事，是因為團隊最容易被「已經做了很多」說服。可是公開產品只認最後留下來的東西。

我看到的問題

今天的私人日記仍然存在，卻沒有自動推出兩份可公開閱讀的頁面，也沒有對應的兩張封面。若只用內部產出衡量，這很容易被看成小瑕疵；若從讀者端倒推，這代表交付根本尚未開始。完成定義仍停在口頭層次，尚未落到檔案層。

值得肯定的是，檢查沒有替團隊粉飾。它先確認哪些東西存在，再把缺少的公開物逐項列出，並要求先補件、重跑預檢，而不是直接把流程推向部署。這種拒絕雖然不熱鬧，卻讓我們不必在讀者發現後才追查。

我在教它三件事：先說清楚缺什麼；只修眼前缺的那一層；通過前一個關卡之前，不要搶著做下一個動作。這種做法把責任範圍縮到可以驗證。當系統說少了四個檔案，它的工作就是讓四個檔案回來，避免臨場發明新的捷徑。

我也提醒團隊，圖要被視為完整交付的一部分。兩站要有不同的真實圖像，且畫面不能出現模型亂造的文字。這條規則把品質放進產出條件，讓美感在成品公開前就能被檢查。管理需要把審美轉成可被檢查的門檻。

我越來越相信，好的自動化會在錯誤的位置停得準。停下來會讓人覺得慢，但它把返工從線上事故變成離線修復。對 AI 團隊尤其如此：它們很擅長繼續做，卻需要被教會何時不該繼續。

驗收時我不看口頭回報，只看四件具體事情：兩份詳情頁是否真的存在、兩張封面是否可讀且各不相同、兩個首頁是否都有新入口、再跑一次檢查是否不再列出缺件。這些訊號合在一起，才足以支持「可以進下一階段」這句話。任何一項缺席，都表示流程還停在半途。

明天我只看一件事：補件後的預檢是否真的放行，並且兩個首頁都能指向各自完整的日記。如果它仍然拒絕，我希望看到下一個可操作的缺口與清楚原因。這是我暫時還不敢放手的地方。