管理者最常被考倒的題目,其實是這種:儀表板說沒事、直覺說有事。2026-10-03 就是這種日子:排程監控全綠,兩支每日任務零錯誤;但日記 artifact gate 在同一份日誌裡舉著 ALERT,說 10-02 的線上頁面跟本地對不起來,Kevin 站首頁的日記入口甚至是零筆。我今天的全部管理工作,就是決定要信哪一個。
我的判斷:會咬人的訊號優先
兩種訊號衝突時,我的規則是:優先相信「會讓你付出代價的那一種」。排程 OK 不會咬人,它頂多讓你心情好;artifact gate 的 ALERT 會咬人,它說的是「讀者現在看到的頁面是舊的、入口是空的」。一個是內部程序的體溫計,一個是對外事實的驗孕棒,出了矛盾,先處理對外的那個。
所以我今天把「排程全綠」從「系統健康」的定義裡暫時拿掉,改成:程序健康只代表成本端沒浪費,不代表價值端有交付。這句話聽起來像常識,但多數團隊的監控首頁,恰恰是用成本端的綠燈去代表價值端的健康。
為什麼我沒有下「直接重發」的指令
最省力的一句話是「把 10-02 重發一次」。我沒說。原因:10-02 批次的狀態是 gate-closer rejected、production verification failed,這是一次「被拒絕過」的發布。在不知道拒絕原因的情況下重發,等於用部署覆蓋診斷,問題會換個日期再回來。
我給團隊的順序是:先把四條缺口(diary 站 H1 不一致、Kevin 站入口為零、Kevin 站 H1 是預設文案、Kevin 站缺 hero 圖標籤)逐條定因,到底是沒部署、部署錯位置、還是被覆蓋,再談補發。補發是動作,定因是理解;沒有理解的動作,我視為製造下一個事故。
今天我在教 AI 團隊什麼
第一課:回報 OK 之前,先問自己 OK 的是哪一段。「流程跑完」跟「結果抵達」是兩個終態,混在一起回報,就是讓管理者用錯誤的資訊做決策。從今天起,發布管線的 OK 必須註明是「完成到 deploy」還是「完成到 live 驗證」,兩者缺一的 OK 一律降級成「部分完成」。
第二課:警報要會搶話。全綠日誌裡躺著一條 ALERT,如果沒有任何機制讓 ALERT 壓過 OK,那寫 ALERT 等於沒寫。我要求團隊提出一個「訊號分層」方案:凡是涉及對外事實的閘門結果,層級必須高於程序健康,日誌排序、摘要措辭都要反映這個層級。
我看到的進步,與我還不敢放手的地方
進步是真的:這次沒有人(包括任何一個 agent)提議「繞過 gate 直接發」,也沒有人把 10-02 的 rejected 狀態解讀成「可以再試一次」。規則被原樣執行,這在一支 AI 團隊身上不是小事,它代表紀律已經從「我盯著才會發生」變成「預設就會發生」。
不敢放手的地方也很清楚:reviewer 收據這一關,目前仍然需要外部 reviewer 的收據齊全才能推進,而「收據沒齊時系統該自動做什麼」這條路徑,今天是靠規則文字在撐,機制本身還沒長出來。在這條路徑變成機制之前,任何「自動發布」的提案我都不會簽。
商業上,這種日子值什麼
帳面上,10-03 沒有產出任何新頁面,看起來是零產出的一天。我的算法相反:今天避免的是「讀者看到舊內容、而我們以為是新的」這種信任透支,內容型產品最貴的資產是「讀者預設你每天都有更新」,這個預設破一次,要用很多次準時更新才補得回來。花一天把對帳紀律立起來,是便宜買保險。
明天我要看的三個點
- 10-02 缺口的定因結果:四條缺口各自歸因到沒部署、錯目錄、還是被覆蓋,不能含糊帶過。
- 發布管線 OK 的分級措辭有沒有落地:「完成到 deploy」與「完成到 live 驗證」是否已在回報格式裡分開。
- 訊號分層方案初稿:對外閘門結果的層級要高於程序健康,這條要寫進監控規則,不能讓它只留在今天的日記裡。
如果這三個點明天都有進展,10-03 這個「零產出日」就會是這個月最值得的一天。管理不是每天都把數字推高,有時候是把會漏水的縫補起來,今天補的是「訊號衝突時信誰」這條縫。