Vercel：skills.sh 七个月破百万——第一百万条教公共知识，下一百万条写公司判断

结论

Vercel 在 State of agent skills 里用 skills.sh 注册表的汇总数据画了一张新市场的前七个月：超过 100 万条 Agent Skill，累计近 2.8 亿次安装。 Skill 是给 Agent 的可复用说明书：Agent 本身能干很多活，但不知道某个团队、某家公司怎么干；Skill 把缺的上下文补上，可以只是一份普通人能读的文件。Anthropic 在 2025 年 10 月提出 Agent Skills，三个月后 Vercel 上线注册表。报告的判断是：第一百万条教的是「大家都知道的做法」；下一百万条要写的是「只有你们公司才会的判断」——退款什么时候批、什么改动能不经再审就发。

要点

• Skill 写的是判断，不是能力。 要把一份工作写成 Skill，必须先把隐性标准说清楚：步骤怎么走、什么叫做好、结果怎么验收。底层能力已经在 Agent 和工具里，Skill 只补这份工作特有的判断。所以它比传统软件好写：会描述工作的人，比会把工作编程实现的人多得多；写完之后，也不必为每个 Agent 重写一遍。

• 目录涨得比 GitHub、App Store、npm 都快，因为创作门槛更低。 skills.sh 七个月到 100 万条。GitHub 仓库用了 27 个月，App Store 应用约 63 个月（五年出头），npm 包约 117 个月（九年以上）。数字比的是「到一百万条目的时间」，不是质量。安装次数是注册表计数器的加总，不代表独立用户，也不一定是独立选择。

• 供给偏工程，安装却铺开到全公司。 他们按「帮 Agent 做什么」给安装最多的一批 Skill 分了类，这批覆盖全部安装的五分之四以上。上架量（供给）里，软件工程、Agent 工作流、数据、基础设施、安全加起来超过一半，软件工程单独约占四分之一。安装（需求）更散：没有任何一类超过两成——软件工程 18%，Agent 工作流 15%，业务运营和写作各接近 11%。超过五分之四的安装落在软件工程之外。

• 单位上架量谁更吃香，看「安装份额 ÷ 上架份额」。 这个指数离 1.0× 越远，供需缺口越大。业务运营平均每条多拿 74% 安装，写作与文档多 50%，云与基础设施多 42%——需求摊在更少的 Skill 上。软件工程少约 30%，教育与效率少 39%，研究少 55%。写 Skill 要懂那份工作；装 Skill 只需要想把那份工作做掉。目录从开发者工具长出来，所以技术类供给多；Agent 能进公司每个角落，所以安装更宽。

• 「改进 Agent 怎么干活」的 Skill，安装极高。 在已分类样本里，Agent 工作流与自动化占安装的 14.8%，仅次于软件工程；在至少 10 万次安装的条目里，它是最大类。这类 Skill 教规划、分派、用工具、自动化浏览器——合同审查只服务合同，规划却能套到合同、报销、发布评审上。人也在用 Agent 改进 Agent；Agent 又帮人写 Skill，目录靠改进自己的生产机器往上长。

• 安装极集中，但没有一个赢家通吃。 将近一半 Skill 只被装过一次。375 条（占注册表 0.04%）拿走 62% 安装，头部 1.2% 拿走 94%。即便安装最多的那一条，也占不到全部安装的 1%。竞争发生在同一份工作内部：团队选定一个报销 Skill 之后，很少再装第二个报销 Skill；但可以同时装表格、调研、演示。每份工作自己加冕，赢家加总才构成大部分安装。

• 八分之七的安装，落在跨行业都能用的 Skill 上。 清理表格、部署网站，银行和医院都会做。这类跨行业 Skill 占已分类条目的 66%、安装的 87.5%，平均每条安装量是行业专用 Skill 的 3.6 倍。只有八分之一的安装绑在特定行业。可移植性——跨工作（如 Agent 工作流）或跨行业——才是被装最多的那一类。功能和行业结论来自分类样本，不是全库逐条标注。

• 下一阶段：公共专长会变成基线，差异化搬进公司内部。 公开 Skill 和更好的模型，会让「人人都会的做法」变成默认能力，不再构成优势。Skill 好不好，今天主要看安装数；模型变强之后，标准会变成：挂上它，Agent 是不是比不挂更好。目录会继续长，供给去追需求；组织要在上面叠一层只有自己才有的知识，并像维护代码一样维护它。

怎么做

面向已经在给 Agent 写 Skill、或准备把团队惯例写进 Markdown 的工程师：

1. 先写清「判断」，再发布。 一份能装的 Skill，至少要有步骤、什么叫做好、怎么验收。只写「帮我做 Code Review」而没有仓库约定、风险档和停手标准，只是又一条供给过剩的软件工程条目。

2. 公开目录里，优先写可移植的活。 规划、分派、工具用法、浏览器自动化，能套到很多工作上，对应原文里安装最高的那一类。报销、表格、发布清单这类跨行业事务，单位上架量也更吃香。再发一条「通用写 React」的 Skill，平均安装会低于目录均值。

3. 同一份工作只保留一个赢家，旁边再叠互补 Skill。 团队已经有报销 Skill，就不要并行再装三个报销；去补表格、调研、演示。安装集中在每份工作的头部，长尾几乎没人用。

4. 公司优势写在内部 Skill 里，不要指望公开目录给你护城河。 退款什么时候批、什么改动可以不经再审就发、事故升级找谁——这些只有你们知道。公共百万条会变成基线；差异化在这一层。

5. 用效果验收，不要只看安装数。 装得多 ≠ Agent 做得更好。给关键 Skill 配一小份评测：有它 / 没它，同一批真实任务谁更接近你们的验收标准。原文预期下一阶段会出现这类测试和基准。

6. 读数字时带上报告自己的限定。 目录总数数的是不重复条目；安装是计数器加总；功能和行业结论来自分类样本。数字可能随方法和底层数据修订。先去 skills.sh 看已有百万条，再决定是贡献一条可移植的公共 Skill，还是先写下你们公司才会的判断。

关键图表

Vercel 原文：skills.sh 七个月到一百万条，对照 GitHub 仓库 27 个月、App Store 应用 63 个月、npm 包 117 个月。门槛更低，是因为更多人能描述工作，而不必先把它写成软件