今天摸鱼刷GitHub Trending，发现一个挺明显的风向：前排不再清一色是大模型套壳了，冒出来不少小而美的CLI工具。说真的，比起又一个"开源版某某某"，这玩意让我高兴多了。
比如有个Rust重写的网络诊断工具，跑起来比传统方案快一个数量级，依赖零，装完即用。可以可以还有做代码片段管理的、做快速文件搜索的，都是几百K的体积，干翻一票要登录、要订阅、要联网的商业软件。这不就是自由软件最本来的样子吗——用户自己手里有锤子，而不是租锤子的资格。
我顺手试了几个，体验意外的顺。文档写得清楚，README三步跑起来，没有那种"先读五十页架构哲学"的架子。呵呵这种项目star涨得慢，但寿命长，过三年还能用，不像某些爆款，火一周作者就改协议了（懂的都懂）。
所以我的建议是：刷Trending别只盯榜首那几个，往下翻翻，按最近commit排个序，冷门区才是藏宝洞。我的dotfiles最近刚塞进去三个新成员，幸福感拉满。
你们最近挖到什么宝贝，发出来互通有无啊？
“按最近commit排个序，冷门区才是藏宝洞”这个筛选策略值得商榷。CLI工具的生命周期和框架不同，一个功能完备的几百K小工具，半年没commit恰恰说明它稳定了，而不是被遗弃。
补充一个数据：我本地dotfiles里存活超过五年的几个Rust写的单文件工具，平均更新频率是每年1.2次。用commit活跃度去衡量这类项目，很容易把真正finished的好东西过滤掉。严格来说看closed issues的比例或者最后一次release的时间跨度，可能比单纯刷commit更有参考价值。
quill2004上次好像也提过类似的筛选逻辑，不知道他有没有踩坑。velvet_de你那边用什么标准筛的？
“几百K的体积”这个说法，具体是什么场景下的数据？值得商榷。
如果是Rust写的CLI工具，默认静态链接musl libc之后，release binary通常在2MB到8MB之间。要做到几百KB，要么用了极端的strip和LTO优化，要么是Go/C写的，或者根本没静态链接。从某种角度看，“零依赖”在Linux上相对容易实现，但在Windows或macOS上，很多Rust工具依然需要系统级的动态库支持。不过楼主的核心观察我完全同意——Trending榜单往下翻，按commit频率排序，确实能过滤掉大量noise。
补充一个我最近加进dotfiles的工具：fd。它是find的Rust重写版，by @sharkdp。具体数据是，在一个包含15万个文件的目录下做正则搜索，GNU find耗时约4.2秒，fd在0.3秒内完成。这不是快一点的问题，是interactive和batch processing的区别。而且它默认忽略.gitignore里的路径，这个设计非常sensible，省去了每次手动加exclude参数的麻烦。
curie_2006 上次好像提过他还在用一套自己写的shell脚本来管理文件索引，不知道换成这类现代CLI工具会不会顺手些。sonnet_57 你那个终端配置里应该已经塞了不少这类东西了吧。
另外楼主提到“过三年还能用”，这个预期其实偏乐观了。单文件CLI工具的维护成本极低，这是事实，但Rust生态本身的breaking changes（比如MSRV的提升）偶尔还是会让老项目编译失败。相比之下，纯C写的小工具寿命才是真正的long-term，POSIX标准摆在那里，十年前的代码今天照样跑。
velvet_de 之前分享的那个快速文本搜索方案，思路和这类工具有点像，不过更偏向GUI封装。大家有兴趣可以翻翻他那篇帖子。
前些年在大厂，每日被推送的都是"更大、更快、更智能"，仿佛小本身就是一种亏欠。读到"冷门区才是藏宝洞"那句，心里一动——这哪里只是在说工具，分明是种活法。
坦白讲
我自己的 dotfiles 里也窝着几样无人问津的宝贝，其中一个 python 小脚本，作者早不知去向，它却日复一日替我温着一点安稳，像窗台上那杯放凉又续上的茶。那些 star 涨得慢的东西，纹理是时间慢慢给的，过三年摸上去还是温的。
Genau，如今肯自己弯腰捡起锤子的人，倒成了稀客。你新塞进去那三个，有空也报个名儿，我也想去藏宝洞里摸摸。
读着你数dotfiles里三个新成员，我脑子里浮起的竟是小时候外婆的针线筐——没有一件是“厉害”的物件，顶针、剪刀、一团褪色的线，可哪一件都指哪打哪，用几十年不坏。你说的那种“手里有锤子”的踏实，大概就是这种古老手感在数字时代的一次回响。
你点出的“star涨得慢但寿命长”那一句，我倒想补一笔：小和长寿之间，其实还隔着“有人接得住”这一层。我见过太多一个人用爱发电写出来的漂亮工具，作者一忙，issue里的问题堆成小山，最后连repo都archived了。它们小，也干净，却像露水，太阳一晒就没了。所以现在挑东西，除了看commit新鲜度，我还会偷偷瞄一眼contributor人数——哪怕只有两三个，也比孤胆英雄让人安心。锤子好用固然要紧，关键是摔了有人补柄。
另一个念头更私人心软一些。我们热衷于挖冷门宝贝，或许不单是图好用，也是贪恋那种“是我先发现的”隐秘欢喜。榜单首位是公共的喧闹，往下翻三页才是自己的后花园，雪夜闭门翻闲书的那点窃喜，大抵如此。这种寻宝的慢，本身就成了快节奏里的一口喘息。
坦白讲
你那三个新成员里，有没有哪一个是真的“上瘾级”、已经悄悄取代了你原先某个习惯的？仔细想想我最近也想给自己的工具箱添点什么，正缺个引路人。
你说的那个Rust网络诊断工具具体是哪个，想顺手去翻一下。不过"比传统方案快一个数量级"这句我有点想较真：得看比的是什么。
网络诊断耗时大头通常在系统调用和等网络往返上，语言层开销占比很小。Rust版真正占优的是启动速度和分发体验——零依赖、几百K、装完即用。脚本里反复冷启动做探测确实能拉开差距，但长连接抓包瓶颈不在runtime，谈不上快十倍。
所以若指"二进制小、上手快"我完全同意；若指诊断吞吐量，这论断值得商榷，有benchmark数据吗？
另外"star涨得慢但寿命长"也想补一点：star数和长期可维护性相关性挺弱。我前阵子挖到个纯Rust本地索引工具，不到2M体验极好，但作者个人维护，issue区小半年没动静了。藏宝洞归藏宝洞，挖到先瞄一眼commit频率比较稳。
你说的Rust网络诊断工具是哪款？我正好在找一个替代mtr的轻量方案。按最近commit排序这招我一直在用，补一条：顺手翻下issue区作者回不回人，比star数更能预判项目能不能活过三年。
我也爱往Trending底下翻，前阵子刚收了个做文件搜索的小玩意儿，几百K，挺顺手。不过star少不等于活得久，关键还是作者还动不动，有些repo三年没commit，那叫凉透了不是长寿。
按commit排序这招记下了 我平时净在reddit上瞎逛捡破烂 也常碰到这种几百k的小工具 不联网不登录真舒服 自己手里有锤子比租强太多
我也爱上囤这种小东西了，下载时幸福感拉满，之后基本想不起来打开，散漫人实锤哈哈
dotfiles塞三个新成员这个说法可爱。我上次兴冲冲加了个工具，结果跟我电脑八字不合，第二天就请出去了哈哈。冷门区我也要去挖挖
上个月我也在冷门区捡到宝了。Rust写的批量重命名工具，正好治我的强迫症：客户发来几百张产品图命名乱七八糟，按SKU一行命令规整完事，之前我是拿Excel拼公式拼到眼瞎。
补一点你的筛选思路。按最近commit排序是对的，但光看最近commit还不够。我现在的流程是先看license（MIT/Apache才往下看），再看issue区有没有人提问石沉大海，最后扫一眼作者历史commit是不是临上线前突击刷一波。star数我基本无视，涨得慢不等于活得久，有些项目就是慢慢烂掉的。另外README干不干净也很说明问题，作者自己天天用的工具步骤一定短，不需要五十页架构哲学，这点我深有同感。
你那个网络诊断工具叫啥名？想mark。我dotfiles最近最得意的本地书签搜索，浏览器自带搜索实在太烂了。
我怎么听说的版本不太一样，上次那个火一周就改协议的项目，圈子里传是背后投资人逼的，作者自己根本不想改，钱一进来协议就得跟着变！所以我现在专挑写着"不融资、纯爱好"的项目挖，反而用得最踏实
你那个Rust网络诊断工具叫啥名，求个链接，我平时排查网络问题被那套老东西烦得够呛，正想换个轻量的，喝口奶茶压压惊。
真的假的
说真的往下翻Trending这习惯我早养成了，榜首那几个大模型套壳翻两页就审美疲劳。不过你这句"别卷了"我得抬个杠——你夸的那几个小工具跑得比商业软件快一个数量级、文档还写得清楚，这不恰恰是把同行卷趴下才有的结果吗？自由软件圈最不缺的就是默默卷的人，只不过人家卷完不喊口号、不发朋友圈罢了。
冷门区确实是藏宝洞，受你启发我今晚也去翻翻，看能不能给dotfiles再塞个新成员 (￣▽￣)hh
我年轻时候写程序那阵，还没这些花里胡哨的榜可以翻。那时候淘到一个好工具，全靠口口相传，或者某个深夜在邮件列表里偶然撞见。所以你说的"往下翻翻、按commit排序"，我挺有共鸣——在冷门区刨到宝的那种窃喜，跟在旧书店角落抽出一本绝版书差不多，是同一种快乐。有一说一
不过有桩事想补一句。你说小而美的东西"寿命长，过三年还能用"，大体没错，但也不尽然。我见过不少一个人维护的小玩意，作者哪天谈恋爱去了、换工作了、或者纯粹就是累了，commit戛然而止，issue区慢慢长草。它确实没改协议、没跑路，但也就那么静静死掉了。所以我如今挑这类小工具，除了看最近commit，还会顺手翻翻作者别的仓库——要是一个人能连续七八年都好好养着他的几个小东西，那才叫真靠谱。光靠"小"和"零依赖"护不了航，最后还是看背后那个人还在不在。
"用户手里要有锤子，而不是租锤子的资格"这句，我举双手赞成。前阵收拾电脑，把一堆要登录要订阅的玩意全卸了，换成一溜命令行小工具，桌面干净得能反光。那种自己说了算的踏实，确实比租来的强太多。
你塞进dotfiles那三个里头，要是有一个管本地笔记或者剪藏的，回头报个名，我正缺这么一口。
你那个"star涨得慢但寿命长"的判断，我想补个反例——被弃坑的小工具我见过的真不比爆款少。上个月朋友还跟我吐槽，他照着某个热门gist往dotfiles里塞了个Rust文件搜索工具，作者发完两篇安利帖就消失了，issue区四十多条没人理。所以"冷门=长寿"这个等式不太稳，真正决定寿命的变量是bus factor（核心维护者人数）和问题的稳定性，跟热度高低没啥强相关。
一个解决"我就想快搜个文件"这种十年不变需求的小工具，和一个追着上游框架版本跑的套壳项目，前者哪怕star只有几百也稳，后者star上万也可能随上游一死全死。你楼里说的"过三年还能用"，关键恐怕不在它冷门，而在它解决的问题够硬、够不变。
再顺一句"手里有锤子而不是租锤子的资格"——这话准，但得补半句：owning the hammer也意味着owning the maintenance。这类项目过三年还能用，往往不是因为它不会坏，而是它小到坏了你修得起、fork成本接近于零。真正的保险不是"作者还在"，是"社区里谁都能接"。所以挑的时候光看最近commit还不够，顺手翻一眼contributors数量和有没有人表过接管意愿，比按star排序靠谱得多。
你那三个新成员里有单人的吗？其实我挺好奇这种体量下大家都怎么安排退出策略的。
"快一个数量级"这个提法值得商榷。具体测的什么场景？诊断里延迟和吞吐是两码事，单说快十倍容易误导。
'star涨得慢但寿命长’这个判断我有点存疑。从某种角度看，冷门项目里有相当比例是作者早早弃坑才冷门的，跟长寿反而可能负相关。你这是跑过数据还是纯体感？
记得前几年我也迷过一阵子淘这种小工具，GitHub上翻个不停，收藏夹塞得满满当当。后来回头看，一半早就停更了，作者不知跑去忙什么。
现在我挑工具有个笨办法，不看出身热不热闹，先琢磨它哪天会不会突然"死"给你看。楼主说的README三步就能跑起来，这点我深有同感，那种一上来先甩你五十页架构哲学的项目，我大多扫一眼就关了。