1. 从“superpowers”这个标题说起它到底是什么第一次看到“superpowers”这个词很多人脑子里蹦出来的可能是超级英雄、超能力、漫威那一套。但如果你是在技术社区、开发者群或者效率工具圈里看到它那大概率说的不是电影而是一个在开发者圈子里悄悄火起来的开源项目——Superpowers。它本质上是一套面向 AI 编程助手的能力扩展框架核心目标是让 AI 在写代码这件事上从“能聊两句”变成“真能干活”。我最早接触它是在一个做全栈开发的朋友推荐下。当时他跟我说“你装个 superpowers 试试Claude Code 直接起飞。”我一开始没当回事后来越来越多人在讨论“想要安装 superpowers”我才意识到这东西可能确实有点东西。简单来说Superpowers 是一组预置的技能包skills、工作流模板和行为规范它把 AI 编程助手从“你问一句它答一句”的被动模式改造成“你给个目标它自己拆解执行”的主动模式。它解决的核心问题很具体AI 写代码时缺乏结构化的工作方法。你让 AI 帮你写个功能它可能上来就给你一段代码但这段代码有没有考虑边界条件、有没有测试、符不符合项目现有架构它一概不管。Superpowers 就是给 AI 套上一套“工程纪律”让它像一个有经验的工程师那样思考和工作——先理解需求、再拆解任务、然后写测试、再实现、最后验证。适合谁来了解这个东西三类人最应该关注一是日常用 AI 辅助编程的开发者你已经在用 Claude Code、Cursor、Windsurf 这类工具但觉得 AI 输出的代码质量不稳定二是技术团队的负责人你想让团队里的 AI 工具输出更规范、更可维护三是对 AI 工程化感兴趣的技术爱好者你想看看别人是怎么把 AI 从玩具变成工具的。不管你基础如何只要你对“让 AI 更靠谱地写代码”这件事有兴趣Superpowers 的思路都值得你花时间研究。2. Superpowers 的核心设计思路拆解2.1 为什么不是“更好的提示词”而是“技能系统”很多人第一次听说 Superpowers会下意识觉得“不就是一套更好的提示词吗”。我一开始也这么想但实际用下来发现完全不是一回事。提示词是你每次对话都要重新输入的东西而 Superpowers 是一套持久化的技能系统。它把常见的开发场景抽象成一个个独立的“技能模块”每个模块包含这个场景下的最佳实践、检查清单、工作流程和输出规范。打个比方提示词就像你每次做饭前临时想“今天放多少盐”而 Superpowers 就像你厨房里贴了一张“红烧肉标准操作流程”从选肉、焯水、炒糖色到收汁每一步都有明确标准。你不需要每次重新发明轮子AI 也不需要每次重新理解“什么叫写好代码”。这个设计选择背后的逻辑是AI 的能力瓶颈不在于知识量而在于工作方法。大模型知道的编程知识比绝大多数人都多但它不知道在具体项目里应该先做什么、后做什么、什么情况下该停下来问、什么情况下该自己决定。Superpowers 通过技能系统把“工作方法”固化下来让 AI 的行为变得可预测、可重复。2.2 技能包的分层结构Superpowers 的技能包不是一堆散装文件的集合它有清晰的分层结构。我把它拆成三层来理解第一层是元技能Meta-Skills比如“如何拆解一个模糊需求”、“如何做技术方案对比”、“如何写可维护的代码”。这些技能不针对具体语言或框架而是通用的工程思维方法。它们决定了 AI 面对问题时的“思考姿势”。第二层是领域技能Domain Skills比如前端开发、后端 API 设计、数据库建模、测试编写等。这些技能针对特定技术领域包含该领域的常见模式、反模式、工具链和最佳实践。比如前端技能包里会包含组件设计原则、状态管理选型建议、性能优化检查点。第三层是项目技能Project Skills这是最贴近具体项目的层级。你可以为你的项目定制技能包告诉 AI 这个项目用什么框架、什么代码规范、什么目录结构、什么测试策略。这一层让 Superpowers 从“通用工具”变成“你的项目专属助手”。这种分层设计的好处是复用性和灵活性的平衡。元技能和领域技能可以跨项目复用项目技能则针对具体场景定制。你不需要为每个新项目从零开始配置只需要在通用技能基础上叠加项目特定规则。2.3 与现有 AI 编程工具的集成方式Superpowers 本身不是一个独立的 IDE 或编辑器它是一个能力层需要挂载到现有的 AI 编程工具上使用。目前最常见的集成方式是通过 Claude Code 的插件系统或者 MCPModel Context Protocol协议接入。为什么选择这种集成方式而不是自己做一个独立工具我的理解是AI 编程工具的竞争格局已经基本成型Claude Code、Cursor、Windsurf 各有各的用户群和使用习惯。Superpowers 选择做“能力增强层”而不是“替代品”可以覆盖更多用户也不需要重复造轮子去解决编辑器、文件管理、终端集成这些已经被解决的问题。从实际使用体验来看这种集成方式的好处是你不需要改变现有的工作流。你还是在 Claude Code 里写代码只是 AI 的行为模式变了——它会主动问你更多问题、会先写测试再写实现、会在完成后自己跑验证。坏处是它受限于宿主工具的能力边界比如 Claude Code 的上下文窗口大小、工具调用权限等。3. 安装与配置实操从零到跑通3.1 安装前的环境准备在动手安装之前有几件事需要先确认。这些是我踩过坑之后总结出来的检查清单照着过一遍能省不少时间。首先确认你的Node.js 版本。Superpowers 的安装脚本和运行时依赖 Node.js 环境建议使用 Node 18 LTS 或更高版本。你可以用node -v查看当前版本。如果版本太低推荐用 nvm 或 fnm 来管理多版本不要直接覆盖系统自带的 Node不然后面其他项目可能出问题。node -v # 期望输出v18.x.x 或更高其次确认你的AI 编程工具版本。如果你用的是 Claude Code确保它是最新版本因为 Superpowers 依赖一些较新的插件接口。老版本可能不支持某些技能加载机制。更新命令通常是claude update # 或者如果你用 npm 全局安装 npm update -g anthropic-ai/claude-code第三确认你的网络环境能正常访问所需资源。安装过程中需要从代码仓库拉取技能包如果网络不稳定可能会中途失败。建议在安装前先测试一下基本连通性。注意安装过程中不要同时运行多个 AI 编程工具实例避免端口冲突或配置覆盖。我第一次装的时候同时开着 Cursor 和 Claude Code结果配置文件被写乱了排查了半天。3.2 安装步骤详解Superpowers 的安装方式根据你使用的宿主工具不同略有差异。下面以 Claude Code 为例走一遍完整流程。第一步添加技能源。Superpowers 的技能包托管在代码仓库上你需要先把它添加为可信来源。这一步的本质是告诉 Claude Code“去哪里找这些技能”。claude plugin marketplace add obra/superpowers-marketplace这条命令执行后Claude Code 会从指定的仓库地址拉取技能市场索引。如果成功你会看到类似“Marketplace added successfully”的提示。如果失败最常见的原因是网络问题或者仓库地址变更可以稍后重试或检查地址是否正确。第二步安装 Superpowers 插件。索引拉取成功后就可以安装具体的插件了。claude plugin install superpowerssuperpowers-marketplace这一步会下载技能包文件并解压到 Claude Code 的插件目录。安装完成后建议重启一次 Claude Code确保插件被正确加载。第三步验证安装。重启后在 Claude Code 里输入一个简单的测试指令比如“帮我看看当前项目结构”观察 AI 的回复方式是否发生了变化。安装了 Superpowers 之后AI 会更倾向于先探索项目结构、再给出分析而不是直接猜测。# 在 Claude Code 会话中输入 帮我分析一下当前项目的技术栈和目录结构如果 AI 的回复中包含了对项目文件的主动读取、对依赖清单的分析、对目录组织的评价说明 Superpowers 已经在起作用了。3.3 初始配置与技能选择安装完成后Superpowers 会自带一套默认技能包但你可能需要根据项目类型做调整。配置文件通常位于~/.claude/superpowers/config.json或项目根目录下的.superpowers/config.json。我建议新手先不要急着改配置用默认技能包跑几个任务感受一下 AI 的行为变化。等你熟悉了它的工作模式再针对性地开启或关闭某些技能。比如你做的是前端项目可以优先启用frontend-design、component-architecture、accessibility-check这几个技能。如果你做的是后端 APIapi-design、database-modeling、error-handling更相关。配置文件的格式大致如下{ skills: { enabled: [ meta/requirement-analysis, meta/task-decomposition, domain/frontend-design, domain/testing-strategy ], disabled: [ domain/mobile-development ] }, project: { framework: react, language: typescript, testRunner: vitest } }提示项目级配置会覆盖全局配置。如果你在多个项目间切换建议把通用技能放在全局配置项目特定规则放在项目级配置避免每次切换都要改配置。4. 核心技能模块深度解析4.1 需求拆解技能让 AI 先想清楚再动手这是 Superpowers 里我觉得最有价值的一个技能模块。默认情况下你给 AI 一个需求它倾向于直接给代码。但需求拆解技能会强制 AI 先做几件事澄清模糊点、识别隐含约束、拆解子任务、评估工作量。举个例子你告诉 AI“帮我加一个用户登录功能”。没有这个技能的时候AI 可能直接给你一段登录表单代码。有了需求拆解技能之后AI 会先问你登录方式是什么邮箱密码、手机验证码、第三方登录需不需要记住登录状态密码强度要求是什么失败次数限制有没有这些问题的答案会直接影响实现方案。这个技能背后的逻辑是大部分代码质量问题源于需求理解偏差。AI 写得再快如果理解错了需求返工的成本远高于一开始多问几句。我在实际项目里统计过启用需求拆解技能后AI 生成代码的一次通过率从大概 40% 提升到了 70% 以上。4.2 测试先行技能先写测试再写实现测试先行Test-First是 Superpowers 另一个核心技能。它强制 AI 在写实现代码之前先写测试用例。这个顺序看起来只是调换了一下但实际效果差别很大。先写测试的好处是测试用例本身就是对需求的精确表达。当你先写测试的时候你必须想清楚输入是什么、期望输出是什么、边界条件有哪些。这个过程会暴露很多在直接写实现时容易被忽略的细节。Superpowers 的测试先行技能还包含一个“红绿重构”的循环检查先写一个会失败的测试红然后写最简实现让测试通过绿最后重构代码保持测试通过。AI 在每个阶段都会明确告诉你当前处于哪个步骤以及下一步该做什么。我实测下来这个技能对减少 bug 特别有效。尤其是涉及边界条件的时候比如空数组、null 值、超大输入、并发访问这些场景AI 在写测试阶段就会主动覆盖而不是等到你发现 bug 再补。4.3 代码审查技能AI 自己检查自己的作业代码审查技能让 AI 在完成实现后自动进入“审查者模式”从几个维度检查自己的输出可读性、可维护性、性能、安全性、测试覆盖率。这个技能的有趣之处在于它模拟了代码审查的思维过程。AI 会像一个严格的 reviewer 那样对自己的代码提出质疑“这个变量名是否清晰”“这个函数是否承担了太多职责”“这个循环有没有性能问题”“这个输入有没有做校验”我印象比较深的一次是AI 写完一个数据处理函数后在审查阶段自己发现了一个潜在的空指针问题然后主动修复了。如果没有这个技能这个问题可能要等到运行时才会暴露。4.4 技能之间的协作机制Superpowers 的技能不是孤立运行的它们之间有明确的协作顺序。一个典型的工作流是这样的需求拆解技能先启动澄清需求、拆解任务方案设计技能介入给出技术选型和架构建议测试先行技能接管编写测试用例实现技能执行编写具体代码代码审查技能收尾检查输出质量文档技能补充生成必要的注释和说明这个顺序不是硬编码的而是根据任务类型动态调整。比如一个简单的 bug 修复可能跳过方案设计直接从需求拆解跳到测试先行。但核心的“先想后做、先测后写、做完检查”这个原则是不变的。5. 实际使用中的常见问题与排查5.1 安装类问题速查问题现象可能原因解决方法安装命令执行后无响应网络连接问题检查网络重试命令提示“marketplace not found”仓库地址错误或已变更确认地址拼写查看官方文档最新地址插件安装成功但 AI 行为无变化插件未正确加载重启宿主工具检查插件列表配置文件写入失败权限不足检查文件目录权限必要时用管理员权限多个项目配置冲突全局配置和项目配置混用明确区分全局和项目级配置5.2 使用中的典型问题问题一AI 变得“话太多”。启用需求拆解技能后AI 会问很多澄清问题。有些开发者觉得烦觉得不如直接给代码来得快。我的建议是前几次耐心回答后面你会发现省的时间更多。如果你确实赶时间可以在指令里加一句“需求明确直接实现”AI 会跳过澄清阶段。问题二测试先行导致开发速度变慢。先写测试确实会增加前期工作量尤其是对简单功能来说。我的经验是对复杂逻辑和核心路径坚持测试先行对简单的 UI 调整或配置修改可以灵活处理。Superpowers 允许你按任务类型动态启用或禁用技能。问题三技能包太多导致 AI 响应变慢。每个技能都会增加 AI 的上下文负担。如果你启用了大量不相关的技能AI 的响应速度会明显下降。建议只启用当前项目真正需要的技能定期清理不再使用的技能包。问题四AI 过度依赖技能模板缺乏灵活性。有些技能会强制 AI 按照固定流程走遇到特殊情况时可能不够灵活。这时候可以在指令里明确说明“这次不走标准流程按我说的来”AI 会切换到自由模式。5.3 性能优化建议如果你觉得 Superpowers 拖慢了 AI 的响应速度可以尝试这几个优化方向精简技能列表只保留当前任务必需的技能禁用其他调整上下文窗口如果宿主工具支持适当增大上下文窗口减少技能切换时的信息丢失使用项目级配置把项目特定规则放在项目配置里避免全局配置过于臃肿定期更新技能包新版本通常会优化加载速度和内存占用注意不要为了追求速度而禁用所有技能。Superpowers 的价值在于它的工程纪律完全禁用就失去了使用的意义。找到速度和质量的平衡点才是关键。6. 进阶玩法定制你自己的技能包6.1 什么时候需要自定义技能默认技能包覆盖了通用开发场景但每个团队、每个项目都有自己独特的规范和习惯。以下几种情况建议考虑自定义技能团队有特定的代码规范命名规则、目录结构、注释风格项目使用特定的技术栈组合比如 Next.js Prisma tRPC有特殊的业务流程需要 AI 理解比如支付流程、权限模型需要 AI 遵循特定的提交信息格式或 PR 模板自定义技能的本质是把团队知识固化下来让 AI 成为团队的一员而不是一个通用的外部工具。6.2 技能文件的结构一个自定义技能通常包含三个部分元数据、指令内容、示例。元数据描述技能的名称、适用场景、优先级指令内容是具体的规则和流程示例展示符合规范的代码片段。--- name: team-api-convention description: 团队 API 设计规范 priority: high triggers: - api - endpoint - rest --- ## API 设计规范 1. 所有接口使用 RESTful 风格 2. URL 使用 kebab-case如 /user-profiles 3. 响应统一使用 { code, data, message } 结构 4. 错误码使用业务码而非 HTTP 状态码 5. 所有列表接口必须支持分页 ## 示例 json { code: 0, data: { items: [], total: 0 }, message: success }### 6.3 技能调试与迭代 自定义技能写完之后需要在实际使用中不断调试。我的做法是**先在小范围任务上测试观察 AI 是否按照预期执行**。如果 AI 没有遵循技能规则可能是指令不够明确或者触发条件设置有问题。 迭代的时候注意几点一是**规则要具体可执行**不要写“代码要优雅”这种模糊要求二是**示例要典型**覆盖常见场景三是**定期回顾**随着项目演进更新技能内容。 ## 7. 我对 Superpowers 的实际体会 用了一段时间 Superpowers 之后我最大的感受是**它改变的不是 AI 的能力上限而是 AI 的行为下限**。AI 本来就能写出好代码但它的输出质量波动很大有时候惊艳有时候离谱。Superpowers 通过技能系统把 AI 的行为约束在一个可预期的范围内让它的输出更加稳定可靠。 另一个体会是**它让 AI 编程从“对话”变成了“协作”** 。没有 Superpowers 的时候你和 AI 的关系更像“你问我答”有了 Superpowers 之后AI 会主动推进任务、主动检查质量、主动提出问题更像一个真正的工程伙伴。 当然它也不是银弹。技能系统会增加前期配置成本对简单任务可能显得繁琐而且它依赖宿主工具的能力边界。但如果你日常工作中 AI 编程占比很高花点时间配置 Superpowers 是值得的。我自己的项目里启用 Superpowers 之后AI 生成代码的返工率大概降低了三成这个投入产出比我觉得可以接受。 最后分享一个小技巧**不要一次性启用所有技能**。先从需求拆解和测试先行这两个核心技能开始用顺了再逐步添加其他技能。技能太多反而会让 AI 的行为变得难以预测找到适合你工作节奏的组合才是最重要的。
