187K star 的 superpowers 我用了三个月：没你想的那么香

187K star 的 superpowers 我用了三个月：没你想的那么香

三个月前初见 superpowers，我确实被震了一下——14 个 skill 装进去，Claude Code 直接变成一套完整软件工程流水线，TDD、代码审查、brainstorming 全覆盖。GitHub 187K star，测评文章喊“生产力提升 100 倍”，HN 置顶帖里工程师疯狂点赞。

用了三个月，结论是：**它确实有价值，但不是对所有人、所有场景**。整个 Claude Code Skills 生态里，包装远比内容强的东西太多了。

背景与为什么现在值得关注

截至 2026 年 5 月，GitHub 上有 1400+ 个 Claude Code Skills，官方 marketplace 收录超 658 个。我自己用过 40+ 个，帮团队清理过 skill 列表，结论很明确：**真正能留在日常工作里的，不超过 10 个**。

技术原理不复杂：一个 `SKILL.md` 文件，YAML frontmatter 写 name 和 description，正文是 Markdown 指令，放进 `~/.claude/skills/` 就能用。Claude 处理请求时用约 100 tokens 扫描所有 skill 的 name 和 description 判断是否激活，激活后才加载完整内容（通常 < 5k tokens）。装 50 个 skill 的额外开销只有 5000 tokens 左右，代价不高。

但这也意味着任何人都能下午写个 skill 发到 GitHub，起个响亮名字，收获一堆 star。有人测试过 100 个社区 skill，70% 不合格。失败原因高度集中：`SKILL.md` 太臃肿（4000+ tokens），无关任务白白消耗上下文；description 写的是营销文案而非路由规则，Claude 不知道何时激活；single-file 包揽一切，五件事塞进一个 skill 哪件都做不精；没有 reference 文件分层，关键逻辑堆在 `SKILL.md` 里，激活一次就吃掉大量上下文。

好 skill 是精准的：description 像路由规则不像宣传语；核心 `SKILL.md` 精简，细节推到 `references/` 按需加载；一个 skill 只做一件事。判断值不值得装，先看 `SKILL.md` 前 50 行，读完不清楚它干什么，扔掉。

对数字产品/软件工具/AI 从业者的启示

**superpowers：真实体验是什么**

superpowers 是整个生态最成功的 skill 集合，从 2025 年 10 月发布到现在 187K 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 做新功能，典型失败模式是：对着模糊需求直接开写，写完发现方向不对，花 2 倍时间重写。superpowers 的 brainstorming 强制你在动代码前把需求想清楚——不是催你写文档，是用一系列问题问出“你其实想要什么”。对照实验：12 个会话，一半用一半不用，同等复杂度任务，superpowers 组 token 用量降 14%，代码质量（PR review 问题数）提升明显。原因很直觉：规划阶段的 token 消耗，远比方向跑偏后重写省。

但它有明显局限。第一，简单任务被拖慢。“帮我写个正则”、“加个 console.log”——被 brainstorming 拦截后要花 10-20 分钟前置流程，完全不值。HN 工程师反馈“Claude 做简单事变得超级啰嗦”，真实存在。第二，计划修改体验差。生成多页计划后想改一小部分，它会整个重新生成。开发者原话：“你给它反馈，它返回一个全新版本的多页计划，而不是只改你提到的那部分。”第三，TDD 规则对模型太强制。要求先写测试再写实现，没有失败测试就删除已写代码。机制本身对，但探索性阶段“先跑起来再说”的需求真实存在。

我最终策略是**有选择地激活**。做新功能、重构、有明确边界的模块，用完整流程。修 bug、加小功能、写一次性脚本，直接用 stock Claude Code。using-superpowers 提供灵活性——可以只装 brainstorming + systematic-debugging，不装全套。

**claude-mem：被低估的那个**

superpowers 讨论最多，但 claude-mem 我觉得最被低估。它解决一个具体问题：Claude Code 每个会话独立，昨天讨论的设计决策、踩的坑、确认的命名规范，今天全没了。claude-mem 的方案：会话结束时把有价值内容压缩成“记忆片段”，存本地（SQLite + Chroma 向量数据库）。下次会话开始自动检索相关记忆，注入 system prompt。目前 72.4K star，v12.6.4（2026 年 5 月），259 个 release，109 个贡献者。

它最有价值的地方：多天迭代项目，第二天不用重新交代“我们用 PostgreSQL 不是 MySQL，因为……”；踩坑记录自动浮现；团队规范说一次“函数命名用动词+名词”之后不用反复说。

真实局限：最大风险是**记忆噪声**。它会记住一切，包括错误假设、临时决策、后来被推翻的方案。不定期清理，检索到的“相关记忆”反而误导 Claude。我踩过这个坑——某次临时测试说“先这样试试”，claude-mem 记住了，之后几次会话 Claude 都参照这个“临时方案”工作，搞了很久才发现。另外它不能替代代码注释和文档。稳定架构决策应写进 CLAUDE.md 和代码注释，不该只活在记忆库里——记忆会过期、被覆盖、产生歧义，代码注释不会。正确用法：把 claude-mem 当“对话记录的增强索引”，不是“架构知识库的替代品”。

**agent-browser：做浏览器自动化就用这个**

让 Claude Code 操作浏览器，2026 年主流选项：agent-browser（200-400 tokens/页，日常浏览、表单、导航，安装复杂度低）、Playwright MCP（2000-6000 tokens/页，复杂 DOM 交互，安装复杂度中）、Playwright CLI（约 MCP 的 1/4，coding agent 优化版）、Chrome DevTools MCP（中等，截图、调试）。

agent-browser 优势只有一个，但很关键：**token 效率最高**。用精简 YAML 摘要表示页面状态，不 dump 完整 DOM 树，每页只需 200-400 tokens。“导航到某页、找元素、提取数据”这类日常任务够用且便宜。安装量 253K+（生态前五），用户反馈一致：日常

来源

来源：https://juejin.cn/post/7689018123110957096