刚接触 Claude Code 的人很容易遇到一个瓶颈单轮对话里让它写个小函数没问题一旦任务变成要做一个完整功能、要改十几个文件它的表现就开始飘忽。一会思路清晰给你列一二三四一会又在一个小 bug 上原地打转。superpowers 这个名字中二感十足但它解决的正巧是这个问题——它把 Claude 的思维方式结构化等于给模型配了一套工地级别的施工流程。这篇文章不会去复述官方 README而是以我实际使用两个月、踩过不少坑之后的视角把 superpowers 到底是什么、具体有哪几个 skills、怎么装、怎么引入、以及实战效果如何一次性讲清楚。1. 先说结论superpowers 实际解决的是Claude 越用越乱的问题1.1 它不是一个代码库而是一套行为说明书集合第一次看到这个项目的人十有八九以为它是个工具链或函数库。实际上 superpowers 是一个基于 Claude Code 插机制分发的能力包里头的核心资产不是代码而是一批 Markdown 格式的SKILL.md文件。Claude Code 在对话过程中读到这些文件之后会改变自己的行为方式遇到复杂需求时先问清楚边界动手之前先写方案执行计划时一次只做一个小任务出错之后按固定套路定位问题而不是无头苍蝇一样乱改。用一句话概括它把临时抱佛脚地使用 AI 编程变成了按施工图干活。我在没有安装它之前给 Claude 布置一个跨文件改造任务经常要反复补充上下文甚至中途因为对话太长、上下文窗口被各种试探性操作塞满最后只能新开对话从头讲一遍。superpowers 的思路是让 Claude 在动手前就把方案固化成一个可审查的文档执行时严格照着文档走这样就算对话被迫切断新对话也能基于计划文件快速续上。1.2 你需要重新看待技能这个概念很多用过 ChatGPT 或 Gemini 的人对技能的理解是像 App 一样装一个插件然后多出一个功能按钮。superpowers 里的 skills 完全不是这种形态。它更像是给 Claude 的一份岗位工作手册Claude 会在恰当的时机主动阅读这些手册然后按照手册里的流程来组织自己的思考过程。举个例子我让它帮我 brainstorm 一下这个 CLI 工具的命令参数设计它会先加载 brainstorming 这个 skill然后做一个我之前没想到的动作——先不急着给方案而是反问我这个工具面向谁、一次性使用还是长期维护、出错时的容忍度如何。这些追问并不是随机生成的而是 SKILL.md 里明确要求它做的。换句话说superpowers 不是给 Claude 增加新功能而是给 Claude 增加新规矩。这也是它最容易被误解的地方你以为装了一个工具包实际上你装了一套质检流程。1.3 什么样的人值得装如果你只是偶尔让 Claude 写个正则表达式、转个数据格式、问点 API 用法superpowers 对你来说可能感知很弱。但如果你符合下面任意一条我建议你认真考虑日常用 Claude Code 写完整功能模块一个任务涉及五六个文件以上需要它做代码重构、跨模块改造又担心改坏原有逻辑经常遇到 Claude 在长对话中失忆——前面定的方案执行到一半被它悄悄改掉了希望 AI 不仅产出代码还能在动手前与你对齐设计决策团队里有人用 Claude Code 协作同一个仓库需要留下可追溯的计划和痕迹我属于前三条全中的重度用户。安装后最大的感受是Claude 从一个聪明但毛躁的实习生变成了一个虽然没那么快但每一步都先汇报、先确认、留记录的可靠同事。代价是对话变啰嗦了、执行变慢了但返工率显著降低这笔账怎么算都划算。2. 拆包看货这套技能包到底装了哪些 skills2.1 核心目录结构速览superpowers 的仓库里有一个skills目录下面每个子目录对应一个独立技能。每个技能目录内部必有一个SKILL.md里面写着触发场景、工作流程、输入输出格式、注意事项。以当前仓库版本为例我实际使用中真正发挥作用的主要有这几个技能名称英文标识核心用途我给它打的标签头脑风暴brainstorming需求澄清、方案生成、多方案对比动工之前先用它制定计划writing-plans将方案落地为分步骤可执行计划方案与代码之间的桥梁执行计划executing-plans按计划推进逐项验证避免跑偏大任务的轨道系统化调试systematic-debugging用结构化流程排查 bug根因分析救火队员代码审查code-review对修改过的代码按标准做评审合并前的最后一道闸测试驱动开发TDD先写失败测试、再写实现、再重构需要纪律时启用还有一些辅助类技能我没有全部列出来它们发挥作用的频率因人而异。核心逻辑是superpowers 不试图让 Claude知道更多而是让 Claude更有条理地使用它已经知道的东西。2.2 几个主力技能的触发时机与行为差异brainstorming是我最常主动调用的技能之一。它适合在任务描述还不清晰的时候使用典型触发话术是use the brainstorming skill to help me think through this。加载之后Claude 会要求我补充背景信息然后给出多个方案而不是直接选一个。它甚至会在方案后面附上每个方案的适用场景和代价逼着我想清楚自己到底想要什么。writing-plans则会做一件让传统编程者非常舒服的事把方案变成一份带检查点的任务清单。正确的用法不是让 Claude 自己把方案生成完就直接执行而是你在对话里确认方案没问题之后再让它 write a plan。生成的计划文件会对齐方案中的每个环节拆成若干个一次只做一件的小任务并注明验收标准。executing-plans是让本来容易失控的长任务保持稳定的关键。它读取已有的计划文件一个任务一个任务地往下执行每一步做完都会标记完成状态而不是一口气把所有代码写出来。这非常像我们平时用项目管理软件拆解任务的感觉只不过干活的是 AI。2.3 怎么查看当前到底有哪些 skills装完插件之后很多人会困惑技能都在哪。最直接的办法是打开仓库目录看如果是通过 Claude Code 插件市场安装的可以在~/.claude/plugins下面的对应目录里找到 SKILL.md 文件如果你是手动 clone 到项目里的通常就在项目的.claude/skills目录下。这些目录里躺着所有技能说明书完全可以打开当操作手册读。另外在实际对话中你还可以直接问 Claude 本身它可以列出当前可用的技能并说明用途因为它能读取到这些目录。我习惯在新项目开始时专门问一句你现在可以用哪些技能分别什么时候用让 Claude 自己复述一遍。这个做法一方面能让我确认安装是否生效另一方面能让 Claude 在后续对话里更自觉地调用它们——因为它知道我知道它有什么工具。3. 安装与引入从零到能跑起来的最短路径3.1 方式一通过 Claude Code 插件市场安装如果你用的是较新版本的 Claude Code最省事的路径是使用插件市场命令。我当时的安装过程非常顺利全程两条命令/plugin marketplace add obra/superpowers /plugin install superpowerssuperpowers第一条命令把作者的仓库注册为插件市场来源第二条命令从该市场安装 superpowers 插件。执行完之后Claude Code 会提示插件已启用。这里有一个容易忽略的细节启用插件之后需要重启当前会话或者至少让 Claude 重新扫描插件目录否则它可能不会立刻意识到自己已经掌握了新技能。如果你的 Claude Code 版本还没有内置插件市场命令也可以直接手动安装。原理非常简单先 clone 仓库再把仓库里的skills目录链接到 Claude Code 的配置目录下git clone https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers然后在 Claude Code 的配置文件通常是~/.claude/settings.json里确保插件目录被加载。不同版本字段略有差异但思路一致让它能读到这个目录下的SKILL.md文件。我自己的经验是手动安装没有太多技术难度但每次更新比较麻烦所以后来还是切回了插件市场方式。3.2 方式二把 skills 放进具体项目里还有第三种更轻量的方案只把需要的技能塞进单个项目。Claude Code 支持项目级技能目录也就是项目根目录下的.claude/skills/里面的技能只在该项目对话中生效。如果你手头已有某个技能的 SKILL.md直接复制到这个目录里就行。这种做法适合不想全局引入、只想在某个特定仓库里试验的情况。比如我在公司一个多人协作的仓库里就没有全局开启 superpowers因为担心行为变化会影响同事的日常提交风格只在个人项目里全局使用。项目级引入的另一个好处是可以和团队约定项目内统一的技能目录大家共享同一套工作流这比每人都改全局配置要干净得多。3.3 安装完成后的第一件事确认技能确实生效了装完别急着开工先做一个冒烟测试。我的做法是新开一个 Claude Code 会话输入一句很简单但能触发技能的话比如use the brainstorming skill to help me decide between a CLI tool and a web UI for a small internal dashboard观察 Claude 的反应。如果它开始读文件、然后反过来追问我需求细节说明技能生效了。如果它只是像平时一样直接给结论那八成是加载失败或者没有匹配到技能触发条件。顺带一提Claude 在调用某个技能后通常会在回复里明确提到我已经读取了 brainstorming 技能或者类似的话这是最直观的生效标志。提示不要一上来就让 Claude全程使用所有技能。superpowers 里的每一个 skill 都有明确的适用场景强制全部用反而会让简单任务变得臃肿。我见过有人为了体验技能让 Claude 给一个纯展示网页先写三页技术方案完全是杀鸡用牛刀。4. 实战记录用 superpowers 从零完成一个小工具文字介绍再多不如跑一遍真实流程来得直观。下面我用最近做的一个实际任务来拆解写一个 Python 批量重命名工具要求支持名字映射规则、预览模式、操作日志回滚。这个任务不算大但足够展示整套技能的协同方式。4.1 第一阶段用 brainstorming 把需求边界钉死一开始我的需求描述非常含糊写个脚本批量改名要安全。如果直接让 Claude 写它大概率会产生一个看起来能用、但边界一塌糊涂的版本。这次我明确要求它先加载 brainstorming。Claude 果然没有直接写代码而是先问了几个关键问题重命名规则是简单替换还是正则匹配是否需要处理文件名冲突预览模式需要展示到什么粒度安全具体指什么——是防止覆盖还是要能回滚这些问题看似普通但现在回看它们全都在后续开发中成了分水岭如果没问是否处理文件名冲突生成的脚本大概率会直接覆盖同名文件如果没问预览粒度用户可能只能看到新旧文件名列表看不到具体差异。brainstorming 的价值在于它把我在需求阶段懒得多想的问题全部给捞了出来。这一轮下来我们确认了三个方案纯 Python 脚本、Python dry-run 参数、以及带变更日志的进阶版。Claude 甚至给了每个方案的推荐场景。4.2 第二阶段writing-plans 把方案变成施工图需求确认后我让它基于选定方案写计划。关键一步在这里计划必须写成独立文件而不是只存在于对话里。我让 Claude 调用writing-plans技能生成一份计划并且明确要求它保存成文件之后执行阶段再调出来。生成的计划结构大致如下# 批量重命名工具实施计划 ## 目标 - 支持前缀/后缀添加、指定字符串替换两种规则 - 支持 dry-run 预览 - 记录变更日志支持按日志回滚 ## 任务清单 1. 搭建项目结构与入口模块 - 创建 main.py定义命令行参数 - 验收python main.py --help 能列出所有参数 2. 实现映射规则引擎 - 规则数据结构定义与解析 - 验收单元测试覆盖替换与前后缀规则 3. 实现 dry-run 预览 - 输出 旧名字 - 新名字 对照表 - 验收执行 dry-run 不实际改动文件系统 4. 实现实际重命名与冲突检测 - 冲突时跳过并提示 - 验收两个文件映射到同一新名字时只保留第一个 5. 实现日志记录与回滚 - 记录到 rename_log.json - 验收根据日志能还原原文件名这份计划的每一个条目都带着明确的验收标准。我觉得这比让 Claude 一口气生成代码重要的多因为验收标准意味着 Claude 在执行时知道自己做到什么程度才算完成而不是自己觉得差不多就收手。4.3 第三阶段executing-plans 按图施工执行计划时我直接告诉 Claude读取之前的计划文件并开始执行。它做了几个我特别满意的动作第一步是重读了计划全文然后开始一个任务一个任务地推进每完成一个小任务就用简短的话报告进度并且对照验收标准自检。在实现映射规则引擎时它还主动补写了几个针对边界情况的单元测试比如空字符串替换、正则特殊字符转义、超长文件名冲突。这让我很意外因为我并没有要求它写测试但它从计划里的验收单元测试覆盖读到了隐含要求于是自作主张把测试补上了。这种按图施工但不机械照搬的表现正是技能文档和模型能力结合得好的结果。4.4 第四阶段systematic-debugging 收拾烂摊子当然计划再周密也会出问题。实际跑起来的时候回滚功能在 Windows 路径上出了 bug日志记录的是绝对路径但文件名含有特殊字符时 JSON 反序列化报错。我没有直接告诉 Claude 怎么改而是让它走一遍systematic-debugging流程。令人欣慰的是它没有上来就大改代码而是先复现问题、缩小范围、提了一个临时加日志的命令让我帮忙跑最终定位到问题根源是json.load时对反斜杠的转义处理不当而不是回滚逻辑本身出错。整个过程大约 15 分钟比我在 Stack Overflow 上翻答案再手动验证的方案快得多。更关键的是它最后在代码注释里写了根因说明避免后人再踩一遍。4.5 实战体验总结三个最直观的变化反复横跳明显减少。以前 Claude 可能在方案 A 和方案 B 之间自动切换现在它只按计划执行计划外的想法会先提出来征求我的意见而不是自己悄悄改变方向。验收标准缺位的场景变少。它每完成一个小任务会自己对照验收标准检查很多时候不用我再特意说你测一下。对话中断可恢复。计划文件独立存在即使中途新开对话也能让新会话读计划文件继续执行不用重新解释需求。这一点在公司里交接给同事新开对话时尤其好用。5. 用了一段时间后的体会和踩坑清单5.1 最大的坑计划文件堆积成山superpowers 的流程天然会产生计划文件、进度标记、变更日志。我第一个项目跑完项目目录里多了至少五个 markdown 文件——计划、子计划、执行状态、复盘。这些文件对长期项目来说是好东西但对一次性小工具来说就是噪音。我的做法是给一次性的小实验单独建临时目录跑完直接删掉整个目录只有真正要持续维护的功能才放项目根目录下保存计划。如果你用 git 管理项目记得把这类自动生成的计划文件纳入版本决策不要一股脑提交否则每个 Pull Request 里都混着一堆计划 markdownreviewer 会抓狂。5.2 不是所有任务都值得走完整流程superpowers 让我最犹豫的地方在于它有些过度工程化的倾向。现在我对任务做分级处理改动一个文件以内的简单改动直接让 Claude 改不调任何技能一个功能模块逻辑清晰但没有太多歧义让它写计划但不强制 brainstorming跨文件、或者需求本身还不清晰的任务完整走 brainstorming → writing-plans → executing-plans如果不分级让一个改 README typo 的任务也先来一轮头脑风暴体验会非常糟糕。技能是给人用的不是给人表演的把它当锤子不代表所有东西都是钉子。5.3 与自定义系统指令的配合方式如果你在 Claude Code 里已经有自定义的系统指令或项目约定的 CLAUDE.me 文件注意它们和 superpowers 可能产生指令冲突。我一开始的项目说明里写了一句尽量直接给出代码不要解释结果与 brainstorming 技能要求的先问问题再给方案直接打架导致 Claude 行为变得飘忽不定。后来我把系统指令改成了与技能兼容的表述把直接给代码调整为对于简单明确的任务可以直接给代码对于复杂任务先按可用技能流程处理。现在两者基本能协同工作不再互相拆台。注意如果你发现安装 superpowers 之后 Claude 的行为和预期不一致先别卸载检查一下是不是自己的系统指令在跟技能文档抢方向盘。技能可以通过自然语言说得更具体这次不要用 brainstorming直接按你的理解写计划。5.4 更新和升级的节奏作为第三方插件superpowers 的更新频率并不低核心技能的流程说明时不时会有调整。我出现过一次问题版本升级后旧计划文件里引用了旧的技能行为描述执行时 Claude 按新版技能流程处理结果和计划文件里的旧标记格式对不上。我的经验是升级插件后不要立刻启动大任务先跑一个 10 分钟内的小任务试探一下行为变化跨版本更新的情况更建议旧项目继续使用旧计划文件新项目再体验新流程。盲目追求最新版本没有必要稳定执行比新特性重要得多。5.5 关于agent 到底有没有变聪明的最诚实观察最后说一点可能和很多人预期不符的体会。superpowers 没有让 Claude 变得更聪明也没有增加我不知道的新能力它甚至让对话变得更笨——开场总是问东问西执行总是拆得碎碎的节奏明显变慢。但它的确让最后交付质量提高了。原因也很简单复杂任务翻车通常不是因为模型不够聪明而是目标没对齐、约束没人记录、方案在中途悄悄漂移。superpowers 提供的全部内容本质上是给这些软性问题装上护栏。对于自己写代码超过十年、习惯先设计再动手的人来说这套流程非常自然几乎不需要适应如果你本身是先跑起来再说的风格那你会觉得它极其啰嗦。我在实际使用中逐渐接受了一种观念让 AI 干活和带人干活是一样的你越是把流程说清楚结果就越可控superpowers 只是把这件事工业化了而已。
刚接触 Claude Code 的人很容易遇到一个瓶颈单轮对话里让它写个小函数没问题一旦任务变成要做一个完整功能、要改十几个文件它的表现就开始飘忽。一会思路清晰给你列一二三四一会又在一个小 bug 上原地打转。superpowers 这个名字中二感十足但它解决的正巧是这个问题——它把 Claude 的思维方式结构化等于给模型配了一套工地级别的施工流程。这篇文章不会去复述官方 README而是以我实际使用两个月、踩过不少坑之后的视角把 superpowers 到底是什么、具体有哪几个 skills、怎么装、怎么引入、以及实战效果如何一次性讲清楚。1. 先说结论superpowers 实际解决的是Claude 越用越乱的问题1.1 它不是一个代码库而是一套行为说明书集合第一次看到这个项目的人十有八九以为它是个工具链或函数库。实际上 superpowers 是一个基于 Claude Code 插机制分发的能力包里头的核心资产不是代码而是一批 Markdown 格式的SKILL.md文件。Claude Code 在对话过程中读到这些文件之后会改变自己的行为方式遇到复杂需求时先问清楚边界动手之前先写方案执行计划时一次只做一个小任务出错之后按固定套路定位问题而不是无头苍蝇一样乱改。用一句话概括它把临时抱佛脚地使用 AI 编程变成了按施工图干活。我在没有安装它之前给 Claude 布置一个跨文件改造任务经常要反复补充上下文甚至中途因为对话太长、上下文窗口被各种试探性操作塞满最后只能新开对话从头讲一遍。superpowers 的思路是让 Claude 在动手前就把方案固化成一个可审查的文档执行时严格照着文档走这样就算对话被迫切断新对话也能基于计划文件快速续上。1.2 你需要重新看待技能这个概念很多用过 ChatGPT 或 Gemini 的人对技能的理解是像 App 一样装一个插件然后多出一个功能按钮。superpowers 里的 skills 完全不是这种形态。它更像是给 Claude 的一份岗位工作手册Claude 会在恰当的时机主动阅读这些手册然后按照手册里的流程来组织自己的思考过程。举个例子我让它帮我 brainstorm 一下这个 CLI 工具的命令参数设计它会先加载 brainstorming 这个 skill然后做一个我之前没想到的动作——先不急着给方案而是反问我这个工具面向谁、一次性使用还是长期维护、出错时的容忍度如何。这些追问并不是随机生成的而是 SKILL.md 里明确要求它做的。换句话说superpowers 不是给 Claude 增加新功能而是给 Claude 增加新规矩。这也是它最容易被误解的地方你以为装了一个工具包实际上你装了一套质检流程。1.3 什么样的人值得装如果你只是偶尔让 Claude 写个正则表达式、转个数据格式、问点 API 用法superpowers 对你来说可能感知很弱。但如果你符合下面任意一条我建议你认真考虑日常用 Claude Code 写完整功能模块一个任务涉及五六个文件以上需要它做代码重构、跨模块改造又担心改坏原有逻辑经常遇到 Claude 在长对话中失忆——前面定的方案执行到一半被它悄悄改掉了希望 AI 不仅产出代码还能在动手前与你对齐设计决策团队里有人用 Claude Code 协作同一个仓库需要留下可追溯的计划和痕迹我属于前三条全中的重度用户。安装后最大的感受是Claude 从一个聪明但毛躁的实习生变成了一个虽然没那么快但每一步都先汇报、先确认、留记录的可靠同事。代价是对话变啰嗦了、执行变慢了但返工率显著降低这笔账怎么算都划算。2. 拆包看货这套技能包到底装了哪些 skills2.1 核心目录结构速览superpowers 的仓库里有一个skills目录下面每个子目录对应一个独立技能。每个技能目录内部必有一个SKILL.md里面写着触发场景、工作流程、输入输出格式、注意事项。以当前仓库版本为例我实际使用中真正发挥作用的主要有这几个技能名称英文标识核心用途我给它打的标签头脑风暴brainstorming需求澄清、方案生成、多方案对比动工之前先用它制定计划writing-plans将方案落地为分步骤可执行计划方案与代码之间的桥梁执行计划executing-plans按计划推进逐项验证避免跑偏大任务的轨道系统化调试systematic-debugging用结构化流程排查 bug根因分析救火队员代码审查code-review对修改过的代码按标准做评审合并前的最后一道闸测试驱动开发TDD先写失败测试、再写实现、再重构需要纪律时启用还有一些辅助类技能我没有全部列出来它们发挥作用的频率因人而异。核心逻辑是superpowers 不试图让 Claude知道更多而是让 Claude更有条理地使用它已经知道的东西。2.2 几个主力技能的触发时机与行为差异brainstorming是我最常主动调用的技能之一。它适合在任务描述还不清晰的时候使用典型触发话术是use the brainstorming skill to help me think through this。加载之后Claude 会要求我补充背景信息然后给出多个方案而不是直接选一个。它甚至会在方案后面附上每个方案的适用场景和代价逼着我想清楚自己到底想要什么。writing-plans则会做一件让传统编程者非常舒服的事把方案变成一份带检查点的任务清单。正确的用法不是让 Claude 自己把方案生成完就直接执行而是你在对话里确认方案没问题之后再让它 write a plan。生成的计划文件会对齐方案中的每个环节拆成若干个一次只做一件的小任务并注明验收标准。executing-plans是让本来容易失控的长任务保持稳定的关键。它读取已有的计划文件一个任务一个任务地往下执行每一步做完都会标记完成状态而不是一口气把所有代码写出来。这非常像我们平时用项目管理软件拆解任务的感觉只不过干活的是 AI。2.3 怎么查看当前到底有哪些 skills装完插件之后很多人会困惑技能都在哪。最直接的办法是打开仓库目录看如果是通过 Claude Code 插件市场安装的可以在~/.claude/plugins下面的对应目录里找到 SKILL.md 文件如果你是手动 clone 到项目里的通常就在项目的.claude/skills目录下。这些目录里躺着所有技能说明书完全可以打开当操作手册读。另外在实际对话中你还可以直接问 Claude 本身它可以列出当前可用的技能并说明用途因为它能读取到这些目录。我习惯在新项目开始时专门问一句你现在可以用哪些技能分别什么时候用让 Claude 自己复述一遍。这个做法一方面能让我确认安装是否生效另一方面能让 Claude 在后续对话里更自觉地调用它们——因为它知道我知道它有什么工具。3. 安装与引入从零到能跑起来的最短路径3.1 方式一通过 Claude Code 插件市场安装如果你用的是较新版本的 Claude Code最省事的路径是使用插件市场命令。我当时的安装过程非常顺利全程两条命令/plugin marketplace add obra/superpowers /plugin install superpowerssuperpowers第一条命令把作者的仓库注册为插件市场来源第二条命令从该市场安装 superpowers 插件。执行完之后Claude Code 会提示插件已启用。这里有一个容易忽略的细节启用插件之后需要重启当前会话或者至少让 Claude 重新扫描插件目录否则它可能不会立刻意识到自己已经掌握了新技能。如果你的 Claude Code 版本还没有内置插件市场命令也可以直接手动安装。原理非常简单先 clone 仓库再把仓库里的skills目录链接到 Claude Code 的配置目录下git clone https://github.com/obra/superpowers.git ~/.claude/plugins/superpowers然后在 Claude Code 的配置文件通常是~/.claude/settings.json里确保插件目录被加载。不同版本字段略有差异但思路一致让它能读到这个目录下的SKILL.md文件。我自己的经验是手动安装没有太多技术难度但每次更新比较麻烦所以后来还是切回了插件市场方式。3.2 方式二把 skills 放进具体项目里还有第三种更轻量的方案只把需要的技能塞进单个项目。Claude Code 支持项目级技能目录也就是项目根目录下的.claude/skills/里面的技能只在该项目对话中生效。如果你手头已有某个技能的 SKILL.md直接复制到这个目录里就行。这种做法适合不想全局引入、只想在某个特定仓库里试验的情况。比如我在公司一个多人协作的仓库里就没有全局开启 superpowers因为担心行为变化会影响同事的日常提交风格只在个人项目里全局使用。项目级引入的另一个好处是可以和团队约定项目内统一的技能目录大家共享同一套工作流这比每人都改全局配置要干净得多。3.3 安装完成后的第一件事确认技能确实生效了装完别急着开工先做一个冒烟测试。我的做法是新开一个 Claude Code 会话输入一句很简单但能触发技能的话比如use the brainstorming skill to help me decide between a CLI tool and a web UI for a small internal dashboard观察 Claude 的反应。如果它开始读文件、然后反过来追问我需求细节说明技能生效了。如果它只是像平时一样直接给结论那八成是加载失败或者没有匹配到技能触发条件。顺带一提Claude 在调用某个技能后通常会在回复里明确提到我已经读取了 brainstorming 技能或者类似的话这是最直观的生效标志。提示不要一上来就让 Claude全程使用所有技能。superpowers 里的每一个 skill 都有明确的适用场景强制全部用反而会让简单任务变得臃肿。我见过有人为了体验技能让 Claude 给一个纯展示网页先写三页技术方案完全是杀鸡用牛刀。4. 实战记录用 superpowers 从零完成一个小工具文字介绍再多不如跑一遍真实流程来得直观。下面我用最近做的一个实际任务来拆解写一个 Python 批量重命名工具要求支持名字映射规则、预览模式、操作日志回滚。这个任务不算大但足够展示整套技能的协同方式。4.1 第一阶段用 brainstorming 把需求边界钉死一开始我的需求描述非常含糊写个脚本批量改名要安全。如果直接让 Claude 写它大概率会产生一个看起来能用、但边界一塌糊涂的版本。这次我明确要求它先加载 brainstorming。Claude 果然没有直接写代码而是先问了几个关键问题重命名规则是简单替换还是正则匹配是否需要处理文件名冲突预览模式需要展示到什么粒度安全具体指什么——是防止覆盖还是要能回滚这些问题看似普通但现在回看它们全都在后续开发中成了分水岭如果没问是否处理文件名冲突生成的脚本大概率会直接覆盖同名文件如果没问预览粒度用户可能只能看到新旧文件名列表看不到具体差异。brainstorming 的价值在于它把我在需求阶段懒得多想的问题全部给捞了出来。这一轮下来我们确认了三个方案纯 Python 脚本、Python dry-run 参数、以及带变更日志的进阶版。Claude 甚至给了每个方案的推荐场景。4.2 第二阶段writing-plans 把方案变成施工图需求确认后我让它基于选定方案写计划。关键一步在这里计划必须写成独立文件而不是只存在于对话里。我让 Claude 调用writing-plans技能生成一份计划并且明确要求它保存成文件之后执行阶段再调出来。生成的计划结构大致如下# 批量重命名工具实施计划 ## 目标 - 支持前缀/后缀添加、指定字符串替换两种规则 - 支持 dry-run 预览 - 记录变更日志支持按日志回滚 ## 任务清单 1. 搭建项目结构与入口模块 - 创建 main.py定义命令行参数 - 验收python main.py --help 能列出所有参数 2. 实现映射规则引擎 - 规则数据结构定义与解析 - 验收单元测试覆盖替换与前后缀规则 3. 实现 dry-run 预览 - 输出 旧名字 - 新名字 对照表 - 验收执行 dry-run 不实际改动文件系统 4. 实现实际重命名与冲突检测 - 冲突时跳过并提示 - 验收两个文件映射到同一新名字时只保留第一个 5. 实现日志记录与回滚 - 记录到 rename_log.json - 验收根据日志能还原原文件名这份计划的每一个条目都带着明确的验收标准。我觉得这比让 Claude 一口气生成代码重要的多因为验收标准意味着 Claude 在执行时知道自己做到什么程度才算完成而不是自己觉得差不多就收手。4.3 第三阶段executing-plans 按图施工执行计划时我直接告诉 Claude读取之前的计划文件并开始执行。它做了几个我特别满意的动作第一步是重读了计划全文然后开始一个任务一个任务地推进每完成一个小任务就用简短的话报告进度并且对照验收标准自检。在实现映射规则引擎时它还主动补写了几个针对边界情况的单元测试比如空字符串替换、正则特殊字符转义、超长文件名冲突。这让我很意外因为我并没有要求它写测试但它从计划里的验收单元测试覆盖读到了隐含要求于是自作主张把测试补上了。这种按图施工但不机械照搬的表现正是技能文档和模型能力结合得好的结果。4.4 第四阶段systematic-debugging 收拾烂摊子当然计划再周密也会出问题。实际跑起来的时候回滚功能在 Windows 路径上出了 bug日志记录的是绝对路径但文件名含有特殊字符时 JSON 反序列化报错。我没有直接告诉 Claude 怎么改而是让它走一遍systematic-debugging流程。令人欣慰的是它没有上来就大改代码而是先复现问题、缩小范围、提了一个临时加日志的命令让我帮忙跑最终定位到问题根源是json.load时对反斜杠的转义处理不当而不是回滚逻辑本身出错。整个过程大约 15 分钟比我在 Stack Overflow 上翻答案再手动验证的方案快得多。更关键的是它最后在代码注释里写了根因说明避免后人再踩一遍。4.5 实战体验总结三个最直观的变化反复横跳明显减少。以前 Claude 可能在方案 A 和方案 B 之间自动切换现在它只按计划执行计划外的想法会先提出来征求我的意见而不是自己悄悄改变方向。验收标准缺位的场景变少。它每完成一个小任务会自己对照验收标准检查很多时候不用我再特意说你测一下。对话中断可恢复。计划文件独立存在即使中途新开对话也能让新会话读计划文件继续执行不用重新解释需求。这一点在公司里交接给同事新开对话时尤其好用。5. 用了一段时间后的体会和踩坑清单5.1 最大的坑计划文件堆积成山superpowers 的流程天然会产生计划文件、进度标记、变更日志。我第一个项目跑完项目目录里多了至少五个 markdown 文件——计划、子计划、执行状态、复盘。这些文件对长期项目来说是好东西但对一次性小工具来说就是噪音。我的做法是给一次性的小实验单独建临时目录跑完直接删掉整个目录只有真正要持续维护的功能才放项目根目录下保存计划。如果你用 git 管理项目记得把这类自动生成的计划文件纳入版本决策不要一股脑提交否则每个 Pull Request 里都混着一堆计划 markdownreviewer 会抓狂。5.2 不是所有任务都值得走完整流程superpowers 让我最犹豫的地方在于它有些过度工程化的倾向。现在我对任务做分级处理改动一个文件以内的简单改动直接让 Claude 改不调任何技能一个功能模块逻辑清晰但没有太多歧义让它写计划但不强制 brainstorming跨文件、或者需求本身还不清晰的任务完整走 brainstorming → writing-plans → executing-plans如果不分级让一个改 README typo 的任务也先来一轮头脑风暴体验会非常糟糕。技能是给人用的不是给人表演的把它当锤子不代表所有东西都是钉子。5.3 与自定义系统指令的配合方式如果你在 Claude Code 里已经有自定义的系统指令或项目约定的 CLAUDE.me 文件注意它们和 superpowers 可能产生指令冲突。我一开始的项目说明里写了一句尽量直接给出代码不要解释结果与 brainstorming 技能要求的先问问题再给方案直接打架导致 Claude 行为变得飘忽不定。后来我把系统指令改成了与技能兼容的表述把直接给代码调整为对于简单明确的任务可以直接给代码对于复杂任务先按可用技能流程处理。现在两者基本能协同工作不再互相拆台。注意如果你发现安装 superpowers 之后 Claude 的行为和预期不一致先别卸载检查一下是不是自己的系统指令在跟技能文档抢方向盘。技能可以通过自然语言说得更具体这次不要用 brainstorming直接按你的理解写计划。5.4 更新和升级的节奏作为第三方插件superpowers 的更新频率并不低核心技能的流程说明时不时会有调整。我出现过一次问题版本升级后旧计划文件里引用了旧的技能行为描述执行时 Claude 按新版技能流程处理结果和计划文件里的旧标记格式对不上。我的经验是升级插件后不要立刻启动大任务先跑一个 10 分钟内的小任务试探一下行为变化跨版本更新的情况更建议旧项目继续使用旧计划文件新项目再体验新流程。盲目追求最新版本没有必要稳定执行比新特性重要得多。5.5 关于agent 到底有没有变聪明的最诚实观察最后说一点可能和很多人预期不符的体会。superpowers 没有让 Claude 变得更聪明也没有增加我不知道的新能力它甚至让对话变得更笨——开场总是问东问西执行总是拆得碎碎的节奏明显变慢。但它的确让最后交付质量提高了。原因也很简单复杂任务翻车通常不是因为模型不够聪明而是目标没对齐、约束没人记录、方案在中途悄悄漂移。superpowers 提供的全部内容本质上是给这些软性问题装上护栏。对于自己写代码超过十年、习惯先设计再动手的人来说这套流程非常自然几乎不需要适应如果你本身是先跑起来再说的风格那你会觉得它极其啰嗦。我在实际使用中逐渐接受了一种观念让 AI 干活和带人干活是一样的你越是把流程说清楚结果就越可控superpowers 只是把这件事工业化了而已。
