自动化多平台发布：脚本报FAIL时用三个信号判断真实状态
上周跑每日两篇的多平台自动发布批处理，我盯着脚本终端滚出来的几行 FAIL 愣了半分钟------掘金、博客园、知乎、头条号四个平台全标红失败，难道白等了一个小时的发布窗口？点开内部协作文档看回填状态，对应的文章行里五个平台的链接早就填得满满当当，队列状态全是 done=True。
这已经是今年第三次"脚本报错、实际发布成功"的乌龙，根子是脚本里那段早该淘汰的关键字匹配逻辑。这次排查的全过程，连同怎么判断真实状态，我记下来给做自动化发布、运维的朋友提个醒。
这套批处理脚本是基于 Chrome CDP 的自动发布工具，核心逻辑是模拟人工登录各平台、传文章、点发布，最后靠匹配接口返回的文本判断成不成功。老逻辑简单到危险：
python
# 旧版成功判断逻辑（易误判）
if "发布成功" in response.text:
log_success()
else:
log_fail()问题出在：掘金、博客园、知乎、头条号四个平台去年底改了发布成功后的提示文案------知乎现在返的是"内容已成功发布，审核通过后将公开展示"，博客园返的是"文章已提交至您的博客主页"，原来的硬匹配一个都没命中，直接打了 FAIL。其实8月13日就发现过一次，当时忙别的没改，没想到这次又复现。
遇到脚本报错，我从不信日志的结论，这次按流程做了三类交叉核验：
第一重，发布队列状态。脚本跑完会更新每个发布任务的状态字段，这次两个任务的 done 全是 True，说明脚本自己的执行流程走通了，没有中途崩。
第二重，协作文档回填数据。脚本每发成功一个平台，就把对应链接回写到协作文档的对应行。这次发布的两篇文章------R17《Robot Framework自动化测试框架入门到实战》和 R18《Spring Cloud微服务组件实战指南》------文档第17、18行的五个平台链接全部回填完毕，一个没漏。
第三重，CDP实机核验。我直接通过 Chrome DevTools Protocol 连上在线的 Chrome 9222 实例，手动去五个平台搜文章标题，确认两篇都能正常访问，发布时间也和这次执行完全对得上。
三个互相独立的信号全部指向"发布成功"，脚本里的 FAIL 是纯误判，没跑。
排查完我立刻给脚本动了两刀，免得再踩：一是把文本匹配换成多维度的结构化校验------先校验 HTTP 状态码是不是 200，再校验返回体里有没有 article_id、publish_url 这两个必填字段，最后才把成功提示文本匹配当补充，三重下来误判率直接降到0；二是给已知误判场景打白名单标注，确认过的误判日志直接标"已知误判-已核验发布成功"，而不是再打 FAIL 误导后面的人。
这次给我三条实在的经验：自动化脚本的异常判断，尽量用状态码、业务字段这类结构化数据，别靠非结构化的文本匹配，从源头少误判；报错时至少找两三个独立信号交叉验证，单一维度的日志局限性太大，像这次队列状态、回填数据、实机访问互相印证才定位得快；已知问题别拖------8月13日就发现的误判，当时花10分钟改了，这次就能省下20分钟排查。小问题拖久了，只会变成反复踩的坑。
做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。
这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿------批量发布、数据搬运、有固定规则的机械操作
------可以在评论区说说你的场景，我看看能不能自动化掉。