先冻结检查，再开始干活：一种防自欺的验证协议

“做完了，而且我用一条命令验证过了。”

这句话听起来很扎实，但它里面藏着两个互相独立的漏洞。

漏洞一：检查是什么时候写的

如果验收检查是干完活之后才写出来的，那么写检查的人已经知道结果长什么样了——他会不自觉地让检查"刚好通过"。这不是恶意，是顺序决定的。

同一份检查，写在动手之前和写在动手之后，可信度不是一个量级。

漏洞二：检查可能永远不会失败

一个从来没被问过"你能不能失败"的检查，和没有检查是一回事。

想想你的健康检查脚本：它一直是绿的。它是真的在测东西，还是仅仅从没遇到过能让它变红的输入？这两种情况在仪表盘上长得一模一样。

把顺序倒过来：三个动作

承诺（commitment）：开工之前，把验收条件写下来，编上序号并用哈希串成链。此后只要有人修改了检查，链就会断——于是之前基于这份检查得出的所有结论，可以被证明地作废。不靠约定，靠数据结构。

结算（settle）：活干完，按事先冻结的那份检查去判定通过与否。判定发生在检查锁定之后，所以判定不能反过来塑造检查。

审计（audit）：判定之后再加一步——把被检查的产物改坏，重跑检查。如果一个检查在坏输入上依然通过，它就从来不是证据。

一段真实的输出

$ precheck register
freeze 1 commitment(s) at seq=1  sha256=e2d4561aa9f0
$ precheck settle
PASS  the deployment config is valid and safe to ship
$ precheck audit
ran 4 mutation(s) across the declared artefacts
2 check/mutation pair(s) survived — these prove nothing yet

最后一行值得盯一会儿：4 个变异里有 2 个"存活"。它们不是缺陷，是候选——每一个都指向一条可能永远不会失败的检查。

这句话也是这套东西的诚实之处：它不喊"发现 2 个 bug"，它说"这两个目前证明不了任何事"。一个会虚报缺陷的工具，在第二次核对时就会被你丢掉。

三条可操作的原则

1. 检查先于工作。 验收条件在工作开始前写定，并能被哈希锁定；事后改检查，等于宣布之前的结论归零。
2. 结论只对未改动的检查有效。 把"检查变更"和"结论失效"绑成同一个事件，不要用自觉去维持。
3. 每个检查都要能回答：什么输入会让它失败？ 答不出来，它就不是检查，是装饰。

一句话

先冻结标准，再做工作。 反过来的顺序不叫验证，叫自我确认。