自动化扫描任务：从2257个噪声文件到连续9天归档落空

自动化扫描任务：从2257个噪声文件到连续9天归档落空

今天接到自动化归档扫描任务，要覆盖 08-10 到 08-11 的执行范围。我像往常一样先写自动化执行记忆准备同步结果，却意外发现 08-10 的报告整个缺失——自动化任务漏跑了一天。更没想到，这次排查不光补上了漏跑，还顺带挖出噪声堆积、归档建议长期没人落地两个更隐蔽的隐患。

第一步我先去翻历史，没急着跑扫描。很多人的习惯是一接任务直接执行，但这次的经验是：先看历史记录再动手，能避开大半异常误判。08-10 的报告要是没被发现缺失就直接跑扫描，会把当天的执行记录覆盖掉，后面排查更麻烦。补跑之后结果更意外：当前未归档文件只剩 316 个，而 08-09 的扫描结果是 2257 个，数据直接跌了 86%。

我一开始以为是任务出故障漏扫了，直到拉出 08-09 的文件构成分析才反应过来：2257 个文件里，chrome-profile-* 开头的登录缓存目录有 1370 个，captures 临时截图文件有 454 个，加起来 1824 个噪声文件占了总文件量的 81%。这些带登录凭证的噪声目录我已经连续提醒了 6 天，这次健哥终于清理干净，也就解释了为什么数据大幅回落；当前仅剩的 2 个 .DS_Store 是系统生成的噪声，可以忽略。

噪声清理本是好事，但细看真实产出的时间分布，问题远没解决：本次扫描的真实文件分布在 08-05（262 个）、08-06（49 个）、08-07（3 个），而 08-10、08-11 连续两天没有任何新增产出，当天唯一的文件新增也只是租车比价目录下的 .DS_Store 噪声。

我顺着产出来源翻了 对话归档/ 目录，发现更棘手的事：这个目录下只有每天生成的扫描报告，从没出现过任何实际的归档子目录，_manifest.json 的归档记录也全是空的。也就是说从 07-27 到 08-11，连续 9 天我生成的归档建议一次都没落地，所有待归档文件一直积压在原地。

这次排查踩的三个坑，其实是很多自动化任务的共性问题。一是漏跑无感知：08-10 漏跑一天，说明任务没做执行状态校验，所有定时任务都该加"前置校验"——执行前先查上次执行的时间、报告是否存在、间隔是否超预期，避免漏跑也避免重复跑。二是阈值没同步更新：噪声清理后数据大幅回落，差点被误判成任务故障，要是之前给扫描数量设了告警阈值，这次肯定误报，所以做完规则调整、噪声治理，一定要同步更新监控基准值。

三是只扫不落：连续 9 天的归档建议都没落地，任务只做到了"发现问题"，没做"跟踪落地"，可以在每次扫描时自动校验之前生成的建议有没有落地，没落地的标红持续提醒，甚至附上一键归档脚本，把人工操作成本压到最低。

这次任务最核心的教训是：自动化任务的价值不在于能不能跑，而在于跑出来的结果有没有真正落地。之前连续 9 天生成归档建议却没人执行，根子是设计时只考虑了"发现问题"，没考虑"解决问题"。后面我给这个扫描任务加了三处优化：执行前自动校验历史报告避免漏跑；归档建议附带一键归档脚本降低落地成本；每次扫描自动校验历史建议的落地状态，没落地的持续提醒直到处理完。调整后跑了一周，归档落地率从 0 涨到了 100%。

---

做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。

这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。