说实话第一次在 GitHub 上看到 superpowers 这个项目名的时候我以为是某个人的中二收藏夹。真正用起来才发现这玩意儿就是给 AI 编程助手装了一套外挂工作流。简单说superpowers 是一组可复用的 Agent Skills它把头脑风暴、任务规划、测试驱动开发、调试排障这些本来靠人经验才能做好的事情固化成了模型能直接读取的操作手册。你不需要会写特别玄学的提示词只要安装好它然后在对话里把技能名字一甩模型就会按一套成熟的方法论帮你把活干完。这篇文章会从 superpowers 是什么、有哪些 skills、怎么安装引入、实际跑通一个任务到常见坑位全流程讲清楚。无论你是刚接触 AI 编程还是已经被模型乱改代码折磨到崩溃都能从这里找到能落地的办法。我自己的使用场景主要是在日常项目开发里接手一个老代码库、拆需求、写单元测试、排查线上问题、补技术文档。以前这些东西都得靠我一遍遍在对话里“喂”上下文后来把 superpowers 装进技能目录之后很多时候只需要一句话“用 brainstorming 帮我想几个方案”或者“用 debugging 技能帮我定位这个报错”。模型输出的质量直接上了一个台阶。这篇文章不会跟你拽术语所有概念我都会用最直白的方式解释并且把每一步操作都拆开给你看。1. 先搞明白 superpowers 是什么它解决的问题和设计逻辑1.1 它不是新模型而是一套“给 AI 的工作手册”很多人第一次看到 superpowers 都会有个误解觉得它是不是一个新的模型或者新的编程语言。真不是。它本质上是一堆用 Markdown 写成的技能说明文件最常见的入口文件叫SKILL.md。这套文件遵循 Agent Skills 的组织规范会被 AI 编程工具自动扫描、索引。当你在对话里提到某个技能名字模型就会去读取对应的说明文件然后按照文件里写好的流程来执行任务。我习惯把它类比成给新员工发的一本《岗位操作手册》。新员工如果是空降的你直接跟他说“把这个模块重构一下”他多半会东一榔头西一棒子最后给你搞出一堆意料之外的改动。但如果你先把手册拍在桌上里面写清楚了“第一步先看调用链第二步列风险清单第三步小步重构第四步跑全量测试”他再笨也能按流程走出个七八分。superpowers 干的就是这件事把人类工程师多年积累的做事方法写成模型能看懂、能照做的标准化流程。这个设计逻辑其实很妙。大模型本身的能力当然重要但同样一个模型给它一段清晰的流程指导和直接丢一句“帮我写代码”结果差异极大。技能包的价值不在于让模型“变得更聪明”而在于让它“更有章法”。我见过身边不少同事抱怨 AI 写代码不靠谱一问才知道他们的用法还停留在“给出需求、直接生成代码”的阶段完全没有利用技能包这类东西去约束模型的思考路径。这就是输在起跑线上了。1.2 为什么我不再用长篇提示词而是改用技能包在接触 superpowers 之前我也算半个提示词工程师每次让模型做事都要在对话开头写一大段“你要扮演什么角色、注意什么事项、分几步完成、输出什么格式”。这种写法不是不行但问题特别多一是提示词越长模型越容易在中间丢掉前面的指令二是每次开新对话都要重新复制一遍稍微改个字就前后不一致三是这些个人风格极强的提示词根本没法在团队里共享。技能包解决的就是这三个痛点。它把方法论和具体任务剥离开来方法论固化在SKILL.md里任务描述则放在你当下的对话里。模型会自动识别该用哪个技能不再需要你每次重复“你要先分析、再计划、最后实施”这种废话。而且技能包只要通过 Git 管理团队里所有人拉到同一个仓库就拥有一模一样的工作标准。这点对团队协作特别重要相当于把“老师傅的经验”变成了“团队的基础设施”。不过这里也得泼一盆冷水技能包不是装得越多越好。我刚开始用时一口气装了十几个技能结果模型每次都要先猜“用户到底想让我用哪个”有时候反而把简单问题复杂化。正确思路是先用默认的最小集把最常用的三五个技能跑顺再逐渐加入新的。技能包解决的是“无序”问题而不是“数量”问题这一点一定要记住。2. 拆解核心 skillssuperpowers 里到底有哪些技能2.1 高频使用的技能清单与适用场景superpowers 的技能列表在不同版本里会有些差异但核心的几个基本是稳定的。我把自己日常使用频率最高的几个整理成了表格方便你对照自己的场景去选技能名称适用场景我的使用频率brainstorming需求发散、方案选型、头脑风暴每周 5 次以上planning把大任务拆解成可执行步骤每周 10 次以上TDD测试驱动开发、先写测试再写实现写新功能时必用debugging定位 bug 根因、系统性排查问题遇到异常必用code-review代码审查、发现潜在缺陷提交 MR 前使用documentation生成 README、接口文档、变更日志低频但很有用retrospective项目复盘、反思迭代过程每个迭代结束用一次先说 brainstorming。这个技能最适合的场景就是需求特别模糊、你脑子里有好几种方向但拿不准的时候。它会要求模型先跟你确认背景信息然后主动生成多个候选方案而不是一上来就写代码。我最近做一个后台权限模块就是靠它一次性输出了“RBAC、ABAC、简单角色继承、策略引擎”四套方案每套还附了优缺点和落地成本。换在以前我可能只会对着模型说“帮我设计个权限系统”然后被它输出的第一版方案牵着鼻子走。再说 planning。这个技能是我日常用的最多的。它会把“实现一个功能”拆成“环境分析、依赖梳理、任务列表、风险点、验证方式、回滚策略”等几个维度让模型先输出一份完整的计划再开始动手。TDD 技能就更硬核了它要求模型先写失败的单测再写最小实现最后重构。我刚用的时候很不适应总觉得这样太慢但坚持两个星期以后项目的回归 bug 明显变少了。debugging 技能则是排查问题时的救命稻草它会引导模型不急着改代码而是先要求你提供复现步骤、日志、代码上下文然后按“假设 - 验证 - 定位”的循环去缩小范围。 code-review、documentation 这类技能属于“锦上添花”但组合起来能给项目兜底。2.2 技能组合起来的“超级工作流”单独用一个技能只能解决一个环节的问题但 superpowers 真正的威力在于把多个技能串成一条完整的流水线。我每次接新需求默认的工作流是这样的先用 brainstorming 把需求聊透看看有没有被忽略的边界情况接着用 planning 把确定下来的方案拆成任务清单写代码阶段切到 TDD让测试先定义“什么叫完成”代码写完后用 code-review 挑毛病最后用 documentation 把坑和用法写清楚。这一整套流程走下来一个需求从模糊到交付中间几乎不需要我自己操心步骤顺序。这种组合方式背后的逻辑是让模型在合适的时间做合适的事情。比如大部分模型天生喜欢“跳过分析直接写代码”如果你在 brainstorming 阶段让它写代码它反倒写不好。技能包相当于给模型设了一道道闸门逼着它先发散、再收敛、再执行、再验证。我经常跟朋友开玩笑说“superpowers 的每一个技能都是一个小监工专门盯着模型不要走捷径。”刚开始尝试组合使用的时候你可能会觉得“多此一举”但这恰恰是最值得投入的地方。你可以从最简单的两个技能开始比如 TDD code-review等熟悉了它们的语气和输出格式再加 brainstorming planning。慢慢你会发现任何复杂的项目开发任务都可以被拆解成一组固定的技能调用链。这个思路放到团队里更是可以直接沉淀成一套内部的“交付标准流程”。2.3 SKILL.md 的结构与自定义要素如果你想真正理解并改造 superpowers光会用是不够的还得会看SKILL.md文件的结构。这种技能文件一般分为两大部分最顶上的 YAML frontmatter以及正文中的步骤描述。 frontmatter 里通常包含name、description、when_to_use、version这些字段相当于技能的“身份证”。模型会通过description和when_to_use来判断当前对话要不要激活这个技能所以这两段描述一定要写得清楚。我自己见过不少改坏技能包的情况都是因为把description写得太笼统模型根本不知道什么时候该用它。下面是一个简化的SKILL.md示例展示核心结构--- name: brainstorming description: 使用头脑风暴方法帮助用户发散需求生成多个候选解决方案。 when_to_use: 当用户面临模糊需求、需要多种方案或难以决策时使用。 version: 1.0.0 --- # Brainstorming 技能 ## 目标 与用户合作生成尽可能多的候选方案并最终收敛到可执行的方向。 ## 执行步骤 1. 询问或提取用户的背景、限制条件与目标。 2. 基于背景信息先不评价优劣生成至少 5 个候选方案。 3. 与用户一起对方案进行快速筛选剔除明显不合适的选项。 4. 输出最终候选方案及优缺点对比。 ## 注意事项 - 不要在第一轮就下结论。 - 每个方案都要说明适用前提和成本。 - 如果用户信息不足主动提问而不是替用户假设。文件里正文的“执行步骤”是模型实际照做的操作流程所以要写得具体、可执行。你在用 superpowers 的过程中完全可以按照自己的习惯去改这些步骤。比如我不喜欢“至少 5 个方案”这种硬性数字就会把它改成“依据问题复杂度生成 3 到 5 个方案”让模型灵活处理。改完以后放到用户级技能目录里就会覆盖掉项目里的同名技能。但改的时候有一个大坑frontmatter 的格式必须严格正确。三个横线不能少字段名不能拼错值不要加奇怪的引号。模型解析 YAML 的能力虽然不弱但遇到格式错误时经常不会报错而是“假装看到”。表现就是技能不生效或者生成的内容跟描述完全跑偏。遇到这种情况不要怀疑模型先回去检查你的SKILL.md头部的语法。3. 安装 superpowers从环境准备到首次调用3.1 安装前置条件与目录规划在动手安装之前先确认三件事。第一你的 AI 编程工具要支持 Agent Skills 这种技能机制目前主流的大模型编程工具基本都已经支持具体可以看工具文档里有没有skills目录的说明。第二本机要装好 Git能 clone 项目仓库这个一般做开发的都有。第三弄清楚技能目录的加载规则项目级目录通常放在当前工程下的.claude/skills/或者工具对应的隐藏目录用户级目录则放在你本机的用户主目录下比如~/.claude/skills/。两者优先级不一样项目级会覆盖用户级这点后面会细说。我的建议是不要一上来就装到用户级目录。先在你的一个真实项目里做一次项目级安装验证熟悉了再考虑用户级全局安装。为什么因为项目级安装的风险面小万一技能包有问题最多影响当前一个项目不会污染你所有的工作环境。而且项目级的技能包可以随着 Git 仓库提交给同事方便团队统一使用。用户级安装更像“全局插件”适合放那些你希望在任何项目里都能调用的通用技能比如 brainstorming、planning 这类不依赖具体业务的技能。还有一点容易被忽略技能目录的命名。通常一个技能包就是一个文件夹文件夹的名字会显示在技能索引里。如果你把一个叫“brainstorming”的技能文件夹误命名为“brainstorming-v2”模型在索引时可能认不出来因为技能名称和文件夹名称不一致的情况很容易出问题。所以安装时尽量保持仓库原有的目录结构不要让技能文件夹多套一层无关的外壳。3.2 实操安装步骤用户级和项目级这里我直接把命令写给你假设你已经把 superpowers 的仓库地址拿到了。在 GitHub 上搜索 superpowers找描述里带 Agent Skills 字样的仓库复制它的 Git 地址然后执行下面的命令。以项目级安装为例cd /path/to/your/project mkdir -p .claude/skills git clone superpowers仓库地址 .claude/skills/superpowers以用户级安装为例mkdir -p ~/.claude/skills git clone superpowers仓库地址 ~/.claude/skills/superpowers装完之后最好看一眼目录结构确保SKILL.md文件确实在superpowers文件夹下面。常见的一个错误是把仓库 clone 成了.claude/skills/superpowers/superpowers/SKILL.md多套了一层目录导致工具找不到技能。如果出现这种情况把多余的一层目录剥掉就行了。装好之后要重启你的 AI 编程工具或者在工具里执行一个“刷新技能”之类的命令让新加入的技能被重新扫描到。这一步特别容易忘有些人装完技能包发现没效果其实只是工具还停留在旧索引里。重启之后你可以在对话里输入类似“列出所有可用技能”的指令工具会把识别到的技能名字逐一列出来。看到 superpowers 下的几个技能出现在列表里才算真正安装成功。3.3 三种引入技能的方式以及各自适合的场景装好之后怎么让模型真正用上这些技能我总结了三种方式你可以根据场景灵活切换。第一种是在对话里用符号直接点名引用。比如输入“brainstorming 帮我想一下登录模块除了账号密码还能怎么做”模型会优先读取 brainstorming 技能然后按里面的步骤来回答。这种方式最推荐因为意图清晰模型不用自己猜该不该用技能。适合在你有明确目标、且确定某个技能能帮到忙的时候。第二种是把技能说明写到项目说明文件里比如项目的README或工具会读取的CLAUDE.md中。你可以加一句“本项目支持使用 .claude/skills 目录下的技能遇到需求分析请使用 brainstorming遇到任务拆解请使用 planning”。这样即使你不手动点名模型在合适的时机也会主动选用技能。适合那些你希望模型“自动形成习惯”的项目。第三种是直接把SKILL.md的核心内容复制粘贴到对话里。这种方式最笨但在工具不支持技能索引或者你临时在网页端使用 AI 时很有用。相当于把技能包当成一个“提示词模板库”。虽然不优雅但在受限制的环境下能救命。我一般出差不方便进入项目目录时就用这种办法从用户级技能包里把对应技能的步骤粘给网页版对话。这三种方式不是互斥的。我的习惯是常用技能用第一种手动点名项目规范类技能用第二种自动激活临时环境用第三种保底。你完全可以根据自己的工具和习惯去组合。4. 实测记录用 planning 技能完整跑通一个任务4.1 一个真实小任务给博客站加标签聚合页光讲理论不过瘾我拿前两天刚刚做完的一个真实任务来复盘。我有个基于静态站生成器搭的博客文章里已经写了 tags 字段但缺少一个把相同标签的文章聚合起来的列表页。这个功能不大不小直接让模型写代码很容易翻车所以我想试试用 superpowers 里的 planning 技能来控场。我在项目目录下启动了 AI 编程工具然后输入了这样一段话“planning 给博客增加一个标签聚合页要求从所有 markdown 文章里提取 tags 字段生成 /tags/ / 这样的静态页面并在文章页显示相关文章列表。请先不要写代码给出计划。”注意我在提示词里刻意加了“先不要写代码给出计划”这个约束。因为 planning 技能的关键输出是计划而不是最终代码。如果你不加约束模型很容易把计划草草两句话带过然后直接开始生成代码。加了约束后模型会按照技能里的步骤去分析项目结构、依赖关系、输出清单。4.2 调用技能前后的模型表现对比没有技能的时候我让模型做同样的任务它的输出大概是这样先一句“好的我来帮你实现标签聚合页”然后就直接列出要改的文件开始写模板代码和生成逻辑。看起来很快但你仔细一看就会发现它完全忽略了一个关键问题当前静态站生成器的版本是否支持动态集合它也没有关心文章顺序、标签大小写、空标签这些边界情况。结果就是生成的代码大概率跑不通或者跑到一半报错。而用了 planning 技能之后模型的输出结构变成了先确认技术栈和项目目录结构再列出“标签聚合数据从哪来、按什么格式输出、路由怎么生成、页面模板需要哪些变量、性能上有哪些隐患、如何验证结果”最后才给出一份分步骤的实施计划。它还主动提出了一个我没考虑到的问题标签页需要处理 URL 中的中文和空格否则生成静态文件时会出乱码。这种细节就是技能包带来的明显差异。整个过程大概多花了几十秒但省掉的是后面数小时的调试时间。用技能包最神奇的一点就是它不会帮你省略思考而是强迫模型先思考再行动。这和我们平时看老师傅带新人是一样的重要的不是代码敲得多快而是流程对不对。模型在流程对的情况下写出来的代码反而比闷头一次性生成的代码要稳得多。4.3 我调整过的一个关键细节第一次使用 planning 技能的时候我发现它对“任务拆分”这件事做得不错但输出的计划偏向于“开发视角”缺少“验证视角”。例如它列出了“生成标签页、修改模板、添加导航链接”但没有明确写出“如何确认所有文章都被正确聚合”。后来我在SKILL.md的步骤里加了一条“每项任务必须包含验收标准”整个计划的质量一下子又提上去了。这个调整让我意识到技能包不是一成不变的神器它更像是一个可以持续打磨的流程框架。你觉得它哪里不够好直接改对应的SKILL.md就行。我后来还把自己的一些编码规范也写进了 planning 技能的注意事项里比如“所有路径必须使用相对路径”“静态资源要加哈希指纹”。这样模型在后续任务里都会默认遵守这些约定相当于把我的个人规范变成了模型的肌肉记忆。但在调整技能包的时候有个线索一定要记住改动只对后续对话生效对当前正在进行中的对话不一定立刻生效。因为模型可能在对话开始时就已经缓存了技能内容。如果你改完技能后当前对话里发现模型还在用老流程别慌新开一个对话再试就好。这个问题我踩过好几次特意放在这里提醒你。4.4 实测下来的效果和注意事项最终我按照 planning 技能生成的计划让模型分步实现了标签聚合页。整个过程比我预估的时间少了大概一半而且代码基本没有返工。最爽的地方在于每步完成之后模型都会回到计划里打勾并给出验证命令。例如它会说“这一步已完成执行npm run build然后检查 /tags/xxx 页面是否生成”。这时候你只需复制命令去终端跑一下看到结果正常就继续下一步。这种“一步一步验收”的节奏让人非常安心。不过也有个注意事项planning 技能生成的计划再完美也要你自己做最后一道审核。它可能会因为你提供的背景信息不足而做出错误假设比如把你的目录结构猜错。所以每次调用完技能我会先扫一眼第一部分的“环境假设”是否正确。如果模型假设错了我会直接在对话里纠正再让它重新更新计划。这一步千万别省模型不怕你纠正怕的是你盲目相信它的第一个输出。5. 常见问题与排查技巧实录5.1 技能没生效最先检查的三个位置如果安装完 superpowers 之后发现模型完全不理技能先别急着怀疑工具 bug按顺序检查三个位置。第一是目录结构。确认SKILL.md文件是不是正确地放在技能的根目录下路径里不要有多余的层级。第二是文件头部格式。你可以打开SKILL.md看一眼最顶部是不是三行横线和 YAML 字段如果横线少了或者字段缩进有问题模型就可能解析失败。第三是工具版本。Agent Skills 是新特性版本太老的工具不支持需要升级到最新版本。我遇到过最诡异的一次是因为不小心把技能目录放在了.claude/而不是.claude/skills/下面工具自然找不到。这类问题用“看目录、查头部、瞧版本”三步法基本能覆盖 80% 的故障。还有一个经常被忽略的检查点技能目录的权限。如果你把技能文件夹放在一个有特殊权限限制的路径下面工具进程可能没有读取权限。尤其在公司电脑上用户主目录或项目目录可能被安全策略限制得死死的。这时你会看到技能列表里什么都没有但也不会报错。解决办法就是确认技能目录对当前运行用户有读权限或者干脆把技能复制到另一个可访问的位置。5.2 模型总是不调用技能怎么把它“点”醒有时候技能装好了、目录也没错但模型在对话里就是不主动用技能尤其明明遇到“该 brainstorming 的问题”它却直接开写。这种情况的原因多半是模型没有从你的话里识别出“该用技能了”。我的处理办法是在提示词里直接点名比如“请使用 brainstorming 技能先发散一下方案”。这个“请使用 xx 技能”短语对模型来说是很强的指令信号比单纯靠when_to_use描述去触发要可靠得多。如果你希望模型以后都能在合适时机自动激活技能而不是每次手动点名可以在项目说明文件里加上一句类似“遇到模糊需求时应该自动使用 brainstorming 技能遇到任务拆解时应该自动使用 planning 技能”。这一招本质上是把技能触发的判断条件前置成项目规范让模型在每次对话开始时就带上这个上下文。我用了之后自动调用技能的频率明显变高了。还有一个小技巧调用技能时不要和模型聊太多无关话题。如果你先聊了一堆中午吃什么再突然说“帮我写个批量重命名脚本”模型有可能会把技能调用这件事冲到九霄云外。尽量在每条涉及任务的消息里都带上技能名最简单也最可靠。5.3 项目级与用户级技能冲突到底谁说了算前面提到项目级技能会覆盖用户级技能但很多人对这个“覆盖”的理解有偏差。实际上在我的实践里同名冲突时项目级目录里的技能文件会优先被加载用户级目录里的同名技能在项目内会被忽略。这个设计本来是为了满足不同项目使用不同技能版本的需求但也带来一个坑如果你在用户级改了一个技能而项目里还留着一个旧版项目级技能你就会奇怪为什么自己的修改“没生效”。排查办法很直接先看看当前项目目录.claude/skills/下有没有同名的技能文件夹。如果有优先处理它。如果你希望用户级技能生效可以把项目级那个同名技能文件夹删掉或改名。反过来如果项目里确实想用定制版建议把定制版提交到项目代码仓库里让团队所有成员共享一套标准而不是各改各的用户级版本。我在本地维护用户级技能的时候会把每个技能的原始版本和我的定制版分开文件夹放比如superpowers-original和superpowers-custom然后让工具只加载定制版。这样一来仓库一更新我还能对比一下官方又改了哪些步骤再决定要不要把自己的定制同步过去。这个小习惯帮我省了很多次“莫名其妙技能行为变化”的排查时间。5.4 技能包用着不顺手自己改一个私有版本superpowers 最大的魅力就是“代码都开源随便改”。如果你对某个技能的执行步骤不满意完全可以直接复制一份到用户级目录改成自己的私有版本。比如我不太喜欢默认 brainstorming 技能里的“至少生成 5 个方案”这条规则因为简单的需求根本不需要那么多方案我就会把它改成“依据问题复杂度生成 3 到 5 个方案”。改完之后项目级和用户级目录中同名技能会以用户级目录里的版本为准所以不影响项目里默认版本。改技能的时候我强烈建议用 Git 管理起来。先给私有技能目录初始化一个 Git 仓库每次修改都提交一次记录“为什么要这么改”。这样万一以后改乱了还能回滚到上一个版本。用 Git 管理还有一个好处你可以把私有技能仓库同步到团队内网让团队其他人也能拉到同一套定制版技能。你的最佳实践就不再只是躺在对话记录里而是变成了团队可复用的资产。要格外注意的是私有化改造不要动掉技能文件的name字段。这个字段是模型索引技能的唯一标识你改了名字就相当于创造了一个新技能原来的触发词就不在了。最好只改正文步骤或description保持技能名字稳定。我自己吃过一次亏把name从brainstorming改成了my-brainstorming结果在对话里喊brainstorming半天没反应排查了很久才发现是名字对不上。5.5 问题速查表为了方便收藏我把上面提到的常见问题整理成一个速查表症状可能原因解决办法技能列表里看不到技能目录层级不对或工具未刷新检查SKILL.md位置重启工具技能看得到但调用无反应frontmatter 格式错误检查 YAML 头部语法模型不主动调用技能缺少触发指令在提示词里点名技能名改了技能没生效项目级同名技能覆盖处理项目级目录下的同名文件技能行为突然变化原仓库更新或缓存未刷新对比更新记录新开对话测试多套一层目录找不到技能clone 命令多了外层文件夹把技能文件移到正确目录层级这张表我打印出来贴在了显示器边上每次谁问我“为什么技能不生效”我就让他先对着表自查一遍。别小看这些基础检查绝大多数问题不是工具 bug而是配置细节没到位。6. 我的最后几条实操心得折腾 superpowers 这几个月我最深的体会是工具再好也得靠流程才能发挥价值。一开始我也走了弯路把技能包装了一大堆结果模型并不知道该先调哪个输出反而比不用技能更乱。后来我狠心删到只剩六个核心技能按“脑暴 - 规划 - 编码 - 审查 - 文档”的顺序组织起来效率才真正上来。所以如果你刚接触千万别贪多挑两三个最贴合你工作流的技能先用跑顺了再慢慢扩展。还有一点经验是每个技能至少单独试两次再把它放进你的组合流程里。第一次试是为了搞明白它的输出风格第二次试是为了验证它是不是稳定。如果两次结果都符合预期再考虑把它加到组合链路中。我现在新增技能都遵循这个原则避免一个不成熟的技能混进主线导致整个工作流质量下降。最后分享一个小技巧把你自己的团队规范也写成技能包。superpowers 给了我一个灵感——既然通用的工程方法能做成技能那团队特有的编码规范、发布检查清单、安全审查要点为什么不也做成技能包呢我现在已经把“项目发布检查清单”和“接口兼容性审查”这两条团队规范写成了私有技能放在用户级目录里。每次让模型改代码之前都会自动触发一遍相关检查相当于给整个团队配了一个从不打瞌睡的流程检查员。这个玩法一旦跑起来你会发现 superpowers 的价值已经远远超出了“下载一个技能包”本身它变成了一套你专属的 AI 工作方法论。