数据与排名说明

数据从哪来

三个来源，全部自动抓取，没有人工录入环节：

• npm registry —— 抓取所有带 opencode-plugin 关键词的包，取得包名、版本、描述、协议、废弃状态与仓库地址。
• GitHub GraphQL API —— 按仓库批量拉取星标数、Fork 数、开放 Issue、最后提交时间、归档状态、topic 与 README。
• npm downloads API —— 取近 7 天与近 30 天的下载量。

每天重新抓取一次并重建整站。当前数据快照生成于 2026-08-20， 共收录 1553 个插件、14 个分类。

综合评分怎么算

只按星标排名有个根本问题：星标是累积量，永远偏向发布得早的项目。 一个上周发布、每天涨 50 星的插件，在总榜上可能连前 100 都进不去。所以综合评分混合了四个信号：

score = 0.35 × 计入星标（对数归一）
      + 0.35 × 月下载量（对数归一）
      + 0.20 × 活跃度（最后提交时间衰减）
      + 0.10 × 增长速度（近 30 天新增星标，按体量归一）

已归档的仓库最终得分 × 0.35

计入星标 = min(仓库星标, max(月下载量 × 8, 1000))

几个设计上的取舍：

• 用对数而不是线性。 10 万星和 1 万星的实际差距，远没有数字差距那么大；线性归一会让头部项目碾压一切。
• 下载量和星标同权重。 星标是「我觉得这个不错」，下载量是「我真的在用」。后者更难刷，但会被间接依赖污染，所以两者互相制衡。
• 增长按体量归一。 一个 100 星的项目涨 50 星，比一个 5000 星的项目涨 50 星更值得注意。
• 归档不等于删除。 归档项目仍然可能是当下最好的选择，只是没人维护了，所以是降权而非剔除。

为什么星标要打折

星标属于仓库，下载量属于包。一个插件如果发布自某个大型项目的 monorepo，它会继承整个仓库的星标数 ——@mem0/opencode-plugin 显示 6.3 万星，不是因为这个插件多受欢迎， 而是因为 mem0ai/mem0 这个仓库有 6.3 万星。

不修正的话，榜首会被一批月下载量只有几十次的包占据 —— 我们第一次跑全量数据时， 排第一的包顶着 27 万星、月下载 49 次。

所以星标只按该包自身的装机量所能支撑的程度计入。真正有人用的插件轻松越过这条上限， 只是恰好躺在一个著名 README 旁边的包则不行。下限 1000 是为了不让刚发布、还没有下载量的新插件直接归零。

目前 18 个包触发了这条修正。它们的星标数会照实显示，但标一个*，鼠标悬停能看到实际计入的数值。

其余已知偏差

• 「本周飙升」需要历史数据。 增长指标靠对比每日快照计算，站点刚上线时这一栏几乎是空的，运行几天后才有意义。
• 只收录发布到 npm 的插件。 纯本地插件（放在 .opencode/plugins/ 里的脚本）无法被自动发现。
• 下载量会被间接依赖污染。 如果一个插件被另一个流行的包依赖，它的下载量会包含并非直接使用者的部分。

分类怎么定的

按包名、描述、npm 关键词与 GitHub topic 做规则匹配，命中的第一个分类生效，所以分类列表是有优先级顺序的。 自动分类必然有误判 —— 分错了可以通过人工覆盖层修正，见提交页面。

健康度徽章的判定

哪些包会被排除

一个包必须至少满足以下一条才会被收录：有描述、有 README、有星标、月下载量超过 50、或被人工标为精选。 这条规则会滤掉相当数量的空包和测试发布。此外还有一份人工黑名单，用于处理明显的占位包与滥发。

关于本站

OpenDock 与 opencode 官方没有隶属关系，是一个独立的社区目录。 所有插件数据都来自公开 API，站点本身是纯静态的。

访问统计与隐私

本站使用自建的 Umami（umami.qunqin.org）统计访问量，并按 15% 的比例录制匿名会话回放， 用来了解大家实际在找哪些插件、哪些页面没做好。没有广告、没有第三方追踪脚本，数据不会出售或共享给任何人。

这些脚本在你点击「允许」之前不会加载。首次访问时右下角会出现一个选择框； 选择结果存在浏览器本地，清除站点数据即可重新选择。选择「拒绝」后不会加载任何统计脚本，也不会有使用数据离开你的浏览器。

有一点「拒绝」拦不住：插件作者头像由 GitHub 自己的 CDN（avatars.githubusercontent.com）提供， 只要页面上有插件列表，浏览器就会去请求这些图片。这是显示头像本身带来的，GitHub 看到的请求与你直接访问对应仓库时没有区别。