最近大半年我把主要精力都放在了 AI 编程助手的深度使用上尤其是 Claude Code 这类 Agent 工具。用得越深越能感觉到一个事实真正拉开体验差距的不是你用的是哪家大模型而是你给模型配了哪些“技能”。今天想聊的 Superpowers 就是一个很典型的项目一套不断增长的 Plugins、Skills、Shortcuts、Workflows 集合本质上就是给 AI 编码代理装一套“外挂”让它从“能听懂人话”进化成“能自己规划、自己干活、自己验收”。如果你正在做 AI 辅助开发、带团队落地 Agent 工作流或者想从手写代码切到 AI 自主开发这套技能包会是一个非常值得研究的样本。1. 什么是 Superpowers给 AI 助手装上“职业素养”1.1 从“帮你写代码”到“替你管项目”我最早接触 AI 编程助手时用的还是最朴素的补全模式我写注释它补函数我写测试它补实现。这种模式在写单个函数、改局部逻辑时很顺手但一旦任务变成“给这个模块加一个新功能”助手就开始犯迷糊了。它不知道要先读哪些文件、要考虑哪些边界情况、改了 A 会不会影响 B结果就是你必须在提示词里把上下文手动塞满周而复始。Superpowers 解决的就是这个问题。它不是一个单一插件而是一整套组织好的技能生态让 AI 助手在接到任务时不再“想到哪写到哪”而是会先做方案拆解、再列执行计划、用测试驱动的方式一步步实现、最后自查代码质量。说得直白一点它是在教 AI 怎么做工程而不是怎么写代码片段。这个项目把关键词定成了三个Autonomy自主、Intelligence智能、Love热爱。翻译成实际操作语言就是让 AI 拥有独立规划并执行任务的能力把一线工程师的经验总结成可复用的方法论同时对细节保持足够挑剔。1.2 四大组成模块Plugins、Skills、Shortcuts、WorkflowsSuperpowers 官方对自己的定义是“a growing collection of Plugins, Skills, Shortcuts, and Workflows”这四类东西是理解它的钥匙。Plugins插件是整个体系的分发单元一个插件可以打包多个技能、配置和依赖脚本。装插件就像往工具箱里放一套完整工具而不是一个一个地去下载零散脚本。Skills技能每个技能是一个“操作手册 执行脚本”的组合。它告诉 AI 在什么情境下触发什么动作、按照什么步骤走、输出什么格式。典型的有 brainstorming、debugging、test-driven-development 等。Shortcuts快捷指令一系列斜杠命令比如在对话里输入/brainstorming、/planAI 就会知道当前该进入哪种工作模式。这是减少重复打字、规范交互入口的核心机制。Workflows工作流把多个技能串起来形成一条完整的流水线例如“头脑风暴 - 写计划 - TDD 实现 - 代码审查”。单个技能解决单点问题工作流解决端到端问题。1.3 为什么说它和普通提示词模板不一样可能有人觉得这不就是一堆提示词吗我自己刚开始也有这个疑问。但真正用下来会发现它跟散落在网上的“AI 提示词大全”有本质区别每个技能不止有“话术”还有配套的执行脚本和触发条件。拿 debugging 技能举例它不会只告诉 AI“请仔细调试”而是给 AI 一套固定的调试动作先收集错误信息再写最小复现再逐步缩小搜索范围最后修复并验证。AI 会按照这个脚本一步一步执行而不是拿一句“根据我的经验问题可能出在 X”来糊弄你。这种“提示词 脚本 校验”的结构才是 Superpowers 能被看成插件生态而不仅仅是模板库的原因。2. 核心机理技能、插件、工作流到底是怎么协同的2.1 技能Skills机制AI 的“操作手册”在 Superpowers 的体系里每个技能本质上是一个目录目录里包含一个SKILL.md文件以及若干辅助脚本或数据文件。SKILL.md用结构化的方式描述这个技能的名称、适用场景、使用步骤、注意事项AI 在读取之后会把其中的步骤当作自己的行为准则来执行。关键点在于触发方式。技能可以在两种情况下被激活一种是用户在对话里主动输入对应的快捷指令另一种是 AI 在任务执行中根据上下文自动判断该启用哪个技能。后者对 Agent 的意义很大因为这意味着 AI 可以在无人干预的情况下自己从工具库里挑合适的工具来处理当前问题。技能还会附带前置条件和预期输出格式。例如 test-driven-development 技能会要求 AI 在写任何实现代码前先写出失败测试然后才进入实现阶段。这些约束让 AI 的输出不再是“自由发挥”而是符合工程规范的结构化产物。2.2 插件Plugins机制生态的“发布单元”为什么要有插件层因为单个技能太零碎了用户如果需要一个一个地去安装、维护、升级成本会非常高。插件机制把一组相关的技能封装成一个整体用户只需要安装一个插件就能获得一整组能力。从技术实现上看插件目录的安装很简单本质上就是把仓库 clone 到本地配置目录然后由 Agent 工具读取并加载其中的技能和配置。这也是它跨工具适配的基础——只要兼容目录结构和读取规则Claude Code、Codex、以及各种基于 Agent 的工具都能用上同一套技能包。安装插件时项目中会生成一个配置文件记录插件来源、版本和启用的技能列表。你可以把这个配置文件提交到代码仓库这样团队所有成员用到的 AI 行为就完全一致了。2.3 快捷键与斜杠命令人机协作的“手势”Superpowers 把常用入口都做成了斜杠命令例如/skills查看全部技能、/superpowers进入主菜单、/plan进入规划模式。这看起来像个小细节但实际使用中非常关键。如果没有这些命令用户就得每一次都用自然语言描述“请你先做规划评估三个方案然后列出步骤”既啰嗦又不稳定。斜杠命令还有一个隐藏好处它相当于给 AI 做了“状态标记”。比如你输入/debuggingAI 就会切换到调试模式之后的回复都会围绕调试流程展开而不会突然跑偏去给你重构代码或者讲解概念。这种模式切换能力对长对话尤其重要能显著减少 AI“自作主张”的概率。2.4 工作流编排把单点技能串成工程流水线单技能解决单点问题但真实任务往往是复合的。Superpowers 的 Workflows 就是把这些技能串成流水线。比如一个功能开发的完整流程可能是先调用 brainstorming 发散方案再用 choosing 技能做决策接着写 plan然后进入 test-driven-development 循环实现最后用 review 技能做代码自检。这个设计让我想到传统软件工程里的 SOP。单个工程师再牛也得按照一套流程来保证产出质量。Agent 也是一样有了流程的约束它在每个节点的行为都变得可预期了。当你把 Agent 从“写代码的”培养成“按流程干活的”它的可靠性会提升一个台阶。3. 安装与上手把 Superpowers 跑起来的完整流程3.1 前置环境要求在动手安装之前先确认你手头的环境满足条件一个支持 Agent Skills / Plugins 机制的 AI 编程工具比如 Claude Code、Codex 或同类兼容工具。Git 已安装用于拉取插件仓库。Node.js 环境部分技能依赖本地脚本运行。能够正常访问网络因为技能发现和插件拉取都需要联网。如果你用的工具版本比较老建议先升级到最新版技能目录和插件接口的兼容性是持续在变的。3.2 安装插件的具体操作安装 Superpowers 最直接的方式是通过插件市场命令。以 Claude Code 为例在对话窗口里依次执行/plugin marketplace add obra/superpowers /plugin install superpowers第一条命令把插件市场注册到当前环境第二条命令把插件本体安装下来。安装完成后会有日志提示插件包含多少个技能、多少个快捷指令。如果你不在 Claude Code 环境里也可以手动操作将仓库 clone 到对应的技能目录例如~/.claude/skills或项目根目录下的.claude/skills然后重新启动会话。这里有个容易踩的坑克隆技能仓库时要注意目录层级。Agent 读取技能时一般只扫描指定目录下的下一级子目录每个子目录对应一个技能。如果你把仓库整个克隆进来技能被套在多层文件夹里AI 就会一个也认不出来。3.3 验证安装是否成功装完先别急着干大事用一个小项目验证一下。我在第一次安装后做了三个快速检查输入/skills确认技能列表里能看到 brainstorming、debugging、test-driven-development 等核心项。输入/superpowers看是否弹出可交互的菜单或指令提示。新建一个临时文件输入/brainstorming然后描述“我想给这个项目加一个用户登录功能”看 AI 是否按结构化方式输出多个方案、优缺点对比、推荐结论而非随便说几句。如果这三步都通过说明插件加载正常。如果第二步没反应多半是会话启动时没有重新加载配置重启一个对话再试。3.4 常用快捷指令速查快捷指令作用/superpowers进入插件主菜单查看所有功能入口/skills浏览已安装技能详情、触发条件/brainstorming进入发散式方案讨论模式/plan制定分步执行计划/todo生成任务清单并跟踪完成状态/debugging进入结构化调试流程/test-driven-development强制先写测试再写实现/review对当前改动做代码自审需要注意不同版本对命令的命名可能略有调整/superpowers本身是当前版本的主入口后续版本可能会扩展更多别名。4. 几个核心技能的深度剖析4.1 Brainstorming先发散再收敛AI 终于不急着动手了默认情况下AI 收到请求后容易立刻给出一个“看似合理但缺乏比较”的答案。Brainstorming 技能强制它先进入发散模式生成至少三个不同的实现方向再逐个分析利弊最后给推荐。我在实际项目中用它做过一次数据库选型讨论。当时团队在 SQLite 和 PostgreSQL 之间犹豫我只把背景信息丢给 AI它就开始按 brainstorming 的流程展开先列出三种方案SQLite、PG、甚至方案式地考虑托管数据库然后从并发量、部署复杂度、备份恢复、团队熟悉度等维度分别评估最后给出推荐和理由。整个过程有理有据甚至比很多同事的讨论纪要还结构化。这个技能改变的是提问方式而不是生成内容的能力。就算不用 Superpowers你也可以手动让 AI “先给三个方案逐个比较”但问题在于你每次都要重复这些约束词。技能化之后一次命令搞定而且格式永远保持一致。4.2 Debugging把“我觉得”变成“我验证”AI 调试代码最让人诟病的一点就是经常一本正经地猜错原因。Debugging 技能做的第一件事就是禁止 AI 直接给猜测答案。它要求 AI 先向用户索要错误日志、复现步骤尝试构造最小复现用例再通过二分定位的方式缩小排查范围最后修复并跑验证。我印象最深的一次是排查一个偶发的内存泄漏问题。AI 按照技能步骤先让我提供稳定的复现条件然后它自己在代码里插桩打印对象生命周期逐步排除可疑模块最终把问题定位到一个缓存未清理的工具函数上。这要是换成默认模式AI 大概率会直接回答“你的缓存没设置过期时间”然后给出一个毫不相关的修复代码。Debugging 技能本质上是把调试方法论中的标准流程写成了强制步骤。它最厉害的地方在于防呆哪怕 AI 的基础能力弱一些只要严格按流程走也不会出现离谱的武断结论。4.3 Test-Driven Development从“补测试”到“测试先行”TDD 技能在 Agent 场景下特别值得尝试。它给 AI 定了铁律必须先写出会失败的测试再实现代码让测试通过然后重构。这套规则对 Agent 来说极其友好因为 AI 本质上不具备人类那种“灵感突现”的能力它需要一种可验证、可反馈的循环来推进工作。我试过让 AI 用 TDD 技能实现一个解析器。它会先根据需求写出针对规则匹配的测试用例跑一次确实是红的然后才开始写实现代码跑绿之后还会主动补边界测试。整个过程就像有个工程师在旁边盯着它做红绿循环。更有意思的是TDD 技能还能反向约束用户需求。因为 AI 无论如何都要先写测试它会反过来跟你确认输入输出格式把模糊需求转化成可验证的例子。这个过程对需求澄清非常有帮助很多原本没想清楚的细节都会被测试用例逼出来。4.4 技能发现从社区生态里动态补充能力Superpowers 不只是一个固定集合它有技能发现机制。通过/skills命令AI 可以浏览本地已安装的技能也可以了解社区中可用的新技能。这个机制让整个生态保持增长状态而不是装完就一潭死水。社区技能的质量参差不齐我的筛选标准很朴素优先选择带完整SKILL.md说明和配套测试的技能检查技能是否依赖过多的外部脚本留意技能触发条件写得是否具体。一个触发条件模糊的技能要么永远不触发要么在不该触发的时候乱触发。5. 实操经验与避坑指南5.1 CLAUDE.md 与技能目录怎么配合Superpowers 的技能目录可以放在用户级目录也可以放在项目级目录。用户级技能对所有项目生效项目级技能只对当前项目生效。我的建议是通用技能放用户级比如 brainstorming、debugging跟具体项目强相关的技能放项目级比如特定框架的代码规范检查。服务体系里有个重要文件叫CLAUDE.md它存放项目的全局说明和规范。技能的工作是定义“怎么做”而CLAUDE.md定义“做什么、遵循什么约束”。两者有重叠的时候建议以CLAUDE.md为准。我习惯在CLAUDE.md里写明技术栈、目录结构和不可触碰的敏感区域技能负责具体执行流程。5.2 技能冲突与优先级问题技能装多了之后冲突一定会出现。最典型的是多个技能都监听同一类任务AI 不知道该启用哪一个。我的处理办法是在技能名或用例描述里写得足够具体同时在CLAUDE.md里声明优先级规则比如“凡涉及数据库迁移的任务一律使用 migration-workflow 技能不使用 generic-workflow”。如果你发现 AI 总是选错技能可以打开对应技能的SKILL.md检查它的触发条件描述是不是太泛了。比如“当用户需要修复 bug 时”这种描述几乎涵盖所有场景和 debugging 技能必然冲突。把触发条件改成“当用户给出错误堆栈或测试失败信息时”触发准确率会明显提高。5.3 自定义工作流的几个要点Superpowers 允许你自己定义工作流但我不建议一上来就搭一个大而全的流程。我做自定义工作流时的步骤很简单先单独验证每个环节的技能好使再串流程串流程时保持每一步输入输出格式清楚给整个工作流写一份说明告诉 AI 什么情况下走完整流程、什么情况下可以跳过某些步骤。还要注意控制工作流的复杂度。一个工作流如果嵌套了七八个技能AI 在长对话中很容易丢失上下文输出质量反而下降。我的经验是最多四个环节超过四个就拆成两个工作流通过命令触发。5.4 性能与 token 消耗的观察技能和插件不是免费的每个技能在进入上下文时都会加载一段说明文本占用的 token 会叠加。我实测下来装了几十个技能之后每次会话初始化都会比裸环境多消耗几千 token。这个数字在短对话里无所谓但在长会话里会推高成本。更明显的性能影响体现在技能脚本调用上。有些技能会调用外部命令比如搜索文件、运行测试、拉取数据这些操作本身有耗时会让 AI 的响应速度明显下降。我的优化策略是项目级目录只放当前项目需要的技能用户级目录定期清理不用的插件避免 AI 在技能之间漫游。6. 应用场景与影响范围6.1 个人开发者的“超级工作流”对个人开发者来说Superpowers 最有价值的场景是单人维护多个项目的时候。以前我切换项目时脑子里的“项目背景”要重新加载现在这些背景写在了项目配置和技能目录里AI 比我记性还靠谱。一个典型的流程开会接收需求 - 用 brainstorming 让 AI 给方案 - 用 plan 生成任务清单 - 用 TDD 实现 - 用 review 自检 - 提交代码。一个人能干出一个小团队的活。6.2 团队协作中的“标准作业程序”团队场景下Superpowers 的价值会进一步放大。你可以把团队的代码规范、审查清单、发布流程都做成技能提交到仓库。新成员加入后不需要再花大量时间口头交底AI 会按照团队既定的工作流辅助他干活。审查代码时review 技能也会按照团队定义的检查项逐条过比人肉审查更稳定。我帮一个小团队落地过类似方案配置好之后最大的变化不是效率提升而是产出一致性。以前每个人的代码风格和工程习惯都不同现在有了统一技能约束至少 AI 参与的环节不会再出现低级规范问题。6.3 与 IDE 补全类工具的本质差异很多人会把 Superpowers 跟 Copilot 这类 IDE 插件相提并论但它们解决的问题完全不在一个层级。IDE 补全类工具做的是 token 级别的预测你写一个函数名它帮你补函数体Superpowers 做的是任务级别的规划与执行你说“做一个用户登录模块”它给你出方案、列任务、写实现、跑测试、做自审。两者的关系更像是“输入法”和“项目的助理工程师”的区别。输入法再智能也不会替你安排工作顺序而 Superpowers 的着眼点是完整的工作流。如果你想推动团队从“AI 辅助编码”走向“AI 自主开发”Superpowers 提供的是一套很好的过渡框架。7. 常见问题与排查技巧实录问题现象可能原因解决方案安装后/skills看不到任何技能技能目录层级不对或插件未启用检查目录结构重新执行/plugin install重启会话/brainstorming没有触发结构化输出技能被其他插件覆盖或未加载输入/status查看加载日志单独禁用其他插件再试AI 总是用错技能触发条件写得过于宽泛编辑对应SKILL.md收紧触发条件会话变慢token 消耗激增技能数量过多上下文塞满说明清理项目级技能目录只保留常用技能技能内的脚本执行报错Node 版本或依赖缺失查看技能目录的README补齐运行环境工作流串不起来各技能输出格式不一致统一各技能的输出为 Markdown 结构便于下一个技能读取还有一个独家的排查技巧当我不确定某个技能是否生效时会直接打开技能目录里的SKILL.md然后手动把内容贴到对话里要求 AI 严格按此执行。这样绕过了自动触发机制可以快速判断问题出在技能内容本身还是出在触发逻辑上。最后再分享两件实际操作中的小事这套东西我用了几个月最深的体会是Superpowers 没有一个技能是“炸裂级”的新东西但组合起来的效果非常惊人。它最大的贡献是把那些隐藏在我脑子里的工程经验变成了一套 AI 能读懂、能执行的显性技能包。对我个人而言最大的变化是 AI 不再像个只会接话的聊天机器人而是真的像团队里一个默默按流程干活、还不需要你操心的同事。如果你也想尝试我的建议是别一上来全装。先装核心插件然后只启用 brainstorming 和 test-driven-development 两个技能用它们跑两个真实任务感受一下“流程化”和“非流程化”的差距。等适应了再逐步扩展其他技能。最后提醒一句技能包是工具真正的判断力还是得靠你自己AI 给的方案永远值得再问一句为什么。