連續兩天失敗後,我決定不修日記先修規則

第一天失敗可以怪運氣,第二天就不行

9月7日的日記發布失敗時,我的第一反應是「可能是偶發問題」。cron任務有時候會因為各種原因抖動一下,通常第二天自動恢復。但9月8日凌晨,同樣的任務再次失敗,而且原因一模一樣——前一天的詳情頁根本不存在。

這時候我看到了真正的問題:頁面為什麼沒生成只是表層,更深的是第一天的失敗為什麼沒有觸發任何動作。如果系統在09-07失敗時就自動進入修復模式,09-08的cron根本不會撞牆。

09-07的失敗確實被記錄了——consecutiveErrors從0變成1,狀態變成error。但這些信息寫在哪裡?寫在一個系統日誌裡,沒有觸發告警,沒有進入每日審計的視野。就像你把火災報警器裝在地下室,二樓著火時樓上聽不見。

我做管理這幾年學到一個教訓:記錄不等於通知。你可以把所有錯誤都寫進日誌,但如果沒有人或系統去讀取、判斷、行動,那些記錄就只是數位垃圾。失敗處理的第一步,是讓對的人在對的時間看見問題。

這次事件推動了一個改變:artifact gate不再只是默默檢查然後退出。它現在會把偵測到的問題結構化輸出,寫進每日memory,進入第二天的daily task audit。這樣一來,問題會持續出現在健康檢查報告裡,直到被解決。

這個設計背後的管理原則很簡單:問題的可見性和問題的嚴重程度一樣重要。一個被完美記錄但沒人看見的問題,比一個被粗糙描述但立刻進入所有人視野的問題更危險。

連續錯誤計數器是一個很簡單的機制,但它解決了一個大問題:如何區分偶發故障和系統性問題。一次失敗可能是運氣不好,連續兩次就是信號。這個數字讓團隊能快速判斷問題的嚴重程度,決定是繼續觀察還是立刻介入。

我特別喜歡這個設計的地方在於,它不試圖「聰明地」判斷問題原因——它只忠實地計數。原因分析是人的工作,但前提是數據要準確、要即時、要可見。consecutiveErrors確保了這一點。

面對連續兩天的失敗,我選擇先不急著補頁面。頁面什麼時候都能補,但如果失敗處理的規則不改,下次還會在同樣的地方跌倒。管理AI團隊和管理人的團隊一樣——你要修的不只是眼前的bug,還有讓這個bug能存活兩天的流程漏洞。

這次的教訓是:自動化系統的可靠性,不取決於它成功時有多快,而取決於它失敗時有多 loud。安靜的失敗是最危險的失敗,因為你根本不知道它發生過。讓失敗變loud,是管理者對自動化系統最基本的要求。