一万多个dsh插件里,第四名是个的简历生成器

▲点击上方卡片关注我

它比 dsh 早了六年。今天排到第四，只因为作者给仓库加了一个 tag。

这事挺荒诞的，但几乎是必然的。

「Everything is a Plugin」这个口号，我是真心喜欢。内核的每一颗螺丝都交到你手里，你可以把它拧成任何形状。开源那阵子，插件和社区大量冒出来，GitHub 上「dsh-plugin」这个标签底下，十几天就攒了一万多个仓库。

然后有人认真数了一遍。

同一天，同一个生态，不同网站统计出来的插件数量差得挺多。原因是「插件」这个词在这个生态里还没有公认的定义，谁都能合理地说自己那个数是对的。把整个生态做成漏斗，从第一层到第三层掉了 81%，从第三层到第五层又掉了 55%。

所以「dsh 有一万一千个插件」和「dsh 现在能用上的不到一千个插件」，这两种说法都成立，无非是看用什么口径。

为什么每层漏这么多？因为官方关于插件生态的全部指引，就只有 README 和 CONTRIBUTING 里各一句话：给你的仓库打上 dsh-plugin 这个标签，方便别人发现你。

就这样。门槛是零。任何人可以给任何仓库打任何标签，不需要审批，也不需要跟 dsh 有任何关系。

有人把这一万多个仓库逐个打开筛了一遍，公开了 1883 条拒稿记录，含理由和复查日期。重新聚合这份数据会发现，93% 的拒绝理由是「按 dsh 的规矩装不上」——没有 dsh.bundle 声明，没有 dsh 依赖，也没有 dsh 能发现的技能布局。

但装不上不等于仓库是假的。抽 50 个被拒仓库看体积，只有 1 个在 5KB 以下，中位数 407KB，12 个超过 5MB，最大的 336MB。语言从 TypeScript、Python、Rust 到 C、C++、Swift、Go、Shell 都有。问题是插件走的是 npm 那条路，Node 之外的语言根本进不来，这里面大概三成从语言选择上就注定做不成插件。

真实构成长这样：极少数是空壳，50 个里只有 1 个；一部分代码是真的，宿主端和浏览器端两半都写齐了，就是没加那句声明、没发布到 npm，官方安装命令认不出它；还有一部分压根不是插件，50 个样本里混着 5 个 Windows 启动器、1 个 macOS 状态栏组件、几个桌面客户端。

看到这里你可能会觉得，那不就是生态有点乱嘛，开源早期都这样。

问题在于，乱和危险是两件事。

这批插件生态里，没有插件目录，没有搜索，没有版本兼容矩阵，没有签名或校验，没有安全上报通道，没有官方推荐清单。

而最刺人的一句是，最严的安全档形同虚设，装一个插件就能读到你的 API Key。

你想想看那个画面。你把 dsh 装好，安全等级拉到最高，你觉得门已经锁上了。然后你从那个按 star 数排序、第四名是简历生成器的列表里，随手装了一个插件。它读走了你的 API Key。

没有签名，你没法验证这个插件是不是作者本人发的、中间有没有被动过。没有安全上报通道，就算你发现了问题，也不知道该跟谁说。没有版本兼容矩阵，你不知道它在新版 dsh 上会不会突然做出意料之外的事。

「一切皆插件」的浪漫，是建立在每一颗螺丝都可信的前提上的。现在的状况是，螺丝被交到你手里，但没人对这批螺丝负责。

我倒不觉得这是 DeepSeek 一家的失误，更像是开源生态的一种天然病。门槛为零的开放，头几个月的繁荣一定是虚高的，因为繁荣的成本不由建设者承担。写一个 tag 的成本是零，判断这个 tag 靠不靠谱的成本，全落在你我身上。

所以如果你现在正在玩 dsh 的插件，我只有一句真心话：别把安全档当成一道防线，把它当成一个还没填上的输入框。

装之前，至少点进去看看这个仓库是谁写的、上次提交是什么时候、装完它到底要哪些权限。麻烦，但比 API Key 被读走划算得多。

那不到一千个过了筛的仓库里，一定有真正的好东西。只是在找到它之前，你得先穿过一片没人管理的荒野。