上升期插件：分数涨得最快的那些 DSH 插件

上升期插件指的是分数往上走而不是往下走的那些，fast growing plugins 值得的注意力和正在下滑的完全不同。这篇讲的是 score momentum：怎么读懂一次 dsh plugin score increase、四个信号里通常是哪一个在推动，以及怎么维护一份 rising star plugins watchlist，把真正的采用和一次元数据清理区分开。

score momentum 到底在量什么

分数是从四个输入重新算出来的，不是一次考完就固定的等级。数字往上涨，说明这四个里有一个动了，而动的是哪一个，决定了这次上涨跟你有没有关系。

• 维护状况：最后一次 push 的时间、发版节奏、issue 挂了多久没人管。
• 文档：有没有 README、覆盖到什么程度、最近是否改过。
• npm 健康度：依赖是否够新、上游有没有失修或被改名。
• 安全：安装脚本的发现项和供应链告警，这两项任一单独就能把分数推动。

等级本身和趋势是两个问题。每个等级代表什么写在 /blog/dsh-quality-score-decoded。

fast growing plugins：涨分只有三种形态

一次跳涨并不自动等于好消息。几乎所有上涨都逃不出下面三种形态，而只有一种意味着这个插件变得更好用了。

• 维护重启。一个沉寂过的插件重新开始提交。这是唯一值得你行动的一种。
• 文档重写。README 变长了，于是文档信号变好，而代码一行没动。
• 依赖刷新。上游包被升上去，npm 健康度信号跟着动了。

这三种里有两种，插件的可用性跟涨分之前完全一样。只有第一种改变了你实际得到的东西，所以涨幅有多大不如是哪个信号造成的来得重要。

怎么分清真正的采用和一次元数据改动

dsh plugin score increase 最常被误读的地方就在这里。文档信号上涨和维护信号上涨看起来一模一样，除非你去查到底是什么变了。

• 对比发版时间。没有新版本却涨了分，几乎一定是文档或元数据。
• 读 changelog，不要只读评分页。如果最后一条是 README 修改，那你对代码一无所获。
• 把最后 push 的时间和评分更新的时间对一下。push 时间很旧而分数在涨，说明涨幅来自别处。
• 看同一时间窗内的安装量或 star 变化。采用和分数一起动，才是值得信的组合。

安装量是从哪来的

/trending 页面按近期活跃度和 star 排序，正好给你第三个可比的来源。分数在涨而活跃度平的插件，是一次文档事件，不是一次采用事件。

score momentum 只告诉你有东西变了，不告诉你有没有人在用这个结果。

十分钟搭一份 rising star plugins watchlist

watchlist 就是一张普通清单，不是什么仪表盘。我的那份有八条，一周看一次，足够抓住所有要紧的变化。

• 列出所有缺了它构建就会失败的插件。这就是全部清单，而且通常比你以为的短。
• 在每条旁边记下分数、等级和你查看的日期。
• 补上最后 push 的日期。这一个字段能解释大部分波动。
• 每周复查。/weekly 上的 DSH Weekly 会把整个生态的分数变动推给你，所以人工那一遍只需要覆盖你自己的这八条。

分数往另一个方向走的问题在 /blog/dsh-plugin-score-trends-what-a-dropping-score-means。先看哪些插件排在 /blog/how-to-avoid-risky-dsh-plugins，维护状况这一个字段单独讲在 /blog/dsh-plugin-maintenance-signals。

常见问题

• 分数涨了就该换到那个插件吗？不该。涨分只说明有东西变了。先读 changelog 再决定，对比方法在 /blog/compare-two-dsh-plugins-side-by-side。
• 多快算快？一个评分周期内涨五分以上值得看一眼。两到四分通常是文档或元数据。
• 分数会因为不对的理由上涨吗？会。只改文档、不动代码，数字一样会涨，而插件本身没有任何变化。
• 上升期的插件就可以少查一点吗？不行。momentum 说明不了安装行为。安装脚本的检查照样要做，写在 /blog/how-install-script-scanning-works。

dshquality.com 上每个插件都有评分页，列出四个信号以及各自的变动方向，所以一个上升期插件是你能去核实的，不是只能选择相信的。活跃度排行在 /trending，每周分数摘要在 /weekly，站上发布的全部内容在 /blog。