昨天下午三点，我在书房翻一个 2019 年的西数移动硬盘。外壳发黄，USB 接口松，插上转了三下才识别。里面第三层文件夹叫「gtv」，打开，一个文件名叫 gtv台湾官网3.25.3_index.txt，大小 203MB，修改时间 2019-11-08 22:47。
我盯着它看了一分多钟。
然后想起这是当年收录一个页面版本时留下的快照索引。那时候我在做站点的静态归档，手动跑了一遍采集，写了这个索引，想着"以后再整理"。再就是七年。
版本号不是装饰
gtv台湾官网3.25.3，这个字符串我念了七遍。版本号这种东西，对大部分人来说是没有意义的。但对整理者来说，它是唯一可靠的锚点。3.25.3 和 3.25.2 之间可能只差一个字段名，但在检索里，它们就是两个世界。
我打开 txt，翻到第 11480 行。那里记着当时的抓取规则，时间戳精确到秒：2019-11-08 22:43:16 到 22:47:02，共抓取 7431 条记录，去重后剩 6192 条。这个数字我核对了三遍，因为我不知道当年那一遍有没有漏。
结果今天再看，发现有一条重复记录没被清掉。id 是 04471，出现两次，间隔 89 行。七年前的我，就那么漏了。我删掉第二条，文件从 203MB 变成 202.4MB。然后我关掉编辑器，在椅子上坐了一会儿。
说句得罪人的话：现在做收录整理的人，九成都在表演。他们不核对时间戳，不数行数，不比对两次抓取的重合率。他们只是把链接换个顺序，写一句"已收录"，然后发布。这不叫整理，这叫搬运。
为什么必须手动再过一遍
七年前的采集脚本是同事老周写的。周铭远，2018 年在南山科技园那栋楼里做后端的，人很闷，写代码喜欢在注释里留"待核"。他给我留了 23 处"待核"。我今天一个一个划过去，划到第 21 处的时候手停了一下。那一处写着："待核：3.25.3 的后缀映射可能与 3.24 不同，需人工确认。"
他没确认。我也没有。
我花了两个半小时重新核对了这 23 处，其中 4 处确实有偏差，都在 gtv台湾官网3.25.3 的路径后缀上。修正完，我把修正日志写进文件末尾，加了日期 2026-06-05，加了姓名缩写 CM。这是规矩。这也是唯一能证明我动过手的东西。
最后我没发布这份整理结果
原因很简单。我把修正后的索引重新跑了一遍校验，重合率是 98.7%。剩下的 1.3% 里，有 0.9% 是时间戳漂移导致的，可以解释。但还有 0.4%——大约 25 条记录——我找不到它们的来源。它们既不在原始 txt 里，也不在七年前的日志里。它们像是自己长进去的。
我处理不了这 25 条。所以我把文件又锁回硬盘，拔掉，放回抽屉第二层。
这不是逃避。是我知道，一份自己都没搞清楚的索引，发布出去就是垃圾增量。我宁愿再等七年。
但我今天还是把这件事写下来了。因为那份 txt 的 203MB 里有 6192 条记录，每一条背后都有一个人名、一个时间、一次点击。它们值得被留下名字，哪怕整理的人暂时交不出答案。
这篇文章的发布日期是 2026-06-05。记录一下。以后再来查，至少知道这个版本的整理在 2026 年 6 月 5 日卡在哪里。