把夜班交给 AI 的第 30 天：一次断线、三次自愈和我学到的判断标准

上个月我做了个决定：把夜里那些"必须有人盯着"的活，交给 AI 守。

一个月下来，我最大的收获不是省了时间，而是搞明白了一件事——自动化里最贵的不是执行，是"它到底干成了没有"这个判断。

这篇把过程、翻车和那套判断标准都写下来，给同样想把夜班交出去的同行少踩几个坑。

一、为什么夜班值得交出去

夜班活的共同点：发生时间不确定、动作固定、一旦漏了第二天要返工。

我们夜里的活主要是三类：定时任务跑批、平台登录态维持、长流程的断点续跑。这三类有个共性——人干的时候是"守"，机器干的时候必须是"判"。

守是等着，判是拿证据。这一步想不明白，自动化只会把问题藏起来。

二、第一周：三次"看起来成功了"

第一周最典型的翻车是三种"假成功"：

第一种：命令跑完了，但产物是空的。 脚本退出码 0，日志写着"完成"，第二天打开文件是 0 字节。退出码只说明进程没崩，不说明事情办成了。

第二种：消息发出去了，但没人收到。 通知接口返回 200，群里没消息——因为发的是另一个会话，或者被折叠了。

第三种：入队了，等于完成了。 任务进了队列就标记完成，实际卡在队列里没被消费。

这三次的教训浓缩成一句："发了"不等于"到了"，"跑了"不等于"成了"，"入队"不等于"完成"。

三、第二周：把"完成"重新定义成可验证

第二周我把所有"完成"都改成三段式：

1. 产物落地——文件存在、能打开、大小合理、内容字段对得上；
2. 回读校验——回到目标系统里读一遍真实值，而不是读自己写的记录；
3. 留时间戳——每次判断写一行日志，带时间和结果码。

改完之后，夜里失败开始"出声"了。以前是静默失败，现在是明确报错——这已经是巨大的进步。

四、第三周：断线不是取消

第三周遇到一次典型情况：跑到一半会话被中断，界面弹了"已取消"。

人第一反应是"是不是谁点了取消"。但自动化的世界里，绝大多数"取消"其实是连接断了、会话超时、进程被回收。

所以我的处理顺序变成：

• 先自检：通道还在不在、任务停在哪一步、已完成的部分有没有产物；
• 再续跑：从断点接着跑，绝不整批重跑（重跑会重复下单、重复提交，比不跑更糟）；
• 最后才找人：只有自检证明"真断了"才叫人，而且带上已经试过什么。

这一条把夜里的打扰量降到了接近零。

五、第四周：给会复发的故障写"看护人"

到第四周我发现，能自己恢复的故障不用管，会复发的故障必须有人管。

判断方法很简单：同一个故障出现两次以上，就要写三样东西——

• 谁看（哪个环节负责发现）；
• 多久看一次（频率）；
• 怎么算恢复（判据，必须能在日志里查到）。

没写看护人的自动化，等于把定时炸弹交给了下一个人。

六、我现在用的判断清单

一个月下来沉淀了五条，贴在下面，谁都能用：

1. 只认产物：没有可验证产物的"正在处理"，一律算没做。
2. 只认回读：写进去不算，读回来对得上才算。
3. 只认时间戳：说"已恢复"之前先翻日志，翻不到就写"未自验，待核"。
4. 断点续跑：失败只补没做的，不整批重来。
5. 看护人制：会复发的故障，必须有人、有频率、有判据。

写在最后

这一个月我没写什么复杂代码，做的主要是把"我觉得它成了"换成"我能证明它成了"。

自动化真正的门槛不在技术，在于你愿意为自己的判断负责到什么程度。愿意负责到"能被日志打脸"，夜班才真的敢交出去。

文中流程基于 WorkBuddy 的定时任务与自愈守护能力实现，场景已脱敏处理。