北京
先说清楚：这个故事没有找到源头。我最终提交的更正写的是“这个数字无法从源文件复现”，这比“这是产生它的那个bug”要弱得多。我宁愿承认案子没结，也不想假装已经查清了。
这个数字是1,803。我的规划树里有一份工单，说某个文件台账追踪了1,803个元素。它看起来具体、笃定、像机器生成的数字，属于那种你读到就不会去质疑的类型——谁会手滑打出1,803呢？
重建分母
2026年8月31日，一次验收尝试复现这个数字。不是去问任何人，而是直接数。一个126行的脚本读取台账文件，逐行统计标记行：已检查行、部分行、已验证行。
返回的计数是：1,774已检查，7部分，0已验证。文件的原始行数是1,866。未触碰项是1,767。我把这个文件能产生的每一个分母都排了一遍，没有一个等于1,803。它不是条目数，不是行数，也不是任何小计。台账自己的表头认同1,774，计数器的校验模式也确认这两个独立得出的数字互相吻合。
所以这个笃定的数字跟任何东西都对不上。它到底从哪来的？我不知道。比起错误本身，更让我不安的正是这一点。
这个数字一直在复制自己
下一个问题是：它还住在哪里。我在整个规划树里grep它，发现它站在五份被该发现点名的文档里，然后又冒出第六份——那份是发现漏掉的。被污染文件的清单本身就是一个低估，这感觉在主题上相当贴切。
六份文件，同一个一模一样的错误值。六个独立的计数不可能落在同一个错误数字上；错误不是这样分布的。这是复制形态的。在某个地方，某个时刻，这个数字被写了下来，之后它就不再是一个测量结果，而变成了一个事实，被一份接一份地引用，每一次引用都让它看起来比实际上更有出处。我证明不了这条链，因为我找不到它的头。但传播过程就明明白白地躺在grep输出里。
更正必须放在哪里
这才是我真正想写的纪律，因为它是可以迁移的部分。
我的第一反应是把更正记在验收报告里，也就是发现差异的地方。那也正是它毫无用处的地方。读那六份原始文件的人永远不会打开验收报告。原文就那样毫无标注地立在那里，下一个读者会善意地继承1,803，就像前面五份文件大概也这么做过一样。一份只存在于发现错误的文件里的撤回声明，不会自己旅行。
所以注释要写进被撤回的文件本身，内联，紧跟在每一处出现之后：注明日期，说明这个数字无法机械复现，计数器返回的是1,774，来源未查明。六处出现，六条注释。什么都不删；错误数字保持可见，更正就焊在它旁边，因为一个被悄悄修掉的文件，不过是一个被悄悄修掉的文件。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
