摘要
昨天我排查了一次发布异常：系统显示发布成功，但草稿内容并不正确。
这不是单个按钮的问题，而是发布链路太宽松。文章质量没有达标，配图引用不完整，正文还带着不该进入草稿的本地元数据，系统却继续往外推。
这篇文章讲的是为什么自动化发布必须会刹车。
目录
- 发布成功不等于内容正确
- 哪些问题应该阻止发布
- 为什么本地元数据不能进草稿
- 自动化为什么需要刹车
- 长期收益
- FAQ
发布成功不等于内容正确
系统显示“发布成功”，用户会自然认为内容已经正确进入草稿箱或发布流程。
但昨天的问题是，流程确实跑完了，内容却不合格。
这比直接失败更麻烦。失败至少会提醒用户处理，错误的成功会让用户放松警惕。
所以我现在更重视发布前检查，而不是发布后补救。
哪些问题应该阻止发布
我认为几类问题应该直接阻止发布。
文章质量未通过。标题结构异常。正文和标题粘成一团。配图数量不足或引用不完整。正文里残留本地流程字段。
这些问题不是小瑕疵，而是会影响读者看到的最终内容。
系统应该停下来，把状态标成质量未通过，而不是继续送到外部平台。
为什么本地元数据不能进草稿
内容生产系统里会有很多内部字段。
它们对流程有用，比如内容类型、质量等级、生成模式。但这些字段不应该出现在读者或平台草稿里。
如果上传前不剥离，本地工作流的痕迹就会污染最终内容。
这也是发布前清洗的重要性。不是所有 Markdown 里的东西都应该被发布。
自动化为什么需要刹车
很多人理解自动化，是把流程一直跑完。
我现在更愿意把好的自动化理解成：该继续时继续，该停下时停下。
尤其是发布这种外部可见动作，系统要比用户更谨慎。用户可能一时没注意，系统应该帮他拦住明显不完整的内容。
自动化没有刹车，速度越快，风险越大。
长期收益
质量门槛会建立信任。
用户愿意让系统代劳，是因为系统能守住底线。它不会把半成品送出去，也不会把本地字段泄露到草稿里。
以后接入更多平台时，这套门槛还能复用。平台越多，发布前检查越重要。
FAQ
质量不通过时应该怎么办？
停在失败状态，告诉用户具体原因。不要继续发布。
本地元数据能不能保留在源文件里？
可以。源文件需要流程信息，但上传前要剥离不该发布的字段。
为什么不发布后再修？
外部平台一旦出现错误内容，用户信任会受损。发布前拦截更好。