Star 之后呢？把 GitHub 当知识库用
我之前统计过自己的 GitHub 账号，Star 了两百多个仓库。然后某天想找一个"之前看到的很好用的 JSON 格式化工具"，翻了十分钟 Star 列表，没找到。最后去搜索引擎搜出来的，还是当初 Star 的那个。
Star 完就忘，等于没 Star。这篇聊聊怎么把 Star 列表变成真正能用的知识库。
为什么 Star 等于没收藏
GitHub 的 Star 列表有两个硬伤：第一，它是按时间倒序排列的，你 Star 得越多，找东西越难；第二，它没有任何分类，一个前端框架和一个爬虫脚本混在一起，三个月后你根本想不起来当初为什么 Star 它。
所以第一步是承认：Star 只是"暂存"，不是"收藏"。真正的收藏，需要你自己再加工一遍。
第一步：给 Star 分门别类
GitHub 自带了 Lists 功能，可以把 Star 过的仓库放进不同的列表。我的分法很简单，按用途分，不超过六个：
- 工具：日常会用的小工具
- 学习：想系统研究的技术和项目
- 参考：写代码时可能要翻的实现
- 灵感：有意思但暂时用不上的
- 待读：还没细看，先占个位
分类不用一次到位。每个月花十分钟，把新增的 Star 归归类就行。关键是"用途导向"——分类标准是"你将来会在什么场景下找它"，而不是"它是什么技术"。
第二步：定期"翻牌子"
收藏夹和冰箱一样，不定期清理就会塞满过期食品。我每个月会做一次 Star 回顾：
- 已经用过、吃透了的：取消 Star，或者移到"已掌握"列表
- 过时没人维护的：取消 Star，不留恋
- 当初随手点的、现在看不出价值的：取消 Star
别心疼。Star 列表的价值在于"找得到"，不在于"数量多"。两百个找不到的 Star，不如三十个随手能翻出来的。
工具之外：Lists 不够用怎么办
GitHub 自带的 Lists 够轻量，但如果你 Star 得太多，或者想加更丰富的备注，可以考虑外挂一层自己的系统。我的做法是维护一份简单的笔记文档，按领域记录：项目名、一句话用途、Star 日期、当前状态（在用 / 待研究 / 已过时）。
这份文档的好处是搜索快，而且不受 GitHub 界面限制。每月回顾 Star 列表的时候，顺手更新这份文档，十分钟搞定。工具不重要，重要的是"有一个你找得到的地方"。
第三步：从收藏到输出
这是最关键的一步，也是大多数人缺的一步。我的做法：
给重要的项目写一句话备注。 为什么 Star 它？解决什么问题？记在自己的笔记里，下次看到这句话立刻能想起来。
用过之后写总结。 比如之前为了搭博客研究过几个 Hugo 主题（《GitHub Actions 入门》 里提到的自动化部署就是那时候折腾的），每个试用过的主题我都记了优缺点。现在换主题，五分钟就能决策。
攒自己的清单。 把某个领域的优质项目整理成一份清单，公开发出来就是 awesome-list。整理的过程本身就是学习，而且公开之后还会有同好来补充，越滚越大。
写在最后
工具的价值不在于"拥有"，而在于"用起来"。GitHub 是个巨大的知识库，但默认状态下它只是个仓库——把"仓库"变成"知识库"的那一步，得你自己走。
从今天开始，每次 Star 之前先问自己一句：我是真的需要它，还是只是觉得"好像有用"？光这一个问题，就能帮你过滤掉一半的无效收藏。