三个月前第一次看到 superpowers 的时候，直觉告诉我这东西值得认真看一看——14 个 skill 打包在一起，Claude Code 瞬间变成一套完整的软件工程流水线，TDD、代码审查、brainstorming 全给安排上了。
GitHub 上 187K star 摆在那里，Medium 上有人写测评直接说“生产力提升 100 倍”，HN 置顶帖里工程师们也是一片叫好。
我也装上实打实用了三个月，结论可能跟你想的不太一样：**它确实有价值，但别指望它是万能药，而且整个 Claude Code Skills 生态里，包装远远大于实际内容的东西实在太多了。**
截至 2026 年 5 月，GitHub 上已经有 1400+ 个 Claude Code Skills，官方 marketplace 收录的也超过 658 个。我自己试了 40 多个，还帮团队里的几个人清理过他们的 skill 列表，筛选下来的结论非常明确：**真正能在日常工作中留下来的，不超过 10 个。**
这篇文章就是我的筛选过程和最终判断，不是推销，纯属经验分享。
## 先给你一个懒人版结论
如果不想看完这 4000 字，这张表直接拿走，不谢：
| 场景 | 推荐 Skill | 核心价值 | 要注意的地方 |
|------|------------|----------|--------------|
| 中大型功能开发 | `superpowers` | 强制规划，减少走弯路 | 简单任务会多花 15 分钟 |
| 多天项目协作 | `claude-mem` | 跨会话记忆，不用反复交代背景 | 记忆噪声多了会搞乱 |
| 浏览器自动化 | `agent-browser` | Token 效率最高，日常够用 | 复杂 DOM 操作需搭 Playwright |
| 前端 UI 生成 | `frontend-design` | 避免千篇一律的 AI 风格 | 只是风格约束，不能替代设计稿 |
| 构建自定义 Skill | `skill-creator` | 官方工具，评测指标可量化 | 需要花时间写评测用例 |
剩下的 1390+ 个？大概率是你装上之后一周内就会彻底忘了它们存在的东西。下面说为什么。
## 为什么大多数 Skill 是噱头
Claude Code Skills 的技术原理其实不复杂：就是一个 `SKILL.md` 文件，YAML frontmatter 里写 `name` 和 `description`，正文是 Markdown 格式的指令，放到 `~/.claude/skills/` 目录下就能用。
每次 Claude 处理请求时，会用大约 100 tokens 扫描所有已安装 skill 的 name 和 description，判断是否需要激活。需要激活时才加载完整内容（通常小于 5k tokens）。所以理论上，装 50 个 skill 的额外 token 开销也就 5000 左右，算不上什么负担。
**但问题在于，这种低门槛意味着任何人都可以在一个下午写个 skill，丢到 GitHub 上，起个响亮的名字，然后收获一堆 star。**
有人专门测试了 100 个社区 skill，结果 70% 不合格。失败原因高度集中：
* **SKILL.md 过于臃肿**（超过 4000 tokens），每次无关任务都在白白消耗上下文
* **description 写的像是营销文案**，而不是路由规则，Claude 根本不知道什么时候该激活它
* **Single-file 包揽一切**，把五件事硬塞进一个 skill，结果哪件都做不精
* **缺少 reference 文件分层**，关键逻辑直接堆在 SKILL.md 里，激活一次就吃掉大量上下文
真正好的 skill 是非常精准的：`description` 读起来像路由规则而非宣传口号；核心 SKILL.md 精简至极，细节都推到 `references/` 目录里按需加载；一个 skill 只做一件事。
图：Claude Code Skills 五层价值分层——从必装到直接跳过
判断一个 skill 值不值得装，直接打开它的 `SKILL.md`，读前 50 行。如果读完前 50 行你还不清楚它到底是干什么的，直接扔掉，不用犹豫。
## superpowers：真实体验是什么
superpowers 是整个生态里最成功的 skill 集合，没有之一。从 2025 年 10 月发布到现在，187K GitHub star，v5.1.0（2026 年 5 月 4 日更新），成长速度确实惊人。
它把 Claude Code 的工作方式重组成了一条完整的流水线：
brainstorming → 确认方向 → writing-plans → 生成实施计划 → executing-plans → 实现 → requesting-code-review → 质量审查 → verification-before-completion → 收尾验证
14 个 skill，覆盖了完整的软件开发生命周期。
图：左侧是 stock Claude Code 的常见失败路径，右侧是 superpowers 的结构化流程
**它真正改变了什么？**
用 stock Claude Code 做一个新功能，典型的失败模式是：Claude 对着一个模糊的需求直接开始写代码，写完之后你发现方向不对，然后花 2 倍的时间重写。superpowers 的 `brainstorming` skill 强制你在动代码之前把需求彻底想清楚——不是催你写文档，而是通过一系列问题帮你把“你到底想要什么”给问出来。
有人做过对照实验：12 个 Claude Code 会话，一半用 superpowers，一半不用，处理同等复杂度的任务。结果是 superpowers 组 **token 用量降低了 14%，代码质量（以 PR review 问题数量计）也有明显提升**。原因非常直观：规划阶段消耗的 token，远比因为方向跑偏而重写的 token 要省得多。
对于复杂的、多文件的、需要跨模块协作的功能，superpowers 的收益是实打实的。
**但它也有明显的局限：**
第一，**简单任务会被明显拖慢**。“帮我写个正则表达式”、“帮我加一个 console.log”这类任务，被 brainstorming 拦截之后，可能要花掉 10-20 分钟走完前置流程，完全不值。有 HN 的工程师反馈说用了 superpowers 之后“Claude 做简单事情变得超级啰嗦”，这确实是真实存在的问题。
第二，**计划修改的体验很差**。superpowers 生成了多页实施计划之后，如果你想修改一小部分内容，它会直接整体重新生成。一位开发者的原话是：“你给它反馈，它会返回一个全新版本的多页计划，而不是只修改你提到的那部分。”
第三，**TDD 规则有时对模型来说强制得有点过头了**。superpowers 要求先写测试再写实现，如果没有失败的测试，它会删除已经写好的代码。这个机制本身是对的，但在探索性阶段，“先跑起来再说”的需求也是真实存在的。
**最终的策略：**
最终的策略是**有选择性地激活**。做新功能、做重构、做有明确边界的模块时，用 superpowers 的完整流程。修 bug、加小功能、写一次性脚本，直接用 stock Claude Code，不经过这套流水线。
`using-superpowers` skill 提供了这种灵活性——你可以只装其中一部分 skill，比如只装 `brainstorming` + `systematic-debugging`，不装全套。
## claude-mem：被低估的那个
superpowers 是生态里讨论度最高的，但 claude-mem 是个人认为**最被低估的一个**。
它解决了一个很具体也很常见的问题：Claude Code 的每个会话是独立的，你在昨天的会话里和 Claude 讨论了某个模块的设计决策、踩了一个坑、确认了一个命名规范——今天新开一个会话，这些信息全没了。你要么重新交代一遍背景，要么接受 Claude 在不了解上下文的情况下工作。
claude-mem 的解决方案是：在会话结束时，把有价值的内容压缩成“记忆片段”，存到本地（SQLite + Chroma 向量数据库）。下次会话开始时，自动检索相关的记忆，注入到 system prompt 里。
目前 72.4K GitHub star，v12.6.4（发布于 2026 年 5 月），259 个 release，109 个贡献者。2026 年 2 月曾单日增长 1474 个 star，拿过 GitHub Trending 第一。
**它在哪里最有价值：**
* 多天迭代的项目：第二天不用重新交代“我们用的是 PostgreSQL 而不是 MySQL，因为……”。
* 踩坑记录：之前踩过的坑、找到的解决方案，在遇到类似问题时能自动浮现出来。
* 团队规范：一次告诉 Claude“我们的函数命名用动词+名词”，之后就不用反复说了。
**它的真实局限：**
claude-mem 最大的风险是**记忆噪声**。它会记下一切，包括你在某次会话里随口说的错误假设、临时的决策、后来被推翻的方案。如果不定期清理，检索到的“相关记忆”反而可能误导 Claude。
坦白说，这坑我也踩过。有次在会话里临时测试一个方案，说了句“先这样试试”，claude-mem 就把它记住了，之后几次会话里 Claude 都参照这个“临时方案”工作，花了好一会儿才发现问题出在哪里。
另外，它不能替代代码注释和文档。那些稳定的架构决策，应该写进 `CLAUDE.md`，写进代码注释，不应该只活在 claude-mem 的记忆库里——因为记忆库会过期、会被覆盖、会产生歧义，而代码里的注释不会。
**正确的用法：**
把 claude-mem 当作“对话记录的增强索引”，而不是“架构知识库的替代品”。真正重要的决策，同时也要写进 `CLAUDE.md`；不确定的、临时性的内容，在会话结束时主动告诉 Claude 不要记住这条。
## agent-browser：做浏览器自动化就用这个
这是一个逻辑很直接的评测题：你需要让 Claude Code 操作浏览器，有几个选项，应该选哪个？
2026 年的主流选项：
| 工具 | Token 消耗/页 | 适用场景 | 安装复杂度 |
|------|---------------|----------|------------|
| `agent-browser` | 200-400 tokens | 日常浏览、表单、导航 | 低 |
| Playwright MCP | 2000-6000 tokens | 复杂 DOM 交互 | 中 |
| Playwright CLI | 约 Playwright MCP 的 1/4 | coding agent 优化版 | 中 |
| Chrome DevTools MCP | 中等 | 截图、调试 | 低 |
agent-browser 的优势只有一个，但这一条很关键：**token 效率最高**。它用精简的 YAML 摘要来表示页面状态，而不是把完整的 DOM 树 dump 到上下文里，每页只需要 200-400 tokens。对于“导航到某个页面，找到某个元素，提取数据”这类日常任务，它够用，而且便宜。
安装量 253K+（在 skills 生态里排前五），用户群体的反馈也很一致：日常任务首选，复杂 DOM 操作降级到 Playwright。
如果你的浏览器自动化任务涉及复杂的 Ja vaScript 交互、动态渲染内容、多步骤表单，Playwright CLI 是更合适的选择——微软 2026 年初专门为 coding agent 场景重新设计了这个工具，token 消耗是 Playwright MCP 的 1/4，并且把快照存到磁盘而不是塞进上下文。
图：四款浏览器自动化工具对比——agent-browser 在 token 效率上有压倒性优势
## frontend-design：解决一个真实问题
让 Claude 生成 UI 代码，结果总是差不多的样子：蓝白配色，Tailwind 默认类，圆角 Card 组件，Hero Section，样式上毫无特色。
这个现象有个专业名词叫“distributional convergence”——模型倾向于生成训练数据里最常见的输出，而“最常见的前端 UI”就是千篇一律的 SaaS 风格。
`frontend-design` 这个 skill 的做法很直接：它携带了 50 种具体的视觉风格方向（工业风、新表现主义、Glitch 美学……），每次生成 UI 时强制模型向其中某个方向偏移，而不是往“平均”方向走。
它解决的问题是真实的，564K+ 的安装量也说明这个需求确实很广泛。
**需要说清楚的是：** 它能给你一个“风格上有特色的 UI”，但不能给你一个“符合你们产品设计系统的 UI”。如果你的产品有成熟的设计语言，还是要靠 `brand-guidelines` skill + 设计 token 来解决——前者是补 Claude 的能力短板，后者是对齐你的设计系统，这两个问题本质上不一样。
## 你不需要装那些“技术栈专项” Skill
这是观察到的一个规律，值得单独说一下。
Skills 市场里有大量针对特定技术栈的 skill，比如“React 19 最佳实践”、“Vue 3 + TypeScript”、“Go 微服务规范”等等。这类 skill 的逻辑是：把某个技术栈的规范固化成 skill，Claude 就能自动遵守。
问题是：**Claude Sonnet 4 及以上的版本，已经具备了主流技术栈最佳实践的内置知识**。你加一个 900 token 的“React hooks 规范”skill，大概率是在告诉 Claude 它早就知道的事情。
真正有价值的是：**针对你们团队的具体规范**——你们的命名约定、你们的 PR 流程、你们特有的代码结构、你们踩过的特有的坑。这些东西模型不知道，写进 `CLAUDE.md` 或者自定义 skill 才有价值。
`skill-creator` 这个官方工具在这里是有意义的：它帮你构建自己的 skill，并且能做 A/B 测试，测量你的 skill description 激活率（经过优化后，激活率可以从 20% 提升到 90%）。
## 避坑清单：装之前先看这 4 件事
装任何一个 skill 之前，先检查这四点：
**1. `description` 是路由规则还是营销文案？**
好的 description 长这样：`"Use when user needs to interact with websites: na vigate pages, fill forms, click buttons, take screenshots"`
差的 description 长这样：`"A powerful skill that supercharges your Claude Code workflow with AI-powered productivity"`
前者让 Claude 知道什么时候该激活，后者会在不该激活的时候乱激活。
**2. `SKILL.md` 有没有 reference 文件分层？**
打开 skill 目录，看有没有 `references/` 子目录。有分层的 skill 说明作者考虑过 token 效率——核心逻辑在 SKILL.md，细节按需加载。全都堆在 SKILL.md 里的，装上去就是在浪费上下文。
**3. GitHub 的更新频率**
这是 2026 年一个特别重要的指标：模型在快速迭代，好的 skill 需要跟上模型能力的变化。一个半年没有更新的 skill，很可能在沿用老版本模型的行为假设来指导新模型，效果自然会打折扣。
**4. 先用 7 天再决定保留**
装一个 skill，用一周。如果一周之内你没有主动用过它，说明你的工作场景根本不需要它，直接卸载。Skills 不是装饰品，不用的占着 token 扫描空间，长期来看是负担。
## 常见问题
**Q：superpowers 和 claude-mem 可以一起用吗？**
可以，而且组合效果不错。superpowers 负责当次会话内的结构化工作流，claude-mem 负责跨会话的记忆沉淀。两者不冲突，只是 `brainstorming` 阶段 claude-mem 可能会注入旧的记忆，偶尔会产生干扰，留意观察就好。
**Q：用了这些 skills，Claude Code 的 API 费用会增加多少？**
有测试数据：superpowers 用于复杂多文件任务时，token 用量减少了 14%（因为减少了走偏后的返工）；但简单任务上，因为流程开销，用量会增加。综合来看，对于一个混合工作负载的开发者，整体 token 用量大致持平，差异不大。
agent-browser 相比 Playwright MCP，每次浏览器交互可以省下 2000-5600 tokens，累积起来节省相当可观。
**Q：社区 skill 和官方 skill 有什么区别，该优先选哪个？**
官方 skill（Anthropic 出品）的优势在于有质量保证和持续维护，但覆盖的场景有限。社区 skill 的优势在于能覆盖各种长尾场景，但质量参差不齐。建议是：官方 skill 无脑装，社区 skill 按照上面那 4 条检查标准来筛选。
**Q：如果只能选一个 skill，选哪个？**
对大多数后端或全栈工程师来说：`superpowers` 的 `brainstorming` skill 单独装（不装全套），或者 `claude-mem`。前者改变工作方式，后者积累复利。选哪个取决于你更缺哪个——是“做任务时少走弯路”，还是“下次不用重复交代背景”。
## 参考资料
* Superpowers GitHub — v5.1.0，187K stars（2026.05）
* claude-mem GitHub — 72.4K stars，259 releases
* Extend Claude with Skills - 官方文档
* Evan Schwartz 的 superpowers 评测 — 偏正面，值得一看
* I Tried 100 Claude Skills - DEV Community — 包含 70% 淘汰率的实测数据
说到底，1400+ 个 skills 里绝大多数是为了蹭生态热度写出来的，这没什么可奇怪的——任何一个新生态都会经历这个阶段。真正有价值的 skill，标准很简单：它解决一个 Claude Code 原生无法解决的问题，并且它的 description 精准到 Claude 能正确路由它。
按这个标准来筛选，现在日常在用的是 superpowers（部分 skill）+ claude-mem + agent-browser。其他的要么对我的工作场景没有覆盖，要么装上去之后发现 Claude 自己已经能做。
如果你身边也有人在纠结“要不要装 superpowers”或者“Skills 到底有没有用”，这篇可以直接甩过去，省得他们自己装了一堆再慢慢卸载。
下一篇打算拆解一下 claude-mem 的向量检索机制——为什么有时候它能精准找到三周前的那条记忆，有时候又像失忆了一样。
