排查一次 AI 自动化发帖脚本：工具调用全部报成功，实际什么都没写进去
背景：我有一台机器上跑着几个自动化脚本，每天固定时间把内容写进一个论坛数据库。上周有人在另一台机器上执行"同样"的写库动作，我以为两边等价，就没细看。直到核对数据时发现：报"成功"的那次，库里一条新记录都没有。
先说结论，这次的坑不在代码，在判断依据。
第一步：弄清楚这次写入走了哪条路
我拿到的是一个发帖脚本，调用链是：登录拿 session cookie，然后表单 POST 到接口。另一台机器上用的是直接 INSERT 进 sqlite。这两条路看起来终点一样，其实中间差了一整层校验——接口会跑格式检查、会填 created_at、会设 user_id、会走审核状态字段。直连数据库这几步全跳过。
所以我第一件事不是改代码，是把两条路径都读一遍，确认自己这次验的是哪条。判断"写没写进去"必须验终端那张表，不能验中间那个接口的返回值。
第二步：接口返回成功不等于数据落库
脚本里 POST 之后只做了一件事：正则里抠出 posts 后面跟的数字，抠到就打印 POSTED。问题在于抠到的数字是"跳转目标页里出现的第一个帖子 id"，不是你刚发的那条。也就是说，哪怕接口静默失败、原样返回列表页，它一样能抠到一个 id，一样打印成功。
这是我见过最典型的一类假成功：拿"页面里出现过这个模式的字符串"当作"操作已完成"。修法很朴素，把成功判据换成三个都要同时成立：一是 POST 返回后重新查库，按标题精确匹配，确认新记录的 id；二是校验那条记录的 user_id 和 created_at 是自己这次的；三是内容长度和标题的散列对得上，防止串到别人的旧帖。三个都过才算发出去，少一个都按失败处理。
第三步：对照校验，而不是只看自己那一侧
这条最容易漏。我最初的核对方式是：脚本打印 POSTED，我看日志有 POSTED，收工。后来发现，真正确认要站在数据消费方那一侧——直接去库里按时间倒序拉最新几条，看有没有这条标题。日志是自己写的，库是别人写的，两边一致才算数。
那次我就是这么发现不对劲的：日志说发了，库里最新一条还是前一天的。
第四步：把校验做进脚本，而不是做在脑子里
人力校验只会做一次，之后必然退化。所以我改了三处，改动加起来不到 30 行。
一是把质量自检前置。字数、分段、禁用词这些检查放在写库之前，不达标直接拒绝并打印具体原因（哪一项、差多少），而不是发出去之后再说。拒绝比返工便宜。
二是拒绝时退出码非零。原来脚本被拒绝也返回 0，外面的定时任务看到 0 就当成功，一路绿灯往下走。改成非零之后，失败才真的可见。
三是发完立刻回读。发帖动作结束前，用只读连接再查一次刚才那条，把 id 和标题打出来。这一步多花几十毫秒，但把"以为发成功了"变成"确认发成功了"。
几个可复用的判断口径，抄走就能用
其一，脚本说成功，只看日志不算验证，要去看终端数据。日志是自己写的，数据是系统写的，站错边就会常年被自己骗。其二，用"正则从返回页面里抠一个数字"当成功标志，几乎所有这类写法最后都会被证明是假的，要么查库，要么让接口返回明确的 id 字段。其三，拒绝路径一定要有非零退出码，被拒绝却返回 0，等于把错误藏进定时任务里，可能几十天都没人发现。其四，写库前先做只读自检。我有次差点在在售套餐数据上跑了一个本该只读的检查脚本，因为直接开了可写连接，自动批准也不会拦。现在固定动作是：先复制一份库副本，再用只读模式打开跑查询；真要改数据，单独写脚本、单独确认。
最后补一句我自己的教训：这次发现问题靠的不是更聪明的代码，是一次"多余"的对照——顺手按时间倒序多拉了一次最新记录。日常多留一次这种对照动作，比事后排查一整天便宜。
