1. 为什么需要superpowersAI不是缺少能力而是缺少方法论1.1 AI助手的“高开低走”现象如果你最近在用Claude Code这类AI编程助手大概率遇到过这种情况一开始让它写个脚本、改个函数效果惊艳到你怀疑人生。但一旦交给它一个稍微复杂的任务——比如“帮我重构整个模块”“设计并实现一个带鉴权的API网关”——它就开始东一榔头西一棒子做着做着忘了最初的目标改了这个文件又破坏了另一个功能最后给你交出一堆看起来能跑、实际上处处是坑的代码。这不是模型变笨了而是大多数AI助手天生缺少一套结构化执行方法论。它确实很聪明知道成百上千种编程技巧但喂给它一个高层次的模糊目标时它缺乏一个“老工程师拿到需求之后先干什么、再干什么、每一步怎么验证”的标准工作流。这就像给一个天才少年三箱乐高零件他能拼出各种精妙结构但你直接丢给他一张“宫殿设计图”让他独立完成他反而会迷失在细节里。GitHub上最近热度很高的superpowers项目解决的正是这个问题。它不是一个新的AI模型也不是什么重型框架而是一套由Jesse VincentGitHub账号obra维护的、为Claude Code等AI编程助手准备的“技能包”集合。这套技能包以Markdown文件的形式把资深工程师处理复杂任务时的思考步骤、提问方式、验证策略、复盘流程全都固化下来让AI在执行任务时能像一位经验丰富的老手一样先规划、再动手、边做边验、事后复盘。一句话概括它是给AI助手装上了一套“工程方法论操作系统”。1.2 superpowers的核心设计理念要理解superpowers得先理解Claude Code里的一个基础概念——Skill技能。在Claude Code的体系中Skill是一个以Markdown格式撰写的指令文件包含一段结构化的提示词。当用户的任务与某个Skill的描述匹配时AI会主动加载这个文件并按照文件里的流程来执行任务。你可以把它理解成给AI预置的一份“任务SOP手册”。superpowers把几十个这样的Skill组织在一起每一份都对应一种典型的复杂工作场景头脑风暴、需求拆解、计划撰写、步骤执行、缺陷排查、代码复审、项目复盘等等。它们不是零散的技巧而是被设计成一套互相衔接的工作流。比如从brainstorming出发把模糊想法梳理清楚进入planning把目标拆成带验证标准的执行计划再到executing一小步一小步地实现并测试最后用debriefing做复盘沉淀经验。这套设计理念最核心的一点是AI的能力上限不是模型参数决定的而是由它遵循的工作流程质量决定的。一个严格执行“先写测试、再写实现、每次小步验证”流程的模型在复杂项目上的表现往往优于一个能力更强但自由发挥的模型。superpowers就是把这些“优质流程”变成可安装、可复用、可扩展的标准件让你不需要每次都在对话里花几十行字去教育AI该怎么干活。1.3 它到底解决了什么问题我实际用下来觉得superpowers解决的核心痛点可以归纳成三件事第一任务过程再也不用“手把手教”。以前让AI写一个复杂功能我必须事无巨细地拆好步骤、写好规则否则它一定会跑偏。现在只需要说一句“用brainstorming帮我把这个需求理清楚”或者干脆在描述里带上任务目标AI自己就会进入对应的Skill流程主动问我关键问题、拆解方案、分阶段执行。第二AI的产出变得稳定且可预期。Skill文件相当于给AI上了一道“工作流程约束”它不再自由发挥而是按照预设的阶段一步步走。计划阶段就只做计划执行阶段就严格按计划小步推进每完成一步都要跑测试验证。这就大大减少了“改一处崩三处”的连锁翻车。第三经验可以被积累、被共享。superpowers本身是开源的它的每一份Skill都是一份精心打磨的Markdown文档。你在自己的项目里对某个Skill做了优化或者自己写了一个新Skill完全可以用Git管理起来分享给团队。时间长了这套技能包就是你个人或团队的“工程方法论文集”。2. 安装与引入三步把superpowers装进Claude Code2.1 获取项目文件首先要说明superpowers并不是通过pip install或npm install安装的常规工具包它本质上是一个从Git仓库克隆下来的目录集合。你需要的核心内容就是仓库里的skills目录里面装满了按主题归档的Markdown技能文件。git clone https://github.com/obra/superpowers.git克隆完成后你可以先看一下目录结构。重点关注的几个路径包括skills/核心技能文件、docs/使用文档、以及项目根目录下的README.md。README里通常会写清楚当前版本支持的Claude Code版本、技能文件的放置规则和注意事项建议先花五分钟通读一遍再动手。cd superpowers ls skills/你会看到类似brainstorming、planning、executing、debugging这些子目录每个子目录里至少包含一个主Skill文件有的还附带示例、模板或配套脚本。这套组织方式本身也说明了一个原则把大而全的“技能库”拆分成功能单一、边界清晰的小文件比塞进一个巨型提示词里要高效得多。2.2 选择正确的安装目录拿到文件之后最关键的一步是把skills目录里的内容放到Claude Code能识别的位置。Claude Code查找Skill的位置有两条路径一是用户级目录对所有项目全局生效二是项目级目录只对当前项目生效。以Linux和macOS为例用户级目录位于~/.claude/skills/项目级目录位于.claude/skills/相对于项目根目录。Windows系统则建议参考Claude Code当前的版本文档路径大致在用户主目录下的.claude文件夹内。我个人的做法是先装到用户级目录全局生效省心。如果你只是在某个特定项目里试用或者希望团队通过Git仓库统一分发技能配置那就放到项目级目录里。完整安装命令大致如下mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/如果你用的是项目级目录就把目标路径换成.claude/skills/。如果你比较在意干净整洁也可以直接在项目里建立一个指向superpowers仓库的软链接这样以后升级superpowers时只需要git pull不用重新复制一遍。还有一个值得一提的做法新版Claude Code支持通过插件市场或plugin配置引入技能包。如果你在配置里看到类似plugins相关的字段说明该版本支持插件方式安装那么只需要把这个仓库的地址添加到插件列表即可自动完成同步升级维护会更方便。具体操作以你手上版本的官方文档为准。2.3 验证安装是否成功安装完之后立刻验证这一步别省。在Claude Code中重启当前会话输入斜杠命令查看可用Skill列表/skills如果一切正常列表里会出现brainstorming、planning、executing、debugging等一系列名称。你也可以直接在对话里输入“列出你当前可用的所有skills”这样的自然语言请求AI会按要求把已加载的Skill文件清单展示出来。注意如果你的Claude Code版本比较旧/skills这个命令可能不存在可以用对话方式询问AI“你加载了哪些skills”确认核心文件是否被正确识别。验证时还有一个容易踩的坑SKills文件的命名和metadata必须符合当前版本的解析规则。比如文件开头的YAML frontmattername、description等字段如果格式不对就会导致Skill被静默忽略。所以如果你复制完文件后列表为空先别怀疑路径问题打开一个Skill文件看看开头是不是长这样--- name: brainstorming description: 在动手之前通过发散提问和结构化思考帮助用户澄清需求并生成可执行的方案方向。 ---只要格式正确Claude Code几乎都能自动识别。2.4 安装方式的几种变体除了最基础的“复制整个skills目录”还有几种变体做法值得你根据实际情况选择第一种是精选安装。superpowers内置了几十个Skill你未必全用得上。如果只想体验brainstorming和planning就只复制对应的子目录不要整个灌进去。这样做的好处是减少AI在自动匹配Skill时的干扰项也让技能列表更清爽。第二种是自定义组装。你可以把superpowers里的Skill文件和自己的团队规范、代码风格约束合并成一个专属技能目录。比如在executing的Skill文件里追加一句“所有新代码必须补充单元测试”以后AI执行任务时就会自动遵守这条规则。第三种是版本固定。如果你的团队有多名成员建议给superpowers仓库固定一个版本通过Git tag或commit哈希防止不同成员克隆到的版本不一致导致AI行为差异。这一点在协作开发时尤其重要——技能包本质上是“AI行为配置”配置不一致行为就一定不一致。3. 核心skills清单理解每一个“超级能力”3.1 brainstorming把模糊需求变成清晰目标很多人忽略头脑风暴在AI编程中的价值觉得“让AI发散思维那不全乱套了”。但superpowers里的brainstorming不是让AI天马行空地胡思乱想而是一套收敛式发散流程。它会让AI围绕你的目标提出一系列开放式问题比如“这个功能的主要使用场景是什么”“有没有类似实现可以参考”“最理想的用户体验应该是什么样的”通过这些问题把你脑海里模糊的需求一点点逼出清晰轮廓。实际使用中我发现这个Skill最大的惊喜是它会主动要求你提供“反例”和“边界情况”。比如你说“我要做一个URL缩短服务”它会追问“如果用户提交的URL包含恶意参数怎么办”“生成的短码有效期多长”“需不需要统计点击量”。这些追问往往能提前暴露需求里的盲区避免开发到一半才发现设计缺陷。brainstorming的输出不是代码而是一份“需求澄清摘要”和一堆备选方向。它还给后续的planning阶段铺好了路——因为你已经和目标AI同步对齐了上下文后面生成的计划会精准得多。3.2 planning把目标变成可执行计划planning是superpowers体系里承上启下的关键环节。它的职责是把经过brainstorming澄清后的目标拆解成一组逻辑清晰、顺序合理、每步都可验证的执行单元。注意这里的“计划”粒度非常讲究不能粗到一句话完成也不能细到每行代码都列出来。好的计划粒度应该是“可以独立验证结果”的层级。举个例子“实现用户登录接口”会被拆成“搭建数据库用户表并编写迁移脚本”“实现密码哈希存储与验证工具函数”“编写登录接口的业务逻辑”“补充JWT签发与校验逻辑”“编写接口单元测试与集成测试”。每个细项后面还要标注验收方式比如“运行pytest tests/test_auth.py全部通过”。这样一份计划交付给执行阶段时AI每一步结束都知道自己该做什么验证而不是埋头写完一坨代码才发现方向不对。planning还会特别要求AI评估依赖关系和风险点。比如某一个步骤依赖另一个步骤的产出或者某个环节存在第三方服务的不确定性计划中必须显式标注。这一步相当于给AI装了一个“风险雷达”让它在大步往前走之前看清楚脚下有哪些坑。3.3 executing小步快跑频繁验证如果说planning是施工图纸那么executing就是施工现场的安全规范。这个Skill的核心原则是每个执行单元都以前面计划里写好的验收标准结尾做完一步验证一步再进入下一步。它不允许AI一口气实现五个功能模块然后统一测试——那样一旦出问题排查成本会被瞬间放大。executingSkill里通常会嵌入一组“执行循环”指令大致是读取当前计划项的验收标准 → 编写或修改代码 → 运行对应的测试和检查命令 → 根据结果决定继续还是回退修正 → 更新执行状态记录。这套循环几乎是把测试驱动开发TDD的节奏固化成了AI的执行习惯。使用过程中最直观的感受是AI的行为变得更“啰嗦”了——每完成一个小步骤都要停下来汇报“测试通过”“本次改动涉及哪些文件”。但这种啰嗦反而让人安心因为你随时都知道它做到哪一步了、验证结果如何。对长任务而言这种“频率换安全”的策略非常有效。3.4 debugging让Bug无处遁形debuggingSkill是我个人最喜欢的一个。程序员日常开发里耗费时间最多的往往不是写新功能而是定位和修复那些莫名其妙的Bug。AI在遇到Bug时如果缺乏流程约束往往会选择“凭直觉改一行代码试试”结果大概率修了这里坏了那里。debuggingSkill强制AI遵循一套系统化的排查流程首先要求能够稳定复现Bug并记录触发条件其次要求建立“最小复现用例”把无关变量剔除干净然后通过二分法或日志插桩定位问题边界最后才动手修改并且在修改后补充一条针对该Bug的回归测试防止它将来卷土重来。这个Skill最厉害的地方在于它要求AI在排查初始阶段先提出所有可能的假设再逐条验证而不是盯着最显眼的那个嫌疑点不放。有一次我的项目遇到一个偶发性内存泄漏AI按照这个Skill的思路先列出“循环引用、全局缓存未清理、事件监听未移除”等五六种假设然后逐个用日志验证最终真的定位到了一个被忽略的定时器引用——如果按以前的方式我估计得花一下午在错误的方向上打转。3.5 writing-plans与debriefing计划文档与复盘文化很多开发者只关注“动手做”忽略了“写文档”和“复盘”的价值。但superpowers考虑到了这一点专门提供了writing-plans和debriefing两个Skill。writing-plans负责把讨论好的方案撰写成一份结构清晰的实现文档内容涵盖背景、目标、非目标、技术选型、模块划分、接口定义、测试策略、里程碑和风险清单。这份文档不是摆设它是后续planning和executing的共同参照物。先写文档再写代码这个习惯能极大减少团队协作中“各做各的最后对不上”的问题。debriefing则是在任务完成后做复盘。AI会回顾整个执行过程总结哪些步骤顺利、哪些环节反复返工、根因是什么、下次如何改进。这个复盘结果会自动沉淀到上下文或指定文件里成为你的“项目经验库”。我习惯在每次大功能完成后主动说一句“用debriefing复盘一下这次开发”得到的建议往往很客观比如“这个功能的前置设计讨论不充分导致后续计划变更了两次”——这种来自机器的复盘反而比人的自我总结更冷静、更不留情面。3.6 其他值得关注的skills除了上述核心Skillsuperpowers里还有一些针对特定场景的实用技能比如用于生成和优化提交信息的write-commit-message、用于代码审查的code-review、用于梳理技术方案的architecture等。你完全可以把它们当作“AI能力插件包”按需启用。值得强调的是这些Skill并不是互不相干的孤岛。它们之间存在一条隐含的工作流链条——从发散思考brainstorming到方案文档writing-plans到执行计划planning到落地实现executing再到问题修复debugging最后以复盘收尾debriefing。你在一个任务里同时使用这条链路上的多个Skill效果会远远好于只调用其中某一个。这也是“superpowers”这个名字的底气单个Skill只是普通工具串联起来才配叫超级能力。4. 实操演示用superpowers完成一个真实功能开发4.1 场景开发一个URL缩短服务前面讲了这么多原理下面用一个完整的实际场景把它们串起来用superpowers这套工作流在Claude Code里开发一个最基本的URL缩短服务。这个例子足够简单方便你看到每一步的动作又覆盖了从需求澄清到代码落地的完整链路能帮你建立“流程感”。环境的初始状态假设如下一个空的Python项目目录已初始化Git仓库装了FastAPI和pytestClaude Code可以正常访问终端命令。现在你在对话框里输入一句话“用brainstorming帮我设计并实现一个URL缩短服务。”4.2 阶段一用brainstorming梳理需求因为你显式提到了brainstormingClaude Code会加载对应的Skill文件并进入发散提问模式。它不会立刻写代码而是先抛出一连串问题例如短码长度和字符集有要求吗是否需要支持自定义短码重定向是用301永久跳转还是302临时跳转需不需要统计访问次数要不要存访问日志远期过期策略是什么短码能否被复用需要防滥用吗要不要做基础的频率限制这些问题看起来琐碎但每一个都直接影响数据模型设计和接口定义。如果你对部分问题没有明确想法可以直接说“你帮我决定给出理由”AI会给出合理的默认选择并做简要解释。在这个阶段结束时AI会输出一份“需求澄清摘要”我建议你把这份摘要保存为项目里的docs/requirements.md——它有可能是你整个项目里最有价值的文档。4.3 阶段二用planning生成实施方案需求清晰之后输入“继续用planning生成实施计划”。AI会基于需求文档输出一份分步计划。针对我们这个URL缩短服务计划大致长这样计划实现URL缩短服务 v1.0 步骤1设计数据模型OriginalURL, ShortCode, CreatedAt, ExpireAt, VisitCount 验收编写SQLModel定义并生成空迁移脚本 步骤2实现短码生成工具基于secrets模块生成8位随机短码 验收创建生成器模块运行单测确认不碰撞 步骤3实现POST /shorten接口 验收curl提交URL返回201和短码JSON 步骤4实现GET /{code}重定向接口 验收curl访问短码返回302和原始URL 步骤5补充单元测试与基础防滥用限制 验收pytest全绿简单负载下无异常注意每个步骤后面都带了一条验收标准这正是superpowers的planning和普通“列待办清单”的本质区别。计划生成后你可以直接要求AI把它存成docs/plan.md后续执行阶段就严格按照这个文件推进。4.4 阶段三用executing执行开发与测试计划就绪后输入“开始执行这份计划”。AI会进入executing模式严格按照计划里的步骤顺序推进。它的行为方式是执行步骤1 → 跑验收命令 → 向你汇报结果 → 进入步骤2 → 依此类推。如果某一步验证失败它会停下来分析原因而不是硬着头皮继续往下写。实际操作中你会发现AI每一步都会打印出它执行的具体命令和结果摘要。比如步骤2完成后它会展示一段类似下面的信息步骤2完成短码生成模块 验证pytest tests/test_codegen.py -q 通过3 passed 变更文件app/codegen.py, tests/test_codegen.py这种小步验证的节奏让你在每一条链路出问题时都能立刻定位而不是等五个模块全部写完再一次性debug。在整个过程中你几乎不需要干预偶尔在它询问需求细节时给一个明确答复即可。4.5 阶段四用debriefing复盘改进功能实现并测试通过后输入“用debriefing复盘这次开发”。AI会回顾整个任务沉淀期输出一份包含“做得好”“遇到问题”“改进建议”的复盘报告。以我的经验这份报告很少是空话。它可能会指出“需求阶段没有考虑短码冲突的数据库唯一约束导致实现阶段补了两次迁移”或者“步骤3和步骤4的接口测试可以合并成一个测试文件减少重复启动开销”。这些具体到环节的建议在你独立开发时很难系统性总结出来但让AI用固定流程回顾一遍问题就暴露得很自然。这份复盘报告建议保存到docs/debrief.md。等你做第二个类似项目时先打开这份文件看一眼能避开上次踩过的坑。这就是把一次性的开发经验变成可复用的团队资产。5. 常见问题与排查技巧实录5.1 安装后Skill列表为空这是大家最常碰到的问题。Skill列表为空基本可以从三个方向排查一是目录路径不对比如复制到了~/.claude根目录而不是~/.claude/skills二是Metadata格式不被解析YAML frontmatter里的字段名或缩进有问题三是Claude Code版本太旧还不支持Skill机制这种情况下需要先升级工具本身再重新加载。排查时别全靠猜直接在Claude Code里让AI“读取你的skills目录路径逐个检查Skill文件是否合法”。它会帮你把文件路径、frontmatter解析结果列出来问题往往一眼就看到了。5.2 Skill没有自动触发你安装了brainstorming但描述任务后AI并没有自动进入该Skill的流程。这种情况通常是因为你的“意图表达”不够匹配Skill的description触发词。比如你只说“帮我写个脚本”AI可能匹配到更基础的代码生成逻辑而不是brainstorming。最稳妥的解决办法是显式带上Skill名称比如直接说“用brainstorming帮我把需求理清楚”。这相当于强制调用指定的Skill不依赖触发词匹配。如果你希望某些场景下AI不经过问询直接进入某个Skill可以把对应描述词写进项目的CLAUDE.md配置文件里例如“当用户提到URL缩短服务时自动使用brainstorming和planning流程”。这样相当于给项目级别的AI行为加了自定义规则。5.3 与项目现有配置冲突如果你的项目里已经有自定义的.claude/skills目录或者通过插件机制引入了其他技能包有概率出现同名Skill文件互相覆盖的情况。由于加载顺序通常是项目级优先于用户级如果两边存在同名技能项目级文件会生效你精心安装的superpowers版本就“悄悄失效”了。排查思路很简单在Claude Code里让AI“打印所有已加载Skill的完整来源路径”对比一下同名文件是从哪个目录加载的。如果有冲突给其中一个重命名或者把项目级目录里不需要的技能文件删除只保留必要的自定义项。5.4 自定义Skill的格式问题很多人在熟悉了superpowers之后会忍不住自己写Skill。常见错误包括写description时没有说明“什么时候该用”而是只写了“这个技能做什么”导致触发匹配不准或者正文里全是泛泛的原则没有具体到步骤、命令和验收方式AI加载后不知道该怎么做。我的经验是写Skill一定要遵循“触发条件清晰 执行步骤可验证 结束标志明确”三条原则。拿一个最简单的“代码格式化”Skill举例description里写清楚“用户提到整理代码风格时使用”正文里列出具体使用的工具命令比如black、eslint --fix、检查范围、以及执行结束后的验证动作比如运行git diff确认改动范围。这样AI才能准确理解你的意图并稳定复现执行。6. 一点个人体会把superpowers用进日常开发流程之后我的体会是它真正改变的不是AI写代码的能力而是我与AI协作的节奏感。以前我会下意识地把任务拆得碎碎的生怕AI做偏现在我可以先把模糊的想法丢给它让它用brainstorming帮我理需求用planning出方案我再审核、修改、批准最后它再去执行。人机之间从“命令与执行”的关系变成了“需求对齐、方案评审、执行监控”的更接近同事协作的关系。还有一点想特别提醒不要一口气把所有Skill都启用。先选brainstorming和planning这两个跑通一遍完整流程感受一下节奏等习惯之后再加executing和debugging逐步把整条链路串起来。Skill不在多能融入你现有工作流、让结果变稳才是真的有价值。最后分享一个小技巧如果你在某个任务里发现AI的执行方式特别顺手不妨翻一下它当时加载的是哪个Skill文件把里面关键的流程片段提取出来凑成属于你自己的“轻量级superpowers”。我自己的项目模板里就常年维护着几个自制的Skill文件它们是从superpowers里学来的方法论再揉进团队实际约束效果比原版更贴合业务。这套“外来的方法论 自己的业务规则”的组合拳才是superpowers最值得借鉴的用法。