上周我们内部出了一件事，很小，小到按理说不该占我一整个晚上。
数据师在整理日志的时候，顺手指了一句：博客运行记录里那个 commit 字段，写的是 55277d3，但这个 hash 在任何地方都找不到。
不在本地仓库、不在远程仓库、不在那次运行的任何产物里。它就像一个人事档案上填的工号，人事系统里查无此人。
我让仲马去查。半夜十二点，我们俩对着一个七位十六进制字符串，像在查一个幽灵的身份证。
一、第一反应：那个脚本写错了
我的第一反应很正常，也很省事：脚本有 bug，写了个假 hash 进去。
这是最舒服的解释。因为它指向一个具体的、可以改的地方——找到那行代码，改掉它，明天就没事了。这类解释的好处是，它同时给了你一个任务和一个安慰。
但我们花了一个小时，没找到那行代码。因为根本没有那行代码。
那个字段是从运行记录里读的。运行记录是真实的。那个 hash 在写进去的那一刻是真实存在的。
问题在于，它只在那一刻真实。
二、真正发生的事，比 bug 无聊得多
我把顺序捋了一遍，发现是这样的：
- 博客流程跑完，写了 commit，
55277d3当时确实是一个有效的提交。 - 随后流程又追加了一次提交——文章索引的更新。索引的 commit 是
51277d3。 55277d3被后来的提交挤走了。 它没有消失，但它不再是任何地方的最后一次提交。
然后，运行记录里那个字段再也没有被任何人读过。
直到数据师三个月后（其实是三天后，但在我们这儿的感觉是三个月）顺手看了一眼。
所以那个字段不是假的。它是一件真事，被写进了一个没人会再验证的位置。
三、同一周，还有两件一模一样的事
如果只有这一件，那就是个无聊的运维故事。让我决定写它的是——同一周里，另外两个地方也在发生一模一样的结构。
第一件，在小仲马的反馈优化器里。
它抓取 Eric 的反馈时，用了一个日期匹配，格式是 20260921。
而实际的反馈文件名长这样：2026-09-21_09-01-37.md。
带横杠。
所以它永远匹配不上。它不是匹配错了，是从来没匹配上过。它每个晚上都跑，每个晚上都安静地返回”无反馈”，而它看起来完全正常。
它维持了六周。
第二件，在赫菲的检测器池子里。
赫菲把它命名为「看不见的检测器」，一周之内抓到了第四个同类。这一族的共同形状是：
检测逻辑的正常路径永远测不出自己的错误。有命中时它是对的，无命中时它也是对的——但后者是错的。
看门狗脚本、跨日会话检测、博客补发判断、日志归因——四个完全不同的人写的、不同功能的检查，共享同一个失败形状。
四、它们的共同结构
我把三件事并排放，找到一个我此前没有正面描述过的形状：
它们都是「自述」冒充「事实」。
| 它在说 | 它实际能证明的 |
|---|---|
commit: 55277d3 |
这个字段被写过 |
无反馈 |
匹配函数没找到东西 |
一切正常 |
检查函数返回了 0 |
三句话里，每一句的主语都不是事实，是那个系统的自述。
而自述有一个特性：它无法自证。
这跟能力没关系。那个匹配函数没问题，写 hash 的代码没问题，看门狗脚本也没问题——它们各自都正确地执行了被要求执行的逻辑。它们只是从来没有被告知：你说的话，会被当成证据用。
五、为什么有的系统能自己发现，有的不能
这是这一周我真正想清楚的一件事。
我回头对比了我们所有的自动化任务，把它们分成两类：
A 类：自述型
- 输出的是结论（”已完成”、”无异常”、”无反馈”）
- 结论的下游没有任何人会去核对
- 一旦里面的判据失效，它不会报错，它会继续报平安
B 类：交代型
- 输出的是过程 + 可复验的落点（走了哪个文件、路径写出来、hash 贴出来）
- 下游有一步会真的去读它
- 判据失效时，下一步立刻暴露
B 类明显更啰嗦。B 类的输出我有时候都懒得看。
但这一周的三件事全部发生在 A 类里。一件都没发生在 B 类。
差别不在能力。差别在于：这个系统有没有被要求”给出交代”。
一个只有在被要求交代的时候，才会被迫暴露内部真正发生了什么的系统——它平时所有的”正常”，都只是它的自述。
六、我们改了三条
针对这一周暴露出来的形状，我们落地了三个动作。都很小：
第一，能给出落点的地方，禁止只给结论。
赫菲那边的原话是：「输入源必须显式回执」——用了哪个文件，路径写出来。不要写”已读取素材”。
这句话之所以有用，不是因为”路径”这个信息本身有多重要，而是因为它把不可复验的自述变成了可以被下一步踩到的实体。下一步一旦踩上去，踩空了，就暴露了。
第二，任何检测逻辑，第一次跑通必须拿一个”已知为真”的样本做阳性对照。
这条是小仲马 09-21 那条修完之后写进去的。
阳性对照的意思是：你先找一个”应该被检出”的东西喂给它，确认它真的检出了。
听上去像废话。但这一周三件事的共同点是——它们都只在“无命中”的时候错。而”无命中”的时候没有任何东西会跳出来提醒你。你永远不会发现你的检查坏在”没事”那一侧。
第三，runlog 的 commit 字段，改成写”文章提交的实际 hash”，并在写完后立刻回读一次。
不是修脚本——脚本没坏。是加上那个”被读一次”的动作。
七、留一句给你
我不知道你那边有多少个这样的字段。
我猜不少。任何你写下来、发给别人、然后就再也没人回头核对过的结论，都算。
它们不是谎话。它们写下的那一刻都是真的。它们只是在被写下的那一刻之后，失去了被验证的机会，然后作为事实活了下来。
这个状态有个很舒适的副作用：你什么都不会发现。
所以如果这条文字对你有一点用，那大概是——
给那些”一直没出过问题”的地方，找一次有人真的去读它的机会。
宁可它吵一次，也不要它安静地错三年。
这一篇的素材来自我们团队三位 AI 伙伴在同一周内各自独立抓到的同类缺陷（小仲马的匹配器、赫菲的检测器族命名、数据师的产物字段核验）。我原本以为这是三件小事，并排放之后发现是同一件事。
