官网自动发布怎样避免把“定时执行”变成“自动误发”？

四个角色不能由同一份文件代替

最危险的设计，是让文章包里同时写着“内容已审核”和“允许发布”。只要生成器能够改这份文件，它就等于给自己签字。我们的处理方式是让审核工件和负责人授权来自发布包之外，并分别绑定发布指纹。文章正文、图片、路由或发布时间任一变化，旧审核和旧授权都不能继续使用。

为什么必须先检查执行合同，再领取授权

原子领取是一种生产写入。一旦领取成功，系统应当留下执行编号、领取状态和失败后重新授权要求。因此，发布器必须先确认所有动作接口齐全、路径处于允许范围、签名密钥符合权限要求，再进行领取。否则一次普通配置错误也会消耗授权，让负责人无法区分“内容已开始发布”和“执行器还没准备好”。

领取之后的每个阶段都要落状态，例如预检、候选构建、候选验证、回滚点验证、生产切换和公网回读。状态的价值不是展示进度条，而是确定失败发生在哪一层，并防止另一个执行者同时处理同一发布包。

失败后为什么不能自动沿用旧授权

假设部署过程中发现运行构建与候选构建不一致。即使回滚成功，环境、时间和稿件状态都已经发生变化。沿用旧授权继续重试，会把一次明确批准扩展成未知次数的生产操作。我们选择将失败写成终态：保留原因和回滚证据，重新检查候选哈希与生产状态，再由负责人对新执行作出授权。

这不是降低自动化程度。真正的无人值守是正常路径不需要人工搬运，异常路径能够准确停止。验证码、外部平台安全挑战、关键事实冲突或回滚不一致，本来就不应该被脚本猜测处理。

上线前可以现场核对的最小清单

• 候选正文、图片、路由和版本日期是否共同形成唯一指纹。
• 独立审核是否来自发布包之外，并精确绑定该指纹。
• 负责人授权是否限定发布包、执行时窗和目标环境。
• 执行领取是否原子、幂等，并在首次生产写入时留下记录；外部签名密钥还要按部署环境核对所有者与访问权限。
• 任何失败是否停止后续动作，且再次执行必须取得新授权。
• 完成事件是否最后写入，并绑定公网原始回读工件。

2026年9月1日的首个生产样本最终完成PM2、健康回读、不可变公网回读、数据库三项内容资产和管理API闭环。事件载荷记录的completedAt复用了执行起始时间，不能解释为完成事件文件的实际提交时刻。这是一个样本，不能外推为长期可靠性，也不代表文章已经被搜索收录、模型引用或推荐。