上一周我连续收到三条同样性质的问题AI 生成了接口代码编译通过但一跑到真实业务场景就露馅。第一条是漏了状态回退第二条是日期边界差一天第三条是把另一个团队正在改造的旧接口当成了稳定的依赖来源。三个问题的共同点不是 AI 不行而是我们把 AI 编程想得太简单了——以为代码生成速度上来了可靠性就会自动跟上。Superpowers 使用指南里反复强调的一句话让我印象很深你要的不只是更快的代码生成而是一套能让 AI 输出被项目直接接纳的流程。Superpowers 不是某个特效工具也不是新语言它是一套围绕 Claude Code 这类 AI 编程终端设计的“技能包”由命令Commands、技能Skills和子代理Subagents三层组成配合精心编排的提示词把散装 AI 对话变成一条有纪律的开发流水线。这篇文章我会从能力拆解、安装步骤、核心工作流、实战细节和踩坑记录五个方面展开适合两类人看一是已经被 AI 编程的“快”吸引、但被频繁返工折磨的开发者二是想让 AI 输出真正融入团队代码库而不是停留在 demo 级别的技术负责人。1. AI 编程“快而不稳”的病根缺上下文也缺流程1.1 一段真实的返工画面我见过太多类似的场景开发者在 IDE 里选中一段代码让 AI 生成某个接口实现。三十秒以后几百行代码呼啦一下出来了语法正确、命名工整、看起来完全可以用。真正开始合入的时候问题全冒出来跟已有模块的调用约定不一致没处理边界条件甚至把老逻辑直接覆盖掉。接下来就是三小时的返工先把 AI 写的东西删掉再在关键路径上手动补回原来的逻辑。这不是 AI 不会写代码而是大多数情况下我们根本没有给 AI 足够的上下文也没有给它设置一个“必须验证自己产出”的流程。速度和可靠性是两条完全不同的能力曲线前者靠模型规模后者靠工程方法。1.2 通用提示词喂不出可靠结果问题出在哪里第一模型对项目结构、历史决策、已有风格的了解非常有限。一个“帮我实现订单状态机”的提示词在模型眼里可能只是“写出一个状态机的代码”而不是“在当前项目约束下实现符合既有状态流转逻辑的订单状态机”。它不知道你们的错误码规范不知道状态字段存在哪个表里更不知道上次重构留下的坑。第二没有校验闭环。即使模型本身具备很强的自我检查能力如果我们没在提示词中要求先跑测试、先编译、再交付它通常会默认“产出看起来合理的代码”就够了。AI 没有压力必须证明自己是对的于是在“看起来很对”和“实际上是对的”之间它总是选择前者。第三缺少迭代纪律。AI 编程的本质是对话式协作每一轮输出都在消耗上下文窗口。如果每次都直接给最终方案没有澄清、没有方案评审、没有验证过程那么错误就没有机会被暴露和修正。快确实是快了但快在整个错误路径上结果就是返工更有效率。1.3 “可靠”到底指什么我理解的可靠是“生成结果可以直接被项目接纳”。这意味着它能通过现有 lint 规则、能通过测试、能被团队其他成员看懂、能正确对齐既有接口而不是在空房间里写出一段孤立完美的代码。Superpowers 这个名字我一开始还以为是营销概念真正研究之后才发现它是一个很工程化的工具集它做的事情就是把上面说的“上下文、校验、迭代”三件事分别用不同的机制注入进 AI 编程会话。接下来我们就拆开看它到底做了什么。2. Superpowers 的能力拆解Commands、Skills、Subagents 三者各管哪一块很多刚接触 Superpowers 的人第一反应是它到底是提示词插件还是脚本答案其实是三个都有。它由三层能力组成每一层解决不同层面的问题共同的效果是把“一次性对话”变成“可复用的工作系统”。2.1 Commands斜杠命令相当于快捷键Commands 是 Claude Code 里的斜杠命令比如/help、/brainstorm、/review。你在对话里输入/brainstormClaude Code 会加载对应的命令文件这个文件本质上是一份精心编写的提示词告诉 AI 该以什么角色、用什么步骤、输出什么格式来完成任务。命令的好处是触发成本极低几乎不需要记忆输入斜杠就能看到候选列表。但命令通常是“一次性”的不会跨会话被自动记住。它解决的是“不知道该怎么指挥 AI”的问题你不必每次重新组织语言一条命令就把所有要求说清楚了。Superpowers 自带的命令通常覆盖这些方向命令作用典型场景/brainstorm澄清需求、发散方案不急着写代码需求模糊先讨论清楚再动手/plan输出结构化实现方案列出改动文件和风险大功能开发前做设计评审/implement按方案实现代码保持与计划一致方案确认后的编码阶段/test进入测试驱动模式要求先写测试再实现希望代码可验证、可回归/debug定位根因不直接给补丁线上 bug、测试失败排查/review从边界、性能、可测性等角度审查代码合并请求提交前的自我检查/document收尾总结把改动理由和运行方式写清楚功能完成后沉淀上下文不同版本、不同仓库分支下命令清单会有差异。我第一次使用时也纠结过“有那些 skills”这个问题后来想明白了重点不是背下每个技能的名字而是理解这套工具的设计取向——每个命令都对应一个软件工程节点而不是一个“写代码”的动作。2.2 Skills可复用的操作流程Skills 是相对更重的机制。每个技能都是一个目录里面包含SKILL.md描述文件有时候还有配套脚本、提示词模板和参考文档。SKILL.md会写清楚这个技能在什么场景下使用、使用前需要收集哪些信息、执行步骤是什么、输出物是什么。AI 读了这个文件后相当于拿到了一张“操作标准作业书”而不是一句笼统的“帮我重构”。它知道什么时候该停下来问问题什么时候该列假设什么时候该运行测试。这种结构化描述对大模型特别友好——模型最擅长顺着清晰的步骤执行最怕含糊的开放式指令。目录结构一般长这样~/.claude/skills/ ├── brainstorm/ │ └── SKILL.md ├── plan/ │ └── SKILL.md ├── implement/ │ ├── SKILL.md │ └── templates/ └── debug/ └── SKILL.md你要是有兴趣完全可以自己照着这个格式写一个团队私有的“上线检查技能”或者“数据库迁移技能”。这才是它真正有价值的地方它不限制你只能用它自带的那几个而是给你一套定义能力的方法。2.3 Subagents让不同的“专家”各司其职Subagents 是第三层也是最容易被人忽略的一层。它本质上是多个独立的 AI 会话角色一个负责架构设计、一个负责写测试、一个专门审视安全风险。Superpowers 会把这类角色的“人设提示词”单独写好放到 Claude Code 的子代理目录里。当主对话需要时你可以临时唤起某个子代理让它以特定视角分析同一个问题。比如主流程里 AI 写完了代码你可以单独唤起一个“测试专家代理”让它专门审查测试覆盖率再唤起一个“安全代理”只看注入风险和敏感信息泄露。每个代理的视角更聚焦得出的结论也更有针对性比在同一个上下文里含糊地要求“你再检查一下”要有效得多。值得说明的是这三层其实可以互相调用一个 command 可以触发一个 skill一个 skill 执行中又可以唤起 subagent。最终效果不是多了一堆散装指令而是形成了一套有层级的可组合能力。3. 安装与引入从零把 Superpowers 接进 Claude Code3.1 先说前提条件我默认你的环境已经装好 Claude Code并且能正常发起会话。除此之外还需要Git用来克隆 Superpowers 仓库Node.js不是所有场景都依赖脚本但安装脚本和部分技能会用到 Node 环境对 Claude Code 的基础操作会打开交互会话、会输入斜杠命令。这里提醒一句如果你还停留在“只在网页聊天窗口里用 AI”的阶段那 Superpowers 暂时不适合你。它针对的是运行在本地终端、能直接读写文件、能执行命令的编程代理工具这也是它能把“验证动作”落地的关键前提。3.2 安装过程两种方式按需选择第一种是仓库安装也是我比较推荐的新手路径git clone https://github.com/obra/superpowers.git cd superpowers ./scripts/install.sh这一步会发生什么脚本会把仓库里的 commands 复制到 Claude Code 的全局命令目录把 skills 复制到技能目录把子代理配置复制到子代理目录。不同版本的 Claude Code 目录结构可能略有差异你只要记住一个原则Superpowers 的安装核心就是把提示词模板和流程文件放进 AI 工具会读取的目录。只要目录正确它就会被自动装载。第二种方式是在 Claude Code 里直接使用/plugin相关命令选择本地目录或 GitHub 仓库。这种方式的优势是方便日后用版本管理维护插件适合已经对 Claude Code 插件机制很熟的人。第一次使用我还是建议先走仓库安装路径清晰、容易排查问题。3.3 验证是否安装成功安装不等于生效。我见过太多人装完就以为万事大吉结果输入命令时 AI 根本无响应。建议按下面的顺序验证输入/help看命令列表中是否出现 brainstorm、plan、review 等输入/brainstorm如果 AI 没有报“未知命令”而是进入提问流程说明命令已经加载打开终端查看目录ls ~/.claude/skills确认每个 skill 目录存在且SKILL.md文件完整。关于验证这一步多说一句如果命令列表里能看到但执行后 AI 表现和普通对话没什么区别问题通常出在 CLAUDE.md 的系统提示词没有被正确加载。这种情况直接重开会话一般就能解决。3.4 常见的安装问题现象可能原因解决方式安装脚本提示权限不足install.sh没有执行权限先执行chmod x scripts/install.sh命令装上但执行无效目录放错或版本不兼容确认当前 Claude Code 实际读取哪个命令目录同名命令冲突之前手动放过自定义命令备份原命令文件优先保留 Superpowers 版本skill 不被触发上下文里技能描述未加载重开会话或检查CLAUDE.md是否有技能引用提示如果你在团队里使用不要让每个人都各自手动克隆安装。建议把安装步骤写进团队文档或者直接维护一个统一的配置脚本这样版本一致后续升级也省事。4. 核心工作流拆解从 Brainstorm 到 Document 的闭环为什么能提升可靠性Superpowers 最让我认可的地方不是某个单独的命令而是它把“AI 编程”从散弹枪变成一条流水线。它代表性的流程是Brainstorm - Plan - Implement - Test - Document。这个顺序看起来就是我们常说的软件工程但它被真正灌进了 AI 的会话逻辑里。4.1 Brainstorm让 AI 先想再做很多提示词的问题在于一上来就要答案而 Superpowers 的 brainstorm 技能会先要求 AI 和你一起澄清需求甚至反问你真正要解决的问题是什么有没有隐藏约束最关键的决策点在哪里这会逼着模型先把问题域画清晰再谈解决方案。我第一次用的时候有点不耐烦觉得多绕了一圈。后来发现正是这一步避免了很多“答非所问”。举例来说当你说“给订单增加取消功能”时brainstorm 会追问取消之后要不要退款库存要不要回滚取消操作可不可以撤销这些追问看起来琐碎但每一个都是真实的业务需求也是后续代码不至于返工的关键。4.2 Plan动手之前把方案铺开Plan 阶段要求 AI 输出一个结构化的实现方案包括涉及的文件、改动点、风险项、验证方式。这相当于传统开发里的设计文档只不过它是为 AI 自己和人类共同服务的。当你看到 plan 之后可以先审一遍发现问题直接在方案层面修正而不是等代码写完再推翻。这个阶段也是人类参与度最高的地方别当甩手掌柜。我常用的做法是要求 AI 用列表形式把改动文件全部铺开然后我快速扫一眼有没有不该动的模块。这一步成本很低但能挡掉大量误伤。4.3 Implement 与 TestTDD 在这里不是摆设Implement 技能会引导模型采用测试驱动或至少测试同步的方式先写测试再写实现或者边实现边补测试。Superpowers 的测试技能会主动要求运行测试命令而不是假装已经通过。这个细节极其重要。普通 AI 往往会“猜测”自己的输出是正确的它会自信地说“测试已通过”但没有任何证据。Superpowers 的做法是让 AI 真正执行测试命令把运行结果作为“完成”的前提。可靠性和快感差的开端就在“是否真的验证过”这件事上。我在实际项目里遇到过一个典型的例子让 AI 写一个日期区间工具函数它理所当然地按“开始日期到结束日期”的直觉逻辑实现了。当测试用例里加入“开始日期晚于结束日期”和“跨年区间”之后实现立刻暴露问题。没有测试兜底这类边界 bug 几乎不可能被模型自己发现。4.4 Document把完成标准钉死很多开发者觉得文档是写给别人看的所以在 AI 编程里总被省略。Superpowers 却把 document 当成最后一道工序要求 AI 总结它改了什么、为什么改、运行方式是什么。这块文档的读者其实不是人而是下一个会话里的 AI。因为下次再让 AI 改这个模块时如果它能读到之前的决策记录上下文质量会高很多。它知道这个模块为什么这么设计、哪些地方是被刻意绕开的、测试覆盖到什么程度。这种“给未来的 AI 留言”的做法等于把团队里最宝贵的隐性知识沉淀了下来。4.5 流程间如何衔接实际用的时候一个复杂任务往往是多个技能串联的先/brainstorm发散再/plan收敛确定方向后/implement写代码写完后/test验证最后/document收尾。Superpowers 的各个 skill 之间不是孤岛它会在前一个 skill 的输出里提示下一步可以调用的命令这等于在提示词层面把项目管理约束写进去了AI 会主动维护这个工作流。5. 把 Superpowers 真正用好的关键细节上下文、检查点与提示词配合5.1 管理上下文不只要装好还要喂对安装完成后很多人的下一个问题是怎么让它更懂我的项目Superpowers 提供了基础的提示词注入但它不能替代你自己的 CLAUDE.md。我强烈建议在项目根目录维护一个 CLAUDE.md写清楚项目结构、构建命令、测试命令、代码风格、常用约定。举个例子一份简洁有效的项目说明可能长这样# 项目约定 - 包管理器pnpm - 测试框架Vitest - 类型检查tsc --noEmit - 代码风格遵循 .eslintrc.cjs - 关键目录src/modules 下按业务域划分这里有个平衡问题写太少 AI 还是瞎子写太多又会占满上下文。我的经验是控制在 1000 字以内只写“这个项目区别于其他项目的地方”。通用编程知识模型已经具备不需要重复教它什么是函数、什么是类它需要知道的是你们项目的特殊约定。5.2 检查点习惯把控制权留给人Superpowers 再强也不会替你做决策。我的习惯是把它给出的 Plan 当检查点AI 跑完 plan 后我不会直接说“继续”而是自己先快速读一遍涉及的文件清单确认没有改错模块。把它设计成人机协作的节奏AI 负责速度人负责方向。我见过很多团队把 AI 编程用成了“全自动代码生成器”AI 说一套跑完发现全偏了。其实流程里最便宜的纠错点就是 Plan 阶段错过这个点后面每走一步都在错误方向上加速。5.3 把项目规范写进提示词如果你想在项目里强制 lint 和类型检查那么这些命令必须出现在 CLAUDE.md 里。否则 AI 不会知道你们项目里用 pnpm 还是 npm、有没有 eslint 配置、测试框架是 Jest 还是 Vitest它只会按照自己的默认习惯执行然后在你的 CI 上炸开。Superpowers 的 test 技能确实会运行测试但跑哪个命令需要你先告诉它。我在自己项目里会把“验证命令”写得很明确pnpm lint --fix pnpm typecheck pnpm test只要这些命令进了 CLAUDE.mdAI 在 implement 之后就会主动执行验证步骤而不是给你一个“应该没问题”的空口承诺。5.4 把项目专属技能和 Superpowers 混用Superpowers 最灵活的地方是它允许你自己补充技能。比如你们项目里有一套私有脚手架经常要把新模块注册到路由表里你就可以自己写一个 SKILL.md 放进 skills 目录AI 之后遇到相关需求时会自动调用。这相当于把自己的团队经验沉淀给 AI越用越贴合。这里分享一个我自己的做法每完成一个比较复杂的任务我会把这次任务的步骤写进一个精简的 SKILL.md作为团队的“遗留技能”。几个月下来AI 对我们的项目理解明显比通用版本深生成代码的风格也更统一。6. 我实际用了一段时间后的体验与踩坑记录6.1 坑一一次性全引入结果对话被技能噪音干扰我第一次用 Superpowers 时把仓库里的所有命令、技能、子代理一股脑全装了。结果每次会话上下文被大量技能描述占满AI 反而变得有点“瞻前顾后”简单需求也走一堆流程。后来我改成按需启用只保留常用的几个命令体验立刻清爽。安装时不用追求全量关键是选贴合自己工作节奏的。6.2 坑二跳过测试可靠性打回原形有一段时间我为了求快让 AI 直接 implement 不走 test。结果它连续给我产出三处隐性问题一处在边界条件一处在类型转换一处在和旧接口的兼容。我后来意识到Superpowers 带来的可靠性提升很大程度来自 test 关卡。你可以缩短流程但这条建议最好不要省。6.3 坑三大型代码库仍然需要人工框定范围Superpowers 不是万能药。在一个百万行代码的仓库里AI 的上下文窗口依然有限如果我不提前告诉它“只需要看 a 模块和 b 模块”它会自己去猜关联范围结果往往跑偏。我的做法是在提示词开头明确定义改动范围必要时先让 AI 用/plan列出涉及文件我再做裁剪。6.4 收益最明显的几个场景用了大半年我最满意的是三类场景重构旧代码逻辑复杂AI 迁移时容易漏掉副作用。用 plan test 的组合可以大幅降低遗漏率尤其是有测试用例覆盖的场景AI 可以在重构后直接跑全量测试确认行为不变修 bug不再让 AI 直接给补丁而是先让/debug定位根因、复现条件、修复方案确认后再动手。这样修完以后AI 还能顺手补一个回归测试下次同类问题会第一时间暴露代码审查让 AI 用 review 技能从可测性、边界、性能三个角度审一遍经常能发现我自己漏掉的问题。尤其是迁移代码的时候AI 会发现“这里把常量硬编码了”“那个函数有副作用但没体现在命名上”。最后说一句我的真实体会。Superpowers 不是什么魔法说到底它是一套把软件工程常识翻译成 AI 能听懂语言的方法论。工具可以很快但可靠的代码一定来自流程。我个人最推荐的入门姿势是先装好基础命令从一个中型项目的一两个模块开始把 brainstorm、plan、test 这三个环节硬着头皮走完两轮你会明显感觉到 AI 的输出质量不一样。等习惯了这个节奏再慢慢扩展其他技能。