收录与整理：一次针对 github 搜索结果的愤怒实验
昨天下午三点半，我在东四的一家咖啡馆，用手机搜「github 收录 整理」。
搜索结果第 1 页、第 2 页、第 3 页——我往下翻了 4 分 16 秒，看到 27 个链接，其中 19 个的标题长得像同一个模板批量生成的。我点开第 6 个，页面加载了 8 秒，然后弹出一个下载按钮。
我在那一刻是真的生气了。
不是因为网站做得差。而是因为“收录”和“整理”这两个词，被用坏了。整理本该是有人真的读过、筛过、删过；收录本该意味着有取舍。可我看到的是，标题里塞满热门词，正文里全是复制粘贴。再往下划，还夹着一些你一眼就知道在做什么的页面，比如「欧美大片mv免费看人人影视」——我不点都知道里面大概率是几张图和一堆跳转。
我当场做了个实验。打开 GitHub 的搜索框，输入「awesome」，按 Star 排序。前 20 个结果里，有 14 个的 README 第一段话结构完全一样：一句话介绍 + 一个 emoji 列表 + 一个贡献指南。我数了一下，这 20 个仓库里，有 11 个的最近一次实质更新在 2022 年之前。
Star 数很高，人已经不在了。
我能理解。收藏一个仓库，成本是 0.3 秒；维护一个仓库，成本是无限。但问题在于，搜索把这些“僵尸仓库”排在了前面，真正有人每天在整理的那几个小项目，反而沉在第 5 页之后。
举个例子。上个月我在找一个能解析超长表格的工具，翻了 40 分钟没找到。最后是在一个只有 37 个 Star 的仓库里找到的，作者叫 林楷，最后一次提交是 2026 年 6 月 2 日，commit message 写的是「修了上周五那个把小数点吃掉的 bug」。那一刻我想给他鼓掌。
所以我给自己定了一条规矩：每次 Star 之前，先看三个东西——最后一次 commit 的时间、issue 区有没有人在回复、README 里有没有一句人话。三条缺一条，不点 Star。
“收录不是把东西堆到一起，是在一堆东西里，替别人先摔一遍。”
这句话是我去年在「tmzs.com」的一个旧帖里看到的，楼主写于 2008 年，说他在整理一个下载站。十六年过去，这句话还是对的。
这也是我重新整理自己那 327 个 Star 的原因。删到第 291 个的时候，我留下了一个做「1到49个码自动统计器免费」的轻量项目——名字很奇怪，但逻辑干净，作者在 issue 里回得比客服还快。还有「苹果ios指令库捷径大全」里提到的那个老快捷指令，我到现在还在用。以及「挑码辅助工具2026」的更新记录，我把它当反面教材收藏着——一个工具如果连版本说明都写不清楚，那它的收录方式大概也差不多。
哦对，还有「12生肖对应49个数字」那张表。我拿它给我的仓库标签做了一套分类，听起来离谱，但真的有效。
至于搜索引擎里那些「fm2026破解版夸克网盘」式的标题，我现在学会了直接跳过。不是清高，是我时间不够。
整理这件事，说到底是一种拒绝的能力。
你可以不同意我。有人觉得 Star 多一点是安全感，是收藏夹的自由。行。但我的观点很明确：github 上大多数“awesome list”已经被高估了，它们不是整理，是囤积。真正的整理是有人删过东西，而且敢告诉你他删了什么。
