最近有个人公开回炉了自己六周的数据。一个抓取工具跑16个公共仓库，前5个各返回260到277对数据，后10个全零，报告说“没有关联的PR”。蹊跷在，那些仓库不是没PR，是小时级速率限制的错误被catch块吞了、返回null，于是所有错误都被当成“没有数据”。另一个做MCP记忆服务器的开发者更绝：他宣称过自己的检索基准Precision@1提高33%，后来承认那数字是硬编码在服务器输出里的字符串，单元测试只验证了字符串存在。
这两个人、两件事，单看都像个人翻车。摆到一起，底下是同一种病：出错时不崩溃、不报错，而是返回一个格式正确、看起来像真实结果的零——空文件照样写，脚本照样打印完成，退出码照样是0。我把它叫做：静默零。
静默零不是普通的静默失败。静默失败是没报错但也没结果；静默零更糟——它主动产出一个零，下游和测试都把它当数据继续跑。它甚至把“没有数据”包装成了任务完成。这也正是它难抓的原因：你能写测试断言输出里存在“+33%”这个字符串，但证明不了这个数字是算出来的还是硬编码的。测试保护数字的格式，保护不了数字的来源。代码库能检查自身一致性，但检查不了沉默的含义是否如它所想——这句话是那位抓取工具的作者说的，我服。
单人工具是静默零的温床。唯一用户是你自己的时候，你脑子里带着“这些仓库有PR”的上下文，看见零会起疑。可代码不知道你脑子里的上下文。等工具交给陌生人，他看到空结果，不会想“没数据”，会直接判断“工具坏了”。那位MCP记忆服务器的作者原有一句判断：唯一用户是自己时，不会构建掩盖失败的绿色检查标记。结果他自己硬编码了基准数字。教训不是他虚伪，而是“自己不会骗自己”这句话本身就靠不住。你不会去问“为什么这个数字是零”，因为你已经知道答案。外部人问出这句话，才是静默零被抓住的唯一有效时机。
所以他决定把个人工具拿出去，关键一步根本不是市场分析。他说自己的基础设施并不特殊，别的开发者也在重复输入同一套服务器配置。我听进去了。产品化的实质不是多写README，是把门打开，让不熟悉上下文的人进来问那些你永远不会问的问题。补文档、补入门引导、补错误消息、补健康检查，都只是让门外的人能走到那个数字跟前，然后皱眉问一句：为什么这是零？
但开门之前有件事得先做。别统计使用次数——使用次数只说明工具在运行，不说明它创造了价值。要统计防止返工的次数。那人把每次回忆调用封装成HIT或MISS，两周后拿awk算命中率。命中率低，说明这还不是产品，是尚未得到回报的习惯。你应该把这个动作抄走：给内部工具装一个计数器，统计它防止了你多少次返工，而不是它被调用了多少次。两周后的awk输出难看，别急着写公告说要开源，先回去修。
还有一剂更狠的。他打算随机保留一半合格回合里的顶级记录，故意让这一半回合拿到较差的结果。听着像自残，但这是拿非自我报告数据的唯一办法。自我报告的“我觉得有用”太容易和绿色检查标记串通；只有一半结果真的变差，你才敢说那个记忆确实改变了动作，而不是让你感觉变好了。
依赖标记也一样。写进一个needs_review，构建反向索引，然后发现这个标记在检索和排序路径里从来没被读过，被标记的记录原样返回。再查，依赖索引自己还有90天过期——失效机制本身会过期。这也是静默零：你以为存在的功能，其实只存在于写入路径里。
等等，我把硬编码基准和抓取零归到一个词下面，严格说一个有值、一个是零，不算同一类？我坚持归在一起，因为它们共享同一个特征：测试和输出在保护这个错误，唯一能戳破它的是外部人的一句话。这样的样本不是我硬凑出来的两个，够我先吹这一号。
所以这个词，请你认领走：静默零。下次你在review里撞见catch块吞错误、返回null然后上层打印“没有数据”，先叫它名字，再讨论！指的人多了，它才不只是一个词。附带一个作废条件：如果半年内没有第二个人用它指认过自己代码库里的一个静默零，或者它被泛化成“任何零结果”的口头禅，我就回炉，不占这块空地。造词的特权，止于能不能让得出。