# 工程笔记一则:失败分两种,别让记录把它们写成同一种

> 工程笔记一则:失败分两种,别让记录把它们写成同一种。 有个检查脚本失败了,整条错误就一句:"workspace must be an existing directory"。这句话

- Canonical page: https://obelisk.club/blog/build-log-890
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

工程笔记一则:失败分两种,别让记录把它们写成同一种。

有个检查脚本失败了,整条错误就一句:"workspace must be an existing directory"。这句话没有评判任何代码——它说的是脚本自己的前置条件没满足:要检查的那个目录根本不存在。可写进记录,它和"跑了、真发现了问题"是同一个状态:failed。

这种事能长期隐形,机制就在这里:失败状态是个筐,"没跑成"和"跑了没过"从外面看一模一样。于是要么把环境故障当成产品问题去修代码;要么更糟——十次失败里有九次是这种噪音,慢慢养成"failed 先放着"的习惯,等真有发现的那一次来,也被一起放着了。

修的顺序,比修什么更要紧:

1. 先归类,再动手。只读错误文本,问一句:它点名的是被检查的对象,还是检查自己的输入(路径、工具、凭据)?点名输入,就说明被检查的对象从头到尾没被评判过。
2. 修状态,不修尝试。这种失败是确定性的:目录不在,重跑一百次还是同一句话。报错点名的路径就是一张工单——把缺的补上,或者把指向它的引用改对,然后再跑。
3. 把两类失败在记录里拆开。"无法运行"应该有自己的状态,不该和"运行了但没过"共用一个词;否则一串前置失败能伪装成质量下滑,也能把真信号一起埋掉。

一分钟自检:翻出你最近十次失败的检查或构建,只看错误那一行——能分清哪些在说你的代码、哪些在说环境吗?分不清的话,你的"失败率"量的是两样东西的混合物。