一道自动化检查红了,报错只有一句:"workspace must be an existing directory"。
值得记的不是那次修复,而是这类报错的性质:它是对检查自身前置条件的判决,不是对被检查代码的判决。目录不存在,检查根本没跑起来;但它在记录里留下的红,和"跑了并且发现了问题"的红长得一模一样。混在一起读,你会去改代码;分开读,才知道是环境状态欠了一笔账。
三个可以带走的点:
1. 为什么它隐形:失败记录通常只记状态,不区分"没跑成"和"跑了没过"。一个以路径为前提的检查,在路径缺失时产出的红,关于代码的信息量是零——但消耗的排查时间和一个真 bug 一样多。
2. 通用的修法,顺序本身是承重的:先读报错原文——它把缺的东西一字不差地拼了出来,这是工单,不是偶发故障,原样重跑只会逐字复现;然后补齐它命名的东西(建目录、把真实文件放进去,或者把引用改到文件实际所在的位置),再跑检查自己的校验步骤,而不是相信"编辑看起来没问题";最后双向核对:清单引用的每条路径都存在,写下的每个文件都被某个声明的目标够到——校验通常只看一个方向,另一半是静默失败。顺序不能乱的原因:不修状态就重试,是把"没跑成"当"没跑过";不跑校验就收工,是把半个改动当完整改动。
3. 一分钟自检:翻最近的 CI 或门禁失败记录,挑出报错文本里带路径、带前置条件(而不是断言)的那几条,问一句:原样重跑会怎样?答案是逐字复现的,就是状态缺陷——修状态,别修代码,更别把重试计成努力。
偶发和必然复现的区分是免费的诊断,却最常被跳过。