我今天收到一盞來源可疑的紅燈，沒有新功能展示。自動化團隊最容易犯的錯，是看到警報就急著證明自己有處理；於是重跑工作、改掉狀態，甚至把紅燈消音。這些動作很忙，卻沒有回答最重要的問題：發出警報的那雙眼睛，現在還看得到真實世界嗎？

我的判斷很直接。監控器若仍讀取退役來源，它沒有資格替工作判定成功或失敗。這時應先修證據鏈，被監控的工作要等查證後再處理。只要責任邊界沒有分清楚，團隊越自動化，錯誤結論就傳得越快；一盞過期綠燈帶來的風險，往往比一盞誠實紅燈更大。

我用三個問題判斷狀態能不能信

三個問題只要有一個答不出來，我就不把狀態當作授權依據。這項限制能避免錯誤自信進入下一層決策。AI 很擅長填補空白；管理者要做的，是規定空白必須保持空白，直到新證據出現。

不要用重跑掩蓋診斷不足

重跑是最容易製造活動感的處理方式。它可能暫時產生新的時間戳，卻沒有修復監控為何讀錯來源。我的要求是先保留現場：記下觀測缺口、確認真實工作狀態、找出來源遷移點，再決定是否重跑。失敗若沒有被準確分類，重跑只是在擦掉可以學習的證據。

退役流程必須連監控一起退役

系統搬家時，人們常只搬執行入口，忘了監控、稽核與告警還留在舊地址。這次我要求把退役工作從健康清單移除，讓新的排程狀態成為唯一可信來源。保留兩套讀法看似多一層保險，實際會產生兩套互相矛盾的現實，最後沒有人知道該相信哪一個。

批准要綁在不會漂移的產物上

同樣的原則也適用於內容發布。審查者批准某一組精確內容與圖片；日期名稱本身不構成批准。只要首頁、站點地圖或文章在審查期間改變，原批准就失去效力。我把發布門改成必須帶入預期指紋；系統不能在發布前偷偷重建清單，再拿舊批准替新內容背書。

我的管理判定：權限跟證據同步

今天我沒有因為紅燈收回整條自動化，也沒有因為工作其實可能正常就忽略警報。我只收回那一段沒有可信證據的判斷權，等觀測來源修好再交還。這是我管理 AI 團隊的核心做法：權限隨著可驗證能力逐段增加，不會一次給滿；證據斷裂時，權限自動縮回安全範圍。

明天我只看一件事：證據能否連續

單次修復成功很容易，連續幾個週期都能提供同樣可信的狀態才算能力。我會看新的觀測來源是否持續更新、不同錯誤是否仍被正確分類、發布時是否真的拒絕漂移指紋。自動化的成熟度不在於它從不亮紅燈，而在於紅燈出現時，團隊知道該停哪裡、修哪裡，以及用什麼證據恢復授權。