2026-05-25：我今天不讓它急著換模型，先逼它把錯誤分層

我的判斷：紅燈出現時，先看錯在哪一層

今天我最在意的是 AI 團隊看到失敗時，會不會先找真因。日記有沒有發出去、模型名字要不要換，都要排在錯誤分層之後。

如果它把每個 timeout 都叫模型問題，把每個非零 exit code 都叫任務失敗，這支團隊就會越修越亂。今天我逼它做的，是先把錯誤分層，再決定動哪個地方。

我為什麼在意這件事

AI 團隊最危險的地方，是它很會補救，也很會解釋。補救速度快，看起來像能力；但如果沒有把根因挖出來，下一次只是換一個地方爆。

所以我今天的管理重點，是把「能跑完」和「知道為什麼會壞」分開。前者只是交付，後者才是可以放手的基礎。

今天我看到的進步與問題

• 進步：它最後沒有把 `omni/mid-model` 簡化成壞模型，因為 deterministic wrapper 已經證明它可以穩定完成任務。
• 進步：它把日記私有版生成、公開文字檢查、線上驗收都逐步固化成腳本，減少臨場 shell 判斷。
• 問題：一開始仍然容易把「公開發布沒綠」理解成內容或模型問題，沒有立刻分辨工具鏈和驗收鏈。
• 問題：內容站路由也暴露同一種毛病，英文 SEO 文章會跑到不該去的站，代表規則還需要進入日常動作。

我今天在教 AI 什麼

我今天教它的是：失敗要分類，成果要歸位。cron 的問題、模型的問題、gateway 的問題、檢查器的問題，不能混在一起；Kevin 站、toolkit 站、工具站、日記站，也不能混在一起。

管理 AI 團隊，要看邊界能不能被守住，努力程度只能當輔助訊號。錯誤邊界守不住，修復會亂；內容邊界守不住，商業線會亂。

今天的管理心得

帶 AI 團隊時，最該警惕的是它太快給出一個看似合理的歸因。只要歸因錯，後面所有優化都會偏。

今天我更敢讓它跑產線，但還不會讓它完全自己判斷失敗。明天我要看的，是它能不能在下一次紅燈出現時，先交出分類證據，再提出修法。