我们最信任的那道检查，
可以在「完全没干活」的情况下亮绿灯。

而且它没有算错——它逐字执行了自己的判据。
问题出在判据够不着的地方。

下面用这个月一次真实的走查，从头走一遍。

起点是人眼，不是机器

这时候，负责检查超链接完整性的那道自动检查是绿的。
它刚刚跑过，没有报任何问题。

它报的不是「都对」，是「没东西可判」

「0 个问题」和「0 个检查对象」，在报告上长得几乎一样。

判据假设的结构，和真实结构不一样

判据是这么写的：「同一个文本块里有没有出现溯源字样」。
而 PRD 卡里的 Source 段，实际是这样长的——

标题和内容行是兄弟关系，不是父子。⇒ 真正要检查的那些行，从来没进过分母。

这次是反过来的：长得像链接，其实点不动

补完射程，我顺手写了条新规矩：凡是带链接的文字，必须是青色 + 下划线。
几十分钟后，在 Journey 卡上实测到这两行——（下图是 Figma 里的实际渲染，不是示意）

我只规定了「有链接的该长什么样」，
没规定「长成链接样子的必须真有链接」。

从「假绿」到「真绿」，中间必须经过一次红

为什么这三个数要一起看：只看头和尾，两次都是「绿」，什么也证明不了。中间那次红，才是这道检查真的在干活的唯一证据。一道从来没红过的检查，和一道坏掉的检查，在报告上长得一样。

判据本身都是对的，
漏的是它没覆盖的那一侧

所以写完任何一条检查规则，跑这三个问法——
⛔ 要问的不是「这条判据会不会算错」。

1. 分母是怎么来的？什么东西会因为形态不同，整批落在射程外？checkedUnits=0 和 findings=0 是两件事。
2. 反过来那一侧谁管？规则形如「所有 A 必须有 B」时，「有 B 但不是 A」由谁判？这次两个反例都出在这一侧。
3. 这条判据是在真实结构上验过的，还是在我想象的结构上？射程盲区的根因就是这个。

为这场分享做的取数工具，
第一次真用就被它自己拦下了

这套流程有条硬规矩：所有数走同一张取数单，它出数之前先自证口径——拿历史上已经核过的几个数当标尺，对不上就不出数。

又是判据量错了对象

那条自证写着「窗口起点取今天，应该至少看得见最新那次提交」，注释里管它叫恒真关系。
它实际量的是——今天有没有人提交过代码。

那天上午还没人提交，于是它红了。红的是判据自己，不是数据。

验的方式：分别注入两种故障 —— 一种只让第一条红，另一种只让第二条红。互不替代，这才说明拆得有必要。

有两个数，我们至今写着「口径不明」

上一期页面上有两个数，这次想复现，四个候选口径算出来的值没有一个对得上。

要让它变成数字，得先把口径钉下来、补一个历史标尺。
在那之前，空着比填一个像的更有用。

这个月没做成的几件

• 「这套东西省了多少时间」，我们给不出数。那是个费率，不是事件——系统里根本没有采集它的地方。所以这条只能讲感受，⛔ 不编数字。
• 这个月的量太小，前后对比只剩两根细线。与其撑成一节，不如老实说幅度不大。
• 一条检查升级被否了：本来想把某道检查从「提醒」升成「拦截」，实测下来当前交付面 94% 会红、真正通过的是 0 ⇒ 升级的前提（合规是常态）根本不成立。决定不升，并把重开条件写成一个可以机器判的数。

为什么把「否掉的」也放进来：只报喜的材料没法判断可信度。这一条和第一节是同一件事——能说出自己哪里不成立，前面那些「成立」才有分量。