摘要
昨天我思考了“自动推草稿箱”该怎么做。最直觉的方案是高频定时器，每隔一段时间扫一次。
但对内容发布来说，我不想让系统像轰炸一样不停重试。更合理的设计是每日巡检：固定时间检查当天内容，推送该推的，补掉漏的。
这篇文章讲的是为什么自动化发布不一定要高频，关键是节奏和幂等。
目录
- 为什么不需要高频定时器
- 每日巡检更适合内容发布
- 为什么要优先更新旧草稿
- 批量推送要按账号和类型处理
- 长期收益
- FAQ
为什么不需要高频定时器
内容发布不是消息队列，不需要每几分钟就扫一次。
如果系统太频繁地检查和推送，反而会增加风险。后台可能出现重复草稿，失败任务会被反复触发，用户也会不知道系统什么时候动过。
发布系统应该有节奏感。它不是越勤快越好，而是要在合适的时间做合适的事。
每日巡检更适合内容发布
我更喜欢每日巡检。
比如早上跑一次，把当天计划内容推到草稿箱。傍晚再补一次，处理上午失败或临时新增的内容。
这样频率不高，但覆盖了主要工作场景。用户知道系统什么时候会帮他处理，也更容易检查结果。
这个设计比“每十分钟跑一次”更安静，也更符合内容工作的节奏。
为什么要优先更新旧草稿
自动推送最怕制造重复草稿。
同一篇文章修改了几次，如果每次都新增，后台会堆出一堆相似内容。
所以我更倾向于优先更新旧草稿。本地有凭证，就更新对应草稿。没有凭证，再按标题和账号谨慎匹配。最后才新增。
这就是幂等思路：同一个任务重复执行，结果也应该尽量稳定。
批量推送要按账号和类型处理
当天内容可能属于不同账号，也可能是图文、小绿书等不同类型。
批量推送不能粗暴地用同一个账号、同一种发布方式处理所有文章。
每篇文章应该带自己的账号和类型。系统按文章自身信息推送，才不会把内容送错地方。
长期收益
长期来看，每日巡检会让发布系统更可控。
用户不用每天手动检查所有文章，也不用担心系统不停乱跑。失败可以集中处理，成功可以稳定追踪。
这比单纯加一个“自动发布”按钮更重要。真正的自动化不是频率高，而是稳定、可解释、可恢复。
FAQ
为什么不每十分钟跑一次？
内容发布通常不需要这么高频。高频会增加重复和误触发风险。
每日跑几次合适？
一般一到两次就够。早上处理当天内容，傍晚补漏。
已有草稿怎么处理？
优先更新旧草稿，而不是盲目新增。这样后台更干净。