認真使用 AI 程式代理之後，最先令人驚訝的往往不是它有多聰明，而是：
「它到底什麼時候下班？」
白天研究，傍晚實作，晚上測試，半夜丟進一個 bug，隔天早上它還在繼續修。
如果是人類團隊，立刻會牽涉夜班、加班、交接、疲勞、排班與管理。AI 的限制則變成方案、使用額度、工具錯誤和系統可靠性。
重度使用後還會發生更怪的事：
一週的額度，幾天就能燒光。
一開始覺得新額度大得不得了，幾天後卻進入「這週已經讓它做太多了」的狀態。
勞動法像是消失了，只是改名成 rate limit。
0. 真正該看的不是工時，而是吞吐量
「AI 一天跑了 12 小時」很容易讓人拿來和人類 12 小時工作比較。
但真正要看的是：
- 完成多少調查
- 修改多少檔案
- 跑多少測試
- 解掉多少異常
- 多少成果真的到正式環境
- 多少成果卡在中途
AI 可以快速重複搜尋、比較、修改與測試。因此重點不是「跑多久」，而是多少有效工作真的穿過整條流程。
1. 24 小時運轉的怪異之處，不是夜班便宜
人類要 24 小時營運，需要夜班、津貼、排班、交接與缺勤備援。
AI 多半受產品額度與系統條件限制。
奇怪的不是「晚上也能工作」。
而是同一個執行單元可以從白天一路跑到深夜，不需要換班。
它也會失敗，但原因通常是脈絡不足、錯誤假設、工具失敗或規格理解錯誤，而不是疲勞。
2. 額度變大，需求也會跟著膨脹
額度變大後，人就不再節省。
以前自己做的事，也開始交給 AI。
原本只是「先調查一下」，很快就變成：
調查→實作→測試→修正→重測→看 log→再修。
所以即使額度看起來大很多，也可能幾天就耗完。
這不一定是容量不足。
供給增加後，AI 工作需求也被誘發出來。
3. 週期恢復不是停工，而是建立緩衝區
等待額度恢復期間，可以：
- 記錄新異常
- 整理重現條件
- 累積 log
- 整理可能原因
- 排定下一批任務優先順序
額度恢復後一次批次處理。
工作型態從即時對話變成批次工廠。
AI 在休息，但佇列在長大。
4. 高品質模式適合「卡住時的設計會議」
高品質、高消耗的推理模式可能一次吃掉大量額度。
但用對地方就很划算。
真正卡住時，可以讓它：
- 列出根因候選
- 整理依賴關係
- 設計修復順序
- 規劃防止復發
- 決定監控項目
也就是把它用在高不確定性的規劃問題。
平常用一般模式。 卡住時升級。 高品質模式負責診斷與規劃。 接著再回到一般模式執行。
5. AI 越快，瓶頸越會移到別處
典型流程：
生成 → 儲存 → 轉換 → 發布 → 正式環境 → 驗證
任何一段不穩定，前面再快都沒用。
生成 100 個，只上線 99 個，剩下 1 個就是庫存。
若反覆發生，就不是偶發錯誤，而是良率問題。
6. 「文章沒出來」不一定是生成失敗
可能故障於：
- 生成成功、儲存失敗
- metadata 驗證失敗
- 在地化中斷
- 沒進發布佇列
- 部署成功但驗證失敗
- 已上線但列表頁未顯示
因此每階段都需要計數。
生成 120 → 儲存 120 → 入列 118 → 正式環境確認 116
這樣消失的 4 個才看得見。
失敗可以接受，靜默消失不行。
7. 24 小時 AI 工廠需要自動恢復
理想流程：
- 偵測缺漏
- 隔離對應 ID
- 記錄錯誤類型
- 可安全重試則自動重試
- 只有反覆失敗才升級給人或更強模型
不要全部重跑。
只重新處理壞掉的部分。
8. 人的角色會減少，但不會消失
人仍然要決定：
- 什麼最重要
- 可接受多少錯誤
- 哪些事情不該自動化
- 速度與品質誰優先
- 哪些異常值得升級
角色從執行者轉成流程設計者。
9. 真正可怕的不是 AI 做太多
真正麻煩的是額度花很多，成果卻：
- 卡在中途
- 沒上線
- 缺漏不可見
- 同一個 bug 一直重來
- 高品質模式被拿去做雜務
更好的原則是：
日常工作便宜快速處理；真正卡住才用高品質模式；失敗必須可見；能自動重試的就自動恢復。
這時，你已經不是單純在用 AI。
你是在設計一座 AI 可以持續工作的工廠。
