一个人写博客，可以同时有两条发稿路径：每天按计划写原创，偶尔又因为某个问题值得立刻说清楚，临时点名发布。如果定时任务只问“今天站上已经发了几篇”，临时文章就可能占掉每日创作名额。反过来，只按新任务的标记计数，又可能漏掉尚未标记的旧文章。
我在整理自己博客的发布流程时，选择把“文章什么时候发”与“这篇文章属于哪个生产承诺”分开。前者是站点日期，后者是编辑频道。这不是我已经经历过一次同日撞车的事故复盘；截至本文写作时，我核验了现行读取与标记路径，尚未通过人工稿和定时稿同日混合发布的真实样本证明整个流程。下面写的是这次具体设计和核验中最容易漏掉的边界。
先把两个问题拆开
“今天已发布几篇”适合回答站点动态，“定时任务今天还欠几篇”却必须知道稿件归属。同一天的人工点名稿应该参与全站查重、站内关联和公开展示，但不应冲抵定时任务承诺的原创数。于是我为发布路径保留了稳定的频道元数据：草稿创建时确定归属，发布前读回，而不是发布成功后再补一个标签。
为什么不直接看分类？分类回答“文章主要谈什么”，不是“由谁、按哪条流程生产”。一个 WordPress 故障复盘既可能是当天自动选题，也可能是作者临时点名；用分类区分，会把内容架构和工作流绑死。标签同理，它属于读者检索语义，不是可信的编辑计数器。
计数口径与查重口径不能共用一个过滤器
我把查询拆成两个集合。计数集合只看站点自然日内已发布的文章，并排除明确标记为人工稿的记录；查重集合则看全部已发布文章，外加仍可能发生标题或主题冲突的草稿，不论来源。这里还有一个迁移细节：旧的定时稿未必带新频道标记。如果计数时只纳入“频道等于每日”的文章，升级当天可能把旧稿丢掉。更稳妥的过渡是默认保留未标记的已发布稿，仅排除明确的人工标记；待历史归属核清，再收紧统计条件。
WordPress 的 元数据查询文档列出 NOT EXISTS、!= 与 OR 等条件；但这只是表达过滤条件的工具，真正决定口径的是编辑合同：缺少标记的老稿如何处理、人工稿是否只从配额中排除。站点自然日则应取站点时区，不直接用服务器的 UTC 日期；WordPress 的 wp_date() 文档说明默认使用站点设置的时区。跨午夜的发布流程尤其要在读回时核对文章实际日期。
“提交成功”也不等于归属已经写入
一次草稿创建成功，只能说明文章对象存在，不能证明私有频道字段也成功保存。尤其走 REST API 时，元数据的注册及可见性有独立规则；register_post_meta()和 register_meta()文档分别说明注册入口及 show_in_rest 等参数。我的停止线是：在草稿状态核对正文、作者、分类、媒体、SEO 和归属字段；缺任何一项就先修草稿，不让它先公开，再赌下一轮统计会正确。
核验还要回到精确对象：今天站点日期、每种频道的已发布篇数、草稿标记与当前目标稿的 ID。一个成功响应或“媒体上传 100%”都不能替代对象读回。若发布请求超时，先查目标稿是否已经公开，不能直接重发，否则计数问题很快变成重复文章问题。
我会怎样验证这条规则
- 固定站点时区，准备一篇明确标记的人工稿和一篇每日稿，分别核对发布前草稿元数据与发布后状态。
- 在同一自然日读取数量：人工稿不占每日配额，每日稿占用；但两篇都进入标题、摘要与正文的重复检查。
- 加入一篇未标记的旧稿，确认过渡期不会因为只认新频道而漏算；再检查午夜边界。
- 最后读回公开页面与任务下一轮的实际判断，而不是只看本轮查询代码返回一个看似合理的数。
目前我完成的是当前站点身份、频道计数入口和全站文章列表的核验，今天没有人工与每日稿混合发布的现实样本，因此不把上面的混合场景称作已验收。对有人工编辑和自动发稿并行的小站，我认为最值得先做的不是复杂排程，而是把配额的归属与内容的查重范围分开：一个允许明确排除人工稿，另一个永远不能因为“不是我这个任务写的”就不看。
说明：本文来自作者对个人博客发布流程的一手整理，AI 辅助编辑。实现细节已抽象化；提到的 WordPress 机制以文中官方开发文档为依据，不代表所有站点已有相同的元数据结构。
