dsh-plugin-index

dsh plugin --profile web add dsh-plugin-index

dsh-plugin-index

在 DSH 里浏览第三方插件，一键安装。

市面上已经有不少 DSH 插件目录，它们失败在同一个地方：用热度代替证据。我抽样验证过其中一个头部目录——被它标为「可用」的 79 条里，有 15 条根本不是插件（在默认按星数排序的顶部，这个比例高达 38.5%）。混进去的有图床客户端、Claude Code 生态的成本工具，甚至目录站自己。

这个插件反过来做：只认 package.json 里的 dsh.bundle.patch 字段。

官方文档明确写着：包名、patch 的文件名都只是惯例。所以任何靠名字、靠星数、靠关键词的判定都会有系统性误差。唯一权威的判据就是那个字段。

---

它长什么样

在 DSH 里：设置 → 插件 → 插件索引

• 收录 1 万余个经校验的插件（还在持续增长）
• 按功能分类筛选（15 类）、按星数筛选；排序可选证据强度、星数或最近更新
• 每条显示仓库名、作者、描述、星数、forks、最近更新日期与分类标签
• 点「复制」拿到等价的手动安装命令，或直接点「安装」交给 DSH

也可以直接访问网站：<https://cj.codexve.cn/>

网站是同一份数据的网页版，排版更宽松，适合在电脑上慢慢挑。

---

安装

dsh plugin --profile desktop add https://github.com/ymck-x/dsh-plugin-index/archive/refs/tags/v0.1.4.tar.gz

desktop 换成你自己的 profile 名（~/.dsh/profiles/ 下的目录名）。装完重启 dsh。

请用完整地址，不要写成 github:owner/repo 简写——那会被 pnpm 解析成 SSH 地址，匿名访问 GitHub 会被拒绝。

也不要用 refs/heads/main.tar.gz 这种分支地址——分支内容会随推送改变，而 pnpm 会记住你安装当时的指纹。作者一更新代码，你之后装任何插件都会撞上 ERR_PNPM_TARBALL_INTEGRITY，且报错指向一个你没在装的包。tag 地址的内容永不改变。

---

清单从哪来

清单由服务器上的一套抓取管道产出，本插件只消费它。发现与判定分三步：

步骤 · 做什么

发现 · GitHub topic 分片枚举 + code search 标记文件 + npm 关键词搜索，三源并集

判定 · 只读 package.json，检查 dsh.bundle 声明——不猜、不靠名字

地址解析 · 优先 npm 版本 → 其次 tag → 再次 commit，绝不用分支地址

排序按证据强度（读到了几个文件、依赖声明是否完整），不按星数。

为什么清单里三分之一以上是 0 星

DSH 生态在 2026 年 8～10 月集中爆发，topic:dsh-plugin 下有 1.8 万个仓库，大量是刚建、还没人发现的。星数分布（11443 条）：

星数 · 占比

0 星 · 34.6%

1-2 星 · 35.7%

3-10 星 · 20.1%

11-50 星 · 6.4%

50 星以上 · 3.3%

但 0 星不等于质量差——里面有不少正经功能（记忆、语音朗读、皮肤管理、用量统计），只是还没被人发现。所以面板提供「星数筛选」和「按星数排序」，你自己决定看哪一段。

---

仓库结构

lib/index.js        Host 半侧（空壳：数据在 client 半，这边无需注册路由）
lib/client.js       客户端半侧 —— 界面 + 内置首片快照（由脚本生成）
site/index.html     网站页面（独立静态站，部署在 cj.codexve.cn）
build-client.py     读 data/plugins.json → 生成 lib/client.js
build-site.py       读 data/plugins.json → 生成 site/index.json + 分片（本地预览用）
cordis.patch.yml    组合层声明

数据怎么来：清单有 4 MB，一次拉完在国内链路上必然超时（实测经 Cloudflare 只有 1–20 KB/s，且时常断流），所以数据分两层按需取：

层 · 内容 · 什么时候用

内置快照 · 首片 500 条，打包进 client.js（约 180 KB） · 远端拉不到时的兜底；也让插件包从 3.5 MB 降到 180 KB

远端索引 + 分片 · index.json（1.5 KB：统计与分片清单）+ p/<生成戳>-N.json（每片 500 条） · 打开面板先取索引，再取第一片；要看更多时按需取下一片

片名带生成戳、内容不可变，所以分片可以长缓存；索引保持 no-cache，才能发现新发布的那一批。拉取失败时面板会明确写出「当前是内置快照」——旧版是静默退回，用户会以为看到的就是最新的。

为什么不把清单整个内联：全量内联会让插件包变成 3.5 MB，而每次安装或更新都要下这么多，兜底数据却只在远端不可用时才用得上。另一个极端是让 Host 半侧读文件再注册 HTTP 路由，那要跨服务注入、路由注册、同源校验三道门，任何一道没接好就是「取不到数据」（这个坑踩过）。

自己构建

# 需要先有一份服务器产出的清单：data/plugins.json（从服务器 scp 下来）
python build-client.py     # 生成 lib/client.js（内置首片快照）
python build-site.py       # 生成 site/index.json + site/p/（本地预览）

或者用脚本一步到位（拉取 + 重建，发版前必跑）：

pwsh -File refresh-snapshot.ps1 -Server ubuntu@<服务器> -Key <私钥路径>

data/plugins.json 不进版本库（12 MB，且是服务器产物）。

---

已知限制

• 「地址已锁定」是按 tag / commit 解析的结果，不代表在当前 DSH 版本上真的能装能用。运行级验证需要一台装了 DSH 的机器。
• 功能分类是关键词规则（匹配描述、关键词、包名、仓库名），不调模型。好处是零成本、可复现、改规则立刻生效；代价是约 16% 归入「其他」。
• 星数只是参考信号，不作为质量结论——它既不能证明好用，也不能证明不能用。
• 列表里的最近更新（pushed_at）和 forks 是两个更实用的信号：前者回答「还在维护吗」，后者表示「有人拿去改造过」。清单里近七成是 0–2 星的新仓库，所以「上周还在更新」往往比「星数高但半年没动」更有参考价值。

许可

MIT