原创

如何做自动发文

自动发文不是“到点把内容发出去”这么简单。

如果没有流程控制，自动发文很容易出事故：草稿被误发、图片没传上去、链接失效、重复发布、定时任务失败没人知道、一个渠道成功另一个渠道失败、内容还没审核就上线。

自动发文的核心，是把内容从 draft 到 published 的过程做成可控流水线。

本文参考了几类官方资料：

自动发文适合什么场景

不是所有内容都应该自动发布。

适合自动发文：

博客定时发布
产品更新日志
每周 newsletter
社媒内容分发
RSS 更新
多语言文章同步发布
文档更新通知
工具站新增页面通知

不适合完全自动：

高风险观点文章
法律、医疗、金融建议
重大产品公告
涉及价格和承诺的页面
未经审核的 AI 内容
需要人工排版的长文

自动化应该先用于低风险、结构化、可回滚的内容。

内容状态机

自动发文第一步，是设计内容状态。

一个基础状态机：

draft
reviewing
approved
scheduled
publishing
published
failed
archived

不要只用一个 published=true。

状态越清楚，系统越容易判断下一步该做什么。

例如：

draft：还在编辑
reviewing：等待审核
approved：审核通过但未安排时间
scheduled：已安排发布时间
publishing：正在发布
published：已发布
failed：发布失败，需要处理
archived：下线或归档

发布前检查

自动发文必须有发布前检查。

检查项可以包括：

标题不为空
正文不为空
封面图存在
slug 唯一
发布时间有效
作者存在
分类存在
内部链接有效
外部链接可访问
图片 alt 文本存在
SEO title 和 description 存在
内容状态是 approved 或 scheduled

如果任何关键项不通过，就不要发布。

自动化的第一原则不是“尽量发出去”，而是“有问题时阻止发布”。

定时任务怎么跑

自动发文通常由定时任务触发。

常见方案：

Vercel Cron Jobs
GitHub Actions schedule
服务器 crontab
Cloudflare Workers Cron Triggers
队列系统延迟任务
后台 worker 轮询

Vercel Cron Jobs 文档说明，Cron 可以按 cron 表达式触发 Vercel Functions。GitHub Actions 的 schedule event 也支持用 POSIX cron 语法按计划运行 workflow。

注意两个问题：

时区
重复执行

很多定时系统用 UTC。你在产品里显示的是北京时间、纽约时间还是用户本地时间，要提前转换清楚。

重复执行也很常见。发布任务必须做幂等。

发布任务要幂等

幂等的意思是：同一个任务执行多次，不会造成重复发布或状态错乱。

自动发文必须防止：

同一篇文章发两次
同一个渠道重复推送
任务超时后重试导致重复
两个 worker 同时抢同一篇文章
发布成功但状态没更新

常见做法：

给每篇文章加 publish_job_id
发布前锁定记录
渠道发布记录单独保存
每个渠道有唯一 external_id
状态更新使用事务
重复执行时先检查是否已发布

幂等比“按时执行”更重要。因为定时任务失败可以补跑，重复发布会更难看。

多渠道要分开记录

一篇内容可能要发到多个地方：

网站
RSS
微信公众号
邮件
X
LinkedIn
Telegram
Discord
知识星球

不要用一个总状态表示所有渠道都成功。

应该有渠道发布记录：

content_id
channel
status
scheduled_at
published_at
external_id
url
error_message
retry_count

这样网站发布成功、邮件失败时，你能单独重试邮件，而不是重新发整篇内容。

图片和附件要先处理

很多自动发文失败，问题不在正文，而在图片。

发布前要确认：

封面图已生成
图片路径有效
图片已经上传到目标渠道
图片格式和尺寸符合要求
图片 alt 文本存在
远程图片 URL 可访问
渠道不支持的格式已转换

如果渠道需要先上传媒体，再把 media_id 放进文章，就要把媒体上传作为独立步骤。

不要在发文最后一刻才处理图片。

失败重试和告警

自动发文一定会失败。

常见原因：

第三方 API 超时
Token 过期
图片上传失败
内容格式不被支持
网络异常
渠道接口限流
定时任务没有触发

失败后要做：

记录错误
标记 failed
按规则重试
超过次数后告警
保留人工重试按钮
不要吞掉异常

Vercel Cron Jobs 的管理文档也提醒，可以通过日志查看 cron 调用情况，并建议使用 CRON_SECRET 保护 cron endpoint。

自动发文要有人工闸门

最稳的方式，是让 AI 或自动化负责生成和排期，但最终发布前有人工确认。

尤其是：

新渠道第一次发布
大规模批量内容
涉及价格和承诺
涉及品牌立场
高风险行业内容

可以设计两种模式：

auto_publish：低风险内容自动发布
manual_approval：高风险内容必须人工确认

不要把所有内容都当成同一风险等级。

一个最小可用方案

独立开发者可以这样做：

1. 内容表增加 status、scheduled_at、published_at
2. 只有 approved 和 scheduled 内容可以发布
3. 定时任务每 5 到 15 分钟扫描待发布内容
4. 发布前做标题、正文、图片、slug、链接检查
5. 每个渠道单独保存发布状态
6. 发布任务加锁并做幂等
7. 失败记录错误并允许重试
8. cron endpoint 使用 secret 保护
9. 发布后更新 RSS、Sitemap 和通知

这套方案已经能支撑大多数个人内容站和早期 SaaS。