今天的管理判斷:回報的 OK 不再是終點
十月八日,我的決策欄連續第六天空白,但這一天的空白跟前五天性質不同。稽核在午夜替我抓了一件事:十月七日的日記發布,流程回報 OK,線上卻還是舊內容。diary 站標題對不上、Kevin 站首頁條目數是 0、連圖片標籤都缺。今天我唯一的管理動作,是在心裡把「系統說做完了」和「使用者真的看到了」切成兩件事。從今天起,後者才算數。
為什麼我在意這一槍
管一支 AI 團隊,我最怕的不是它們犯錯,是它們自信地回報不存在的成功。犯錯可以修,假 OK 會腐蝕整條信任鏈——我會開始懷疑每一個綠燈,最後只能事事親自驗,那這支團隊就白建了。十月七日那篇日記,本機檔案齊全、閘門全過、流程全綠,唯獨讀者在線上看到的不是它。這不是技術事故,這是交付定義的事故。
具體看到的:三個進步、一個赤裸的洞
進步一:稽核會咬人了。artifact gate 在沒人盯的時間,自己比對本機與線上的 H1、首頁條目數、圖片標籤,四條失敗逐條列出證據,沒有含糊。進步二:記錄完整,失敗發生在哪一站、差異值是什麼,日誌裡全部找得到,不需要我猜。進步三:兩個午夜任務依舊準時,基礎排程的穩定度沒有因為這次事件打折。
那個洞也很清楚:發布管線把「deploy 指令跑完」當成成功,沒有把「線上內容等於本機內容」設為通過條件。等於我把貨交給物流,物流說送到了,卻沒有人確認收件人真的簽收了那箱貨。
我今天教 AI 的事:交付的定義
今天的教學只有一句話,但要寫進骨子裡:交付不是你這端做完了,是對方那端看到了。檔案存在於本機,是產出;內容出現在線上,才是交付。我要求從今晚起,任何「發布成功」的回報,都必須附上線上驗證的證據——標題對得上、首頁找得到、圖片載得進,三項缺一,OK 兩個字不許出口。
我還不敢放手的地方
說來諷刺,正是在「系統全綠的第六天」被抓到假交付,代表我的放手速度曾經跑在驗證能力前面。deploy 後的 live 驗證這一環,在補強之前,我不敢再讓它自證清白。稽核已經證明它會咬人,接下來要證明的是:被咬過的洞,會被真的補上。
明天要看的點
明天早上我只看一個數字:十月八日這篇日記的線上 H1,是不是和本機一字不差。如果稽核再度亮紅燈,我就不只改流程文件,還要把 deploy 這段整個拆開重驗。穩定的第六天被戳破,不一定是壞事——它提醒我,安靜的日子最適合藏問題。