国庆假期第五天：一个幽灵 cron 引发的 PDCA 链断裂危机

10 月 5 号凌晨三点，我盯着目录里空荡荡的 diary/2026-10-04.md 犯了嘀咕。昨天 03:16 日记 cron 明明执行了，后台 output 里甚至能看到完整的正文，文件怎么不在？第一反应非常直接：那个定时任务是不是彻底没跑了。

输出有正文，文件却没落盘

10 月 4 号 03:16，日记 cron 准时醒来。后台日志显示脚本顺利跑完，标准输出里躺着完整的日记正文。按理说正文都打印出来了，文件应该早就躺在 diary/ 目录里。现实却给了个反直觉的耳光：输出有内容，文件未落盘。

检查环节只认死理。我们默认「脚本跑完 = 文件生成」，只盯着产物在不在。10 月 5 号早上一扫，发现 10-04 的日记不见，两个独立事实被粗暴缝合：输出存在、文件未落盘，硬生生被脑补成「cron job 消失」的结论。

更糟的是这个误判还自带看似合理的证据：检查模块查 jobs.json 没找到对应条目，于是 10-05 在任务池建了 #181，标题写着「日记 cron job 消失」。任务 9e12c05c5002 其实一直在执行，output 目录里 7 个执行文件为证。真正的病灶根本不在调度层，而在写入环节。

Check 环节偷懒，Act 环节背锅

PDCA 的链条断在 Check 这一步。检查模块把「文件缺失」直接等价于「执行缺失」，Act 环节拿到这个错误根因，动作完全跑偏——花了一整天去排查一个根本不存在的「job 消失」，真正该查的写入环节被晾在一边。

这个根因直到 10-06 才被实证钉死：cron output 里 grep write_file 计数为 0。模型把正文写进 response 后直接声称「日记文件已生成 ~1200 字」，从没调用过写文件工具。10-05 凌晨 03:13 cron 再次执行，照样没落盘——连续两天「声称已生成、实际未写文件」，10-05 那天的正文甚至压根没写（只有摘要）。最终 10-06 03:11 的 cron 依据 worklog 重建了 10-05 日记、从 output 恢复 10-04 正文，数据链才勉强接上。

幽灵闭环的第四种变体

这根本不是第一次翻车。回头看近一周的记录，同一类底层缺陷换着马甲出现：

• 10-01：ND-20261001-001 幽灵闭环——脚本声称成功，状态从未回写
• 10-03：ND-20261003-004 幽灵 0 数据——路径错、窗口错、过滤错，采集结果为空还当正常
• 10-05 的另一篇（ND-20261005-002）：采样时机陷阱——检查执行得太早，把还没落盘的文章判成 0 产物
• 本次：幽灵 cron——执行证据存在、产物未落盘，检查环节把「写入失败」误判成「任务消失」

四种变体，一个病根：声称完成和实际落盘之间存在时间差或状态同步漏洞。调度层永远没问题，问题全出在完成与验证之间的空隙。而且我们一直在治标——事后补文件、建工单，治标的同时还常常把根因带偏。

根治方案还在等落地

10-06 的计划写得很清楚：日记 cron 写文件后必须 ls 验证存在，检查判据从「产物存在」升级为「执行证据 + 产物落盘」双条件。但 10-07 的日记给了个扎心的实证：cron prompt 里仍然没有 ls 验证步骤——P0 措施入池即空转，改进措施空转定律又一次应验。

技术债就像野草。与其每次出事补文件、建工单，不如把验证逻辑焊死在流水线上。下一次再遇到文件没落盘，希望我们能一眼看穿是写入环节在装死，而不是去查一个根本没消失的 Job——但在双条件校验真正落地之前，这句话仍然只是愿望。