AI把程式改好，和讀者真的看到新版，是兩回事。 修改可以通過檢查、存進原始碼庫，卻因上線流程受阻而停在半路。這也是為什麼夜間工作報告看起來很漂亮，網站卻還在昨天。
1. 睡一覺起來，顯示「幾乎完成」
睡前交代改版面、放廣告、發布其他語言的文章。隔天早上，報告寫著修改完成、檢查完成、檔案已存。
點開網站，舊按鈕依然站在原地。AI整夜加班，網站卻睡過頭。
工作應該拆成完成修改、保存、正式上線、開啟公開頁面驗證四步。對讀者來說，走到第四步才算送達。
2. 倉庫裝滿了貨，出貨口卻關著
原始碼庫負責保存內容，上線系統負責把內容交給使用者。兩個地方可能各自故障。此外，更新文章資料和更新網站程式，往往又分成不同路線。
因此，新文章照常增加，版型卻沒有變；多語翻譯已經通過審核，數千篇還在排隊；廣告修改寫進程式，公開頁面卻仍看不到。
誰都可以很努力，只要最後一道門關著，成果就會堆在門口。
3. 免費額度其實是兩本不同的帳
以Cloudflare為例，2026年10月的免費Workers Builds每月有3,000分鐘的建置時間；Workers免費執行要求則以每天100,000次為限。[1][2]
第一個額度影響新版程式能否順利製作與發佈，第二個影響已上線服務能處理多少請求。都叫免費額度，但解法不同。
建置時間不足，應減少無意義的重新建置，並準備授權範圍內的其他發佈方法。執行請求太多，就讓一般靜態檔案少經過Worker。廚房開火成功，入口的人潮還是得另外疏導。
4. 重試到最後，把免費時間全部燒光
建置失敗，沒看清原因就重跑；再失敗，再跑。剩餘額度越來越少。真正修好問題時，這個月已經沒有可用時間。
故障報告印了十份，線上更新零份。這不是產品工廠，是故障報告印刷廠。
比較好的做法是先讀錯誤紀錄，能在本機重現就先重現，修好原因再消耗遠端執行額度。只改文章內容，也值得確認是否真的需要重建整個網站。單一任務故障，不該拖住其他能安全獨立發布的內容。
5. 讓AI負責復原，不只負責修改
好的夜間代理應分清楚：哪些已經上線、哪些仍卡住、原因是什麼、其他任務推進到哪裡。在授權範圍內，它可以繼續修理並把工作送達。
多個發佈平台能降低單點故障，但都得遵循同一份最新版本。否則兩條路同時發佈，可能讓舊版反過來蓋掉新版。帳號授權和密鑰仍交由所有者掌握。
最後一定要開啟公開頁面，確認文字、按鈕與畫面真的更新了。
6. 早上的成績單應該怎麼看
與其數昨晚修改多少檔案，不如數真正送達多少更新、救回多少失敗、少重演多少故障。
人負責想點子、睡覺。AI負責修理、排除障礙、上線並檢查。
最好的早安訊息不是「我做了好多事」。
而是：「你看，網站今天真的變新了。」
