内容运营自动化 把四源验证接进发布闸门

日更流水线的前半段早就自动化了：选题轮转、写稿、调 CLI 发布、按台账记账。但真正让我把「发出去」和「真上架」分清的，是把第四源平台侧核验也接进发布闸门这一刀。三源全绿只是提交成功，闸门后面还站着平台审核那一道，漏掉它就会把假上架当成真产出。

为什么三源绿还不够

发布一篇掘金文章，我们习惯看三个本地证据：CLI 输出文件里出现「文章发布成功」且退出码为 0；应用主日志里也有一行「文章发布成功」（注意日志是 UTC，要加 8 小时换算北京日期）；pushData 回执里 publishStatus 是 success，并且带上了真实的文章 id 和 lastPublishAt。三者对齐，我们称之为「三源绿」。

def three_source_ok(mmcli_out, master_log, push_data):
    a = "文章发布成功" in mmcli_out and exit_code == 0
    b = "文章发布成功" in master_log          # 需把 UTC 行换算成北京日期
    c = push_data.get("publishStatus") == "success" and push_data.get("id")
    return a and b and c   # 只证明「提交成功」

但 2026-09-05 有过一次实锤：一篇标题带「变现」的文章三源全绿，pushData 也拿到了真实 id，结果创作者中心列表里那条带着 [未通过] 标记，压根没公开展示。也就是说，三源只能证明「我成功把内容提交给了平台」，证明不了「平台真的把它放出来给人看」。提交成功和真上架之间，还隔着平台的内容审核。

发布闸门要拦在哪一道

答案不是再加一个本地证据，而是把验证推到平台侧去问。这就引出第四源：直接打开掘金创作者中心的内容管理页，用标题关键词去搜，看那条到底落在哪个状态。判定分几档——列表命中且前方无状态标记，才是真上架；带 [未通过] 是内容被拒；带 [审核中] 多半是当天提交量过大被平台暂扣；列表正常但搜不到是存疑；页面没加载出来被挡，则只是核验没拿到判据，不等于没发布。

提交成功 ──三源对齐──▶ 闸门第一关：已提交
                        │
                        ▼
              第四源平台侧核验 ──FOUND────▶ 真上架（对外可见）
                        │
              AUDIT_FAIL/AUDIT_REVIEW ──▶ 闸门拦截：不计入真实产出

四源核验怎么接进流水线

把第四源接进流水线的关键，是让它在「三源绿」之后自动跑，而不是靠人肉记着去点。每次发布完成，先以「提交成功」把台账记一笔，状态落 success；紧接着后台唤起核验脚本，把 verdict 回写进台账的 verify 字段。这样任何一条发布记录都自带「最终判据」，复盘时不会再出现「退出码 0 就当发了」的误会。

# 闸门落地的真实顺序（伪代码）
publish_article(md)                 # 调 CLI，写 MMCLI_OUT
record_ledger(status="success")     # 先记提交成功，不猜可见性
verdict = verify_juejin_live(title[:12])   # 第四源平台侧核验
update_ledger_verify(verdict)       # 回填：FOUND / AUDIT_FAIL / ...
if verdict == "AUDIT_REVIEW":
    stop_today()                    # 当天量过大，立即停手，次日再发

闸门落地的三个实现细节

第一，verdict 必须异步回填，不能阻塞发布。核验要起 headless Chrome 解密分区 cookie，本机沙箱有时需要放行，跑完约 30 秒。把它放在发布之后的独立步骤，既不影响当天配额统计，也不会因为核验慢而拖垮写稿节奏。

第二，遇到 [审核中] 要立刻停手。这是平台因当天提交量过大而暂扣，与内容无关，但继续发只会堆更多暂扣、甚至牵连账号权重。正确做法是当天停止，回到 1 篇/日的节奏，次日再发。

第三，核验被挡（BLOCKED）不要降级、也不要狂重试。页面没加载出来不等于没发布，盲目重试既浪费时间又可能重复发布。记一笔 unverified，留给人工或下次复核即可。

台账怎么记才不骗自己

台账里 status 只写 success 表示提交成功，是否真的对外可见，看 verify.verdict。两者分开记，是避免自我欺骗的核心：一旦历史上把「提交成功」误记成「已上架」，不要去改原条目，而是追加一条 #audit-fail 修正，原记录保留。非破坏性修正让账本永远可追溯，也方便日后统计真实的对外可见率。

自动化运行的现实约束

接进闸门之后，自动化每天发 1 篇就够了，多发反而容易踩到平台量闸。每次运行先探活——根路径要返回 <h1>MatrixMedia API</h1> 才算服务真的起；再用量闸确认当天掘金 success 还没到 1，才放行写稿发布。还有一个容易被忽略的坑：同一个自动化可能跑出并发实例，两个实例共用同一个输出文件，删除时若报「文件被另一进程占用」，说明有并发发布正在进行，应当场中止本实例，而不是清文件重试，否则会撞发同选题。