自動化不是做越多越好。真正決定你能撐多久的，不是你做了幾個，而是你每週要花多少時間確認它們還活著。
這篇要講的是一件反直覺的事：在某個數量之後，多做一個自動化，會讓你整體變慢，而不是變快。
先看那個會嚇到人的乘法
假設你做的每一個自動化環節都很可靠，十次有九次半是對的。95%，這個數字已經相當漂亮。
但如果你把五個環節串起來，前一個的產出餵給下一個，那整條線一次跑完全對的機率是：
0.95 的五次方 ≈ 77%
每一環都有 95%，整條線卻只剩 77%。等於每四次就有一次，中間某個地方出錯。
再放大一點。如果每個環節是 90%，串十個：
0.9 的十次方 ≈ 35%
90% 聽起來很厲害。串十個之後，你有三分之二的日子是壞的。
這不是悲觀，是算術。而這就是為什麼「再加一個自動化」在某個點之後會變成負的。
解法不是提高每一環，是不要串
多數人看到上面的數字，第一個反應是「那我把每一環做到 99% 就好」。0.99 的十次方還有 90%，聽起來可行。
問題是把一個環節從 90% 做到 99%，成本通常比做出那個環節本身還高，而且你要對十個環節都做一次。
比較務實的做法是：不要串。
五個自動化各做各的、誰都不吃誰的產出，壞掉就只壞一個，風險是加法。串起來才會變成乘法。
具體到做法上，就是寧可在中間保留一個「人按一下」的動作，也不要讓 A 的輸出直接變成 B 的輸入。那一下按鈕看起來很笨，但它把乘法切回加法。
這件事學界也量過
有一篇被引用很多的論文叫做〈Why Do Multi-Agent LLM Systems Fail?〉（arXiv:2503.13657），研究團隊收集了 1,600 多條實際的執行紀錄，涵蓋 7 個主流的多代理框架。
他們整理出 14 種失敗模式，歸成三大類，其中一整類是「代理之間對不上」。
這一類的存在本身就在說明一件事：有些失敗是你加了第二個才出現的，單獨跑的時候根本不會發生。所以多做一個的代價，不只是多一個會壞的東西，還包括它和既有系統之間新長出來的那些接縫。
留下來的三個條件
我自己判斷一個自動化要不要留，用三個條件，全部通過才留：
一、它要能獨立失敗。 它壞掉的時候，不可以把其他東西一起拖下水。
二、它壞掉的時候你要看得見。 注意是「你從外面能驗證」，不是「它自己回報說成功」。讓程式自己宣告自己成功，是最常見的假象——它的紀錄每天寫著完成，實際上什麼都沒發生。
三、它省下來的時間，要大於你每個月照顧它的時間。 這一條砍掉的東西最多。一個每月幫你省 20 分鐘、但你每月要花 1 小時確認它還活著的自動化，是負的。
一個比漏報更嚴重的問題：誤報
這裡要特別講一個很多人沒注意到的陷阱。
假設你做了一個監控，用來確認某條流程有沒有正常跑。後來你把那條流程停掉了，但監控不知道，於是它每天照常通知你「今天沒跑」。
連續幾天之後會發生什麼事？你開始跳過那則通知。 等到哪一天它報的是真的，你也一樣跳過去了。
誤報比漏報更傷。 漏報只是你不知道；誤報是你學會了不要看。所以每一則你會略過的通知，都應該被當成待修的 bug，而不是可以忍受的雜訊。
三十天規則
新做好的自動化，建議讓它連續跑滿三十天不出事，再做第二個。
三十天這個數字不是隨便講的。一個月裡才會遇到連假、月底結帳、網路中斷、API 改版、憑證過期這些狀況，而這些才是真正會打死自動化的東西。只跑一週看起來很穩，往往只是還沒遇到。
我自己踩過的坑
上個月我一次刪掉了十六個自動排程，全部都是我自己建的，每一個當初都有很好的理由。
它們不是一次長出來的，是一個月長兩個、長了一年多。等到我發現「每天開電腦的第一件事變成檢查昨晚誰壞了」，數量早就超過我能照顧的範圍。
更諷刺的是，我曾經為了確認兩條自動發布的流程有沒有正常運作，特地做了一個監控去盯它們。結果那個監控自己壞了——它需要一組憑證才能查資料，而我把它搬到的環境根本沒辦法存放憑證。
於是它每天準時寄信通知我：我今天沒辦法檢查。而在它壞掉的那幾天，我因為「以為有人在看」，自己反而沒去看。
多做一個自動化最大的風險，不是它會壞，是它讓你以為那件事已經有人在管。
結論：問題問錯了
「我該做幾個自動化才夠？」這個問題本身就問錯了。
該問的是：你每週願意花多少時間照顧它們？ 那個時間就是你的上限。
而你真正的產能，不等於你做了幾個自動化，等於那些你已經可以放著不看的有幾個。
如果想先把觀念理清楚，可以看AI 數字員工是什麼；想知道哪些工作適合先交出去，被 AI 取代的十大工作那篇有比較完整的判斷方式。
想拿一份可以直接照著檢查的清單，可以先下載體驗版的指令包。