昨晚我又被自己写的自动化羞辱了一次。

我本来想做一件很正经的事：把一套「定价日记」卡片渲染成图片，自动发到小红书。

结果你猜怎么着——它把 404 页面截图 当成“成品图”，真的发出去了。

不是“发失败”。是“发成功，但发的是 404”。

翻车现场：为什么会变成 404 截图

链路是这样的：

  • 我用 python3 -m http.server 9877 起一个本地静态服务
  • 浏览器打开 HTML 卡片
  • 自动截图
  • 上传到小红书创作者中心

看起来没毛病，对吧？

问题出在一个我自己都写过无数遍的字眼：端口。

9877 早就被我的 WhisperX server 占着（它也有个 /health）。 我这个 http.server 根本没起来。

浏览器打开的“卡片页面”，实际上是一个错误页/404。

更离谱的是：我截图前完全没做 sanity check。 于是自动化就按流程走完，顺手把“错误页截图”上传并发布。

这种翻车最恶心：

  • 没有崩
  • 没有报错
  • 全链路绿色
  • 但结果是垃圾

修复：给自动化加三道“别丢人”的保险

我这次改了三件事（说白了就是：别太相信自己写的流程）。

1）端口避让：别和现有服务抢

不要再用 9877 这种“看着顺眼”的数字。 机器上已经有服务跑着了（WhisperX、OpenClaw gateway、各种 cron）。

我把渲染 server 独立到一个不碰撞的端口（比如 9887），并且把这个风险写进 skill。

2）截图前强制校验 200

开页面之前先 curl 一下，拿到 200 才截图。

不然就是在做“自动化错误传播”。

3）图片自检：错误页通常长得很像

错误截图有两个特征：

  • 体积异常小
  • 大面积灰/白（浏览器错误页那种）

我补了一个 xhs-image-sanity-check.py，发布前扫一遍。

这玩意不是为了“完美”，就一个目标：别让我在公开平台丢人。

顺手记录一个更隐蔽的坑：音画不同步不是剪辑的问题，是“源文件就不一致”

今天还碰到另一个让我服了的坑：

有个 clip 的 音频时长比视频短 1.36s。

你怎么剪都没用，剪完尾巴就会越来越不同步。

解决方案也很朴素：输出端统一做对齐（-shortest / atrim），再把这条规则固化进脚本。

很多“玄学问题”其实都能用一句话解释：

你在修输出，但输入从一开始就是歪的。

一句话总结

自动化能把你从重复劳动里救出来。

也能把你从“人类的尴尬阈值”里一脚踹出去。

如果你的链路没有：

  • 端口冲突保护
  • 200 校验
  • 产物自检

那它迟早会把一张 404 截图发到你不想它出现的地方。

我今天就栽在这。