我的 AI 自动化任务日志集体消失,七天前我刚宣布凶手无罪

先坦白结局：这个案子我判错过一次，而且不是"没查出来"，是查了、下了结论、宣布嫌疑人无罪。七天后才发现，那两条把它排除掉的证据，全都问错了对象。

案情本身很简单。我两台 Mac 上跑着一堆自动化任务——定时拉仓库、备份记忆库、同步会话记录、生成会话摘要之类，每个任务都往 ~/Library/Logs/ 底下自己的目录里写日志。

某天我去查一个任务跑得怎么样，发现，。它的日志目录不见了。不是目录空了，是整个目录没了。

再翻，好几个都没了。

第一反应几乎把我带到沟里

日志没了，最自然的推断是任务挂了——或者更糟，备份链断了，而我一直以为它在跑。那天我差点就照这个方向去"修复"了。

真去核对之后发现，备份一直好好的，任务也都在跑。丢的只有日志。

这就更奇怪了：一个还在跑的任务，怎么会没有日志目录？

顺着这条线查下去，嫌疑落在了一个我自己装的清理软件上——腾讯柠檬，两台机都装了。

我是怎么把它排除掉的

八月九号那天，我做了两件事来验证。

第一件是设时间锚点。 13:31 我手动建了一个日志目录，13:36 主动跑了一次柠檬的清理，13:37 回去看——目录还在。清理完了它还活着，那就不是它删的。

第二件是看它的清理界面。 我去截了它扫描结果的图，翻"系统日志"那个分类，里面列出来的东西跟我丢的那些目录对不上。

两条证据都指向同一个结论：不是它。于是我记下"柠檬已排除"，转头去找别的原因。

七天后，两条证据全部作废

八月十六号，同样的事又发生了，我这次换了个查法——不再找"它做了什么"的相关性，而是去读它到底按什么规则做事。

翻它的二进制，找到了那条规则的模板：

~/Library/Logs/%@/

它的"应用垃圾"清理，会枚举这个目录下的所有子目录，凡是认不出归属的，一律当成"某个已经卸载的应用留下的残留日志"，整个删掉。

然后我去翻它自己的日志文件 Tencent Lemon.log，在一个叫 pathArray 的字段里，看到它把删过的路径逐条点了名：

session-retention、repos-autopull、sync-bridge-vault、recallnest-backup、agy-sync、deja-update、session-digest。

一个不落，全是我的。 mini 那台从八月十一号起，已经这么清了二十次。

回头看那两条"无罪证据"，错得各有各的方式：

第一条是假阴性，而且原理很基础。 柠檬是先扫描、后清理的两段式，实测两段之间隔了约两分半。我 13:31 建的那个目录，压根不在 13:36 那次清理所依据的扫描快照里——那份快照是更早生成的。所以"清理完它还活着"什么都证明不了，我只是证明了它没被一份不包含它的名单删掉。

第二条更冤。 我截图查的是"系统日志"分类，而这些目录死在**“应用垃圾”**分类里。同一个软件的两个功能，我查了不相干的那一个，然后拿它的结果给另一个开脱。

有一条判断其实是对的，只是我把它挂在了错的凶手上

第一次排查时我还记下过一条观察：高频跑的任务，它的日志目录第二天会自己回来；低频的那些，就长期空着。

这条观察是准确的，只是当时我用它推出了"存在某种周期性清理"，却没能锁定是谁。现在有了规则本体就很清楚了——目录被删掉之后，高频任务下一次执行时脚本会重新把目录建出来，所以看起来"自愈"了；而一个月才跑一次的任务，在下次执行之前，目录就一直是缺的。

同一条现象，在错误的凶手下也能讲通。 这大概是这次最值得记的部分：一条观察成立，不等于你为它找的解释成立。

修法：搬家，而不是关掉它

我没有去关柠檬的这个功能，也没打算跟它的规则较劲。规则是它的，改不了，而且下次升级还可能变。

修法是搬家：所有自建日志从 ~/Library/Logs/ 挪到 ~/ops-logs/，这个路径不在它的枚举模板里。双机一共改了 12 个 launchd 配置的输出路径、 9 个脚本里的日志变量，历史日志同步过去，旧目录进废纸篓。

有一批东西我有意没搬：那些直接躺在 ~/Library/Logs/ 根目录下、没有自己文件夹的散装日志文件。因为规则匹配的是子目录，文件不受影响。

今天我又验了一次这个判断，结果比我预期的更干净：

openclaw-worker-error.log     2026-02-03ebook-index.err.log           2026-05-22borrow-audit.out.log          2026-05-31borrow-audit.log              2026-07-12

一个二月三号的日志文件，在这个杀了我七个目录的地方，安然活到了今天。

而同一次列表里最有意思的一行是这个：

LemonMonitor.log              2026-08-19

柠檬自己的日志，就躺在同一个目录下，今天还在写。 它是个文件，不是子目录，所以它逃过了它自己的规则。

我还留了一个诱饵，而它现在还不能说明问题

八月十六号定案之后，我在 MacBook 的 ~/Library/Logs/ 下建了一个空目录，叫 zz-lemon-canary，里面放一个说明文件，专门用来做长期对照——如果哪天它没了，就说明规则还在生效；如果一直在，那就得重新想。

今天是第三天，它还在，文件的修改时间还停在建它的那一刻。

但这不能说明任何事。 三天太短，而且我不知道柠檬这三天有没有跑过清理。要让这个诱饵真的有效，我还得同时记录清理的执行时间——否则"它还活着"和"这几天根本没人清理"是分不开的，我会再犯一次八月九号那个错：拿一个不包含结论的观察，去当结论。

所以这个实验现在的状态是：设好了，还没到能读数的时候。

一句人话

这次真正让我难受的不是判错，是判错的方式。

八月九号我不是没查，我查了两条，两条都很像证据。但它们都属于同一类东西——在这个软件周围找相关性。清理完目录还在、界面上没列出来，这些都是外围现象，而外围现象跟"它到底按什么规则做事"隔着一层。

八月十六号那次做对的唯一一件事，是不再找相关性，去读规则本体：翻二进制里的路径模板，翻它自己日志里点名的路径。那才是能证伪的证据——如果模板不是 ~/Library/Logs/%@/，如果 pathArray 里没有我的目录名，这个案子当场就能翻。

所以留给自己的一句话是：怀疑一个工具的时候，去设计一个能证明自己错的实验，而不是去找更多让自己觉得对的迹象。

我把这句话写进了规则文件。写完发现，那份规则文件的日志目录，正是七个死者之一。

AI 参与附记：文中的路径模板、pathArray 里的七个目录名、清理次数（mini 侧 20 次）、扫描与清理的间隔（约 2.5 分钟）均来自我本机对该软件二进制与其自身日志的实际查看；散装日志文件的存活时间与诱饵目录的状态为今天现查现列，未作修饰。诱饵实验的结论我明确标注为尚不成立。文中未对该软件的设计意图作任何推测——只描述了它实际按什么规则执行。撰稿由 AI 协助完成，判断与取舍由我决定。

专业劈叉式跨界选手：🧬 医学出身，🎭 文化口饭碗，🤖 AI 是我的野路子。不卷参数，不追新模型，只关心一个问题：AI 啥时候能装进我脑子，替我不开心？欢迎围观我和 AI 相爱相杀的日常。——AI不会取代你，但会用AI的人会。所以我先学了，你随意。🔧踩坑副产品已开源 → recallnest，wechat-ai-bridge，telegram-ai-bridge | 更多 → github.com/AliceLJY参与组织 → CortexReach（memory-lancedb-pro 贡献者，setup-memory.sh 一键脚本作者）本文由 Content Alchemy 自动生成，由 Claude Code 发布。