实测20个最热门Agent技能：安装量第一的反而拖后腿

装的人多，就等于好用吗？有人拿安装量最高的 20 个 Agent 技能做了一组对照实验：同一批任务，分别在有技能和无技能的情况下各跑一遍，再看答案质量有没有变化。结论有点反直觉——安装量排名第一的 find-skills，在两个模型上都让答案变差了。

这组测试来自 Driftproof（一个开源评测工具，作者本人也是测试者，文中已披露利益关系），数据基于 skills.sh 10 月 17 日的快照。测试使用 Claude Sonnet 5.5 和 Claude Opus 5.5 作为作答模型，Claude Haiku 5.5 担任裁判，共产生 40 组结果。

总体记分板：过半技能确有帮助

先看整体结论。在 20 个技能中，有 11 个在两个模型上都表现出「明显有帮助」。

结果	Sonnet 5.5	Opus 5.5
明显有帮助	12	12
明显变差	4	2
样本不足无法判断	4	6

这个分布说明，多数高安装量技能并非「装了就图个心理安慰」——它们在纯文本任务上确实能改变输出质量。但同时也说明，安装量榜单里混进了会拉低表现的项目，而且排名越靠前，问题越扎眼。

帮倒忙的那些：榜首技能翻车

最受关注的失败案例是 find-skills（vercel-labs/skills），它是安装量第一名，却在两个模型上都被判定为「明显变差」。两次出问题的都是同一个搜索请求类任务：带技能时得分约 0.75，不带技能反而有 0.92 到 0.95。

这里需要说清楚测试边界。find-skills 本质上是一个路由器，负责把 Agent 指向其他技能。测试者评分的是它自己写出的回答，而不是它转交出去的那些技能的效果。换句话说，这更像是「路由器的说明文字干扰了直接作答」，而非路由功能本身失效。

其他被判定为拖后腿的还有：

• reddit-automation（flowkit-labs/skills）：两个模型上都变差，涉及排序任务，以及 Sonnet 上的回复任务。
• grill-with-docs 和 hyperframes：仅在 Sonnet 上明显变差。

同一技能在不同模型上表现分化，说明技能与模型之间存在适配问题，单看一个模型的结论容易误判。

提升最明显的几个：分数翻倍不是夸张

正向案例的幅度同样可观：

• hyperframes-registry（heygen-com/hyperframes）：Sonnet 上从 0.43 提升到 0.98，Opus 上从 0.62 提升到 0.97。
• prototype（mattpocock/skills）：Opus 上从 0.36 提升到 0.93。
• triage（mattpocock/skills）：两个模型上都拿到满分 1.00，无技能时约为 0.7。

triage 在两个模型上同时拿到 1.00，是这组数据里最稳定的正向信号。hyperframes-registry 的增幅最大，接近把「不及格」拉到「接近满分」。

有 10 组结果，测试者选择不公布数字

40 组结果中有 10 组被标记为「样本不足无法判断」。grill-me、tdd 以及 Anthropic 自家的 frontend-design 在两个模型上都落在这个区间。

测试者特意强调，这不等于「没有效果」。它意味着同一任务多次运行（每个实验组最多 10 次）之间答案波动太大，无法给出可信结论。相比报一个重跑就会翻转的数字，他们选择直接标注「测不出来」。这种处理方式在评测类内容里并不常见，值得肯定。

评测方法：怎么才算「明显有帮助」

判定标准是这套实验可信度的关键：

1. 每个技能对应三个纯文本任务，任务依据技能自身的描述和 README 编写，并在任何运行开始前固定下来。
2. 每个任务分别在有技能和无技能条件下作答，每组重复 3 到 10 次，每个答案评分 5 次。
3. 「明显有帮助」的定义是：至少一个任务上，两组得分的区间（均值加减一个标准差）不重叠且差距不小于 0.05，同时没有任何任务明显朝反方向走。任何一个任务上的明显下降，都会压过其他任务上的提升。

第三条规则相当严格——它意味着「总体平均分更高」不足以判定为有帮助。

「均值加减一个标准差」的区间不重叠，是统计学里判断两组数据是否「显著不同」的一种直观近似。严格来说，这类比较通常采用双样本 t 检验或 Mann-Whitney U 检验，并报告 p 值和效应量。本文采用区间法，好处是阈值直观、对非统计背景读者友好，但也更保守：当样本量小、方差大时，区间容易重叠，从而把真实存在的差异判为「测不出来」；反之，若方差极小，即便差距只有 0.05 也可能被判为「明显」。因此，文中「明显有帮助」「明显变差」「样本不足」的三分类，本质上是效应方向与稳定性的联合判定，而非严格的假设检验结论。

另一处值得注意的设计是「每个答案评分 5 次」。这是用 LLM 作为裁判时的常见做法：单次打分方差较大，多次打分取均值或多数票可以降低随机性。但重复评分只能减少裁判侧的噪声，无法消除裁判模型的系统性偏好（例如偏好更长、结构更清晰的回答）。文中仅使用 Claude Haiku 5.5 单一裁判，正是这一局限的来源。

局限：结论不能外推太远

测试者自己列出三条限制：每个技能只有三个纯文本任务，且由测试方而非技能作者编写；没有测试工具调用、生成媒体或部署服务；只有单一裁判模型。此外，「热门」在这里指的是报告安装量，不等于质量。

这些局限决定了结论的适用范围：它回答的是「在三个固定文本任务上，加载这个技能会不会改变答案质量」，而不是「这个技能在真实工作流里好不好用」。对于涉及工具调用的技能，这套方法基本没有覆盖。

如果你认为某个任务不公平或结果有误，每个技能页面都提供重跑申请入口，所有评分记录、任务集和保留的答案都是公开的。完整表格见 driftproofhq.com/skills/，详细报告为第 015 号。

安装量是市场信号，不是质量信号。这份实测的价值不在于给 20 个技能排个高低，而在于提醒一件事：把技能装进 Agent 之前，值得先问一句——它到底让输出变好了，还是只是让配置看起来更专业了。