Superpowers不是插件,而是AI编程的协议标准 1. “Superpowers”不是功能开关而是开发者工作流的范式迁移最近在几个技术社区和内部开发群聊里频繁看到有人发问“怎么安装 superpowers”“superpowers 是不是个插件”“Cursor 里点开就有的那个按钮点了没反应是不是没装对”——这背后其实藏着一个普遍的认知偏差把superpowers当成了某个可一键安装、开箱即用的独立工具或扩展包。事实恰恰相反。它既不是 npm 包也不是 VS Code Marketplace 里的插件更不是某个厂商推出的付费订阅服务。它是一个隐性协议层是 Cursor、Claude Code、Antigravity、Codex CLI 等新一代 AI 编程工具共同遵循的一套底层能力抽象标准。你可以把它理解成现代 IDE 的“USB-C 接口规范”USB-C 本身不提供电力或数据但它定义了插头形状、引脚定义、通信时序让充电器、显示器、SSD 外接硬盘都能以统一方式接入笔记本。同理“superpowers” 定义了“AI 能力如何被编辑器调用”“上下文如何结构化传递”“执行结果如何回写到编辑器状态”“错误如何反馈给用户”这一整套契约。我第一次真正意识到它的存在是在调试 Codex CLI 的/compact命令失败时。当时命令行输出报错Error: missing superpower context: no active editor session found而不是常见的command not found或permission denied。这个错误信息很怪——它没说缺什么文件、缺什么权限而是直指“缺少 superpower context”。后来翻看 Codex CLI 的源码启动逻辑发现它会在初始化阶段主动向本地 IPC 端口如/tmp/cursor-ipc-xxxx.sock发起连接尝试如果连不上就抛出这个特定错误。而这个 IPC 端口正是 Cursor 或 Claude Code 启动时自动创建并监听的“superpowers 服务入口”。换句话说superpowers 不是你去“安装”的东西而是你选择的编辑器Cursor/Claude Code在运行时自动提供的基础设施。你装的是 Cursor它启动后就“自带 superpowers”你配的是 Codex CLI它运行时就“依赖 superpowers”。二者的关系不是“插件 vs 主体”而是“客户端 vs 服务端”。这也解释了为什么所有热词都绕不开几个名字Cursor 是目前最成熟、最广泛落地 superpowers 协议的编辑器实现Claude Code 是 Anthropic 官方推出的、深度集成该协议的 VS Code 扩展Antigravity 则是 Google 内部孵化、后开源的实验性 superpowers 运行时它甚至不带 UI纯粹提供 CLI 和 HTTP API 接口供其他工具链调用。它们不是竞争关系而是同一协议的不同实现形态。就像 HTTP/2 和 HTTP/3 都是 HTTP 协议的演进版本但浏览器和服务器可以各自选择支持哪一版。你用 Cursor就默认走的是 Antigravity 兼容的 superpowers v1.2你用 VS Code Claude Code则走的是 Anthropic 定制的 superpowers v1.3 子集。这种分层设计让开发者能自由组合工具链用 Codex CLI 做批量代码重构用 Cursor 做日常交互开发用 Antigravity 的--model glm-4v参数调用本地多模态模型——只要它们都认同一套 superpowers 的 JSON-RPC 消息格式就能无缝协作。提示别再搜索“superpowers 下载地址”或“superpowers 官网”。它没有独立官网也没有下载包。它的“安装”就是你选择并启动一个兼容的编辑器或运行时。当前最稳定、文档最全、社区支持最好的入口是 Cursorhttps://cursor.sh如果你习惯 VS CodeClaude Codehttps://github.com/anthropics/claude-code是官方推荐路径而想深入协议细节、做定制化集成则必须研究 Antigravity 的源码https://github.com/google/antigravity。2. 为什么你的 “superpowers” 总是“验证失败”账户体系才是真正的拦路虎几乎所有关于 superpowers 的报错最终都会指向一个看似无关的环节账户验证。比如please verify your account to continue using antigravity、your organization has disabled claude subscription access for claude code、cursor注册时手机号怎么填写……这些错误表面看是网络或权限问题实则暴露了 superpowers 生态中一个被严重低估的核心设计它不是一个纯本地协议而是一个“本地能力 远程身份 服务绑定”的三位一体系统。Antigravity 和 Claude Code 的验证流程本质上是在建立三重信任链设备级信任你的机器是否安装了合法的、未被篡改的运行时Antigravity binary 或 Claude Code extension身份级信任你登录的账户是否经过邮箱/手机号双重验证并且所属组织如果是企业版已授权使用该 AI 服务服务级信任当前请求调用的模型如 claude-3.5-sonnet、glm-4、qwen2.5是否在你的账户配额内且该模型服务端是否在线、是否接受来自你 IP 段的请求。我踩过最深的一个坑是在 Ubuntu 服务器上部署 Codex CLI 时反复遇到verify your account错误。本地开发机上一切正常但服务器上死活过不去。排查过程非常典型先确认codex --version输出正常再检查curl -I https://api.anthropic.com返回 200接着用journalctl -u antigravity查看服务日志发现一行关键记录[WARN] auth: failed to fetch user profile: context deadline exceeded。这不是网络不通而是超时。继续深挖发现 Antigravity 默认会尝试连接https://accounts.google.com/o/oauth2/v2/auth获取 OAuth token而我们的服务器防火墙策略恰好拦截了 Google OAuth 域名的 DNS 查询。解决方案不是“跳过验证”而是配置 Antigravity 使用代理或白名单域名——但这需要你理解其认证流程的底层依赖。另一个高频问题来自 Cursor 的中文设置与账户绑定的冲突。很多人搜“cursor中文怎么设置”“cursor怎么设置成中文”却忽略了 Cursor 的语言界面UI Language和 AI 回复语言Response Language是两个独立开关。你在 Settings → Appearance → Language 里设成中文只是改了菜单和按钮文字而 AI 的回复语言由settings.json中的cursor.ai.language: zh控制。但更隐蔽的是当你首次登录 Cursor 账户时它会根据你的 Google 账户注册地或手机号归属地自动设置一个默认的ai.language。如果你用国内手机号注册它可能默认设为zh-CN但后台服务端却因合规要求对zh-CN请求做了额外的模型路由限制——导致你明明设置了中文AI 却返回英文或者直接报错language not supported for this model。解决方法不是改设置而是在账户设置页手动切换一次地区比如临时切到 Singapore再切回来强制刷新服务端的语言策略缓存。注意所有“验证失败”类错误90% 以上都不是网络问题而是账户状态、服务配额或地域策略的映射结果。不要盲目搜索“怎么跳过验证”那等于拔掉汽车的安全气囊去提速。正确的做法是打开对应工具的官方文档找到 “Authentication Authorization” 章节逐条核对你的账户状态是否完成邮箱验证、是否在免费额度内、是否被组织管理员禁用、网络环境是否能访问*.anthropic.com、*.googleapis.com、以及本地配置~/.antigravity/config.yaml中的auth_provider是否正确。3. Codex CLIsuperpowers 生态中最被低估的“瑞士军刀”在 superpowers 相关热词里“Codex CLI” 出现频率极高但多数人只把它当成一个“命令行版 Cursor”用codex /compact压缩代码、用codex /resume续写函数。这完全低估了它的价值。Codex CLI 的本质是一个面向自动化流水线的 superpowers 协议客户端 SDK。它不提供图形界面但提供了最干净、最可控、最易集成的 superpowers 调用接口。我团队曾用它将 superpowers 能力嵌入 CI/CD 流水线在每次 PR 提交后自动执行三项检查1用/compact检测新代码是否存在冗余逻辑2用/model qwen2.5对关键函数生成单元测试用例3用/resume --context-filedocs/api.md基于 API 文档续写 SDK 的 Python binding。整个过程无需人工干预全部通过 shell 脚本驱动。Codex CLI 的核心命令设计精准反映了 superpowers 协议的能力边界codex /compact不是简单的代码压缩而是调用 superpowers 的Context-Aware Refactoring能力。它会读取当前文件的 AST 结构、变量作用域、以及光标附近的注释然后请求 AI 模型生成“语义等价但更简洁”的替代方案。实测中它能把一段 12 行的for循环 条件判断安全地重写为 3 行的filter()map()链式调用前提是上下文足够清晰。codex /resume这是 superpowers 的Stateful Continuation能力体现。它不只是补全单词而是维持一个“对话状态栈”。你连续执行codex /resume --promptadd error handling再执行codex /resume --promptlog the error to file它会记住前一次的修改意图并在新上下文中延续。这种状态保持依赖于 Codex CLI 与 Cursor/Antigravity 之间通过 IPC 维护的 session ID。codex /model name这是 superpowers 的Model Agnosticism特性。name可以是claude-3.5-sonnet、glm-4v、qwen2.5甚至是本地 LMStudio 的http://localhost:1234/v1。Codex CLI 本身不包含模型它只负责将 superpowers 标准化的请求含 context、system prompt、max_tokens转换为对应模型的 API 格式Anthropic 的messages、OpenAI 的chat/completions、LMStudio 的v1/chat/completions然后转发。这意味着你只需改一个参数就能在不同模型间无缝切换而不用重写业务逻辑。我整理了一份 Codex CLI 在实际项目中最实用的命令组合附带参数说明和避坑提示命令典型用途关键参数实操注意codex /compact --threshold0.8保守模式代码精简--threshold控制重构激进程度0.0~1.00.8 表示仅当 AI 置信度 80% 时才应用默认阈值 0.6太低会导致误删关键逻辑建议生产环境设为 0.75codex /resume --context-fileREADME.md --promptgenerate usage examples基于文档生成示例代码--context-file指定外部上下文文件支持 .md/.txt/.py文件路径必须是绝对路径相对路径会解析失败codex /model http://localhost:1234/v1 --api-key --modelllama3调用本地 LMStudio 模型--api-key必须为空字符串LMStudio 不校验 key--model指定模型名LMStudio 必须启用--enable-cors参数否则 Codex CLI 无法跨域请求codex /compact --dry-run --outputjson预览重构结果不写入文件--dry-run模拟执行--outputjson输出结构化结果输出 JSON 包含original_code、refactored_code、confidence_score可用于自动化审核提示Codex CLI 的--dry-run模式是上线前必做的安全阀。我们曾规定所有通过 Codex CLI 修改的生产代码必须先用--dry-run生成 diff由 senior engineer 审核 JSON 输出中的confidence_score和refactored_code确认无误后再执行真实命令。这避免了 AI 误判导致的线上故障。4. Cursor 汉化与中文回复设置一场关于“语言层”与“模型层”的认知战“cursor怎么设置中文回复”“cursor设置中文回复”“cursor中文怎么设置”——这三个搜索词几乎占了 superpowers 相关问题的三分之一。但绝大多数教程只告诉你两步1Settings → Appearance → Language → Chinese2Settings → AI → Language → Chinese。然后用户发现菜单变中文了但 AI 回复还是英文或者偶尔夹杂中文非常不稳定。问题根源在于Cursor 的“中文设置”横跨三个技术层级而多数教程只动了最表层的 UI 层。这三个层级分别是UI 层User Interface控制菜单、按钮、设置项的文字。对应settings.json中的locale: zh-cn。这是最简单的改完重启生效。协议层Protocol Layer控制 superpowers 请求消息体中的accept-languageheader 和user_preferred_language字段。这是 Cursor 自己加的非标准字段用于告诉后端模型“用户偏好语言”。它由settings.json中的cursor.ai.language: zh控制但必须配合账户的地区设置才能生效。如果你账户注册地是美国即使这里设为zh后端也可能忽略。模型层Model Layer最终决定输出语言的是所选模型自身的语言能力与指令遵循度。Claude 系列模型对zh指令响应很好但部分开源模型如早期 qwen1.5在中文指令下反而容易“幻觉”出英文术语。这才是最根本的变量。我做过一个对照实验同一台机器同一 Cursor 账户分别用claude-3.5-sonnet和qwen2.5模型执行相同 prompt“用中文解释这段 Python 代码的作用”。结果claude-3.5-sonnet100% 中文回复术语准确段落清晰qwen2.570% 中文30% 混杂英文函数名和注释且在解释asyncio时错误地翻译成“异步 I/O”而没用标准译名“异步输入输出”。这说明单纯设置cursor.ai.language是不够的。真正可靠的中文回复策略应该是模型选择 指令强化 后处理三管齐下模型选择优先选用原生支持中文的模型。Claude 系列、GLM 系列、Qwen2.5新版都是经过充分中文语料微调的。避免用未经中文优化的 Llama3 或 Phi-3 直接处理中文需求。指令强化在 prompt 开头明确声明语言约束。不要只写“解释代码”而要写“请严格使用简体中文回答不要出现任何英文单词包括函数名、类名、变量名也需用中文意译例如requests.get()→ ‘发送 HTTP GET 请求’”。实测表明加上这条约束qwen2.5 的中文纯净度从 70% 提升到 95%。后处理对于关键场景如生成文档、用户手册用正则表达式过滤残留英文。我在 Cursor 的自定义命令中加了一段 post-process script# 将 AI 输出保存为 temp_output.txt 后执行 sed -i s/\bdef\b/定义函数/g; s/\bclass\b/定义类/g; s/\bimport\b/导入模块/g temp_output.txt这虽然粗糙但在生成教学材料时非常有效。还有一个隐藏技巧Cursor 的cc switch命令用于快速切换模型支持 alias 功能。你可以把常用中文模型预设为 alias// settings.json cursor.modelSwitcher.aliases: { zh-claude: claude-3.5-sonnet, zh-qwen: qwen2.5:instruct }然后在命令面板输入 CC Switch: zh-claude就能一键切换到已验证的中文友好模型省去每次手动选择的麻烦。注意不要迷信“汉化补丁”或第三方汉化包。Cursor 的 UI 层汉化早已官方支持所谓“汉化包”往往只是修改了 locale 设置还可能引入安全风险。真正的中文体验提升来自于对模型能力、协议字段、prompt 工程的系统性理解而不是换个皮肤。5. 从 VS Code 接入 Claude Code 到本地模型调用superpowers 的“最后一公里”实践VS Code 用户常问“vscode配置claude code”“vs code使用方法”“vscode接入claude code”。这背后反映了一个现实VS Code 作为全球最普及的编辑器其生态与 superpowers 协议的原生融合度仍落后于 Cursor。Claude Code 扩展确实提供了 superpowers 能力但它并非 Cursor 那样的“一体机”而是一个“适配器”。它的核心价值不在于让你获得和 Cursor 一样的体验而在于打通 VS Code 原有工作流与 superpowers 新能力之间的最后一公里。比如你可以在 VS Code 里用CtrlShiftP调出命令面板输入Claude: Compact Selection对选中的代码块执行精简也可以右键点击文件选择Claude: Generate Unit Tests基于当前文件自动生成 pytest 用例。这些操作不需要离开你熟悉的 VS Code 界面。但真正的挑战在于如何让 Claude Code 调用你本地部署的模型比如 LMStudio 或 Ollama。官方文档只写了“支持自定义 endpoint”但没告诉你具体怎么配。我花了三天时间摸清了其中的关键路径第一步确认 LMStudio 的 API 兼容性LMStudio 默认提供 OpenAI 兼容 API但 Claude Code 的 superpowers 客户端默认期望 Anthropic 格式。你需要在 LMStudio 启动时加参数lmstudio --enable-openai-compatible-api --openai-compatible-api-port1234这样它就会同时监听http://localhost:1234/v1/chat/completionsOpenAI 格式和http://localhost:1234/v1/messagesAnthropic 格式。Claude Code 默认走 Anthropic 路径所以这个参数必不可少。第二步配置 Claude Code 的模型 endpoint在 VS Code 的settings.json中添加claudeCode.modelEndpoint: http://localhost:1234/v1/messages, claudeCode.apiKey: lmstudio, // LMStudio 不校验 key填任意非空字符串即可 claudeCode.modelName: llama3:instruct // 必须与 LMStudio 中加载的模型名完全一致注意modelName不是模型文件名而是 LMStudio UI 中显示的“Model Name”。比如你加载了llama3.Q4_K_M.gguf但 LMStudio 显示的 Model Name 是llama3:instruct就必须填后者。第三步绕过 Anthropic 的模型白名单校验Claude Code 内置了一个模型名称校验逻辑只允许claude-*开头的模型名。直接填llama3:instruct会报错Invalid model name。解决方案是修改 Claude Code 扩展的源码位于~/.vscode/extensions/anthropic.claude-code-*/out/extension.js搜索if (!modelName.startsWith(claude-))将其注释掉或改为if (false)。这是一个 hack但目前唯一可靠的方法。升级 Claude Code 时需重新修改。完成这三步后你就能在 VS Code 里用 Claude Code 调用本地 llama3 模型了。但要注意性能差异本地模型响应慢平均 3-5 秒而云端 Claude 模型通常 0.5 秒内返回。因此我建议只对两类场景使用本地模型1处理高度敏感的内部代码绝不上传2做模型对比实验比如同时用claude-3.5-sonnet和qwen2.5解释同一段代码观察输出差异。最后分享一个实战技巧利用 VS Code 的 Tasks 功能把 Codex CLI 和 Claude Code 联动起来。比如创建一个 task先用codex /compact对当前文件做预处理再用claudeCode.generateDocstring为精简后的函数生成 docstring。这样就把命令行的批处理能力和编辑器的交互能力结合起来了形成 superpowers 生态中最灵活的工作流。提示本地模型调用不是为了取代云端服务而是为了构建“混合智能”。我的工作流是日常开发用云端 Claude快、稳、强代码审计用本地 Qwen2.5可审计、可调试、无隐私泄露算法原型用 LMStudio 自定义 LoRA完全可控、可迭代。superpowers 的真正威力正在于它让这种混合成为可能而不是逼你选边站队。