最近我几乎把主力开发环境切回到了 VS Code 上，原因是一个叫 superpowers 的开源扩展。很多人可能和我一样，先在热搜上看到这个名字，第一反应是“这不又是一个 AI 编程助手”。直到我把它真正装进编辑器、连续用了两三周之后，才意识到它和我想象的那种“侧边栏聊天框”不是一回事。如果你最近正想安装 superpowers，却不确定装完该做什么，这篇就按我的实际经历来写，从安装到上手再到避坑，尽量帮你省掉前面几天的试错时间。
1. superpowers 到底是个什么东西：它不是又一个 Copilot，而是把 AI“嵌”进了开发环境
1.1 为什么它不叫 AI 助手，而叫“超能力”
先解释一下这个名字。项目名 superpowers 直译就是“超能力”，但它想表达的不是帮你写几行代码，而是让普通开发者的操作效率接近“开了挂”的程度。你可以把它理解为一套运行在编辑器内部的 AI 工作台：选中一段代码就能直接发指令，可以让 AI 解释、改错、重构、写测试，也可以一次性把好几个文件甚至整个目录丢给模型去研究。
它不是又一个悬浮在侧边栏的聊天框。用过 Cursor 或者各种聊天型插件的人应该都有这种体验：遇到问题先复制代码，粘贴进聊天框，等它给出一段回复，再手动把结果贴回编辑器。这个过程看起来很智能，实际上很伤手感和心流。superpowers 的思路是把 AI 操作做进编辑器原生的交互里：选中即是上下文，输入即是指令，模型输出直接以 diff 的形式呈现，你决定是否接受。这样一来，写代码的主线不会被频繁打断，更像是有个熟练的结对程序员坐在旁边。
1.2 它和 Copilot、Cursor 的核心区别
我从实际使用体验出发，用下面这个表格做个简单对比：
| 工具/方向 | 交互方式 | 典型使用场景 | 最大短板 |
|---|---|---|---|
| GitHub Copilot | 行内补全 | 写样板代码、续写函数 | 不适合做跨文件重构 |
| Cursor | 聊天+编辑 | 问答、改局部代码 | 对话上下文割裂感重 |
| superpowers | 选中即指令、上下文引用、代理式任务 | 跨文件改代码、解释老项目、批量重构 | 需要自己配置模型、上手有门槛 |
尤其要说一下跨文件这个点。我在老项目里经常遇到“这个 bug 的根源在另一个模块”的情况。以前用聊天型工具，我会手动把相关文件代码一段段贴进去，粘贴两三轮之后，上下文长度已经告急。superpowers 的引用机制可以直接指定文件或文件夹作为上下文，模型能同时看到好几个文件的代码，推理出来的结果才更有全局性。
1.3 一个绕不开的前提：它依赖 Continue 运行时
这是很多人安装之后懵住的地方。superpowers 在底层复用了 Continue 的运行时，也就是说它不是一个完全独立的应用，而是基于 Continue 生态构建的一层“增强能力”。它借用 Continue 的模型管理、提示词模板和上下文管理机制，自己专注在编辑器的深度集成上。
这个设计其实很聪明。模型管理、密钥配置、上下文拼装这些脏活，没必要每个项目都从头做一遍。superpowers 选择了站在已有轮子上，把精力放在别人没做好的部分——比如怎么让 AI 操作和编辑器交互更自然。结果就是：安装它之前，你需要有一个可用的模型服务；配置模型的方式和 Continue 是同一套体系。
2. 安装全过程：从扩展市场到跑通第一次对话
2.1 在 VS Code 里安装扩展
先说明一下，我全程用的是 VS Code，这也是这个工具最成熟的运行环境。安装步骤其实很简单：
- 打开 VS Code 的扩展面板，快捷键是
Ctrl+Shift+X（Windows/Linux）或Cmd+Shift+X（macOS）。 - 在搜索框输入
superpowers。 - 搜索结果里会出现一些同名或名字相近的扩展，需要留个心眼。我建议认准项目主页指向 GitHub 官方仓库的那个版本，避免装到不活跃的仿制品。拿不准的话，可以先访问项目的 GitHub 页面，那里会有指向扩展市场的官方链接。
- 点击 Install。
- 安装完成后，VS Code 一般会提示 Reload Window，直接重载一次。
重载之后，你会在侧边栏看到新增的图标，点击就能打开与 AI 对话的主面板。如果这里没看到任何变化，不要着急，大概率是运行时还没有完成初始化，先继续往下走配置。
2.2 准备一个可用的模型服务
这是我最想提醒新手的一件事：superpowers 本身不携带任何模型，它只是一个客户端，需要你去接一个能干活的大模型后端。常见的做法有两种。
第一种是使用云端模型服务。你需要准备好对应的 API Key，然后在配置文件里把模型信息填进去。以我自己的配置习惯为例，配置文件路径会跟随系统的 Continue 配置，一般在用户目录下的.continue文件夹里，文件名是config.json或config.yaml。一份最小化的配置大概长这样：
{ "models": [ { "title": "Main Model", "provider": "openai", "model": "gpt-4o", "apiKey": "YOUR_API_KEY" } ] }注意，不同版本的 Continue 和 superpowers 对字段名可能略有差异，但核心就是指定 provider、model 和 apiKey。如果你用的是其他家的模型服务，字段会相应变化，比如 Anthropic 的 claude 系列、本地兼容 OpenAI 接口的服务等，provider 和 model 名称跟着改就行。
第二种是使用本地模型。如果你想完全离线、或者担心代码被第三方接口记录，可以在机器上装 Ollama，拉一个适合写代码的模型下来。常见的开源代码模型有不少，7B 参数的版本日常使用已经比较流畅。配置本地模型时，provider 一般填ollama，model 填你本地拉取的名字，不需要 apiKey。
2.3 首次对话的验证方法
配置写好后，回到编辑器，在 superpowers 面板里随便输入一句测试指令，比如“请用一句话介绍你自己，并列出你能帮我做的事情”。
如果模型正常返回，说明整条链路已经通了。如果没有任何反应，我建议按下面这个顺序排查：
- 先确认模型服务配置是否正确，API Key 是否有效。这是最高频的问题。
- 再确认当前模型服务是否还有可用额度，有些云端服务会在额度耗尽时静默返回错误。
- 最后看一眼 VS Code 的输出日志，里面通常会有具体的报错信息，能帮你快速定位是哪一步断了。
我第一次安装时就卡在这个环节，以为扩展坏了，折腾半天才发现是配置文件里的模型名写错了。所以这一节多花五分钟，后面能省很多事。
3. 第一天就该掌握的三类核心操作
3.1 选中代码直接提问
这是 superpowers 最日常的操作，也是我和它磨合时第一个爱上的动作。做法很简单：在编辑器里选中一段代码，然后在面板里输入你的问题。
举个例子，我在接手一个旧的支付模块时，有一大段时序逻辑看不懂。以前的做法是打断思路去翻文档、查调用链，现在直接选中那段函数，输入“这段代码在什么场景下会被调用？里面的状态流转是怎样的？”模型会基于选中的代码上下文直接给出解释，而且是结合你这份代码的解释，不是泛泛的百科式说明。
这个小操作还有一个隐藏价值：它可以帮你保持心流。写完一段逻辑想确认有没有问题，不用切换到浏览器、打开聊天界面，在编辑器里原地就能完成一次“自检”。对于每天写大量代码的人来说，这种交互省下的时间相当可观。
3.2 用 @ 语法把文件甚至整个目录作为上下文
如果说选中代码是“局部能力”，那引用文件和目录就是“全局视野”。在输入框里使用@文件名就能把对应文件加入上下文。
我之前遇到过一个典型问题：某个接口的响应字段突然多了一组数据，导致前端渲染出错。这种问题光看接口定义文件是看不全的，还需要对照数据库模型、序列化逻辑和前端消费方。以前我要手动打开三个文件来回切换、复制关键片段；现在直接在输入框里写：
@src/controller/order.ts @src/model/Order.ts @src/services/serializer.ts 这个接口最近是不是改过字段？为什么前段渲染会拿到未定义的值？模型会同时看到这三个文件的内容，从字段变化的源头开始排查，给出的结论比单文件提问靠谱得多。注意哈，我在代码块里的换行只是为了展示清楚，实际输入时写在同一行也没问题。
3.3 让 AI 直接改代码，而不是只给建议
很多 AI 工具只负责“说”，改代码还是得自己动手。superpowers 的不同之处在于，它可以生成编辑建议，并直接在编辑器里以 diff 的形式呈现，你确认后才会应用。
我常用的一个场景是重构。前阵子有个工具函数越写越长，里面还夹着几段重复逻辑。我选中整个函数，输入“把这段逻辑拆成三个小函数，保持对外行为完全不变，并补上关键注释”。模型很快给出了一份重构方案，我打开改动预览，逐个函数检查确认，没问题就接受，有问题就退回修改。
这里分享一个重要经验：无论模型看起来多靠谱，一定要看 diff、要能读懂它改了什么。我的习惯是每次 AI 改动之后先看一眼总览，确认没有超出我限定的范围，再仔细检查具体改动点。AI 是辅助，最后一道审核的闸门必须在自己手里。
4. 真正拉开体验差距的配置细节
4.1 不同任务分配不同模型：别让“实习生”干“资深工程师”的活
刚开始用的时候，我只配了一个模型，什么任务都往上面堆。用了一段时间，我发现一些很轻量的操作——比如解释一个函数、给代码加注释——也把它当成大任务在做，响应慢、消耗多，纯属浪费。
后来我在配置里增加了第二个模型。思路很简单：快速、便宜的模型负责日常问答和解释；强模型负责复杂的重构、跨文件推理和架构级建议。这就像团队里分工：查资料、写周报这类活给实习生，方案设计和疑难故障才轮到资深工程师。
在配置里加上第二个模型之后，把不同操作的模型选择对应好，日常体验会明显上一个档次。轻量操作几乎秒回，重活也不会因为占用了同一个模型而被拖慢。
4.2 自定义系统提示词：把团队规范沉淀进编辑器
superpowers 支持在配置里加入自己的系统提示词（或者叫规则）。很多人忽略了这个功能，但我觉得这正是它和普通聊天工具拉开差距的地方。
比如我所在的团队要求所有代码变更必须附带一句变更原因注释，而且某些目录下的文件不允许 AI 擅自修改。这些规则如果只在代码评审时说，约束力很弱；如果写进配置里作为系统提示词的一部分，模型在生成回复时就会主动遵守。
我在配置里加过这么一条规则：如果请求涉及修改核心业务逻辑，必须先给出一段简要方案说明，再进入编码阶段，禁止直接输出大段不可控的改动。加了规则之后，AI 的输出格式明显更有条理，我 review 的负担也小了不少。
4.3 上下文管理：不是塞得越多越好
这个点很多人会忽略。既然 superpowers 支持引用文件和目录，新手最容易犯的毛病就是一次引用十几个文件，恨不得把整个项目都塞给模型。
上下文越大，模型的注意力就越分散，响应越慢，token 成本也越高。更麻烦的是，上下文里的无关信息太多时，模型反而可能“找不着重点”，给出一些模棱两可的回答。
我的做法是：先明确这个问题到底需要哪几个文件，尽量只引用必要的。如果一个问题确实要覆盖整个模块，我会先让模型快速扫一遍目录结构，再挑选关键文件深入讨论。这种由粗到细的提问策略，比一次性砸一堆文件进去更高效。
5. 用了一个月后我踩过的坑和绕坑方案
5.1 装完之后面板一直转圈
这是我遇到的第一个坑。装完扩展、填好配置，面板却一直显示加载中，转圈转得人心烦。
排查之后发现，问题出在第一次加载 Continue 运行时上。它需要拉取一些依赖并初始化，这个过程在部分机器上会比较慢。解决方案很简单：多等一会儿，或者重新加载窗口。如果依旧不行，就打开 VS Code 的输出面板看日志。日志里通常会写明白是运行时初始化失败，还是模型服务连接不上。
5.2 配置和原来的 Continue 串在一起
因为 superpowers 复用 Continue 的配置体系，如果机器上原本就装过 Continue，会出现配置互相覆盖或模型列表异常的情况。
我就遇到过：原来 Continue 里精心配置的几个本地模型，安装 superpowers 之后莫名消失了。原因是两者共用同一个配置文件目录，在写入时发生了覆盖。
解决方法是：改配置前先备份原始的配置文件。如果你两个工具都要用，可以考虑在配置里把模型列表合并到一起，避免互相覆盖。如果不想牵扯太多，也可以单独用一个干净的配置文件专门给 superpowers 用，互不干扰。
5.3 让它“优化一下”，结果它改了一堆代码
这是我踩过最痛的坑。有一次我让 AI 优化一个循环里的性能问题，它确实解决了问题，但同时也把我精心调整过的代码格式全部重排了一遍，还顺手改了几个变量名。虽然功能没坏，但 diff 变得巨大，review 成本陡增。
从那以后，我的每条修改指令都会写清边界，比如：“只修改 selected 函数内部的性能瓶颈，不要改变函数签名，不要调整代码格式，不要修改其他函数”。其实也可以直接在系统提示词里加一条通用规则：“没有明确要求时，保持原代码风格和格式。”加了这条之后，改动范围控制得明显好了很多。
5.4 本地模型上下文溢出
用本地小模型跑大任务时，上下文溢出的概率很高。表现就是模型回复到一半突然截断，或者直接报错说上下文长度超限。这不是 superpowers 的问题，而是模型本身的限制。
我的解决思路是：把大任务拆成小任务。比如“先解释这个文件里模块的整体作用”，然后再“基于前面的总结，重点看函数 B 的实现”，而不是指望一次性把八个文件的内容全部塞进一个上下文窗口。控制 @ 引用数量也是关键，能一句话描述清楚的文件，就不需要把整个文件读进去。
6. 一些值得后来者注意的个人经验
6.1 从小项目开始，而不是直接接手大项目
如果你之前没有深度使用过这类 AI 工作台，我强烈建议先拿一个中小型项目练手，而不是一上来就让 AI 帮你梳理一个几十万行的老系统。原因很简单：工具的运作逻辑、提示词的习惯表达、上下文引用的分寸，都是需要磨合的。在一个小项目里试错，成本低、反馈快，你很快就能找到适合自己的人机协作节奏。
等到用顺手了，再把它带到真实的生产项目里，那时候你对它的边界已经有数了：什么任务可以放心交给它，什么任务必须自己把关。
6.2 把常用指令沉淀成自己的模板
用了一周之后，我有一个体会：很多请求其实可以复用。比如“为某函数补单元测试”“解释这段代码的核心业务逻辑”“检查这个文件里的潜在越界问题”，每一次都从头写指令太浪费了。
我自己的做法是建一个prompts.md文件，把常用需求固化成模板，用的时候稍作替换即可。这样不仅保证了指令质量稳定，也让团队协作时有据可依。如果团队里有人也用 superpowers，这些模板可以直接共享，相当于大家一起把“怎么和 AI 描述需求”的经验沉淀了下来。
6.3 每个 AI 操作都放在分支上进行
最后这一点是我个人的血泪教训。AI 生成的改动再可控，也可能出现意料之外的副作用。所以我的习惯是：凡是让 AI 做较大范围的重构或者跨文件修改，先在 Git 里开一个新的分支，再让改动发生在分支上。确认没问题再合并，有意外直接丢弃分支，成本几乎为零。
尤其在生产项目里，这种“先隔离、再试错”的习惯能帮你省掉大量还原现场的时间。现在 AI 编程工具越来越多，真正拉开体验差距的，不是哪个模型更聪明，而是你怎么用工具、怎么为自己的工作流设置安全护栏。
就我目前的工作流来说，superpowers 已经不是一个偶尔打开的实验性工具，而是每天写代码时都会使用的常规基础设施。安装它只是开始，花几天时间摸清楚它的交互方式、配置细节和边界，你获得的回报会远超安装时那五分钟的投入。
