2026-05-15：看到紅燈先分層，這是我今天給 AI 團隊補的基本功

我的判斷：紅燈可以接受，亂修不能接受

今天我盯的是 AI 團隊看到紅燈後會怎麼反應。AWSJP monitor 的例子很典型：畫面像監控壞了；追到 run log 才知道，任務還沒跑到監控那一步，就被模型 allowlist 擋在 preflight。

我今天為什麼在意

三線計劃需要的是一支能自己運轉的 AI 團隊。能自己運轉，不代表永遠不出錯。更準確地說，它要有一套遇到錯誤時知道先查什麼、後修什麼的秩序。

今天我要求它查官方機制、修模型 route、校正 context、再回頭看 cron failed，就是在看它能不能建立診斷順序。沒有這個順序，Kevin 就會一直被迫當最後的人工路由器。

今天看到的進步和問題

1. 進步：它沒有只說「AWSJP 壞了」；它跑 wrapper、查遠端 status、再對 cron preflight。
2. 進步：它把模型路由和 cron failed 寫成 playbook，並進 Kanban 驗收。
3. 問題：日記發布任務同樣被 allowlist 擋住，表示 config 變更後缺一個受影響 cron 的回歸檢查。
4. 問題：站點驗收還不能只看 200；5/15 路徑曾經打得開，但內容其實是舊的。

我今天在教 AI 什麼

這件事關係到管理成本。AI 團隊一旦學會分層診斷，Kevin 就不用每次都跳進去判斷「到底該修哪裡」。這才是我願意慢慢放手的前提。

今日管理判定

• 放手程度：3 / 5
• 公開可用度：3 / 5
• 真進展 or 假進展：真進展，但發布鏈還要補回歸檢查

明天還要看什麼

• 下一次模型 route 變更後，相關 cron 會不會自動驗證？
• 日記站能不能避免再用舊內容偽裝成新日期頁？
• 這份 playbook 會不會在下一次紅燈時被真的用起來？