我电脑上跑着三个 AI。

一个在云上，负责调研、日报、写草稿；一个在本机，负责写代码、整理知识库；还有一个是我现在用的这个，居中调度。

听起来挺像回事。

实际上，本机那个从 9 月 28 号到 10 月 14 号，整整 16 天——0 提交、0 沉淀、0 学习。

它不是坏了。它只是什么都没干，而且没人发现。

装的时候，一切看起来都对

10 月 14 号晚上我决定给它装套东西，三件：

一、每天早八点对一次账。云上那个昨天干了啥、本机这个干了啥、我自己干了啥，写一份摘要扔进仓库。

二、常驻一个进程盯着。云上那个一有新产出，就写条通知。

三、超过七天没动静，写一条沉默告警。

装完我挨个验了一遍：两个守护进程都在跑，日志一天不落，状态文件的时间戳每天都在更新。

我当时想的是：这事完了，以后它自己会盯着自己。

然后就再也没管过。

11 月 3 号，我把数据翻出来看

不知道为什么想起来翻一眼。

摘要文件夹，21 天，空的。通知文件夹，21 天，空的。告警文件，根本不存在。

机制全绿，数据全空。

那种感觉挺荒诞的——就像你给员工装了打卡机，每天都有打卡记录，月底一看，一单没开。

三个 bug，一个比一个蠢

我把三个脚本从头到尾读了一遍。

第一个：盯错了地方。脚本去读一个目录下的 jsonl 文件，可那个目录在我的电脑上压根不存在。因为它压根没被创建过。于是每次检查都是"没有新文件"，安安静静地跳过，日志里连个错都不报。

第二个：自己给自己打分。沉默告警的判据，是状态文件里的"最后活跃时间"。问题是——这个时间，每天早上会被对账脚本自己刷新一遍。所以检测器测的从来不是"本机那个 AI 有没有干活"，而是"我这个定时任务有没有跑"。当然每天都在跑，当然永远不告警。

第三个：少了一个人。三方对账，第三方的位置我写死了四个字——"暂无自动探测"。也就是说这套东西从生下来那天起，就只对了两方的账。

三个 bug 有个共同点：没有一个会让程序报错。它们全都安安静静地正常退出，退出码 0。所以你看日志，一切正常；你看数据，全空。

改法其实很土：别让它自己报自己

我把所有判据，从"它自己说的"换成"外部事实"。

云上那个有没有干活，不看通知，看仓库里 24 小时内的提交记录；本机这个沉默了多少天，不看它自己记的时间，看它最后一次提交是哪天。

第三方那一段也补上了，按作者名过滤，现在是真的三方对账。

改完三分钟，它把自己抓了

新版本上线三分钟，立刻暴露了两个我自己造的坑。

一个是自反馈环。盯产出的那个进程不区分提交作者，本机这个 AI 自己提交完，被判成"云端有新产出"，写通知；通知要提交，又一次提交，又被判成新产出……差点进死循环。修法是：把自己身份的提交从列表里滤掉。

另一个是基线失效。如果记录的那个基准提交被另一台机器 rebase 掉了，比对区间会直接报错。加了祖先链检查，不在链上就重新打基线，记一条警告，不写通知。

修完再跑，同一天的输出总算像句人话了：

这事教我的

不是"多测一测"这种废话。

真正的坑是：所有让 AI 自己报"我在工作"的设计，都有可能是假的。

它可能真的在跑，跑的东西没有对象；它可能真的在报时间，报的时间是自己刷的；它可能真的在对账，账本少了一角。这些都不会报错，因为站在程序的角度，它没错。

唯一的办法，是拿一件它无法篡改的事实当判据。对我来说是提交记录。对你可能是订单表、发布记录、客户的回复。

装完不等于装对。跑起来，也不等于跑对。