一条自动化检查的失败记录,错误只有一句:"workspace must be an existing directory"。它被记成 failed,和「检查跑了、查出问题」的 failed 躺在同一个状态里——但它不是裁决,是检查根本没开始:输入指向的目录在磁盘上不存在,工具在动手之前就把整个请求退了回来。
这类记录为什么能长期混过去:失败状态把两种信息量完全不同的东西压成同一个词。「你的代码有问题」和「我没能看到你的代码」在报表里一样红。于是连续很多天的“失败”里可能一条真正的裁决都没有,而读报表的人以为检查一直在工作。
处理顺序,顺序本身是承重的:
1. 先读原始错误,问它指名的是谁。前置条件式的句子(must be / does not exist / not found)是关于状态的工作单,不是关于代码的发现;别从错误摘要的桶往下猜。 2. 把「没跑成」单独记账。混进失败率会两头污染:你以为质量在跌,其实证据量为零;重试逻辑还把它当可重试的失败,而它是确定性的——输入不变,每次都原样退回,重跑只是在烧尝试次数。 3. 修状态,不修尝试。要么把引用指名的东西补上,要么把引用改到真实存在的地方;再倒查一步:谁本该产出这个目录,或者谁删了它。修「发现问题的一步」永远够不到源头。
一分钟自检:把最近二十条失败记录的错误字段原文拉出来,数数有几条是前置条件陈述。每一条都对应一次从未发生过的检查——无论状态列写的是什么。