别再直接搜 ClawHub：这份清单先挡掉 7215 个问题技能

海盐芝士 技术创作者 2026-11-01 10 阅读

截至 2026 年 10 月 30 日，GitHub 仓库页 VoltAgent/awesome-openclaw-skills 显示：About 区写 5,400+ skills，README 开头却写 5300+。两个数字差约 100，这里先不展开。更值得注意的是一手页面里的过滤表：这份清单从 OpenClaw 官方技能注册表 ClawHub 中，共挡掉了 7,215 个问题技能，只留下精选后的分类目录。为什么现在值得看？腾讯云开发者文章在 2026 年 3 月报道时还称它只有 700+ skills，英文媒体 Kocpc 在 2 月说 1,700 curated；到 10 月一手快照已经到 5,400+。用户自己出海选的试错成本明显抬升，这张过滤表开始比“收录了多少”更有信息量。

从 7215 个被过滤项看筛选口径

仓库 README 直接给出五类被移除原因。数字全部来自该仓库页，我把它整理成下表：

过滤原因 数量
疑似垃圾：批量账号、机器人、测试/垃圾 4,065
重复/相似名称 1,040
低质量或非英文描述 851
Crypto/区块链/金融/交易 886
恶意：研究者公开安全审计识别，排除 VirusTotal 373
合计未收录 7,215

五类相加正好是 7,215：4,065 + 1,040 + 851 + 886 + 373。其中垃圾类最大，占未收录数的 56.3%；恶意类 373 个，占约 5.2%。这个占比是我按表内数直接算出来的，不是官方给的。需要特别注意恶意类的口径：官方标了 “excluding VirusTotal”，也就是统计时不把 VirusTotal 的结果算进去，依据是研究者公开发表的安全审计。这既不是完备的安全审计，也不是说 VirusTotal 无价值，而是这张表自设的边界。

5300+、5400+、700+：同一仓库在不同来源里的三个数字

除了 About 和 README 差 100，更明显的口径差来自二手报道。中文社区视角的腾讯云开发者文章在 3 月给出的标题是“700+ Skills”，并称仓库有 5.3K Star；英文媒体 Kocpc 在 2 月初说项目收录 1,700 个安全实用 skills，当时 ClawHub 至少已有 3,000 个 skills。把这几个时点放在一起：

来源/时点 收录技能数 Star 快照
Kocpc，2 月初快照 1,700 curated 未给
腾讯云，2026-03 700+ 5.3K
GitHub 仓库页，2026-10-30 5,300+/5,400+ 53.5K

这些不是官方增长率，只是不同时点的快照比较。我的判断是：中文文章里的 700+ 已经严重过时，Kocpc 的 1,700+ 也是快照，只有回到 GitHub 仓库页才能拿到最新口径。另一个细节是仓库 Topics 里还留着 clawdbot、moltbot 等旧名，腾讯云文章也提到它“一直跟随官方改名”。这意味着你搜到旧文章时，看到“Clawdbot 技能合集”说的就是同一个项目，别当成两个仓库。

一条命令安装技能，不等于拿到安全保证

安装本身很简单。仓库给出的命令是：

openclaw skills install <skill-slug>
# 或使用 ClawHub CLI
npx clawhub install <skill-slug>

# 手动安装位置
~/.openclaw/skills/      # 全局
<project>/skills/        # 项目
# 优先级：Workspace > Local > Bundled

但 OpenClaw 是本地运行的 AI assistant，技能让它能与外部服务交互、自动化工作流、执行专门任务。也就是说，装一个技能相当于让本地 agent 获得一类操作能力，不是单加一个按钮。仓库本身没有承诺技能永远安全，它建议用户安装前自行检查，或用 Claude Code、Codex 审查潜在危险行为。Kocpc 在 2 月的报道里也提到，当时 ClawHub 缺少安全扫描功能。这份清单解决的是“从海量里筛出能用的”，不是“给你一个安全认证”。如果你把它当作安全审批，就误解了它的定位。

原始技能池至少有多大：一个必须标明来源的推算

如果把 7,215 个未收录项和 About 区 5,400+ 收录项相加，能推出 ClawHub 在 10 月快照前后至少映射出约 12,615 个技能。计算式如下：

total_not_taken = 4065 + 1040 + 851 + 886 + 373   # 7215
estimated_pool = 5400 + total_not_taken            # 12615

这个 12,615 是我的推算，不是官方说法：仓库没有明说这两者相加等于注册表总数，因为可能还有不在过滤表口径内的项目。另一个可复算观察是，恶意项在未收录项里约占 5.2%，约等于每 20 个被筛掉的技能里有 1 个被研究者审计标记为恶意。这个“约每 20 个”也是按 373/7215 换算，不是官方说法。

把三个数字放在一起算：六成技能没能进这份清单

现在可以把不同来源的数字拼起来了。仓库 About 区写的是 5,400+ 收录项，README 的过滤表写明未收录 7,215 项。两者相加得到注册表在 10 月快照前后的下限：

registry_lower_bound = 5400 + 7215 = 12615
acceptance_rate = 5400 / 12615 ≈ 42.8%   # 收录项占注册表的比例
filter_rate     = 7215 / 12615 ≈ 57.2%   # 被过滤掉的比例

也就是说，每 10 个已发布到 ClawHub 的技能里，约有 6 个没能进入这份清单。这个比例比”5,400+ 收录”这个数字本身更能说明清单的边界性质 —— 它是一个筛选结果，不是一份全量列表。

再把 2 月初的第三方快照放进来看：Kocpc 在 2 月初报道的收录数是 1,700+，到 10 月的 5,400+，约八个月增长 3.2 倍。但这个增长率不能当成官方数据 —— 第三方报道用的是当时的仓库状态，而仓库的增长既可能来自新技能发布，也可能来自维护者事后补收录，两者在数字上无法区分。能确定的只有两端数字本身，中间过程不可考。

同时要提醒的是中文社区那篇 3 月的报道里写的”700+ Skills”，与仓库自己 2 月的 1,700+ 就对不上。两者都不是仓库官方数字，且口径不明（可能只数了某个分类下的活跃技能）。引用二手报道里的收录数时，一定要注明是哪个时点的快照，否则读者会拿它跟仓库当前状态直接比。

README 里的广告位与维护模式，和技能列表不是一回事

读这份仓库时，还要分清哪部分是技能索引，哪部分是生态推广。README 后半段推荐了 Crawlbase，称其被 70,000+ developers 使用，提供爬虫 API 和 MCP server；还有 Cloudways 的托管服务。这些是商业推广位，并非精选技能的组成部分，适合放进另一层判断：一个开源列表的广告位多少，和收录质量无关。仓库页面还显示，截至 2026-10-30，它有 566 commits，Issue 标签 1 个，Pull requests 标签 3 个。从这个页面看，issue 和 PR 都只有个位数，这不是大规模社区协作的信号；但我没有更多历史数据，这只是快照观察，不是官方定位。对普通用户来说，好处是维护路径相对集中；代价是贡献入口不活跃，遇到错误别期待社区快速回应。

这份清单会误导哪类用户

它最适合已经使用 OpenClaw、不想在 ClawHub 海选的人。最容易被误导的两类：一类是把 curated 当成安全认证，直接在企业环境里装；另一类是需要 crypto/链上工具的人，因为整类被排除，他们只能回 ClawHub 自行找，并且要做更严审查。手动安装时还要注意同名覆盖：官方标注的优先级是 Workspace > Local > Bundled，装之前确认路径，否则同名技能可能加载成你没打算用的那份。最后，Contributing 规则只接受已经发布到 ClawHub 的 skill，不接受个人 repo 或 gist。这保证了可追溯性，但也意味着一些小而美、未挂上 ClawHub 的项目不会出现在这里。

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

海盐芝士 10 阅读