自动化发布器里最贵的 Bug：返回成功，但什么都没发生

做多平台分发这两年，我踩过最贵的坑不是接口 500，也不是选择器失效。

是它告诉我发成功了，我信了，三天后才发现后台什么都没有。

这篇把三次真实事故拆开，给出一套「先验证、再提交」的发布器写法。代码用 TypeScript，思路和语言无关。

事故一：按钮文案变了，请求根本没发

某平台的发布按钮，用 element.click() 触发后，文案会立刻变成「发布中...」，几十秒后又自己变回来。没有 toast，没有报错，控制台干净。

当时脚本的判断逻辑是「按钮文案变化 = 提交成功」，于是继续往下走去列表页找新文章------当然找不到。

后来在 Network 里看，整个过程没有一条提交请求，只有埋点。

修复很土：换成 CDP 的可信点击（Input.dispatchMouseEvent，或 Playwright 的 locator.click()），一次就过了。

结论：按钮反馈只是乐观更新，不能当提交成功的判据。真正能信的只有两样，真实请求和后台数据。

事故二：标题被导入文件名覆盖了

第二个更隐蔽。Markdown 导入后，标题自动填成文件名 xxx_20261017。我用原生 value setter 改了标题，紧接着在同一次调用里点了发布。

结果：成功页显示「发布成功」，列表里也确实有这条，但从另一个入口（流量券的可推广文章列表）看过去，标题还是文件名。

原因是平台在打开发布弹窗时会把标题写进内部 model，最后一次赋值离弹窗太近，model 还没 flush。

修复两步：改完字段等 3~4 秒；开弹窗单独一次调用。发布后必须去列表复核字段，不信成功页。

事故三：创作后台和主站是两个账号

这个跟代码质量无关，纯粹是环境。

某平台的创作服务平台和主站登录态是分开的。后台登着 A 账号，主站登着 B 账号。发布一切正常，但去主站点赞同评论一律被拦，提示还挺误导人。

后来固定加了一条前置校验：发布前读一次页面上的账号名，和目标账号比对，不一致直接终止，不去猜。

多账号环境下，这条比任何重试都有用。

设计：verify-first 发布器

三次事故指向同一个设计缺陷：把「动作完成」当成了「结果发生」。

改成 verify-first 之后，每个写操作都必须配一个只读探针：

ts 复制代码

type Probe = () => Promise<{ found: boolean; detail?: unknown }>;

async function publishWithProbe(action: () => Promise<void>, probe: Probe, tries = 3) {
  await action();

  for (let i = 0; i < tries; i++) {
    const state = await probe();
    if (state.found) return { ok: true, state };
    await sleep(1500);
  }

  return { ok: false, stage: "verify" };
}

两条约束建议直接写进注释，不然下次改代码的人一定会破坏它：

probe 只能只读。写操作套写操作，出问题时根本分不清哪一步坏的。
校验失败只重试读，不重试写。重复提交的代价远大于少发一篇。

配合的三个探针：

后台列表探针：按发布时间倒序，看标题 + 状态 + 时间三个字段
请求探针：page.waitForResponse 抓目标域名的 POST，超时即失败
换视角探针：用未登录态打开详情页，或从另一个列表入口查

三个都命中才算成功。只命中一个，按失败处理。

提交前的 8 条硬检查

这套东西真正的价值不在发布，在于让脚本学会「不做」。

账号名正确（多账号必查）
页面无验证码、无实名弹窗
正文无联系方式、外链、二维码
无承诺词与极限词
AI 辅助内容已勾选平台声明
本账号 2 小时内无发布
今天没用过同一模板骨架
目标内容状态允许提交（审核未通过的不重复提交）

任何一条不过，直接终止并记录，不进入发布流程。

最后

自动化省下来的时间，很容易被「错误的成功」吃掉，而且吃得悄无声息。

宁可多发一次查询，也别少一次回读。后台列表不会说谎。