先区分正文和发布

一个工程站点最容易犯的错误，是把“编辑器里当前的文本”直接当成“读者看到的正文”。这两个状态应该分开：草稿可以反复修改，公开版本必须冻结，发布动作才负责切换读者看到的版本。

因此文章表只保存稳定身份和发布指针，正文放在不可变的 article_revisions 中。每次发布都产生版本号和内容哈希，读者、RSS 和只读 API 读取同一个 published_revision_id。

渠道状态不能反过来影响网站

网站发布成功后，RSS、Atom、小程序和公众号是不同的下游渠道。公众号投递失败，不应该回滚网站已经公开的正文；外部渠道未知时，要保留 needs_reconcile 一类状态，而不是用一个“失败”覆盖所有情况。

这也是 Outbox 存在的原因：事务里记录“应该发生什么”，消费者再处理缓存清理和渠道投递。这样一次发布至少能回答三个问题：发布了哪个版本、下游处理到哪一步、失败后是否可以安全重试。

内容也要有验证边界

文章应明确首次发布时间、当前修订更新时间和最后验证时间。对仍在计划中的功能，不把设计稿写成已经上线；对只在本地验证过的实验，写清楚环境边界；对已过时的结论，保留历史版本但改变验证状态。

个人站不需要一开始就做成大型 CMS，但需要从第一篇文章开始保留这些边界。可验证的内容，才有机会成为下一次项目的输入。