排程執行不等於自主編輯
「把原始 Markdown 拿來，修一下，然後發布。」
看起來簡單得不得了。
真正開始自動化後，「修一下」會立刻長出一大串工作。
讀 Markdown、判斷能不能發布、檢查 12 種語言、移除奇怪的小標題、檢查連結、發布、打開正式頁面確認、失敗後查原因、修復、重跑、再確認沒有把別的地方弄壞。
不知不覺，你已經要求輸送帶兼任總編輯。
問題並不是 Cloudflare Workers、排程任務或 GitHub Actions 不夠強。
只是它們擅長的是另一種工作。
固定流程的重複執行很適合自動化。 但每次都要讀不同文章、判斷「這次到底哪裡怪」、修正並驗證，更接近 AI 代理，而不是普通排程器。
1. 看似同一條流程，實際上每篇文章的問題都不同
內容工廠很像大量生產。
輸入是 Markdown。 輸出是已發布文章。
所以很容易以為，同一套流程跑 100 次就夠了。
但文字不是規格完全一致的螺絲。
文章 A 的標題很怪。 文章 B 少了 12 種語言中的一種。 文章 C 有翻譯，但當地人搜尋時根本不會這樣說。 文章 D 把內部 SEO 備註一起發進正文。 文章 E 的聯盟連結技術上有效，但位置非常不自然。 文章 F 已經成功發布，可狀態仍顯示處理中。
它們都在同一個「發布文章」流程裡出錯。
但修法完全不同。
輸入每次不同，失敗的樣子也會不同。
2. 排程系統最擅長「按照已知規則做已知工作」
GitHub Actions 是由事件、手動操作或時間表觸發，執行預先定義工作與步驟的自動化系統。[1]
ChatGPT Scheduled Tasks 也是在指定時間或支援的事件發生時執行任務。[2]
Cloudflare Workers 則很適合請求處理、排程執行與服務編排。
這些系統很會回答：
「什麼時候啟動？」 「跑哪個腳本？」 「這個命令成功了嗎？」 「符合條件後下一步做什麼？」
但下面這些問題不一樣：
「這個標題是不是很像機器翻譯？」 「內容沒錯，但這一段對讀者有用嗎？」 「連結有效，可是為什麼放這裡？」 「今天的錯誤和昨天真的是同一個原因嗎？」
排程器有時鐘。
但不會自動附贈編輯的直覺。
3. 真正困難的是把 PDCA 迴圈完整跑完
困難的不是「改一次」。
而是完整做到：
發現失敗， 判斷原因， 修改， 重新執行， 確認正式結果， 檢查副作用， 如果還不對，再換一個假設。
人會很自然地這樣做。
自動系統卻必須明確設計每一個狀態。
最麻煩的是「半成功」。
頁面已發布，但狀態記錄沒更新。
翻譯工作結束，但一種語言是空白。
儲存庫修改成功，可正式部署失敗。
這時盲目重跑，可能造成重複發布或重複處理。
所以可靠自動化真正追求的不是「永不失敗」，而是：
重跑也不會把最終結果弄壞。
Cloudflare Workflows 官方文件也強調可持久化步驟、重試，以及讓工作在多次執行下仍安全的設計。[3][4]
4. Cloudflare 很會復原，但復原不等於編輯判斷
Cloudflare Workflows 可以保存多步驟工作的狀態，在失敗後重試個別步驟，並從已完成的位置繼續。[3]
Cloudflare Queues 也能把多次失敗的訊息送到 Dead Letter Queue 另行處理。[5]
這非常適合：
暫時性網路錯誤， API 失敗， 逾時， 持續失敗的訊息， 稍後再繼續的工作。
但另一類問題完全不同：
「西班牙文看得懂，但當地人不會這樣搜尋。」
「正文正確，可這個小標題讓文章變難讀。」
把重試次數從 3 次改成 10 次，不會突然長出編輯能力。
只會更穩定地重複錯誤。
重試機制不能取代判斷。
5. GitHub Actions 是很好的工作台，不是自主總編輯
GitHub Actions 很適合規則明確的工作。
測試。 檢查檔案。 建置。 符合條件後部署。 固定時間執行腳本。
這些都是它的強項。[1]
但 Actions 自己不會讀完文章後想：
「其實問題不在標題，在開頭。」
當然可以從 Actions 呼叫 AI。
可是一旦這麼做，真正的難題就變成：
要給 AI 什麼內容？ 可以改什麼？ 怎麼驗證？ 失敗後從哪裡繼續？
把編輯會議議程交給電鑽，再怪電鑽不會主持，多少有點冤枉。
6. 與其追求 100% 自動化，不如分成正常路徑與例外路徑
實際的內容工廠應該有兩條路。
正常路徑：機器直接處理
能清楚判定的事情全部自動化。
- 必要檔案存在
- 12 種語言齊全
- 沒有空欄位
- URL 格式正確
- ID 不重複
- 發布命令成功
- 正式頁面可存取
Worker、腳本、Actions 很適合這些工作。
例外路徑：隔離失敗，但不要停工
一篇文章失敗，不該讓整條產線停止。
記錄原因。 把該文章移到旁邊。 繼續下一篇。
例如：
- 缺少語言版本
- 結構錯誤
- 連結錯誤
- 發布錯誤
- 需要內容判斷
- 原因不明
100 篇中如果有 90 篇可以自動通過，就先讓 90 篇出去。
沒必要讓 90 篇正常文章陪 10 篇怪文章一起罰站。
跳過例外，繼續運轉。
7. 把剩下的例外交給能讀儲存庫的 AI 代理
例外通常需要的不是再按一次重試，而是閱讀、理解、修改與驗證。
這正適合程式開發代理。
OpenAI 的 Codex Cloud 官方說明介紹了在準備好的專案環境裡調查錯誤、修改程式、執行測試，並在支援的裝置上繼續同一個雲端工作。[6]
放進內容工廠，就是維修台：
取出失敗文章， 讀原始 Markdown， 看生成結果， 看失敗記錄， 必要時看相關程式， 修改， 執行檢查， 重新發布， 再確認正式頁面。
AI 不需要浪費推理能力處理每一篇正常文章。
簡單的交給機器，奇怪的才交給 AI。
8. 當同一種例外變常見，再把它升級成自動規則
例外區也不能永遠堆垃圾。
同樣問題一直出現，就代表它已經不是例外，而是模式。
某一語言常漏掉，就加自動缺漏檢查。
某個多餘小標題常混進來，就加自動阻擋。
發布完成後常只漏掉狀態更新，就先查正式頁面，再自動修復狀態。
合理順序是：
先讓工廠跑。 收集真實失敗。 少見問題由 AI 修。 找出重複問題。 最後只把高頻問題寫成固定規則。
一開始就想預測所有可能的失敗，只會得到一座永遠施工、永遠不出貨的工廠。
結論：排程器是輸送帶，AI 代理是維修台
如果要求 Cloudflare、排程任務、GitHub Actions 像自主編輯一樣工作，它們當然會顯得不夠聰明。
但角色拆開後就很清楚。
排程系統負責：
啟動， 機械檢查， 讓正常項目繼續， 隔離失敗項目， 確保整條線不停。
AI 代理負責：
「為什麼只有這篇怪？」 「哪裡要修？」 「修完真的好了嗎？」
最後的架構很簡單：
簡單路徑自動化。 不要讓一個例外堵住整批。 只有例外交給 AI。 重複例外之後再升級成機械規則。
內容工廠真正需要的，不是一條什麼都會想的輸送帶。
而是一條不停的輸送帶，加上一個專門修掉隊箱子的聰明維修台。
參考資料（6筆）
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
