定时执行不等于自主编辑
“把原始 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 次，并不会突然产生编辑能力。
只可能把同一个错误稳定地做 10 次。
重试机制不能替代判断。
5. GitHub Actions 是优秀的工作台，不是自主主编
GitHub Actions 非常适合规则明确的工作。
跑测试。 检查文件。 构建。 满足条件后部署。 定时执行脚本。
这些都是它的强项。[1]
但 Actions 自己不会读完文章后想：
“问题其实不在标题，而在开头。”
当然可以从 Actions 调用 AI。
可一旦这么做，难点就从“怎么写 Actions 配置”变成了：
给 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
