Superpowers 这个项目最近在开发者圈子里火得有点不讲道理热门搜索词直接就是“想要安装 superpowers”各大技术群里天天有人问怎么配、怎么用、命令行到底怎么敲。一开始我以为又是个蹭 AI 热度的花瓶工具实际装完用了两周之后我只想说我错了——这玩意是真的能把 GitHub Copilot 从“一个会打字的聊天机器人”变成“一个懂你项目上下文、能复用的高级助理”。如果你也是每天要跟 Copilot Chat 反复说“帮我按团队规范生成提交信息”“检查这个文件的 bug”“给这段代码写测试”的开发者那这篇就是给你的实操记录。我会从安装、配置、第一个 Action 的诞生到真实项目里的工作流和踩坑实录一条龙讲清楚。1. 为什么“Superpowers”值得装痛点与设计逻辑1.1 别把 Copilot 当聊天工具把它当“实习生”很多人的 Copilot 用法是打开对话框把文件路径一贴然后开始手打一大段提示词“请帮我看一下 src/modules/order/index.ts 这个文件当前用户是管理员时未做权限校验请修复并补充单测注意不要修改其他文件……”这段话每次都要重新敲每次都要把上下文重新描述一遍。团队里有十个人十个版本的提示词输出风格五花八门。Superpowers 的核心设计逻辑就一句话把重复性的 AI 指令固化成可复用的操作Action像函数一样按需调用。你可以把这个思路理解成代码重构——把散落各处的重复逻辑提取成公共函数。以前你每次跟 Copilot 对话都是在现场写一段“临时脚本”现在你把这段脚本抽出来、放进专属目录、给它取名、定义参数项目成员一键复用。这种体验上的差距就像从复制粘贴代码到使用工具函数库的区别。1.2 它解决的不是“生成代码”而是“稳定复现高质量交互”我见过太多团队抱怨 Copilot 生成的东西“不可控”。其实很多时候问题不在模型而在提示词太随意。Superpowers 把提示词做成了带 frontmatter 的 Markdown 文件让提示词可以版本管理、评审、测试、演进。这就把原本玄学式的“AI 调教”变成了工程化的资产沉淀。另一个关键痛点是上下文。Copilot Chat 默认的上下文窗口有限而且经常拿错文件。Superpowers 允许在 Action 里显式声明需要读取哪些文件、关注哪些目录、输出什么格式这等于你手动给模型划定了一个“工作半径”。实测下来同样的任务用它组织过的提示词比临时手打的准确率高出一大截尤其是在大仓库里。1.3 工作原理一句话讲清楚Superpowers 本质上是 VS Code 的一个扩展它提供了一组管理命令让你能创建、编辑、触发“操作”。每个操作就是一个 Markdown 文件文件名就是操作的“函数名”文件内容就是系统提示词。当你触发操作时扩展会把操作内容、你附加的文件或选区、以及当前项目上下文一起注入到 Copilot Chat 中并自动生成一条完整的、格式良好的对话消息发给模型。你可以把它理解成给 Copilot Chat 装了一套“快捷指令”——不是简单地把一串话粘贴进输入框而是带着完整的上下文编排逻辑去调用模型。这套设计的好处非常明显团队协作时大家用的是同一套沉淀好的提示词模板而不是各自发挥。2. 安装与环境准备从零把环境搭起来2.1 前置依赖清单先别急着敲命令把环境清单过一遍。Superpowers 依赖的是 VS Code 的 Copilot Chat 能力所以下面这些东西缺一不可依赖项版本要求说明VS Code1.85 及以上老版本对 Chat 的支持不完整容易出现兼容问题GitHub Copilot 插件必须安装需要有一个可用的 Copilot 订阅账号GitHub Copilot Chat 插件必须安装Superpowers 通过 Chat 面板与模型交互Node.js可选16仅在使用 CLI 命令创建操作时需要这里有个容易踩的坑有些人只装了 Copilot 本体没装 Copilot Chat运行 Superpowers 时一脸懵。因为 Superpowers 的触发入口在聊天面板它调用模型也是走 Chat 这条链路没有 Chat 就没法工作。2.2 两种安装方式图形界面与命令行第一种方式最直观打开 VS Code按CtrlShiftX打开扩展面板搜索 “superpowers”找到发布者信息里带官方标识的那个点 Install。装完重启一下窗口。第二种方式适合喜欢用命令行操作的人在终端里执行code --install-extension nexus-ai.superpowers看到输出Extension nexus-ai.superpowers was successfully installed!就说明装成功了。如果code命令提示找不到说明 VS Code 没有把 CLI 工具加到 PATH 里在 VS Code 里按CtrlShiftP搜索 “Shell Command: Install ‘code’ command in PATH” 执行一次就好了。安装完检查一下打开命令面板输入 “Superpowers”如果能看到 “Create New Superpower Action”“List Actions” 之类的命令说明核心功能已经加载成功。2.3 验证环境是否跑通打开 Copilot Chat 面板在聊天输入框里敲一个/看自动补全菜单里有没有出现你创建的 Action。没有 Action 也没关系能看到 Superpowers 相关的命令就是这个扩展已经挂载成功的信号。为了保险我建议顺手验证一次完整链路用命令面板执行 “Create New Superpower Action”随便填一个名字编辑器里会打开一个 Markdown 文件里面是操作模板。此时你再回到 Chat 对话框输入/加那个名字如果能看到补全项说明从“创建到触发”的整个链路已经通了。这一步之所以重要是因为很多人装完只看到侧边栏多了个图标就以为完事了结果发现聊天框里调不出来问题往往出在 Copilot Chat 没重启。3. 核心概念与 Action 文件神学3.1 Action 到底是个什么东西说真的我第一次看到它的文档时愣了一下原来一个“超能力”就是一个 Markdown 文件对就是如此简单。这个设计非常聪明——用纯文本格式承载提示词意味着你可以把它扔进 Git 仓库、做 Code Review、写自动化测试、在团队里直接分享。每个 Action 文件由两部分组成头部 frontmatter 和正文提示词。frontmatter 声明元信息比如操作名称、描述、是否危险正文就是在告诉 Copilot 遇到这个指令时应该怎么思考、按什么格式输出。这种把“方法论”从人脑中抽出来、落到文本的形式恰恰是知识管理最朴素也最有效的形态。3.2 文件存放位置与搜索规则Action 文件默认存放在项目根目录的.superpowers/actions/下面。当然它支持全局目录——放在用户目录下的~/.superpowers/actions/这样你在任何一个项目里都能调用。需要注意搜索优先级项目内的 Action 会覆盖全局同名 Action。这个规则很容易被忽略有时候你在全局定义了一个“代码审查”操作到某个项目里触发后却得到了完全不同的结果八成是项目里有同名文件把它覆盖了。排查时先看看.superpowers/actions/下有没有同名文件。另外文件名就是触发名。比如你创建一个review-code.md在 Chat 里输入/review-code就能触发。文件名的命名直接决定你们的“输入口令”最好用英文小写加连字符别用空格和中文——不是不能用是团队协作时切换输入法很痛苦。3.3 操作文件的基础格式与变量注入打开一个新建的 Action 文件你会看到一个模板结构。它包含几个关键的 frontmatter 字段下面这几个是最常用的字段作用示例name操作显示名生成提交信息description操作说明辅助 Copilot 自动匹配根据 git diff 生成提交信息dangerous标记高危操作触发时需确认truemodel可指定模型按需使用gpt-4o正文部分支持变量注入。我最常用的是两个{file}表示当前活动文件的完整路径{selection}表示你在编辑器里选中的代码文本。还有{command}之类的但用的比较少。这些变量看起来简单却是让操作从“通用模板”变成“懂你项目”的关键。举个例子你可以在操作里这么写请分析文件 {file} 中选中区域 {selection} 的逻辑找出潜在的边界条件问题并直接给出修复代码。当这个操作被触发时占位符会被自动替换成真实内容Copilot 就相当于拿到了“精确坐标”不再需要你手打文件路径。4. 实操创建第一个能用的 Action4.1 第一个操作自动生成规范提交信息我强烈建议你的第一个 Action 别搞复杂的就从“根据暂存区 diff 生成提交信息”开始因为它的收益立竿见影。在项目根目录创建.superpowers/actions/write-commit.md内容如下--- name: 生成提交信息 description: 根据暂存区的 git diff 生成符合 Conventional Commits 规范的提交信息 --- 请执行以下操作 1. 先运行 git diff --cached --stat 查看暂存区改动文件列表 2. 再运行 git diff --cached 查看完整 diff 3. 根据改动类型判断是 feat、fix、refactor、docs 还是 chore 4. 输出一条简洁的提交信息格式为type: 中文描述 5. 不要写正文只输出标题行长度不要超过 80 个字符保存之后在 Copilot Chat 输入框敲/选 “生成提交信息”你会看到 Copilot 依次执行 git 命令、分析 diff、输出一条规范的 commit message。全程不需要你复制任何 diff非常省事。这里有个细节操作正文里写“先运行 git 命令”不是装饰语Copilot 在编程场景接到这类指令时确实会去执行终端命令来收集信息。这也提示了一个原则——给 Copilot 的信息不要靠描述而是靠让它自己取准确性会高很多。4.2 进阶带参数的操作参数功能让 Action 真正具备了“函数”的味道。还是以生成提交信息为例如果不只想生成提交信息而是想根据 bug 单号创建 fix 分支就需要接收一个参数。创建.superpowers/actions/hotfix-branch.md--- name: 创建热修分支 description: 根据 bug 单号创建 fix 分支并切换到该分支 --- 请根据以下参数执行操作 - bug 单号{bugId} 执行步骤 1. 运行 git checkout main 2. 运行 git pull 3. 运行 git checkout -b fix/{bugId} 4. 运行 git push -u origin fix/{bugId}触发时Copilot 会先询问你“bug 单号”的取值你输入之后它再执行。实测中这个交互体验非常自然它基本等于给了 AI 一个“参数化的工作流模板”。要提醒的是涉及git push、删除文件、覆盖代码这类操作务必在 frontmatter 里加上dangerous: true。这样每次触发时界面会多一个确认步骤能有效挡住手误。我自己就曾经在一个演示里直接让 Copilot 推了一个临时分支上去倒也没出事但那种“它自己动手执行外部操作”的感觉还是有点吓人确认机制可以让心里更踏实。4.3 调试动作跑一次看它到底干了什么第一次触发新的 Action建议在 Chat 面板里把对话展开仔细观察它理解的“参数”和“步骤”是否符合你的预期。所谓调试其实就是看两件事第一变量是否被正确替换第二模型的执行顺序是否正确。如果发现变量没替换成真实值先检查文件名和变量拼写{}这种语法很容易手滑多打个空格如果执行顺序有问题就把步骤列表改得更死板一点用数字编号 1、2、3并在每个步骤前加“必须”模型对这个词的响应很灵敏。5. 把 Superpowers 用到真实项目工作流5.1 代码审查流程改造这是我目前最喜欢的用法。以前做 Code Review我得打开 PR 页面逐个文件看 diff然后自己总结问题。现在我把整个流程打包进了一个 Action--- name: 审查当前分支 description: 对当前分支相对 main 的全部改动进行代码审查 --- 请按照以下步骤执行 1. 运行 git diff main...HEAD --stat 获取改动文件列表 2. 逐个文件阅读改动内容 3. 按照以下维度输出审查意见 - 逻辑正确性是否存在边界条件漏洞 - 安全性是否有越权、注入、敏感信息泄露风险 - 性能是否有明显可优化的循环或查询 - 代码风格是否与现有代码风格一致 4. 每个问题标注所在文件和行号情绪平和直接指出问题触发这个 Action 后Copilot 会自动拉取当前分支与 main 的比较结果然后给出结构化审查报告。实测下来它最大的价值不是替代人工审查而是先把低级问题——比如重复代码、明显的空指针风险、命名不规范——全部过滤掉让人工 review 的精力聚焦在架构和业务逻辑上。5.2 测试驱动开发中的测试生成写单测是很多人最头疼的环节因为重复度高、模板化强。我建议单独建一个测试生成操作专门针对选定函数--- name: 生成单元测试 description: 为当前选中函数生成完整的 Vitest 单元测试 --- 请为 {selection} 生成单元测试 1. 使用 Vitest 的 describe / it / expect 结构 2. 先梳理该函数的输入输出、依赖和边界条件 3. 覆盖正常场景、空值场景、异常场景三种情况 4. 不要 mock 业务内部函数优先使用真实集成 5. 测试文件路径与源文件同目录文件名追加 .spec 后缀这个操作配合编辑器选区使用特别舒服——我把光标放在函数名上触发操作它自己读取选区内容然后直接在右侧新建测试文件。模板化的测试再也没让我因为“忘了边界条件”而被 code review 打回。5.3 团队共享与版本化管理Superpowers 最有价值的应用模式是团队沉淀。把.superpowers/目录提交进 Git 仓库就等于给全组人发了一套统一的 AI 操作手册。新人来了clone 项目、装扩展马上就能用跟全组一样的提示词体系不用再亲手教他“怎么问 Copilot”。这跟我们写代码时抽取公共函数、统一工具库的思路完全一致。哪怕是两三个人的小项目我也建议把.superpowers/纳入版本管理否则每个人都在自己的全局目录里维护一套私有操作时间一长操作风格又会漂移成五花八门的形态。6. 常见问题与避坑手册6.1 最常踩的五个坑这半个月我在公司内部带了几个人装把高频问题整理成了一张表问题现象根因解决办法聊天框里输/看不到 Action 列表没有重启 VS Code 窗口CtrlShiftP执行 “Developer: Reload Window”触发了 Action 但没有任何反应当前文件不是项目文件变量注入失败确保打开的项目里至少有一个文件提示 “No actions found”全局和项目目录都没有 Action 文件先用命令面板创建一个再触发Action 生成的代码质量远远不如预期正文提示词没有指定输出格式在操作里写清楚“请直接输出代码”否则它会解释团队里有些人能用有些人不能用扩展版本不一致或未装 Chat 插件统一检查版本号对口安装 Copilot Chat第一行那个坑特别隐蔽。很多情况下装完扩展所有命令都能看到但聊天框里就是刷不出来不是没生效而是聊天面板的扩展缓存还停留在旧状态。强制重载窗口十有八九能解决。6.2 两个值得养成的习惯第一个习惯Action 文件要写 description 字段。这个字段看似只是说明文档实则非常重要——Copilot 在自动匹配操作时会读取它。你的描述越具体模型越能准确判断用户意图对应哪个操作。如果描述写得模糊二选一的时候很容易选错。第二个习惯不要把秘密写进 Action 里。因为这个目录会进 Git 仓库一旦里面写死了 API Key、数据库连接串、内网地址一次提交推到远端全公司乃至公开仓库的人都看到了。敏感信息请通过环境变量或 VS Code 的配置项注入由操作里的变量替换来引用而不是硬编码。6.3 如何排查一个“不听话”的 Action当操作执行结果跟预期差得很远时我的排查顺序是先重新读一遍正文提示词看是否存在歧义。比如你说“检查代码风格”模型可能理解为读一遍而不输出意见你要明确说“逐行检查并输出所有不符合规范的行”。再用最朴素的用户体验原则提示词越像给人类实习生布置任务模型的执行效果就越好。如果还是不对就在操作正中间加一句“在开始之前先用一句话复述你理解的任务”。这个小技巧能让你看见模型对操作的真实理解往往能瞬间暴露问题所在——不是它没读懂而是你压根没说清楚。我的使用心得写到这里让我说点实在的。Superpowers 不是一个“装了就立刻开挂”的工具它是那种需要花一小时整理操作、长期迭代才能真正发挥价值的东西。我现在的星标目录里核心操作已经沉淀了十来个覆盖了 commit、review、测试、架构分析、模块创建、疑难 bug 排查基本上把每天重复的 AI 对话全数收敛成了“按键调用”。我个人实际操作的体感是最爽的时候不是它帮我写了一大段代码而是当我输入一个斜杠命令看着 Copilot 自动执行 git diff、分析上下文、给出精确修改方案的时候——那种“这个工具真的长在这个项目里”的感觉是普通聊天式 AI 很难给的。建议你先从提交信息这个最小场景入手跑通第一个 Action 之后你自然会知道下一步该把什么流程固化成文件。别贪多一次一个操作持续沉淀很快你会发现AI 编程的下半场拼的早就不只是模型而是你怎么跟它配合。