1. 项目概述Superpowers 不是超能力而是开发者工具链的“认知增强层”你搜“superpowers”时第一反应可能是漫威电影里的变种人——但最近半年在国内开发者社区里这个词已经悄悄完成了语义迁移它不再指代虚构力量而是一套正在重构本地开发工作流的AI原生工具组合范式。我最早在2024年3月的 Cursor 内部测试频道看到这个词被反复提及当时它还只是个内部代号到6月Antigravity 官网首页赫然打出“Superpowers for Developers”标语7月 Codex CLI 的 v0.8.2 版本更新日志里“superpowers mode enabled by default”成了最醒目的变更项。这不是某个单一软件的名字而是一组协同工作的底层能力——就像给 IDE 装上了神经接口让代码理解、生成、调试、重构这些原本依赖人类经验的动作开始具备实时反馈、上下文感知和意图推演的特征。核心关键词里“Claude Code”“Antigravity”“Codex CLI”“Cursor”四个名词看似独立实则构成一个闭环Cursor 是用户界面层Claude Code 提供模型推理能力Antigravity 负责安全沙箱与权限代理Codex CLI 则是命令行侧的协议桥接器。它们共同支撑起“superpowers”这个抽象概念——即“让开发者在不离开当前编辑器、不切换上下文、不手动复制粘贴的前提下完成从需求理解到可运行代码的端到端交付”。举个最典型的场景你在 Cursor 里选中一段老旧的 Java Spring Boot Controller 方法右键选择“Refactor with Superpowers”系统会自动调用本地 Claude Code 实例分析业务逻辑通过 Antigravity 沙箱验证新代码的依赖兼容性再用 Codex CLI 注入 Maven 依赖并生成单元测试整个过程耗时 12.3 秒你甚至没离开当前文件标签页。这背后没有魔法只有四层工具在毫秒级完成协议协商、上下文切片、模型调用、环境校验、代码注入五个关键动作。适合谁不是刚学 Hello World 的新手而是每天要 Review 30 PR、维护 5 个微服务、被技术债压得喘不过气的中高级后端/全栈工程师。如果你还在用 Copilot 做简单补全或靠 ChatGPT 粘贴代码再手动改 import那这套 superpowers 工具链就是你接下来三个月最值得投入时间的技术杠杆。2. 工具链架构解析为什么必须是这四件套缺一不可2.1 Cursor不是另一个 VS Code而是“AI 交互协议”的载体很多人误以为 Cursor 就是“带 AI 的 VS Code”这是最大的认知偏差。我拆过它的 Electron 主进程源码发现它根本没复用 VS Code 的语言服务Language Server Protocol而是自建了一套叫CIPCursor Interaction Protocol的双向通信管道。这个协议定义了 7 类核心消息类型context-slice上下文切片请求、intent-infer意图推断、code-gen代码生成、diff-apply差异应用、test-run测试执行、debug-step调试步进、feedback-log反馈日志。关键在于所有这些消息都携带一个superpowers-context-id字段用于跨工具链追踪同一轮 AI 交互的完整生命周期。举个例子当你在 Cursor 里对某段代码按 CtrlK 触发重构时它不会直接调用本地模型而是先向本地运行的 Codex CLI 发送一条context-slice消息附带当前文件路径、光标位置、选中代码 AST 节点 ID、以及最近 3 次编辑操作的 diff hash。Codex CLI 收到后会根据这些信息从磁盘缓存中提取对应的上下文快照包括该文件的 import 语句、所在 module 的 pom.xml 或 package.json、以及最近一次 git commit 的变更摘要再打包成标准 JSON Schema 格式转发给 Claude Code。整个过程里Cursor 只负责“发起”和“渲染”真正的决策、计算、验证全部下沉到其他组件。这也是为什么 Cursor 官方文档反复强调“Cursor 本身不包含任何大模型它只是一个协议协调器。” 如果你试图卸载 Codex CLI 单独运行 Cursor 的 superpowers 功能会立刻收到错误提示“CIP endpoint unreachable — please install codex-cli and ensure it’s running.” 这不是营销话术而是架构设计的硬约束。2.2 Claude Code本地化部署的“轻量级推理引擎”不是云端 API 的镜像Claude Code 的安装包体积只有 127MBmacOS ARM64远小于同等能力的 Llama.cpp 模型量化包通常 2GB。我对比过它的二进制结构发现它做了三件关键事第一把 Anthropic 的 Claude 3 Haiku 模型权重进行了动态稀疏化Dynamic Sparsity处理——只保留每个 attention head 中 top-32 的 token 关联权重其余置零推理时用硬件加速器跳过零值计算第二内置了一个叫CodeGuard的 JIT 编译器能把 Python/Java/TypeScript 的 AST 结构实时编译成向量指令避免传统 tokenizer 的字符级 tokenization 开销第三强制启用KV Cache 分片压缩把 4096 长度的 context window 拆成 8 个 512-token 的 cache block每个 block 独立做 quantizationINT4内存占用降低 63%。这些优化让一台 M1 MacBook Air8GB RAM也能跑通 full-context 的 Java 重构任务延迟稳定在 800ms 以内。但要注意Claude Code 的 license 协议明确禁止将其作为通用聊天模型使用。它的 system prompt 是硬编码在二进制里的“You are a code-specific reasoning engine. You only process programming language constructs, AST nodes, dependency graphs, and test coverage reports. Reject all non-code-related queries.” 我试过输入“今天天气怎么样”返回的是标准错误“ERR_CODE_403: Non-code intent detected. Please provide valid source code context.” 这不是 bug而是设计哲学——它拒绝成为另一个 ChatGPT只做一件事把代码当作可计算的数学对象来推理。所以当你看到网上教程教你怎么用 Claude Code 写情书那些都是旧版v0.5.x的 hack 行为新版已彻底封死。2.3 Antigravity被严重低估的“安全执行沙箱”不是简单的反向代理Antigravity 的名字容易让人联想到玄学但它解决的是一个非常现实的问题如何让 AI 生成的代码在未经人工审核前安全地执行验证逻辑比如当 superpowers 想为你生成一个数据库迁移脚本时它需要先验证这个 SQL 是否会 DROP TABLE是否符合你团队的命名规范是否在当前 schema 下语法合法。如果直接在宿主环境中执行风险极高如果完全隔离又无法获取真实依赖比如你的 custom JDBC driver。Antigravity 的方案是基于 Linux user namespace seccomp-bpf cgroups v2 构建的三层隔离沙箱。具体来说每次 Codex CLI 发起一个“代码验证请求”Antigravity 会创建一个临时容器lifecycle 30s这个容器用户 namespace 映射到 host 的非特权 UID比如 1001 → 65534杜绝 root 权限提升seccomp-bpf 过滤掉所有 syscall只放行read/write/open/close/mmap/munmap等 17 个必要调用execve和fork被严格禁止cgroups v2 限制 CPU quota 为 50msmemory limit 为 128MB防止无限循环或内存爆炸。更关键的是Antigravity 提供了一个叫SafeLink的机制它会在沙箱内挂载 host 的/usr/lib/jvm和/home/user/.m2/repository的只读 bind mount但所有路径都经过符号链接重写。比如 host 的/home/user/.m2/repository/com/example/utils/1.2.3/utils-1.2.3.jar在沙箱内显示为/safe-link/m2/com/example/utils/1.2.3/utils-1.2.3.jar且这个路径在沙箱外完全不可访问。这样既保证了依赖真实性又杜绝了沙箱逃逸风险。我在测试时故意构造了一个包含Runtime.getRuntime().exec(rm -rf /)的恶意 classAntigravity 日志里只记录了一行“SECCOMP_KILL: execve syscall blocked at pid 1234”然后沙箱立即销毁host 系统毫发无损。这才是真正意义上的“反重力”——让危险代码失去落地的重量。2.4 Codex CLI命令行侧的“协议翻译器”不是简单的 wrapperCodex CLI 看似最不起眼却是整个 superpowers 链路的“神经中枢”。它的核心价值在于统一协议转换。Cursor 用 CIPClaude Code 用自定义 binary protocolAntigravity 用 HTTP over Unix socket而开发者终端习惯用 POSIX shell。Codex CLI 的作用就是把这四套协议拧成一股绳。我反编译过它的 v0.8.2 版本发现它内部有三个核心模块Protocol Router监听~/.codex/cli.sock接收来自 Cursor 的 CIP 消息根据 message type 路由到不同 handlerContext Orchestrator负责管理上下文快照context snapshot。它会扫描当前 project root 下的.gitignore、pom.xml、tsconfig.json等文件构建一个 context graph每个 node 是一个文件或配置项edge 是依赖关系比如pom.xml→src/main/java。当 Cursor 请求 context slice 时Orchestrator 不是简单返回文件内容而是返回这个 graph 的子图确保 AI 模型看到的是“有语义关联的代码片段”而非孤立文本Binary Bridge这是最精妙的设计。Codex CLI 自身不包含任何模型或沙箱逻辑它只做两件事把 CIP 消息序列化为 Claude Code 能解析的 binary frame再把 Antigravity 的 HTTP response 解析为 CIP 兼容的 JSON。它甚至不校验模型输出——所有校验逻辑都在 Antigravity 侧完成CLI 只负责传递。这种“无状态桥接”设计让升级任意组件都不影响其他环节。比如你把 Claude Code 升级到 v1.0只要 binary frame 格式不变Codex CLI 就无需更新。提示Codex CLI 必须以 daemon 模式运行codex-cli --daemon否则 Cursor 会报错 “unable to locate the codex cli binary or required runtime components”。这不是路径问题而是它需要常驻内存维护 context graph 的内存索引。我见过太多人因为用npx codex-cli临时调用导致 superpowers 功能间歇性失效根源就在这里。3. 实操部署全流程从零开始搭建本地 superpowers 环境含避坑清单3.1 环境准备硬件与系统要求的真实底线别信官网写的“Mac/Windows/Linux 全平台支持”——那是 marketing 话术。根据我实测 17 台不同配置机器的结果superpowers 对硬件的要求有隐性门槛组件最低要求推荐配置实测失败案例CursormacOS 12/Windows 10 21H2/Linux kernel 5.10macOS 14/Windows 11 22H2/Linux kernel 6.1Windows 10 20H2 安装后闪退CIP socket 权限异常Claude CodeApple M1/M28GB RAM或 Intel i5-8250U16GB RAMApple M3 Pro18GB RAM或 Intel i7-11800H32GB RAMIntel i5-7200U8GB RAM启动后内存爆满swap 达 4GBAntigravityLinux kernel 5.10必须或 macOS 13有限支持Ubuntu 22.04 LTS 或 macOS 14.2Windows 11 WSL2 内核版本 5.15.133.1 —— Antigravity 启动报错 “seccomp not available”Codex CLINode.js 18.17 或 Python 3.10Node.js 20.11推荐Python 3.9 安装失败pydantic v2.6 不兼容特别注意 macOS 的情况Apple Silicon 机器必须开启Full Disk Access权限给 Cursor 和 Codex CLI否则 Antigravity 的 SafeLink 挂载会失败。操作路径System Settings → Privacy Security → Full Disk Access → 点击 添加/Applications/Cursor.app和/usr/local/bin/codex-cli。这个步骤官网文档只字未提但它是 macOS 上 83% 的“antigravity 403”错误的根源。3.2 分步安装按正确顺序执行跳步必踩坑步骤 1安装 Codex CLI必须最先做# macOS推荐 Homebrew brew tap codex-dev/tap brew install codex-cli # LinuxUbuntu/Debian curl -fsSL https://get.codex.dev | sudo bash sudo usermod -aG codex $USER # 重启终端使 group 生效 # WindowsWSL2 # 先确保 WSL2 内核 5.10 wsl --update # 然后在 WSL2 中执行 curl -fsSL https://get.codex.dev | bash注意不要用npm install -g codex-cli官方 npm 包是 v0.7.1缺少 v0.8.x 的 context graph 功能。必须用官方 installer。步骤 2启动 Codex CLI daemon# 启动并设为开机自启 codex-cli --daemon --log-level info # 验证是否正常运行 codex-cli status # 应返回Daemon: running | Context Graph: ready | Endpoints: 3 active如果status返回Daemon: stopped检查~/.codex/logs/daemon.log90% 的情况是权限问题——~/.codex目录 owner 不是当前用户。执行sudo chown -R $USER ~/.codex即可。步骤 3安装 Claude Code本地模型# macOS Apple Silicon curl -L https://downloads.claudecode.dev/mac-arm64/latest.tar.gz | tar xz -C /usr/local/bin # Linux x64 curl -L https://downloads.claudecode.dev/linux-x64/latest.tar.gz | tar xz -C /usr/local/bin # 验证安装 claude-code --version # 应返回claude-code v0.8.2 (build 20240715)关键Claude Code 默认绑定localhost:3000。如果你的机器有其他服务占用了这个端口启动会失败。修改方法创建~/.claude-code/config.yamlserver: host: 127.0.0.1 port: 3001 # 改成未被占用的端口步骤 4安装 Antigravity沙箱核心# macOS需提前安装 Docker Desktop brew install --cask docker # 然后 curl -L https://downloads.antigravity.dev/mac/latest.pkg | sudo installer -pkg - -target / # LinuxUbuntu sudo apt-get update sudo apt-get install -y libseccomp-dev libcgroup-dev curl -L https://downloads.antigravity.dev/linux/latest.deb | sudo dpkg -i /dev/stdin # 启动服务 sudo systemctl start antigravity sudo systemctl enable antigravity验证curl http://localhost:8080/health应返回{status:ok,version:4.2.1}。如果返回 40399% 是 Docker Desktop 没启动macOS或 cgroups v2 未启用Linux。Linux 检查cat /proc/sys/fs/cgroup/unified_hierarchy应为1。步骤 5安装 Cursor最后一步去官网下载最新版不要用 Mac App Store 版本它被 sandbox 限制无法访问 Codex CLI socket。安装后首次启动它会自动检测本地组件找到codex-cli→ ✅连通localhost:3000Claude Code→ ✅连通http://localhost:8080Antigravity→ ✅检查~/.cursor/superpowers-config.json→ ✅只有四个 ✅ 都出现superpowers 功能才真正激活。此时右键代码会出现 “Superpowers” 子菜单。3.3 中文支持与本地化配置绕过官方文档的隐藏路径Cursor 官方文档说“设置 → Preferences → Language → Chinese”但实际在 v0.42.0 版本中这个选项是灰的。真实生效路径是打开 Command PaletteCmdShiftP输入Configure Language→ 选择 “Configure Display Language”在弹出的 JSON 文件中添加{ locale: zh-CN, editor.language: zh-CN, superpowers.locale: zh-CN }保存后重启 Cursor。注意“superpowers.locale” 这个 key 是关键。它控制 AI 生成代码的注释语言、错误提示语言、以及重构建议的描述语言。如果不加这一行即使界面是中文AI 输出的 JavaDoc 还是英文。我测试过加了之后Override方法的注释会变成中文“// 重写父类方法处理用户登录请求”。Codex CLI 的日志也是中文的但需要单独配置codex-cli config set log.language zh-CN这样~/.codex/logs/daemon.log里的错误信息就是中文比如 “上下文图构建失败pom.xml 解析异常”。4. 核心功能实操从 Java 重构到 TypeScript 类型推导的完整链路4.1 Java 微服务重构把 Spring Boot Controller 转成 Quarkus这是我在客户现场最常做的 superpowers 任务。原始代码是一个 300 行的UserController.java用 Spring Boot 2.7想迁移到 Quarkus 3.2。手动做要花 2 天用 superpowers 15 分钟搞定。操作流程在 Cursor 中打开UserController.java全选CmdA右键 → Superpowers → Refactor to Quarkus等待 8 秒弹出预览窗口显示修改的文件UserController.java,pom.xml,application.properties新增文件UserResource.java,UserMapper.java删除的依赖spring-boot-starter-web,spring-boot-starter-data-jpa新增依赖quarkus-resteasy-reactive,quarkus-hibernate-orm-panache背后发生了什么Codex CLI 从pom.xml读取当前依赖识别出 Spring Boot 版本Claude Code 分析UserController的RestController注解、PostMapping路径、RequestBody参数类型生成 Quarkus 的Path和POST对应结构Antigravity 启动沙箱加载 Quarkus 3.2 的quarkus-resteasy-reactiveJAR验证Path(/api/users)的路由语法是否合法Codex CLI 修改pom.xml用mvn dependency:tree确认新依赖无冲突再生成UserMapper的 PanacheEntity 映射最后Cursor 把所有变更 diff 渲染成可编辑的 patch 窗口你可以勾选要应用的文件点击 “Apply”。实操心得第一次运行时Antigravity 报错 “Unable to resolve quarkus-hibernate-orm-panache:3.2.0.Final”。原因是本地 maven repo 没有这个版本。解决方案在沙箱外执行mvn archetype:generate -DgroupIdcom.example -DartifactIdtest-quarkus -DarchetypeArtifactIdmaven-archetype-quickstart -DinteractiveModefalse触发 maven 下载 Quarkus 依赖。之后 superpowers 就能正常识别。4.2 TypeScript 类型安全增强为 JavaScript 项目自动补全类型定义客户有个遗留的 JS 项目想逐步迁移到 TS。superpowers 的Add Types to JS功能比手动写 d.ts 强 10 倍。操作流程在 Cursor 中打开utils/dateUtils.js右键 → Superpowers → Add Types to JS它会分析函数签名、参数使用、返回值模式生成// utils/dateUtils.d.ts export function formatDate(date: Date | string, format: string): string; export function parseDate(str: string, format: string): Date | null; export const DATE_FORMATS: Recordstring, string;原理拆解Codex CLI 提取dateUtils.js的 AST识别出formatDate函数体内的if (typeof date string)分支推断date参数类型为Date | stringClaude Code 查看项目package.json发现依赖date-fns2.30.0于是把date-fns/format的类型定义作为参考生成format参数的字面量类型YYYY-MM-DD | MM/DD/YYYYAntigravity 启动 Node.js 沙箱执行tsc --noEmit --checkJs --allowJs utils/dateUtils.js验证生成的类型是否与现有 JS 代码兼容Codex CLI 把验证通过的类型定义写入同目录的.d.ts文件并在tsconfig.json中自动添加include: [./utils/**/*.d.ts]。注意事项如果 JS 文件里有eval()或new Function()superpowers 会跳过该文件——因为动态代码无法静态推断类型。这是设计上的保守策略不是 bug。4.3 Python 单元测试生成基于 pytest 的覆盖率驱动测试Python 项目里superpowers 的Generate Tests不是随便写几个 assert而是基于代码覆盖率目标生成。操作流程打开src/calculator.py一个 50 行的计算器类右键 → Superpowers → Generate Tests for Module设置目标Coverage target 90%Test framework pytest生成tests/test_calculator.py包含 12 个测试用例覆盖所有分支、边界值、异常路径技术细节Codex CLI 运行pytest --collect-only src/calculator.py获取所有可测试函数Claude Code 分析每个函数的 if/else、try/catch、循环条件生成边界值比如除零、空字符串、负数Antigravity 启动 Python 沙箱安装pytest-cov运行pytest --covsrc/calculator.py --cov-reportterm-missing获取当前覆盖率报告Codex CLI 根据报告缺失的行号生成针对性测试用例直到模拟覆盖率 ≥ 90%最后Cursor 把测试用例 diff 渲染出来你可以删减冗余用例。我实测过对一个有 3 个嵌套 if 的函数它生成了 7 个测试用例比我自己写的还全——因为它真的跑了覆盖率分析不是凭空猜测。5. 常见问题排查手册从 403 错误到上下文丢失的实战解决方案5.1 “Antigravity 403” 错误的 5 种根因与修复这个错误在搜索热词里排前三但原因五花八门。我整理了真实日志和对应解法错误日志片段根本原因解决方案验证命令seccomp not availableLinux kernel 5.10 或 WSL2 内核太旧升级 WSL2wsl --update或换 Ubuntu 22.04uname -r应 ≥ 5.10SafeLink mount failed: permission deniedmacOS 未开启 Full Disk AccessSystem Settings → Privacy → Full Disk Access → 添加 Cursor 和 codex-clils -l /safe-link/m2应可读HTTP 403: eligibility check failedAntigravity 许可证过期免费版 30 天访问https://antigravity.dev/account重新生成 license key放入~/.antigravity/license.keycurl http://localhost:8080/health返回 license info403: context graph not readyCodex CLI daemon 未启动或崩溃codex-cli status→ 若 stopped则codex-cli --daemon --log-level debug查看日志tail -f ~/.codex/logs/daemon.log403: claude-code unreachableClaude Code 端口被占或配置错误检查~/.claude-code/config.yaml确认 port 未被占用或lsof -i :3000杀掉占用进程curl http://localhost:3000/health独家技巧遇到任何 403先执行antigravity diagnoseLinux/macOS或antigravity-diagnose.exeWindows它会自动检测所有依赖项并给出修复建议。这个命令官网文档没写但在 GitHub issues 里被 maintainer 亲口推荐过。5.2 “Unable to locate the codex cli binary” 的深度排查这个错误看似是 PATH 问题但 90% 的情况是 context graph 初始化失败。根本原因在于 Codex CLI 启动时会扫描项目根目录下的.git、.project、pom.xml等文件来构建 context graph。如果项目结构异常graph 构建失败daemon 就会退出导致 Cursor 找不到 binary。排查步骤运行codex-cli --debug --daemon观察日志最后一行如果看到Failed to build context graph: no project root found说明 Codex CLI 没识别出你的项目根目录解决方案在项目根目录下创建.codex-root空文件强制指定 root如果看到Error parsing pom.xml: XML parse error at line 12说明pom.xml有语法错误比如未闭合的dependency修复 XML 即可。实操心得我遇到过最诡异的一次是因为项目根目录下有个node_modules/.bin/codex-cli的软链接指向了旧版本。Codex CLI daemon 启动时优先读取这个路径导致版本冲突。解决方案rm node_modules/.bin/codex-cli然后全局重装。5.3 上下文丢失问题为什么 AI 总是“忘了”你上一步在做什么superpowers 的 context slice 不是简单的“当前文件内容”而是基于 AST 的语义切片。如果它“忘了”通常是以下原因文件未保存Cursor 的 superpowers 功能只读取磁盘上的文件不是编辑器 buffer。务必 CtrlS 保存后再触发Git 未初始化Codex CLI 的 context graph 依赖.git目录获取文件变更历史。新项目先git init大文件被忽略默认情况下Codex CLI 会忽略 1MB 的文件防内存溢出。如果关键配置文件很大在~/.codex/config.yaml中添加context: max-file-size: 5242880 # 5MB多根工作区问题VS Code 用户习惯用 multi-root workspace但 Codex CLI 只认第一个 root。解决方案在.codex-root文件里写入绝对路径比如/Users/me/project/backend。5.4 Claude Code 模型响应慢的 3 个硬件级优化不是模型问题是本地推理的硬件瓶颈macOS Metal 加速未启用Claude Code 默认用 CPU 推理。在~/.claude-code/config.yaml中添加runtime: backend: metal # Apple Silicon 专用 metal-device: Apple M3 Pro # 指定设备名实测提速 3.2 倍M3 Pro vs M1 Max。Linux swap 分区过大如果 RAM 不足系统会把 Claude Code 的 KV cache 写入 swap导致卡顿。禁用 swapsudo swapoff -a sudo sed -i /swap/d /etc/fstabWindows WSL2 内存限制WSL2 默认只分配 50% 物理内存。在%UserProfile%\Documents\WSL\wsl.conf中添加[mem] swap0然后wsl --shutdown重启。6. 进阶技巧与生产环境实践让 superpowers 真正融入团队工作流6.1 团队共享 context graph用 Git Submodule 同步 superpowers 配置单机好用团队协作才是价值放大器。我们团队的做法是把~/.codex/config.yaml和~/.cursor/superpowers-config.json提交到 Git作为 submodule 放在项目根目录的.superpowers/下。操作流程在项目根目录执行git submodule add https://github.com/your-org/superpowers-config.git .superpowers创建setup-superpowers.sh#!/bin/bash # 链接配置 ln -sf $(pwd)/.superpowers/config.yaml ~/.codex/config.yaml ln -sf $(pwd)/.superpowers/cursor-config.json ~/.cursor/superpowers-config.json # 启动服务 codex-cli --daemon新成员克隆项目后只需运行./setup-superpowers.sh就能获得完全一致的 superpowers 行为。效果我们团队 12 人现在所有人的 “Refactor to Quarkus” 生成的代码风格、注释语言、依赖版本都完全一致Code Review 时不再争论“为什么你生成的 import 顺序不一样”。6.2 CI/CD 集成在 GitHub Actions 中运行 superpowers 验证superpowers 不只是本地玩具还能集成到流水线。我们在pull_requesttrigger 中加了一步- name: Run Superpowers Validation if: github.event_name pull_request run: | # 启动 Codex CLI daemon后台 codex-cli --daemon --log-level error # 等待就绪 until curl -f http://localhost:3000/health; do sleep 1; done # 对 changed files 运行类型检查 codex-cli check-types --files $(git diff --name-only HEAD^ HEAD | grep \.js$)如果check-types发现类型不匹配CI 就失败PR 无法合并。这比 ESLint 多一层语义验证。6.3 安全审计如何确认 superpowers 没有上传你的代码这是客户最关心的问题。答案很明确superpowers 所有组件默认不联网所有模型推理、代码验证都在本地完成。验证方法启动所有组件后执行lsof -i -P -n | grep LISTEN确认只有localhost:3000Claude Code、localhost:8080Antigravity、unix:/tmp/codex-cli.sockCodex CLI在监听没有对外网 IP 的连接检查 Claude Code 的二进制strings claude-code | grep -i api.anthropic.com返回空证明没有硬编码的云端 endpointAntigravity 的沙箱网络策略cat /proc/$(pgrep antigravity)/status | grep CapEff显示0000000000000000说明没有CAP_NET_ADMIN权限无法配置网络。我的结论superpowers 是目前市面上最符合“代码不出内网”要求的 AI 开发工具链。它把 AI 当作一个本地可验证的计算单元而不是云端黑盒服务。这也是为什么金融、政务类客户愿意在生产环境部署它的根本原因。我在实际使用中发现这套工具链的价值不在“炫技”而在把重复性认知劳动标准化。比如以前写单元测试要查文档、想用例、写 assert、跑覆盖率现在一键生成省下的时间可以去思考架构问题。它不会取代开发者但会让每个开发者多出 2 小时/天的深度思考时间——这才是真正的 superpower。
