自动发文出错了怎么回滚：按发布阶段拆分的恢复清单

自动发文失败后的回滚顺序是"先停、再读、后动"：先停止后续任务，再读日志与后台回读确认现场，最后按失败发生的发布阶段执行对应恢复动作。盲目重发是扩大错误的最快方式。本文按阶段给出一张回滚动作表。

自动发布工作流属于 Vibe Marketing 的"自动化与测量"能力。它的典型故障不是"发布失败"这一种，而是卡在不同阶段的半成品状态：草稿写进去了、正文不完整、分类错了、定时任务重复触发。每个阶段留下的现场不同，恢复动作也不同。

回滚的第一原则：先停、再读、后动

发现异常先做三件事：停掉正在跑的批量任务和定时任务，防止同一错误继续写入；读发布日志和后台文章列表，确认已经写进去什么、状态是什么；再决定下一步。顺序颠倒的代价很高——比如在没确认已发布内容的情况下重新跑批，可能生成两批重复文章。

按发布阶段诊断：失败发生在哪一步

把自动发文链路拆成四个阶段，先定位异常落在哪一段：

1. 草稿写入：内容已入库但状态是草稿，或部分字段缺失。
2. 公开切换：状态已改为公开，但 SEO 字段或分类不对。
3. 字段与链接：文章公开后，标题、slug、SEO 描述与预期不符。
4. 批量与定时：定时任务重复触发、批量任务中途中断，留下半批文章。

定位方法优先用只读操作：后台列表加详情接口回读，比直接改库安全。回读时对照三样东西——状态、分类、SEO 字段，三样都能对上，才认为写入成功。

回滚动作表：对应每个阶段做什么

涉及删除时守两条线：只删自己刚写入且确认多余的内容；能改状态下线的，先下线而不是直接删除。删除不可逆，下线可恢复。

什么算恢复完成

三个信号同时出现才算结束：后台详情与预期一致；前台页面可见且状态正确；触发任务已停且不会再次执行。只做到"看起来正常"还不够——定时任务还在，问题就会在下个周期复发。

预防：把回滚成本压到最低

四条默认降低回滚难度：公开前先过草稿加人工确认；批量任务加间隔和单批上限；每次运行前记录"这一批要发什么"，出问题可对照；发布脚本保留幂等逻辑，重复运行不产生重复文章。回滚设计得越早，故障时的选择越多。

FAQ

自动发文失败了，直接重跑一遍可以吗？

先不要。先确认哪些已写入、哪些没写入，再决定重跑。不带幂等逻辑的重跑，容易把半批变两批。

文章已公开才发现内容有错，怎么处理？

先改正文再更新，保持同一篇不重复发布；如果错误严重，先下线再修改，改好核对后再恢复公开。

回滚能力是自动发布的标配，不是补救措施。把"先停、再读、后动"和阶段动作表写进发布 SOP，下次出错时按表执行，比临场判断快，也比临场判断安全。