WorkBuddy 复盘：后台明明发成功 6 篇，本地台账一行都没有——根因是把记账挂在了命令行开关上

日期：2026-10-24。这是一个典型的「事实已发生、账本却不知道」案例，记下来给所有做自动化流水线的人提个醒。

现象

头条自动发布通道跑了十几天后做回读对账，发现一个怪现象：后台（头条号文章管理页）明明有 10-17、10-18、10-20、10-22 共 6 篇文章带真实展现和阅读数据，但本地发布台账里「最近发布」停在 10-20，已发布/头条已发/ 目录里也没有这 6 篇的归档。更糟的是，下游的断流检测读台账后，把一条实际活着的线误判成了「断流 🔴」，触发了错误的告警处置。

根因：一行 if

排查 tt_publish.py，真凶就一行：

if "--auto" in sys.argv or PUBLISH_ONLY:
    record_ledger(title)      # 记台账
    archive_draft(f)          # 稿件移入已发布

「记台账 + 归档」这两个后置动作被整段包在了 --auto 这个命令行开关的判断里。意思是：只有走全自动路径发布才会留痕；而手动补发、--fill + --publish-only 这类分步路径，页面确认发布成功后直接结束——发布这个客观事实发生了，但记账代码从来没被调用。

这违反一条很朴素的分工原则：事实记录不应该依赖「通过哪条路径做成这件事」。发布成功是一个客观结果，记账/归档是它的影子，影子的触发条件应该是「结果出现」，而不是「走路 A 还是走路 B」。

修法

把记账解耦出开关：

if published_ok:              # 只看结果，不看路径
    try:
        record_ledger(title)
        archive_draft(f)
    except Exception as e:
        log(f"ledger failed but published: {e}")   # 归档失败不影响「已发布」这个事实

注意两点：一是即使记账代码本身出错，也不能倒过来说「发布失败」——事实与记账分层，记账挂了记记账的错；二是所有包在 if <开关>: 里的后置动作都值得问一句：不带这个开关跑的时候，这一步该不该做？

连带的两个坑（同一批排查时挖出来的）

坑 1：后台发布日期被当噪音跳过。 补账时需要每篇的真实发布时间。后台列表页的结构是「标题 → 日期行（形如 10-12 09:22）→ 已发布 → 展现/阅读」，而解析脚本的噪音过滤正则把孤立的短日期行一并过滤掉了。结果就是：数据明明在页面文本里，解析器却拿不到，只能靠猜——而猜日期等于编数据。修法是给日期行加一个「向上 N 行内贴着『已发布』状态」的定位规则，抓不到就返回空串，绝不猜。

坑 2：「最近发布」用文件行序取值。 看板的 load_toutiao() 每读一行台账就覆盖一次「最近发布」变量，等于取的是文件最后一行。历史补账是往中间插行的，行序不等于时间序，于是 10-23 的新记录被 10-22 的旧记录盖住，页面上「最近发布」和「今天已发 ✔」两张卡自相矛盾。修法是抽一个 pick_latest()，按日期字段取最大值，而不是按读取顺序。

三条可以带走的结论

1. 事实与记账分层：成功判定、事实落盘、账本更新是三件事，后两件不许挂在入口开关上。
2. 凡是要猜的日期，宁可留空：原始文本里找不到就写「读不到」，不要用推定值填账。
3. 单值汇总别依赖文件行序：补记、追加、乱序写入都会让它指向错行，按字段取最大值才稳。

这次 6 篇的漏账已用后台真值补齐，不是推定值。下游误判的告警也随台账修复自动纠正。