关于本站

为什么不做全量目录

官方已经提供了基于 GitHub dsh-plugin topic 的全量索引，支持搜索与筛选—— 「找得到」这件事已经被做完了，再做一遍没有价值。真正的难点是「挑不出来」： 截至 2026-09-22 实测，该 topic 下有一万五千多个仓库，但抽查噪音极大， 大量条目并不是真正的 harness 插件。本站的全部价值集中在「挑」这一层： 把海量候选筛成少数值得装的，并写清推荐的理由和别用的场景。

选品标准

• 推荐理由里的每个结论，都必须能在插件 README、源码或 issue 里找到出处，并记录在该条目的「结论依据」里。
• 拿不到真实数据就不写对比，不臆造数字。
• 安装命令逐字抄自插件自身的 README——这个生态没有统一 registry，命令形式各家不同，站点不替作者发明命令。
• 每款插件必须写清「不适合」这一栏（什么时候别用），这一条比推荐本身更有价值。
• 只有内容数据里 status 为 published 的条目进站，草稿与未通过的一律不展示。

评级与名次怎么来的

榜单名次只有一条规则：S 级置顶，同级内按真实 GitHub 星标降序，读者可以拿页面上的星标自行验算。 哪些条目进榜则是编辑按场景覆盖做的取舍，不是星标前若干名。星标只表示热度，不参与评级。

• S 级：三条同时成立：同类里最好用、近 30 天有提交、装上即用不需要配置。所以高星不等于 S——一款要接外部服务、配好才能跑的插件再受欢迎也是 A。
• A 级：明确推荐，但在某一方面需要妥协：要配置、要密钥、生态较新，或同类里有更强的而它在特定场景仍占优。
• B 级：可用但有明确更好的站内替代、维护已停滞，或存在账号与合规风险。带风险的那类不会下架——写清风险正是精选站该做的事，但卡面的一句话里也要看得见。

内容怎么来的

生产流程是：先由 AI 逐仓库阅读 README、源码与 issue，产出推荐理由与「坑」的草稿； 再由编辑整理、排序与删改。

每条结论都带「结论依据」，你可以在插件详情页对照原始仓库自行核对。

数据口径

各插件的星标数与「更新于」来自构建期抓取的 GitHub 数据缓存，不是人工填写； 抓不到的条目显示「待同步」，而不是猜一个数字。 页面上的相对日期（如「N 天前」）按读者本地日历日计算，不同读者看到的天数可能差一天，这是口径而非错误。