機器撐住了，判斷沒有。13 天、169 次服務檢查全部在線，內容與流程卻出了 7 件錯。
2026-10-25 閱讀時間約 8 分鐘
10 月 8 日我們發過〈人不在的一個月〉，條件是：我不在辦公室，沒有其他真人員工，內容交給 AI 團隊，我只保留簽核。這篇先講結果。
這個實驗測的不是 AI 有多萬能，是管理者每天只有 30 分鐘、只有手機，其餘交給 AI 員工，後台會怎樣。30 分鐘，夠不夠管住一家公司。
13 天後，先講結論。機器撐住了，判斷沒有。169 次檢查全部在線，內容與流程卻出了 7 件錯，其中 6 件不是機器壞掉，是檢查設在錯的位置。
169 / 169
服務檢查全在線
37.1 分鐘
一天在場，是目標的 1.24 倍
1 / 7
7 件錯裡只有 1 件是工具壞掉
01
每天一次健康檢查，13 天沒缺；13 個服務乘 13 天，169 次全在線，5 個對外入口每天實測 HTTP，65 次正常。12 天全綠，10 月 4 日黃燈一天（兩服務各重啟 3 次，不是中斷）。
機器這一層：13 天全部在線
每天台北時間 12:30 自動檢查一次，13 天沒有缺過。
169 次檢查全在線
65 次 HTTP 實測全正常
12 天全綠、1 天黃燈
有個數字沒觸發警示：磁碟從 74% 爬到 84%，就像腳上的酸痛，慢慢累積，等你發現時已經走不動。
02
目標 30 分鐘。實際中位數 37.1 分、平均 47.8、最短 22.3、最長 92，一天進場 13 次、每次 3 分鐘，13 天只有 2 天達標，合計 10.4 小時。
每天在場時間，13 天裡只有 2 天在 30 分鐘內
橘色為超過 30 分鐘的當天；點上數字是當天進場次數。單位：分鐘。
換算下來，我每 1.8 小時出現一次，每次 3 分鐘，比較像來按讚的路人。問題不在多出的 7 分鐘，在 37 分鐘切成 13 段。這種狀態下，人只能看結論、點頭或退回，沒有餘裕驗事實（在場時間是估計值，5 分鐘內算在線）。
簽核那一關：56.3 小時的等待，不到 10 分鐘的判斷
10 月兩期電子報，從完稿到點頭。以每次進場 3 分鐘估。
一天 24 小時，他有紀錄的在場時間 37 分鐘，剩下 23 小時 23 分鐘，任何要等他點頭的事都停在那裡。
03
7 件、8 筆，多出的那筆是同一件誤判被推翻。一件影響到讀者：電子報頁面夾著內部註記，前後 10 期；同一份檔案兩個出口，寄信有稽核，官網沒有。一件在造成影響前被攔下：情報摘要寫了當天沒收錄的 Gartner，是程式做機構名交集抓到的。
7 件錯，6 件是檢查的問題
只有 1 件是工具真的壞掉。另計排程層 5 次故障，全部自行解除。
一類重複犯兩次：跨日去重先漏 1 筆、又漏 4 則，改成 30 天池 350 條。另三件沒對外但吃時間：IG 檢查程式寫錯、模型卡七分鐘、封面誤判三輪；排程層 5 次故障都自己解除。只有 1 件是工具壞掉，其餘都是檢查的問題。
04
5 篇
官網文章
3 期
電子報寄出
4 支
影片上線
10 組
IG 圖卡
13 天
情報掃描沒中斷
10.4 小時
13 天的管理時間
10.4 小時，換 13 天 operation：文章 5 篇、電子報 3 期、影片 4 支、IG 10 組，情報掃描沒中斷。代價是 7 件只有 2 件留下修復時間。
05
系統健康不等於內容正確，檢查看服務，不看交付物。
30 分鐘買到的是判斷，不是驗證，驗證要在東西送到他面前之前做完。
有限窗口下，人的作用是推翻，不是多讀，力氣花在指定「驗什麼」。
06
這 13 天我在朝聖路上。我原以為要驗的是 AI，結果 AI 一次都沒停，停下來的是我這一關。回頭看，我最常做的決策叫「可以」。
人工簽核我以前覺得是負責。這次 7 件告訴我，簽核後面沒有證據，只是一種感覺。這種感覺，山上特別多。
還有一件我要承認：很多 pending 不是東西沒做好，是我在走路，一天走七到九小時。最大的風險不是 AI，是我走到沒訊號的地方。
我要改的是順序：先問這件東西被誰驗過、用什麼驗、驗的是不是要交出去那份，再問我覺得好不好。前一題十分鐘就夠。
郭鎮榕 榕耀管顧
07
本來這篇排在十一月，颱風天在家閒閒沒事，就先結算了。下週我們會公告改善計畫：根據這 13 天的結果，說明管理方式要怎麼改。
