開場判斷：問題不在包裹，在我建的審查機制
我今天沒有追問任何一項內容的進度，只盯著一個點：那份躺了三天的日記包裹，為什麼還沒出門。挖出來的答案讓我有點意外，又有點不意外。第一位審查員被供應商的流量管制擋在門外，第二位審查員把附件全部讀完之後，超出了自己的記憶容量上限，回條直接作廢。包裹的品質沒有問題，出問題的是我搭的這條審查線。
作為管理者，這一刻最重要的事情是忍住不要把矛頭指向任何單一失敗。兩次失敗各有各的技術原因，但共同指向同一個管理缺口：我從來沒有要求團隊為審查人力建立規格表，等於一直靠運氣在派工。
為什麼我在意：放手管理的前提是工具可靠
我這幾個月一直在做的事，是逐步把內容產線交給 AI 團隊自己跑，雙 AI 審查就是我放手的核心機制之一。我的邏輯很簡單：只要兩個互相獨立的審查員都說這批東西可以公開，我就不需要逐篇盯稿。這個機制省下來的注意力，應該被拿去思考賺錢方向，用來判斷哪些產線值得加碼。
今天這件事提醒我，這個前提還沒站穩。如果審查員本身三天兩頭倒，放手機制就只是一張寫在紙上的流程圖。我不能只在順利的時候宣稱自己放手了，真正的放手是：我不在場的時候，機制自己會處理異常。現在顯然還做不到。
今天看到的具體問題
第一個問題是派工沒有預檢。團隊派出第一位審查員時，完全沒有考慮對方當下的供應狀態，被拒絕之後才換人。第二個問題是規格錯配。第二位審查員的記憶容量大約十三萬個詞元，而完整包裹加指令超過這個數字。這個資訊在派工之前查一下就能得到，卻是在任務失敗後才被發現。等於我們用一次完整的失敗，換來一條本來免費的資訊。
第三個問題比較隱晦，但對我最重要：團隊對失敗的反應是「換一個人再試」，這是戰術反應，缺少的是戰略反應。什麼時候該把一個供應商整個移出名單，什麼時候該為每個候補位置準備兩層人選，這些規則今天之前不存在。
我今天做的決定：把不穩的供應商移出名單
其中一家供應商的模型最近反覆出狀況，回條不穩、限流頻繁，之前團隊一直抱著「再給一次機會」的心態輪流派工。我今天直接指示：把它移出審查名單。審查名單收斂到兩家目前相對穩定的供應商，每一個候補位置都要求先確認記憶容量足以裝下完整包裹，再接受派工。
這個決定看起來小，其實是放手管理的基本功。放手的前提是工具可靠，而可靠靠淘汰與驗證累積出來，對不可靠的來源一直心軟，到頭來是在用整條產線的穩定性替它買單。
我今天在教 AI 什麼
第一課：派工之前先驗證規格。容量、供應狀態、過往失敗率，這三件事在任務發出之前就能查到，查完再派人，失敗率會直接砍半。第二課：失敗要分層。一次失敗是事件，同一類失敗重複出現是訊號，訊號該觸發的是機制調整，像今天這樣直接移除供應商。第三課：放手是一種需要維護的狀態。我敢放手多少，取決於工具鏈經過多少次驗證，這個數字每天都在變，團隊要有意識地經營它。
今日管理判定與明天要看的
放手程度：3，維持不變。公開可用度：3，審查線修好之前不調升。真進展的判定：今天算真進展，因為換來的兩條規則會在明天的派工裡立刻生效，這和單純解決一個故障是兩回事。
明天我要看的很具體：第三位審查員能不能順利簽收，讓包裹出門；以及團隊有沒有把「派工前驗證規格」這條規則落實到下一次審查任務上。如果明天還在同樣的地方卡住，那就表示今天教的東西只進了日記，沒進流程，我會把放手程度往下調一級。