第 3 章｜Skill 市场全景 2026

本章所有数字，来自 AgentSkillsHub 在 **2026-04-22** 运行的一次全表查询，样本量 **61,776** 条。所有分析脚本和原始数据都在 `data/ch03_analysis.py`，欢迎复算。

这是蓝皮书里最不好看的一章。它把一些看起来光鲜的数字拆开来看，顺便暴露了几个 Hub 自己的漏洞。先把这章放出来，是因为后面十一章所有的判断都建立在这些数字之上。

3.1 当我们说"55,000 个 Skill"的时候，其实在说什么

我在推文里和播客里反复说 **"Agent Skills Hub 收录了 55,000+ 个 skill"**，像是在讲一个听起来足够震撼的故事。

把数据库打开一看，今天的真实数字是 **61,776**。清理掉 15 个明显是机器批量生成的污染账号之后（后面 3.7 节会讲），这个数字缩到 **61,776**——也就是说，上周我在推文里说的"55K"已经不准了，**3 天涨了 6,000 个**。

数字在膨胀。但膨胀得越快，"55K 个 Skill"这个说法就越不诚实——因为 **61,776 条记录里，53.8% 的 stars 是 0**。

那是 33,417 个 Skill。**没有一个用户点过 star，没有出现在任何榜单，没有被任何人转发**。它们躺在 GitHub 上，也静静躺在我们数据库里。

这章的第一件事：把这个数字放在该放的位置。

**"55,000 个 Skill"的真正含义不是"55,000 个值得装的东西"，而是"55,000 次有人决定用 Markdown + YAML 格式把什么东西 push 到 GitHub"**。这两件事的距离很远。

把这句话写在最前面，因为后面所有分析都要靠它支撑。

3.2 残酷的长尾：54% 的 Skill 从未被一个人看见

先看星级分布（图 3-1）：

![Figure 3-1 Skill 星级分布的残酷长尾](/book/assets/ch03-fig1-long-tail.png)

| 星级段 | 数量 | 占比 |

|-------|------|------|

| 0 star | **33,417** | **54.1%** |

| 1-9 stars | 18,443 | 29.9% |

| 10-49 stars | 4,669 | 7.6% |

| 50-99 stars | 1,450 | 2.3% |

| 100-499 stars | 2,395 | 3.9% |

| 500-999 stars | 543 | 0.9% |

| 1K-9K stars | 707 | 1.1% |

| **10K+ stars** | **152** | **0.2%** |

这个形状不意外。任何开放内容平台都是幂律分布——YouTube、npm、AppStore 都差不多。意外的是**这一刀切得比上面任何一个平台都狠**：

超过一半（54.1%）的 Skill **一个 star 都没有**
84% 的 Skill 星数在 10 以下
10,000 stars 以上的 Skill 只有 **152** 个，占 0.2%

这 152 个是真正的明星。再往下，707 个是准明星（1K-9K）。加起来 **859 个真正被看见的 Skill**，占全体 1.4%。

剩下 98.6% 是什么？是 61,000 份被精心准备但没机会上桌的"邀请函"——作者花了几个周末写 SKILL.md、整理 README、画 logo，然后 push 到 GitHub，然后不会再被任何人打开。

这不是作者懒或产品差的问题。54% 的 0 star，大概率不是 54% 的垃圾。是**分发机制失灵**的问题。这条结论我会在第 9 章"Distribution"里展开——但请记住这个数字的形状。它是这本蓝皮书大部分论点的起点。

3.3 供给爆炸：2026 年 3 月之后的世界

如果只看存量分布，你会觉得 Skill 生态是个成熟市场——因为成熟市场才有这种稳定的幂律。

但看增量就知道了，**这是一个刚爆炸的市场**。

![Figure 3-2 Skill 供给爆炸](/book/assets/ch03-fig2-supply-surge.png)

按 GitHub repo 的 `created_at` 时间分组，最近 18 个月的新增 Skill 数：

| 月份 | 新创建的 Skill |

|------|--------------|

| 2025-11 | 1,079 |

| 2025-12 | 1,507 |

| 2026-01 | 3,280 |

| 2026-02 | 6,304 |

| **2026-03** | **27,720** |

| 2026-04（至今） | 13,860 |

**2026 年 3 月，单月 27,720 个新 Skill 被创建**。

这个月发生了什么？Anthropic 官方 `anthropics/skills` 的发布 + Claude Code 把 skill 加载做成一等公民 + 几篇"人人都该写 Skill"的病毒级文章同时出现。需求侧把 Skill 格式正式化之后，供给侧在 30 天内把过去 5 年的积累翻了 7 倍。

作为对比：

整个 **2023 年**全年，才有 **613** 个 Skill repo 被创建
整个 **2024 年**全年，1,174 个
整个 **2025 年**全年，8,810 个
**2026 年 Q1**，51,164 个

2026 年一季度的创建量，是 2023 年的 **83 倍**。这不是"增长"，这是相变。

相变意味着什么

**旧规则不再适用**。2024 年写一个中等质量的 MCP server，大概率能拿到几百 star。今天发同样的东西，大概率停在 0。供给侧饱和到这个程度，Skill 市场的 "baseline noise floor" 已经盖过了中等质量作品。
**发现机制价值飙升**。当你一天能看到 900 个新 Skill（3 月峰值日 / 30 ≈ 900），任何能帮你筛掉 99% 的工具都是有价值的。这是 AgentSkillsHub、skills-manage、各种 Awesome List 集中涌现的真正原因——不是写 skill 的人多了需要管理器，而是**找 skill 的人需要过滤器**。
**作者策略要变**。2024 年的策略是"把 skill 写好"。2026 年的策略是"把 skill 写好 **并且被看见**"。后一半才是瓶颈，前一半已经是及格线。

这也解释了为什么在写第 9 章时，我会说 lovstudio 的"商业化三角"之外还有第四条边——**Distribution**。在 2026 年 3 月之前，Distribution 勉强还能靠运气，之后必须有机制。

3.4 基尼系数 0.983：一个比任何已知内容市场更极端的数字

把所有 Skill 按 stars 降序排列，算一下洛伦兹曲线和基尼系数：

![Figure 3-3 基尼系数对比](/book/assets/ch03-fig3-gini-compare.png)

**基尼系数 = 0.983**
**Top 0.1%（62 个 Skill）占总 stars 的 45.9%**
**Top 1%（617 个）占 83.2%**
**Top 5%（3,088 个）占 95.7%**
**Top 10%（6,177 个）占 98.6%**

拿来对比一下（数据是近年不同研究的估算值，仅作尺度参考）：

| 市场 | 基尼系数 | 说明 |

|------|---------|------|

| 中国居民收入分配（2023） | 0.47 | 社会已经被称为不平等 |

| 美国居民收入分配（2023） | 0.40 | |

| YouTube 视频播放量（2020 研究） | 0.87 | 创作者经济被公认为极度集中 |

| npm 包下载量（2022 研究） | 0.93 | |

| iOS AppStore 收入（2023 估算） | 0.95 | 多年被称作"应用墓地" |

| **Skill 生态（2026，AgentSkillsHub 实测）** | **0.983** | **比上述任何一个都极端** |

**Skill 生态是目前已知内容市场里集中度最高的**。

62 个 Skill，决定了接近一半的流量。这 62 个里，你能想到的大项目都在：`openclaw/openclaw`（361K stars，实际上是 Claude Code 本体）、`n8n-io/n8n`（185K）、`Significant-Gravitas/AutoGPT`（184K）、`ollama/ollama`（170K）、`obra/superpowers`（163K）……它们中没有一个是"某个作者周末写的 skill"。

**基尼系数 0.983 的另一个意思：平均数完全失去意义**。算术平均 stars 是 128.5，中位数是 **0**。任何写"全站 Skill 平均有多少 stars"的报道，都在误导读者。

这也是为什么我从第一天就反对"按收录总数吹牛"这个 KPI——

你可以很容易地把数据库从 61,776 刷到 200,000。这只是调整搜索关键词 + 降低入库门槛 + 多跑几次 GitHub API 的事。但这样做的代价是：**分母越大，头部越显眼，中间层越隐形**。基尼系数反而会继续上升。

一个健康的生态要的不是更多的 0 star 记录，是更多的 50-500 star 中间层——那是真正的"作者赚到第一份反馈"的区间。今天这个区间只占全量 6.2%（50-499 stars 合计），是偏低的。

3.5 僵尸王图鉴：Skill 的半衰期可能只有 6 个月

看活跃度分布（图 3-4）：

![Figure 3-4 Skill 生命状态](/book/assets/ch03-fig4-lifecycle.png)

按 `last_commit_at` 分组：

| 活跃度 | 数量 | 占比 |

|-------|------|------|

| 30 天内有更新 | 41,385 | 67.0% |

| 30-90 天 | 16,920 | 27.4% |

| 90-180 天（衰落） | 791 | 1.3% |

| **180+ 天（死亡）** | **2,686** | **4.3%** |

单看这个数字，5.6% 的死亡率似乎还能接受——毕竟还有 67% 的 Skill 在过去 30 天被碰过。

但这个数字骗人。因为 Skill 生态的大多数 repo 是**过去 3 个月创建的**（3.3 节数据），所以分母被最近的新增稀释了。如果只看创建时间超过 1 年的 repo 里有多少 180+ 天没更新，比例会高得多。

更刺眼的证据是**僵尸王名单**——stars ≥ 1,000 但超过半年没有任何代码更新：

| Stars | Repo | 上次更新距今 |

|------:|------|-------------:|

| 20,816 | `winfunc/opcode` | 188 天 |

| 16,242 | `stackblitz/bolt.new` | 491 天 |

| 15,059 | `plandex-ai/plandex` | 201 天 |

| 10,537 | `bytebot-ai/bytebot` | 222 天 |

| 8,067 | `WooooDyy/LLM-Agent-Paper-List` | 222 天 |

| 6,835 | `Maciek-roboblog/Claude-Code-Usage-Monitor` | 220 天 |

| 5,979 | `BrowserMCP/mcp` | 363 天 |

| 5,969 | `kuafuai/DevOpsGPT` | 616 天 |

| 5,524 | `antiwork/shortest` | 247 天 |

| 5,382 | `modelscope/FunClip` | 285 天 |

| 5,219 | `appcypher/awesome-mcp-servers` | 230 天 |

点开这个名单里任何一个 repo 的 README，你会看到类似"revolutionary new way to..."的语言。这些当初都是现象级项目。

`winfunc/opcode` 是最早期的 Claude Code GUI，曾经是"必装 Skill"Top 5。**188 天前停更**——没有公告、没有 fork 接管、没有任何解释。20,816 个 star 挂在那里，像一座空城。

`stackblitz/bolt.new` 让整个 2025 年互联网都在讨论"一键生成 Web App"。**491 天没更新**。

`appcypher/awesome-mcp-servers` 这个最讽刺——一个 awesome-list 自己死了 230 天。

这个现象在软件生态里不是新闻，但在 Skill 生态里有个特殊的严重性——**Skill 是 Agent 直接读取执行的**，不像普通 library 还会人工判断"这个 package 有没有维护"。一个半死的 Skill 在 GitHub 上仍然会被 Claude Code 安装，被用户用，然后默默产出过时或错误的结果。

一个经验法则（基于当前数据的猜测）

Skill 的半衰期：**从发布到"不再活跃"大约 6-12 个月**。

我没有足够的时间序列做严格统计，所以这是猜测。但从僵尸王的 last commit 分布看，超过 90% 的"前明星僵尸"停更时间在 180-540 天之间——也就是说，**大多数明星项目在 1 年内死掉**。

这对蓝皮书后面几章的含义是严肃的：

第 5 章讲迭代的价值时，需要数字化"多少周没 commit 就会被惩罚"
第 10 章讨论 Verified Creator 的续费机制时，**活跃度必须是核心信号**，不能只看 stars
第 11 章设计 Hub 的企业版合规审计时，"Skill 停更预警"是基础功能

3.6 作者画像：谁在真正生产

61,776 个 Skill 背后是 **33,314 个独立作者**。

| 分布 | 数量 | 占比 |

|------|------|------|

| 只发过 1 个 Skill 的作者 | 17,833 | **54.6%** |

| 发过 2-4 个 | 13,544 | 41.5% |

| 发过 5+ 个 | 1,289 | 3.9% |

| **发过 50+ 个** | **45** | **0.1%** |

**超过一半的作者是"一发即弃"**——他们只 push 过一个 Skill repo 到 GitHub，然后没有第二个。

这对比是残酷的。3.9% 的作者发过 5 个以上 Skill，他们合计占全部 stars 的 **63.6%**（Top 100 作者占全部 stars 63.6%；Top 10 作者占 23.1%）。

**生产力的基尼系数，和 stars 的基尼系数一样极端。**

产量 Top 10（清理污染账号后）

|--:|--------|--------:|-----------:|---------:|

| 1 | JimLiu（宝玉备用号）| 249 | 50,269 | 202 |

| 2 | **steipete**（Peter Steinberger） | 180 | 87,901 | 488 |

| 3 | wshuyi（Shuyi Wang） | 164 | 6,851 | 42 |

| 4 | geekjourneyx | 151 | 2,604 | 17 |

| 5 | joeseesun（向阳乔木） | 126 | 6,968 | 55 |

| 6 | **alchaincyf**（花叔） | 91 | 34,984 | 384 |

| 7 | garrytan（Garry Tan） | 64 | 88,948 | 1,390 |

| 8 | op7418 | 63 | 22,409 | 356 |

| 9 | antfu（Anthony Fu） | 54 | 162,491 | 3,009 |

| 10 | Panniantong | 48 | 18,012 | 375 |

注意最后一列 Avg Stars，差异极大：

**antfu 3,009 stars/skill**——但这是因为 antfu 有几个 Vue 生态级 repo 把均值拉高，不代表每个 skill 都是爆款
**花叔 384 stars/skill**——2 个 1K+ 爆款把这个数字拉得很高，但大多数是 100-500 stars 的中等 skill
**wshuyi 42 stars/skill**——高产但单产量有限，这是"持续发布"型
**geekjourneyx 17 stars/skill**——更极端的"持续发布"，也可能是批量半自动创作

这些数据在第 5 章"5 种作者原型"里会用到。这里只想先把一个反直觉的事实摆出来——

**高产不等于高质。而且生产力本身极度集中。**

32,666 个作者里，**17,833 个只发过 1 个**，剩下的 45.4% 发过 2+；但**真正"像一个 creator"那样每季度都在产出的人，全球估计只有 Top 200 以内**。

这也是 AgentSkillsHub 第 10 章要讲的 Verified Creator 认证——**不是给 200 人发徽章这件事本身有商业价值**，而是把 200 人的迭代记录、分发效果、社群反馈稳定在一个可见的位置，让**认真做 Skill 这件事变成一个值得做的事**。

3.7 自我解剖：Hub 的四个漏洞

这节是这一章我最不想写但必须写的部分。

前面 6 节呈现的数据，有 4 个地方暴露了 AgentSkillsHub 自己的问题。蓝皮书不是宣传材料，它该长什么样我在第 1 节就讲过——**把一些看起来光鲜的数字拆开来看**。

漏洞 1: 批量污染账号污染了 1,035 条记录（已清理）

跑统计时发现产量 Top 10 里有几个奇怪的名字：

`TeleAI-mcp`：266 个 skill，**总 stars = 0**
`mcp-tool-shop-org`：204 个 skill，总 stars = 17
`pipeworx-io`：53 个 skill，总 stars = 0

这些明显是**脚本批量生成账号**——把某个产品的 API 接口挨个包装成一个 Skill，没有 README、没有说明、全部 0 star。

这种账号对我们的数据分布有三重伤害：

**拉高了总量**。刚才所有"61,776"的数字，在清理前是 62,748。多了 972 条"僵尸 skill"凭空让分母膨胀。
**污染了质量分分布**。第 11 章讨论 quality_score 算法时需要明确基线，这些 0 分 skill 会把基线压低。
**污染了作者产量分析**。Top 10 作者里有 4 个是这种批量账号，完全掩盖了真正的高产作者画像。

**已处理**：2026-04-22 执行了一次全表清理，删除 15 个确认的批量污染账号共 **972 条记录**。清理脚本保留在 `backend/discover_candidates.py`。

**未处理**：还没有 `author_blocklist` 表，下次 GitHub sync 可能把这些账号重新抓回来。这是一个需要在 Q2 闭环的工程问题。

漏洞 2: quality_score 算法对"顶级项目"区分度不足

我们现在的 quality_score 是 9 维加权的 0-100 分。分布是：

| 区间 | 数量 | 占比 |

|------|------|------|

| 0-19（差） | 7,068 | 11.3% |

| **20-39（中下）** | **47,420** | **76.8%** |

| 40-59（中） | 6,998 | 11.3% |

| 60-79（良） | 290 | 0.5% |

| **80-100（优）** | **0** | **0.0%** |

**76.8% 挤在 20-39，一个都没上 80**。

这不是"库里没有好 skill"，而是算法天花板太低。随机挑 20 个 10K+ stars 的 Skill 跑分：

openclaw/openclaw                      ⭐361,884  q=53.1
n8n-io/n8n                             ⭐185,026  q=43.4
Significant-Gravitas/AutoGPT           ⭐183,645  q=44.6
ollama/ollama                          ⭐169,643  q=39.4
affaan-m/everything-claude-code        ⭐163,158  q=54.7
obra/superpowers                       ⭐163,010  q=50.7
langflow-ai/langflow                   ⭐147,222  q=53.1
anthropics/claude-code                 ⭐116,614  q=45.4
google-gemini/gemini-cli               ⭐102,033  q=57.3
github/spec-kit                        ⭐ 89,934  q=53.3
punkpeye/awesome-mcp-servers           ⭐ 84,821  q=37.0
modelcontextprotocol/servers           ⭐ 84,003  q=27.9
garrytan/gstack                        ⭐ 79,571  q=52.1

平均分：46.8（这是全站 Top 20 的平均）

**全站 Top 20 平均只有 46.8 分**。punkpeye 的 awesome-mcp-servers 被我们打 37 分。modelcontextprotocol 官方的 servers 被打 27.9 分。

**原因**：9 维里的 `quality_examples` 和 `quality_agent_readiness` 两个维度，现有算法对"文档风格"要求过严。像 ollama 这种"重实用轻文档"的项目，自然就拿不到高分。但用户的实际体感是——ollama 值得 95 分。

**这是 Hub 的评分算法问题，不是这些项目的质量问题。**

**未处理**：蓝皮书定稿前我不打算改评分算法。改算法 → 重跑 62K 条数据 → 所有榜单数字变化 → 比起把问题诚实写进章节，风险更大。

**Q2 工作项**：引入第 10 维 `adoption_signal = f(stars, velocity, forks, fresh_commits)`，重新校准权重。把这个流程做成"每季度盲评 100 个 Skill 测算法偏差"的机制。

漏洞 3: 召回覆盖不全，大项目被漏收

"最近 30 天 first_seen 的新作者"里出现了这些名字：

`Significant-Gravitas`（AutoGPT，183K stars，**2023 年创建的项目**）
`ollama`（170K stars，2023 年创建）
`obra`（superpowers，163K stars）
`anthropics`（官方，125K stars）
`github`（89K stars）

这些不是"新出现的项目"，是**过去几年就存在但 Hub 漏掉了，最近 30 天才被抓进来的明星项目**。

说明我们的 GitHub 搜索查询关键词覆盖不全。现有的 sync 查询主要是 `mcp-server`、`claude-skill`、`agent-tool` 这几个明确的标签词。像 `ollama`、`AutoGPT` 这种不带 agent/skill 标签但实际是生态核心组件的项目，**只能靠手工提交或关联发现**。

**已处理**：extra_repos 手动白名单机制允许管理员提交任意 repo（2026-04 用于补录 iamzhihuix/skills-manage、cclank/news-aggregator-skill、alchaincyf 系列）。

**未处理**：自动化的"邻近发现"。一个合理机制是：对每个已收录的高质量 Skill，抓取它 README 里提到的其他 GitHub repo（或它的 dependent 项目），作为候选加入 sync 队列。目前这步还要人工做。

漏洞 4: Verified Creator 名单是空的

我在 2026-04-21 上线了 Verified Creator 程序（`/verified-creator/`），首批定了 4 个 Founding Members：lovstudio、tw93、antfu、garrytan。**第二天我意识到这 4 个人并没有申请过，我把他们的名字放上去是未经同意的**。

当天晚上撤下，页面改成"暂无 · 首批邀请制进行中"。

这不是数据问题，是运营决策问题。但它导致一个结果：**所有关于 Verified Creator 的数据在本书撰写时都是 0**。不是因为没人愿意加入，是因为程序上线 48 小时就因为作者冒进而暂停申请。

**后续处理**（写进第 10 章）：

4 月 23 日起开放正式申请通道
首批邀请名单必须有本人书面同意
蓝皮书定稿前公布首批 Founding Members（目标 5-10 人）

把这件事写进这里的原因：**如果一本书里连"我在过去两周踩了哪些坑"都不敢写，那它就不配叫蓝皮书**。

3.8 本章要记住的一句话

**2026 年 Q1 的 Skill 市场：6 万条记录，1% 决定命运，54% 无人问津，0 分到 40 分之间挤了 88% 的工作量，而你每个月会多看到一万个新 Skill 从 0 开始。**

这个市场的基本面不在于"Skill 能不能更好"，而在于**发现机制能不能跟上供给速度**。

蓝皮书接下来几章要讨论：

写 Skill 怎么才能不进那 54% 的无人区（第 4、5 章）
框架的选择如何决定可发现性（第 7 章）
为什么源码保护不是出路，Distribution 才是（第 9 章，引自《商业化三角少了一条边》）
Hub 如何承担那条被忽视的"发现机制"职责（第 10、11 章）

附：本章的原始数据

所有分析脚本和产出都在：

skill-blue-book/
└── data/
    ├── ch03_analysis.py         ← 可重跑的分析脚本
    ├── ch03-stats.json          ← 快照数字（61,776 样本，2026-04-22）
    ├── ch03-fig1-long-tail.png  ← 星级分布
    ├── ch03-fig2-supply-surge.png  ← 月度供给
    ├── ch03-fig3-gini-compare.png  ← 基尼系数对比
    └── ch03-fig4-lifecycle.png  ← 生命状态

数据来源：AgentSkillsHub Supabase 数据库的 `skills` 表全表查询（`SELECT *`），时间戳 **2026-04-22**。如果你拿到这本书时数字已经过时，`ch03_analysis.py` 可以随时重新跑一遍。

**下一章**：第 4 章｜站在 Agent 角度设计 Skill（宝玉四条哲学）