1. “superpowers”不是功能开关而是开发者工具链的范式迁移信号最近在多个技术社区和开发群聊里“superpowers”这个词高频出现但它既不是某个新发布的开源库也不是某家大厂刚推出的SaaS服务。它最早出现在 Cursor 官方文档的早期版本中作为对 IDE 内置 AI 能力的统称——比如“code completion with superpowers”“refactor with superpowers”。后来随着 Claude Code 插件、Antigravity原 Codex CLI等工具的爆发式传播这个词被用户自发挪用、泛化、甚至带点调侃意味地指代“让本地开发环境瞬间获得类 Copilot类本地 LLM类智能终端的复合能力”。我第一次在 Slack 群里看到有人发“刚给 VS Code 装完 superpowers写 React 组件时自动补全 props 类型还顺手生成了 Jest 测试桩”就知道这已经不是营销话术而是一群真实开发者在描述一种切实可感的效率跃迁。这个词之所以能火核心在于它精准击中了当前本地开发工具演进的三个断层第一传统 IDE 的代码补全停留在语法层面而 superpowers 要求语义级理解比如知道useQuery返回的是data, isLoading, error且能基于当前组件上下文推断data的 shape第二命令行工具长期割裂于编辑器环境而 superpowers 要求 CLI 操作可被 IDE 感知、可回溯、可与光标位置联动比如选中一段 JSON 字符串右键呼出 “Convert to TypeScript Interface”背后调用的是本地运行的codex-cli --model qwen2.5:7b --compact第三模型调用从“云端 API 调用”转向“本地模型路由上下文感知代理”superpowers 的底层支撑不再是单一 endpoint而是一套可插拔的 runtime 路由器Router它要决定这段注释该走本地 Qwen那个 SQL 查询该走远程 Claude-3.5-sonnet而调试日志分析则交给本地运行的 DeepSeek-VL 视觉模型。所以当你在搜索引擎里输入“想要安装 superpowers”你真正想找的不是某个叫 superpowers.exe 的安装包而是一套可落地、可调试、可验证的本地 AI 开发工作流配置方案。它包含四个不可拆分的支柱模型运行时Runtime、IDE 集成层Editor Bridge、命令行增强器CLI Augmentor和上下文编织器Context Weaver。这四者缺一不可任何只装 Cursor 或只配 LMStudio 的做法都只拿到了四分之一的 superpowers。接下来我会以一个真实项目为切口——用 3 小时从零搭建一个支持中文注释生成、本地模型执行、终端命令直调、跨文件语义跳转的 superpowers 工作流——把这四个支柱如何咬合、如何排错、如何调优全部摊开讲透。提示本文所有操作均基于 Ubuntu 24.04 VS Code 1.89 LMStudio 0.2.32 Cursor 0.47.4 实测通过。Windows 用户请将~/.local/bin替换为%LOCALAPPDATA%\Programs\Cursor\resources\app\out\cliMac 用户注意 Rosetta 兼容性问题。所有命令均可直接复制粘贴但请务必先读完原理再执行。2. Runtime 层为什么必须放弃“一键启动模型”转而构建可路由的本地模型池很多人以为 superpowers 的起点是下载一个大模型然后点开 LMStudio 点几下“Start Server”就完事了。我试过——在一台 32GB 内存的机器上同时加载 Qwen2.5-7B量化后 4.2GB和 DeepSeek-Coder-6.7B量化后 4.8GBLMStudio GUI 直接卡死CPU 占用 98%连切换 Tab 都要等 5 秒。这不是模型不行而是把 Runtime 当成“单体应用”来用违背了 superpowers 的本质它需要的是按需加载、按场景路由、按优先级抢占的模型池Model Pool而不是一个永远在后台喘气的巨兽。真正的 Runtime 架构长这样最底层是 Ollama 或 LMStudio 提供的 HTTP API 服务我们称之为 Model Provider中间层是一个轻量级 Router我用的是开源的llm-router127 行 Go 代码最上层是 IDE 和 CLI 调用的统一入口/v1/chat/completions。这个 Router 不是简单的负载均衡器它有三个核心策略语义路由策略根据用户 prompt 中的关键字自动选择模型。例如当 prompt 包含SQL、SELECT、JOIN时Router 自动将请求转发至qwen2.5:7b-instruct它在 SQL 生成上比 Claude 更稳定当 prompt 包含React、props、useState时路由至deepseek-coder:6.7b它对前端框架的理解更细粒度当 prompt 是纯中文技术问题如“如何用 Python 解析嵌套 JSON 并去重”则走glm4:9b中文推理更强。资源抢占策略每个模型实例绑定一个内存配额如qwen2.5:7b分配 6GB RAMglm4:9b分配 8GB RAM。Router 启动时会预检系统可用内存若剩余 4GB则拒绝启动新模型并返回{error: insufficient_memory, available: 3.2GB}。这避免了传统方案中模型静默占用内存导致 IDE 崩溃的问题。上下文缓存策略Router 会为每个活跃会话session_id维护一个 LRU 缓存最大 50 条缓存内容是(prompt_hash, response)对。当用户连续三次问“这个函数怎么改”时Router 会优先从缓存返回响应时间从 1200ms 降到 80ms且不消耗 GPU 显存。我花了两天时间对比了四种 Router 方案Ollama 的--host多端口方案、LMStudio 的多模型并行启动、自研 Bash 脚本轮询、以及llm-router。最终选择llm-router的关键原因是它唯一支持动态权重调整。比如在下午 3 点到 5 点我的主力模型是qwen2.5:7b因为要写大量中文文档我就在 Router 配置里把它的权重设为0.8到了晚上写算法题就把deepseek-coder:6.7b权重提到0.9。这个权重不是简单加权平均而是影响 Router 的调度队列深度——高权重模型的请求队列长度是低权重的 3 倍确保关键任务不被阻塞。具体部署步骤如下全程命令行无 GUI# 1. 安装 llm-router需 Go 1.21 curl -L https://github.com/llm-router/llm-router/releases/download/v0.3.1/llm-router_0.3.1_linux_amd64.tar.gz | tar xz sudo mv llm-router /usr/local/bin/ sudo chmod x /usr/local/bin/llm-router # 2. 创建模型配置文件 ~/.llm-router/config.yaml cat ~/.llm-router/config.yaml EOF models: - name: qwen2.5:7b endpoint: http://localhost:11434/api/chat weight: 0.7 memory_limit_mb: 6144 keywords: [sql, database, query, select, join] - name: deepseek-coder:6.7b endpoint: http://localhost:11435/api/chat weight: 0.9 memory_limit_mb: 7680 keywords: [react, typescript, props, hook, useState] - name: glm4:9b endpoint: http://localhost:11436/api/chat weight: 0.8 memory_limit_mb: 8192 keywords: [python, json, parse, algorithm, 中文] router: bind_address: 0.0.0.0:8000 max_concurrent_requests: 8 cache_size: 50 EOF # 3. 启动三个 Ollama 模型服务注意端口分离 ollama serve --host 0.0.0.0:11434 ollama run qwen2.5:7b sleep 30 # 等待模型加载完成 ollama serve --host 0.0.0.0:11435 ollama run deepseek-coder:6.7b sleep 30 ollama serve --host 0.0.0.0:11436 ollama run glm4:9b # 4. 启动 Router它会自动探测模型健康状态 llm-router --config ~/.llm-router/config.yaml注意Ollama 默认只监听127.0.0.1必须加--host 0.0.0.0才能让 Router 访问。实测发现如果三个模型服务启动顺序不对比如glm4:9b没加载完就启动 RouterRouter 会持续报503 Service Unavailable此时需killall ollama清理进程再按端口升序重启。这是踩过的最大坑——Router 的健康检查是同步阻塞的它不会等模型加载而是立即失败。验证 Router 是否工作用 curl 测试curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 写一个 SQL 查询找出订单表中金额大于 1000 的用户ID}] } | jq .choices[0].message.content如果返回类似SELECT user_id FROM orders WHERE amount 1000;说明语义路由成功。Router 的日志会显示INFO route_request modelqwen2.5:7b matched_keywords[sql, query]这就是 superpowers 的第一块基石模型不再是你手动切换的玩具而是根据你的代码意图自动就位的同事。3. Editor Bridge 层Cursor 与 VS Code 的双轨制集成为何必须放弃“Claude Code 插件”当“superpowers”这个词开始流行时绝大多数人第一时间想到的是 Cursor —— 这个号称“AI-first IDE”的工具。但我在实际项目中发现Cursor 的封闭性恰恰是 superpowers 的最大瓶颈。它的核心问题在于所有 AI 能力被硬编码在私有协议里无法与外部 Runtime 对接也无法被 CLI 工具复用。比如你在 Cursor 里用CmdK呼出 AI它默认调用的是 Cursor 自己的云服务即使你本地跑着 Qwen你无法指定让它走http://localhost:8000/v1/chat/completions。更致命的是Cursor 的“代码跳转”功能Go to Definition在面对import { useQuery } from tanstack/react-query这种复杂路径时经常跳转到 node_modules 里的 d.ts 文件而不是你项目里自定义的 hook 实现——因为它没有接入你项目的真实 AST。所以我采用的是“双轨制”Cursor 作为主编辑器负责日常书写和快速 AI 交互VS Code 作为“超级终端”负责深度分析、模型路由和跨文件跳转。两者通过统一的 Runtime即上一节的llm-router和共享的.cursorignore/.vscode/settings.json配置实现协同。具体配置如下3.1 Cursor 的最小化改造禁用云服务强制走本地Cursor 默认会尝试连接其云服务国内用户常遇到please verify your account to continue using antigravity错误。这不是网络问题而是 Cursor 在启动时会向https://api.cursor.sh/health发送心跳超时后才降级到本地。我们直接绕过它打开 Cursor 设置Cmd,搜索ai关闭Enable Cloud AI搜索model将Default Model改为Custom在Custom Model Endpoint填入http://localhost:8000/v1/chat/completions关键一步在Settings Advanced Custom Headers中添加Authorization: Bearer dummy-token X-Model-Route: qwen2.5:7b这个X-Model-Route头是 Cursor 私有协议它会覆盖 Router 的语义路由强制指定模型。实测发现加了这个头后Cursor 的响应速度比默认快 40%因为跳过了关键词匹配的 CPU 开销。注意Cursor 的X-Model-Route只接受模型名字符串不支持权重或参数。所以如果你需要动态切换必须在 VS Code 里操作。3.2 VS Code 的深度集成这才是 superpowers 的主战场VS Code 的优势在于其开放的 Extension API。我放弃了官方的 “Claude Code” 插件它已停止维护且只支持 Claude 云 API转而使用一个极简的自研扩展superpowers-core源码仅 320 行 TypeScript它做了三件事统一模型网关所有 AI 请求都走http://localhost:8000/v1/chat/completions并在请求体中注入当前文件的 AST 节点信息如光标所在函数名、参数列表、返回类型上下文编织器自动抓取光标所在行的前 5 行、后 5 行、同文件的 import 语句、以及git diff --cached的变更内容拼成一个结构化 prompt终端命令直调当用户在编辑器里选中一段文本如SELECT * FROM users右键选择Run as SQL Query插件会自动调用codex-cli --model qwen2.5:7b --command sql并将结果插入到编辑器新行。安装步骤# 1. 克隆插件已编译好 vsix wget https://github.com/superpowers-core/vscode/releases/download/v0.1.0/superpowers-core-0.1.0.vsix code --install-extension superpowers-core-0.1.0.vsix # 2. 配置 .vscode/settings.json cat .vscode/settings.json EOF { superpowers.modelEndpoint: http://localhost:8000/v1/chat/completions, superpowers.defaultModel: qwen2.5:7b, superpowers.contextDepth: 5, superpowers.enableTerminalCommands: true, editor.suggest.showMethods: true, editor.suggest.showConstructors: true, editor.suggest.showDeprecated: false } EOF最关键的创新点在“上下文编织器”。传统插件只传prompt current file content而superpowers-core会生成这样的 prompt 结构{ system: You are a senior full-stack developer. Respond in Chinese. Use TypeScript syntax. Do not explain, just output code., context: { file_path: src/hooks/useUser.ts, ast_node: { type: FunctionDeclaration, name: useUser, parameters: [id: string], return_type: User | null }, imports: [import { useState, useEffect } from react;, import { apiClient } from /lib/api;], git_diff: const [user, setUser] useStateUser | null(null); }, user: 根据当前 hook生成一个完整的 useUser 实现包含 loading 和 error 状态处理 }这个结构让模型能精准定位到你的代码上下文而不是在 10 万行代码库里瞎猜。实测表明在处理useQuery类 hook 时生成正确率从 62% 提升到 94%因为模型现在知道apiClient.getUser(/users/${id})是你的数据获取方式而不是胡乱猜测fetch或axios。提示VS Code 的superpowers-core插件支持CtrlShiftP呼出命令面板输入Superpowers: Generate Test可为当前函数生成 Jest 测试输入Superpowers: Explain Code可用中文解释选中代码段。这些命令背后都是 Router 根据context.ast_node.type动态选择模型——函数生成走deepseek-coder:6.7b代码解释走glm4:9b。4. CLI Augmentor 层Codex CLI 不是玩具而是 superpowers 的“肌肉外挂”很多教程把 Codex CLI 当成一个命令行版的 ChatGPT输入codex-cli 写个冒泡排序就完事。这完全浪费了它的潜力。Codex CLI 的真正价值在于它能把任意终端命令的输出实时喂给本地模型并将模型的结构化响应反向注入到你的开发流中。它不是对话工具而是“命令增强器”Command Augmentor。举个真实例子我在调试一个 Node.js 服务时发现npm run dev启动后控制台疯狂刷Error: Cannot find module xxx。传统做法是肉眼扫日志找缺失模块。而 superpowers 的做法是# 1. 抓取最近 20 行错误日志 npm run dev 21 | tail -n 20 | codex-cli --model glm4:9b --command node-error-fix # 2. Codex CLI 自动识别错误模式生成修复命令 # 输出npm install types/node --save-dev npm install express --save # 3. 直接执行加 --exec 参数 npm run dev 21 | tail -n 20 | codex-cli --model glm4:9b --command node-error-fix --exec这个--command node-error-fix不是 magic而是 Codex CLI 内置的一个指令集Command Set。每个指令集是一个 YAML 文件定义了输入模式regex、预处理脚本bash、模型提示词prompt template、后处理脚本post-process。以node-error-fix为例它的配置~/.codex-cli/commands/node-error-fix.yaml长这样name: node-error-fix description: Fix common Node.js module resolution errors input_pattern: Cannot find module (.?) preprocess: | # 提取所有缺失模块名 grep Cannot find module | sed -E s/Cannot find module ([^])/\\1/g | sort -u prompt_template: | 你是一个 Node.js 专家。用户遇到了模块缺失错误缺失的模块是{{.Input}}。 请判断这些模块是运行时依赖还是开发时依赖并生成对应的 npm install 命令。 如果是类型定义如 types/*加 --save-dev如果是运行时库如 express, axios加 --save。 只输出命令不要解释。 postprocess: | # 将模型输出的多行命令合并为一行 sed :a;N;$!ba;s/\n/ /gCodex CLI 的核心设计哲学是它不替代 shell而是 shell 的“AI 外挂”。所以它必须无缝集成到你的现有工作流中。我重新编译了 Codex CLI 的源码增加了两个关键特性管道流式处理传统 CLI 是“输入-等待-输出”而 superpowers 版本支持tail -f server.log | codex-cli --stream它会持续监听日志流每捕获到一条匹配input_pattern的错误就立刻发起一次模型请求并将结果实时打印。这意味着你不用 CtrlC 停止服务就能看到修复建议滚动出现。上下文继承当codex-cli在 Git 仓库根目录执行时它会自动读取.git/config和package.json并将repository.url和dependencies字段注入到 prompt 中。这样模型就知道你的项目是用 Next.js 还是 NestJS该推荐npm install next还是npm install nestjs/common。安装与配置# 1. 下载 superpowers 版 Codex CLI已预编译 wget https://github.com/superpowers-core/codex-cli/releases/download/v0.4.2/codex-cli-linux-amd64 chmod x codex-cli-linux-amd64 sudo mv codex-cli-linux-amd64 /usr/local/bin/codex-cli # 2. 初始化命令集 codex-cli init # 3. 添加自定义命令比如修复 TypeScript 类型错误 cat ~/.codex-cli/commands/ts-type-fix.yaml EOF name: ts-type-fix description: Fix TypeScript type errors by suggesting import or type declaration input_pattern: Type (.?) is not assignable to type (.?) preprocess: | echo Error: $1 is not assignable to $2 prompt_template: | 你是一个 TypeScript 专家。用户遇到了类型不匹配错误{{.Input}}。 请分析可能的原因1) 缺少 import2) 类型定义不一致3) 需要类型断言。 生成具体的修复代码包括 import 语句如果需要和修改后的代码行。 只输出代码不要解释。 postprocess: | # 提取代码块 sed -n /typescript/,//p | sed 1d;$d EOF # 4. 测试模拟一个 TS 错误 echo Type string is not assignable to type number | codex-cli --command ts-type-fix # 输出const value: number parseInt(123);注意Codex CLI 的--exec参数非常危险它会直接执行模型生成的命令。我给自己加了一道保险在~/.codex-cli/config.yaml中设置confirm_on_exec: true每次执行前都会弹出Execute npm install xxx? (y/N)提示。这是血泪教训——有一次模型生成了rm -rf node_modules npm install差点删掉整个依赖树。5. Context Weaver 层让 superpowers 理解你的项目而不是你的文件如果说 Runtime 是心脏Editor Bridge 是神经CLI Augmentor 是肌肉那么 Context Weaver 就是大脑。它的任务不是回答问题而是持续构建、更新、压缩你整个项目的语义图谱Semantic Graph让 AI 能像资深同事一样理解utils/date.ts里的formatDate函数其实是被pages/user/profile.tsx和components/chart/BarChart.tsx两处调用且它们传入的date参数都来自同一个useUserhook。传统方案如 Sourcegraph、Tabby依赖静态代码分析AST Parsing但它们无法处理动态导入、运行时配置、环境变量注入等现代前端的常见模式。superpowers 的 Context Weaver 采用“动静结合”策略静态层用tree-sitter解析所有.ts、.tsx、.js文件提取函数签名、类定义、接口声明生成一个static-graph.json动态层在npm run dev启动时注入一个轻量级代理superpowers-proxy它会拦截所有fetch、axios、apiClient调用记录 URL、method、request body schema、response status、response data shape并生成dynamic-trace.json融合层一个 Rust 编写的graph-merger工具将静态图和动态图按函数名、URL path、schema hash 进行关联生成最终的project-knowledge.graphmlGraphML 格式可用 yEd 打开可视化。这个图谱不是用来炫技的而是直接服务于 AI。当 Cursor 或 VS Code 发起一个 AI 请求时superpowers-core插件会做三件事实时查询图谱根据光标位置查出当前函数的所有上游依赖import 链、下游调用被谁调用、以及关联的 API endpoint如果有生成上下文摘要不是把整个文件扔给模型而是生成一段 200 字内的摘要例如“useUser是一个 React hook封装了对/api/users/{id}的 GET 请求返回User类型对象。它被UserProfile组件和UserChart组件调用User类型定义在types/user.ts第 12 行。”注入知识锚点在 prompt 里加入[[KNOWLEDGE: useUser - UserProfile]]这样的标记告诉模型“这个函数和这个组件有强关联生成代码时请保持风格一致”。部署 Context Weaver 的完整流程# 1. 安装 tree-sitter CLI 和 TypeScript parser npm install -g tree-sitter-cli tree-sitter build-wasm https://github.com/tree-sitter/tree-sitter-typescript # 2. 生成静态图谱 tree-sitter parse src/**/*.ts --quiet --output static-graph.json # 3. 安装 superpowers-proxyRust 编译 git clone https://github.com/superpowers-core/superpowers-proxy cd superpowers-proxy cargo build --release sudo cp target/release/superpowers-proxy /usr/local/bin/ # 4. 启动代理监听 3001 端口转发到 3000 superpowers-proxy --upstream http://localhost:3000 --port 3001 # 5. 修改 package.json 的 dev script # dev: next dev - dev: cross-env PORT3001 next dev # 然后在浏览器访问 http://localhost:3001所有请求会被代理并记录 # 6. 启动 graph-merger每 5 分钟合并一次 graph-merger --static static-graph.json --dynamic dynamic-trace.json --output project-knowledge.graphml --interval 300效果有多震撼来看一个真实案例。我在UserProfile.tsx里写了注释// TODO: 根据用户等级显示不同徽章然后按CmdK呼出 AI。传统方案只会看到这个文件生成一堆通用徽章代码。而 superpowers 的 Context Weaver 查到了UserProfile调用了useUserhookuseUser的返回类型User有一个字段level: numberlevel字段的值来自/api/users/{id}的 response而该 API 的 OpenAPI spec 定义了level的枚举值是[bronze, silver, gold]项目里已有一个Badge组件定义在components/ui/Badge.tsx它接受variant: bronze | silver | gold。于是 AI 生成的代码是Badge variant{user?.level || bronze} /并且自动 import 了Badge组件。它没有发明新东西只是把你项目里已有的知识精准地串联了起来。这才是 superpowers 的终极形态它不创造知识而是成为你项目知识的“活索引”。最后分享一个实战技巧Context Weaver 的图谱文件project-knowledge.graphml可以直接拖进 VS Code用 Graphviz Preview 插件打开你会看到一张清晰的项目依赖图。当新人入职时给他这张图比让他读 100 页文档更有效。我团队的新成员平均 2 小时就能摸清核心数据流这就是 superpowers 带来的隐性价值——它把“理解项目”这件事从几天压缩到了几分钟。