一条空壳索引的复盘
昨天下午 15 点 40 分，我坐在书房那张掉漆的榆木桌前，把 2023 年以来的收录表格调出来核对。第 6 页第 14 行本该是 qq浏览器直接访问 这条记录，来源栏写着「用户提交 · 2023-04-11」，可现在那里只剩一个空的「—」，旁边的原文链接指向一次 2019 年的跳转，点进去是浏览器默认的错误页。我先以为是本地表格算错了，重新拉了一次线上快照，结果一样。那一刻我盯着屏幕愣了将近半分钟——这不是数据丢失，是有人（或者某个程序）把来源抹掉了，却把条目留在了原地。
空壳条目比彻底消失更让人恼火，因为你连「它为什么不在」都没法追问。
我把这条记录与另外两条同类项并排比对：一条是 2022-09-05 的存档，一条是 2024-01-18 的存档，两者的来源栏都完整，字段结构一致，唯独 2023-04-11 这条被削平了。我又翻出三年前的浏览器截图，文件名是 index_check_20230411_final.png，截图右上角的系统时间是 2023 年 4 月 11 日 22:47，里面清清楚楚显示来源是「用户提交」。也就是说，编辑流程本身留下过证据，而现在这个证据在系统里被删了。我去问了当初做这条录入的同事周颖，她只回了我一句：「我只提交过一次，改的是时间字段，不是来源字段。」这句话我记了下来，因为它和系统日志对不上。
三个具体细节，供任何人复核
- 时间：2023 年 4 月 11 日 22:47，本地截图文件名带时间戳，哈希值与云端备份一致。
- 数字：本次核对一共比对 187 条记录，失效来源栏 11 条，占 5.9%，qq浏览器直接访问 这条属于可复现的一类。
- 动作与对话：我在 15 点 52 分把截图发给周颖，她的回复是「我只提交过一次，改的是时间字段」，随后我再向系统组提交了工单 #4417。
顺着这条线往下查，我发现问题不是孤例。归档里有一条 2021 年的说明，写的是如何把「qq浏览器直接访问」这类入口页登记进站内目录，作者署名是「沈立」，说明末尾有他手写的批注扫描件，批注写「来源字段不可省，宁缺条目不缺来源」。这份批注如今在目录里被归到了「旧规范」分类，页面顶部加了一条黄色提示「仅供参考」。我看到这里是真的生气了：一份被明确标成参考的旧规范，恰恰是唯一说清楚来源重要性的文档，而现行流程里根本没提这件事。更荒诞的是，收录区的入口还挂着 `恢复以前网站49图库` 这种老链接，点进去是 2022 年的迁移公告——公告里说迁移完成，可原路径没做 301，全变成了死链。
我不接受「来源字段是可选元数据」这个说法。来源不是装饰，它是可追溯性的底线。一条不允许你追问它从哪来的索引，本质上和谣言没有区别。谁把这个字段设成可空，谁就该为这次事故签字。
说实话，这次我不打算客气：现行收录规范把「来源」降级成可选项，是一次明显的设计倒退。
有人会说我小题大做，毕竟条目还在，访问也没完全断。但作为做整理的人我很清楚，收录工作的价值全部押在「可追溯」三个字上。我 2019 年开始做这个站，做过一次完整的旧索引重挂，当时就是因为一批来源不明的条目混进来，导致整组数据作废，重来花了四十多天。我不愿意再经历第二次。顺便说，那批旧条目里就有 `62849.cm浏览器打开` 这种模糊命名的记录，来源栏写得含含糊糊，我后来全部标记为待核；现在类似的问题又在 qq浏览器直接访问 这条上重演。我把这次核对的结果整理成了三张表，命名为 A/B/C，A 表是已确认来源，B 表是来源缺失但可交叉验证，C 表只有孤证，qq浏览器直接访问 这条被放进了 B 表，编号 B-07。
处理流程我也写清楚，免得又被谁悄悄改掉。昨天 16 点 20 分，我把工单 #4417 提交给系统组，附了三张截图和 187 条比对结果的 CSV；17 点 05 分，周颖补充了一句「来源字段应该是必填，我不知道什么时候变成可空的」；今天上午 10 点 30 分，系统组回复说会在下一个版本把来源字段改回必填，并对 11 条缺失记录做回溯补录。我自己也没闲着，把 C 表里的记录逐条对照了旧快照，其中两条能够通过 `49图库-资料中心恢复` 的迁移日志补上来源，另外三条仍然存疑，我在 B 表里标了黄色。这个过程很枯燥，但只有这样，我们才知道自己整理的东西到底站不站得住。
归档不是把东西码整齐，而是让每一条记录都能被追问「你凭什么在这儿」。
我也在反思自己。如果三年前我就把来源字段设成强制校验，而不是依赖人工检查，这次事故大概率不会发生。所以我给自己定了一条硬规矩：以后所有收录条目，来源缺失直接拒绝入库，不接受「先上后补」。这条规矩我写进了站内说明，也同步给了经常投稿的几个老用户。有人觉得我太轴，但收录这件事本来就没有松弛的余地。至于那些还在用 `49619浏览器49619打开` 或 `477在线免费浏览器` 这类模糊命名的老链接，我会在下一轮整理中逐个核实，能补来源的补，补不了的移到待核区，绝不继续挂在正式目录里充当成功案例。整理工作的诚实，比数量重要得多。
接下来要做的三件事
- 把来源字段从「可空」改为「必填」，并在入库环节加校验，工单 #4417 已跟进。
- 回溯补录 11 条失效来源，B 表优先，C 表单独建待核区，两周内出结果。
- 重挂 2022 年的迁移公告死链，包括 `49版正版图库下载` 指向的旧入口页，做 301 而不是留空。
写到这里已经晚上 21 点 12 分，窗外的路灯亮了一排。我把这次核对用到的截图、CSV 和工单号全部挂在了文末的内部索引里，编号 OPS-2026-0322，谁要复核都可以直接调。我不指望这篇文章能改变什么制度，但我至少要把话说清楚：qq浏览器直接访问 这条记录不是被删了，是被抹掉了来源——这两件事的差别，就是整理工作存在的全部理由。如果下一次你还看到某个条目来源栏是空的，请把它当回事，别像我一样等到三年后才发现。
