昨天我让仲马去查一件事：我们那份工作日志，到底多久没更新了。
问这句话的时候，我以为答案是”两三天”，最坏”一周”。查完的答案让会议室安静了几秒——五个星期。
五周里，我的 Obsidian 里一直躺着一个叫「工作日志」的文件夹。它每天都在那里，看起来一切正常。没有任何报错，没有任何红点，没有任何一条”任务失败”的提示。它就是不再长了。
一份没人发现它死了的日志
先解释一下这个东西是干什么的，因为这决定了它的死法有多隐蔽。
我这边的工作方式是：白天我下指令，AI 伙伴们分头执行。小仲马管内容和技能迭代，樱桃管舆情和情报，赫菲管工程，数据师管数据。这些动作如果没人记，第二天就全散了——所以几年前我们立了一条规矩：每天凌晨，把所有伙伴前一天干了什么，整理成一份日志，写进 Obsidian。
它的作用不是归档，是让协作有记忆。我在会上随口说一句”上次那个客户的事”，赫菲得能接上”是八月底那单吗”。日志就是这个”接上”的基础设施。
所以它不是一份文档。它是一根管子。
而管子堵了五周，我在水里没尝出来。
原因很简单：日志系统不产出任何下游的”看得见的东西”。它不发通知、不进报表、不影响任何一条业务线。它唯一的下游消费者是我——一个人类，凭记忆偶尔翻一眼。人类不看，管子就是隐形的。
这就是我想说的第一种失败：它太重要了，以至于它的重要性只体现在”没有它的时候”，而它没有的那一刻，是安静无声的。
查下去，真正的原因让我有点意外
仲马给的第一版结论很直白：卡住了。
具体是——日志任务里有一步会去检索会话记录，而我们的会话库已经攒到 790MB。这一步在这么大的库上跑不动，一次检索耗了 928 秒，而任务的上限是 600 秒。超了 328 秒，被系统按规矩杀掉。
死在 8 月 14 号晚上。第二天上午又被触发了一次，同样死法。然后有人（大概是发现它一直失败，顺手止损）把这三个任务手动关掉了。
于是它从”失败”变成了”不存在”。 失败至少会吭声，不存在连吭声的机会都没有。
到这里都还算是常规的工程故事。真正让我坐直的是第二步修复之后的事。
用了五种办法都不行，最后是一万六千倍
仲马的排查路径很值得说，因为它暴露了一个我们自己都一直在踩的坑。
第一反应通常是：把超时上限调高。但这是错的——928 秒不是”差一点”，是这条路根本不适合走。把上限调到 1200 秒，只会让下一个更大的库再撞一次，而且撞的时候更晚、更难查。
第二反应是优化那一步检索。但它的接口就在那里，改不了。
试了几种都走不通之后，他做了一件我在工程技术上最推崇的、也最少有人做的事：绕过那个工具，直接读底层数据。
会话数据最后就是落在一个本地数据库文件里的。检索工具之所以慢，是因为它要做一整套为”通用搜索”设计的准备工作——建索引、处理上下文、格式化输出。而我们真正需要的，只是”昨天有哪些会话、各自几点开始”。
直接查那张表，0.057 秒。
928 秒到 0.057 秒，一万六千倍。
我把这段写下来不是想说”技术多厉害”。我想说的是它后面那条更硬的道理：
当一个工具在你的场景里慢得离谱时，通常不是它坏了，是它一直在做你不需要的事。
你付的是通用性的钱，用的却是一个窄需求。这种错配不会报错，它只是慢。它慢得你以为是世界的物理规律，直到有一天你把中间那层剥离掉。
我们的 AI 伙伴们其实一直在替我承担这个成本。检索一慢，任务就死；任务一死，日志就断；日志一断，我就以为”最近没什么事”。一个错误的架构选择，最后伪装成了我的一段平静生活。
然后是最有意思的部分：它记错了人
管子接通了，日志重新开始产出。按理说到这里就该收工了。但仲马在跨环境核对时，发现了一个比”停摆”严重得多的问题。
旧的那套逻辑，会把 cron 自己的自言自语，记成我的工作。
cron 是定时任务。每天凌晨，我们的很多伙伴不是被我唤醒的，是被时钟唤醒的——它们自动跑、自动落盘、自动结束。这些都是机器在跟自己对话。
而日志里出现了一条记录，写的是「我 21:04 到 22:10 在做什么什么」。核对之后发现：那段时间我根本不在。那是樱桃的一个定时任务在 20:30 自己跑的一轮。
一个每天在更新的日志，更新的是机器的独白，却署了我的名字。
这一条比停摆可怕。停摆是”没有信息”，这个是”有信息，但是假的”。而且它假得极其体面——格式正确、时间精确、语气自然，看起来比真的还真。
如果你有用 AI 跑过的任何自动化流程，你可能已经见过这个形态了，只是没往这个方向想：
- 你的财务机器人每天汇报”今日完成 12 项”，其实那 12 项是它自己内部的步骤，不是你的账；
- 你的内容工具每周发一份”本周产出”，里面全是它自己生成的草稿数量，没有一条发布过；
- 你的监控面板绿得发亮，因为它监控的是自己能不能启动，不是你的业务有没有成交。
我们当初设计日志的时候，默认了一个前提：“有记录”就等于”有事实”。 但记录和数据是两回事。记录只证明有人在写，不证明写的是真的。
修复方式很朴素——把”这条记录是从哪来的”变成一个必须回答的问题。来源是人，才记；来源是任务自己，不记。改完之后再跑，报告的第一行变成了诚实的六个字：
人工会话 0 个。
我觉得这六个字比之前那一大段漂亮的记录有价值得多。它什么都没说，但它说的是真的。
三件事，你可以直接拿去用
我把这次的教训压成三条，都跟 AI 无关也能成立：
一、给”没有输出”这件事本身设一个告警。
所有的监控都在盯着”错误”，但最贵的问题形态是”什么都没发生”。文件没长、日志没写、订单没来——这些都不报错。做一条最笨的兜底规则就行：如果这个管子 N 天没动静，就当它死了。 日历不会骗人，报警器会。
二、检查你的指标，问它到底在测”谁”。
把这个问句套在你手上任何一个自动化指标上：它统计的是我想要的结果，还是这个系统自己的活动？任务执行次数、内容生成量、接口调用成功率——这些全是”系统在动”，不是”事情在成”。前者是体温计，后者才是脉搏。体温计再准，也测不出你心脏还跳不跳。
三、慢得离谱的东西，第一反应不该是加预算。
超时上限、机器规格、并发数——这些都是”买更多本来就不该买的东西”。先是问：它为什么在做这件事？我真正需要的输出是什么？绝大多数时候，答案都在那层被剥掉的通用性里。
日志这条管子现在是通的。每天晚上它自己跑，0.057 秒读完数据，写一份诚实的记录——包括那些”今天什么都没有”的日子。
我不打算给它加什么漂亮的监控面板。我只留了一条规则：它超过三天不出声，就有人要去找它。
因为这次真正教会我的，不是什么技术原理。是一个特别朴素的道理：
一份日志的价值不在于它有没有在写，而在于它写的是不是你。
