在很多人刚接触 AI 编程的时候衡量工具好坏的标准特别简单提示词一发代码是不是立刻就能跑起来。可一旦你真把一个业务模块交给 AI 改上几个星期你大概率会换一个标准代码是不是无论需求怎么变都不会散架。老实说我自己经历过从“生成得真快”到“改得真怕”的转变真正让体验发生质变的不是换了更强的模型而是开始使用 Superpowers。这套东西针对 AI 编程提示词和 skills 机制做了很系统的设计恰好解决的是“快而不稳”这个阶段最让人头疼的问题。最近在网上搜“superpowers 具体使用”“有哪些 skills”“怎么引入这些技能”的人不少说明很多开发者已经意识到普通的提示词不够用了只是还没找到一条能直接照做的路径。这篇文章我不打算只给概念我会把 Superpowers 的定位、设计思路、安装步骤、常用 skills 清单以及我实际改造开发流程时看到的差异都摊开讲。你可以把它当成一份能跟着操作的入门指南也可以当成一份评估清单看看这套方法论到底适不适合你的项目。1. 先讲清楚痛点AI 编程的“快”为什么会带来新的不可靠1.1 我遇到的一次典型“快翻车”现场前两个月我在维护一个内部数据看板项目功能不算复杂从接口拉数据、清洗、展示。前期我用 AI 辅助搭框架速度确实快半天不到就跑通了第一版。但后面需求一变要在看板里加一个筛选条件同时保持旧的默认视图AI 拿到我给的提示词后立刻改了数据查询逻辑结果默认视图也受影响线上报表数据乱了小半天。这类问题几乎每个用 AI 编程的人都遇到过。AI 的优势在于生成代码速度快劣势在于它并不会天然地去维护“你之前明确表示过的隐性约定”。如果每次对话都是独立的AI 对项目的记忆就只是当前会话的局部记忆当上下文轮次增多它甚至可能覆盖前面的决定。只要没有一套机制要求 AI 在执行前先“回顾上下文、识别约束、确认影响范围”它就会朝着最快路径前进而最快路径通常忽略了回归。这不是模型能力不够而是工作流缺陷。我把关键词“快”看成了生成速度而不是系统整体可靠性。在没有技能约束的情况下AI 的每次决策都会基于会话的最新状态不会自动带着类似“旧版本契约”的持久概念。如果方案上不限制行为代码库的熵会随着修改次数增加直到某次修改彻底失控。1.2 为什么“把提示词写得更长、更细”不是解药在我接触 Superpowers 之前我尝试过各种办法缓解这个问题最常见的就是把提示词写长把需求、约束、禁忌、输出格式全部塞进一段话里。短时间看是有效的因为 AI 在本次对话里确实更遵守规则。但用久了会发现三个问题提示词是一次性用品。长提示词只对它所在的那个会话起作用换个任务之后你又得重新写一遍。长提示词会挤占上下文窗口。模型需要处理的 token 变多反而更容易遗忘核心信息。提示词没有办法被精细地触发。哪怕你写了“请先做 code review”在复杂的多步骤任务里模型大概率还是会把 review 和写代码混在一起。后来我慢慢意识到真正需要的并不是“更长的提示词”而是一套可以复用的技能。所谓技能就是你把某一类任务的完整工作方式固化下来形成一个可被 AI 自动识别和执行的模块。1.3 “可靠”到底指什么在这篇文章里可靠对应三件事。第一行为可预期。同一类任务用同一套技能输出的路径基本一致不会出现这次先写测试、下次先写实现这样的随意性。第二回归更少。改 A 不坏 B这是工程里最朴素的标准。AI 编程如果做不到这点效率再高也只是在给未来埋雷。第三过程可追踪。AI 做了哪些分析、基于什么决定修改每一步都有迹可循而不是只给你一个最终 diff。Superpowers 之所以值得花时间研究正是因为它围绕这三件事提供了一套成体系的 skills 和调用机制。下面我会从设计思路、安装方式、常用技能和工作流改造这几个角度把实际使用经验一次说清楚。2. Superpowers 的核心设计把“临时提示词”升级为“可复用技能”2.1 Superpowers 到底是什么有一种说法Superpowers 本身不是一个 AI 模型也不是一句万能提示词而是一组由社区维护、专门针对 AI 编码代理设计的 skills 集合。你可以把每个 skill 想象成一本操作手册。手册里不只是告诉 AI“你要做代码审查”还会告诉它审查的关注点是什么、先看什么后看什么、发现问题之后用什么格式输出、什么情况下要停下来向人类确认。AI 一旦检测到自己正在做的事情符合某个 skill 的描述就会自动按这本手册执行。这点很关键skills 不是给人类的文档而是给 AI 的运行时指令。传统意义上的提示词是一次性写给模型看的skills 则是把某一类任务的标准动作从“对话内容”里抽出来变成项目里的持久化资产。2.2 这样设计解决了什么问题第一个问题是从零开始。以前拿到新项目我往往要花很多话告诉 AI 我们应该怎么合作先问需求、再写方案、再动手、最后自查。有了 Superpowers 之后这些约定是现成的。AI 自动匹配技能不用我再反复交代。第二个问题是记忆的持久。skills 平时就躺在项目目录里每次对话开始时它们都会被 AI 感知到或通过特定触发词唤醒。相比普通提示词它是持续存在的不会因为换了新对话而失效。第三个问题是抽象层次。一个人写提示词的时候很容易陷入过分具体的细节例如“第 37 行改成这样”。而 skill 提供的是通用方法例如“遇到不确定的第三方接口行为时先用最小用例验证再写正式实现”。这种抽象让 AI 即使换了代码库、换了语言也能用同一套方法处理问题。2.3 三大核心优势从使用者的角度看Superpowers 的价值可以归纳成三句话安装一次处处复用不用每次开新项目都重新写规则把技能库拖进去即可。按需触发不干扰日常AI 不是任何时候都加载一堆规则来影响速度而是识别到相应场景时才启用。社区迭代持续更新今天能用的技能只是起点。社区会持续补充新的领域技能比如前端、后端、规范审查、测试等。接下来我会专门讲安装和引入因为这是新手最容易卡住的地方。3. 一步步安装并引入 Superpowers从 clone 到第一次调用3.1 安装前需要确认的三件事在动手之前先搞清楚自己的环境。不同的 AI 编程客户端加载技能的机制并不完全一样盲目照搬别人的路径容易白忙一场。第一你用的是哪种客户端。是 Claude Code、Cursor、Cline还是其他命令行工具它们对技能目录的扫描规则各有各的约定。第二客户端约定的 skills 目录在哪里。常见做法是在项目根目录下放一个隐藏目录或者读用户主目录下的全局配置目录。第三你是一人开发还是团队协作。如果团队一起使用技能库最好放在项目仓库里跟着代码版本走这样大家的 AI 行为基准才一致。3.2 下载 Superpowers最简单的办法是使用 git clone 把技能集合下载到本地。官方项目一般会把所有 skills 打包在仓库里结构大致是每个技能一个子目录里面放一个说明文件和相关模板。git clone 官方仓库地址 superpowers cd superpowers ls skills我没有在这里写成具体的完整地址因为项目仓库可能会迁移最稳妥的方式是去项目主页或社区讨论帖里找当前有效地址。下载之后你会在skills目录下看到一堆以技能命名的文件夹比如brainstorm、plan、debug、code-review之类的名字具体以你拿到的版本为准。如果你不想手动 clone也可以看看项目是否提供一键安装脚本。部分版本会有一个install.sh或类似入口执行后帮你直接复制到默认目录。我个人的建议是第一次使用尽量手动复制这样你会清楚地知道每一个文件被放到了哪里后续排查问题时更有方向感。3.3 复制到正确目录以把技能放在项目里的方式为例mkdir -p .claude/skills cp -r superpowers/skills/* .claude/skills/如果你希望所有项目都能用到同一套技能可以放到用户级目录mkdir -p ~/.claude/skills cp -r superpowers/skills/* ~/.claude/skills/这里有个细节容易踩坑很多客户端要求每个技能是独立目录目录名就是技能名目录内部放主文件比如SKILL.md。我们要复制的不是某个 Markdown 文件而是整个技能目录。如果你的客户端是 Cursor路径可能不太一样比如.cursor/rules或者它支持自定义规则目录。核心逻辑不变把技能的说明文件放到客户端能扫描到的地方。3.4 验证导入结果导入完成后最有效的验证方式是开一个新会话让 AI 列出当前可用的技能。比如你可以直接问你现在加载了哪些可用的技能请分别用一句话说明它们的作用和触发条件。如果它能准确报出名字和功能说明导入成功。如果它说没有发现任何技能先检查目录结构、技能说明文件的 frontmatter 字段是否完整、路径是否在客户端扫描范围内。之后再做一次冒烟测试故意给它一个需要拆解的需求看 AI 是不是先输出计划再开始写代码。比如“帮我在这个项目里新增一个导出 Excel 的功能”。如果它按照 plan 技能的方式先问需求、列步骤说明技能已经生效如果它上来就甩代码那大概率还是没加载成功。3.5 一个关于安装范围的小建议新手只装 core 技能就行不要一开始就把所有技能全部导入。技能太多会增加 AI 的甄别成本反而降低匹配效率。我自己吃过这个亏第一天把所有技能都装进去了结果 AI 经常不知道该用哪个甚至把多个技能的操作步骤混在一起执行。后来我只保留了最常用的几个匹配准确率明显提升。4. 我实测过且觉得值得优先使用的几类 skills4.1 规划类brainstorm 和 planbrainstorm的适用场景是需求还没完全明确、只有一个大概方向的时候。它的价值不是马上给出代码而是把目标、约束、可选路径、风险全部摊开。比如你想“提升这个页面的加载速度”AI 在 brainstorm 技能下会先问你预期是从网络层优化、渲染层优化还是数据层优化可接受的改动范围是什么需不需要兼容旧浏览器plan的适用场景是需求已经明确但任务比较大需要把动作拆开。它要求 AI 先识别现有代码结构再拆任务、定义验收标准然后按步骤执行。这一条对长期项目尤其重要因为它让 AI 在动手前先拿出一个可以被你审核的清单而不是悄无声息地改掉一堆文件。4.2 执行类test 和 debugtest技能走的是测试驱动开发的路径。它要求 AI 先写测试、再写实现用测试结果反过来校准代码行为。这里我不打算展开 TDD 的争论但实操下来AI 写代码时有一组可运行的测试在旁边确实比“写完了拍脑袋说应该没问题”要稳得多。debug技能是我觉得性价比最高的一个。出现与预期不符的问题时它会引导 AI 先复现、再定位、再修复、再回归而不是上来就猜着改。我们后面讲工作流改造时会专门用场景来拆它。4.3 审查类code-review 和 refactorcode-review适合在合并代码前检查改动。它会关注逻辑正确性、边界情况、性能隐患、安全问题和可维护性并输出结构化的审查意见。以前我让 AI 审查代码得到的往往是“看起来不错”这类废话换上技能之后它能列出具体风险点和修改建议虽然不一定每一条都对但至少提供了可以继续讨论的素材。refactor则是在不改变外部行为的前提下改善代码结构。这个技能对 AI 来说有挑战因为它需要在“变化结构”和“保持行为一致”之间找到平衡。我也经常用它来做小步重构每一次改动后都要求 AI 跑一遍测试来确认没有破坏原有功能。4.4 实际使用中的优先级排序如果你是第一次尝试建议先配备这四个技能brainstorm、plan、debug、code-review。理由很简单这四个场景覆盖了项目生命周期里风险最高的环节需求发散期、任务执行前、出错排查时、代码合并前。把最常遇到的四类场景管好可靠性已经有非常明显的提升。剩下的技能完全可以等熟悉之后再逐步加入不用急。5. 如何用 Superpowers 改造真实工作流三个我常用的场景5.1 场景一新需求下来不再急着让 AI 写代码以前我拿到新需求习惯是打开对话框直接说“帮我实现一个 xx 功能”。AI 往往直接给出十几行代码我试一下发现不对再补充细节再改反复三四轮才能接近想要的效果。这个过程看起来很快实际算下来并不高效。引入 Superpowers 之后AI 识别到任务描述不够完整会自动使用brainstorm技能反过来问我几个关键问题。比如目标用户是谁现有代码中哪些函数可能跟这个新功能交叉有哪些可选方案各自的成本与风险是什么需不需要兼容旧行为第一次被 AI 追问的时候我是有点不适应的但几次之后我意识到这些正是我自己写代码前应该想清楚、却经常偷懒跳过的问题。技能把“先想后做”这个原则固化进了流程而不是指望我每次都能自律。5.2 场景二改一个跨模块功能先让 AI 产出实施计划当需求比较明确但改动会涉及多个模块时plan技能会起作用。它不会一次性改完全部文件而是先给出一个任务清单里面包含具体的步骤顺序、每个步骤涉及的文件、每个步骤的验收点。有一次我要加一个统一登录状态同步的功能改动横跨前端路由、后端鉴权中间件、前端请求封装三个部分。以前让 AI 直接改它会按顺序修改但改到第三个模块时可能已经忘了第一个模块里的约定。现在它会先生成计划每一步结束都做一次状态确认再进入下一步。这种做法的好处是中途就算发现需求有变化已经做完的步骤依然可以保留而不是推翻重来。花在“规划”上的时间会在后续执行阶段成倍赚回来。5.3 场景三线上 bug不再靠“猜”调试是最容易让人上火的环节。以前我遇到 bug第一反应是把报错信息丢给 AI让它直接给修复补丁。它往往能给出一个方案但经常是按下葫芦浮起瓢修好了这个边界又弄坏了另一个逻辑。在debug技能下AI 的工作路径变得很清晰先要求我提供能复现的步骤或最小用例然后检查日志、圈定可能出问题的模块再逐层缩小范围直到找到根因。修复之后它不会马上结束还会要求我跑回归测试确认同类问题不会在其他路径上复发最后输出一份问题总结。完整链路是这样复现问题 → 缩小范围 → 找到根因 → 修复 → 回归验证 → 输出总结。以前这一步我要在提示词里反复叮嘱现在只要触发debug技能它就会自动走这套流程。省下的不只是时间还有一种“不知道这次改完会不会又炸”的心理焦虑。5.4 这些变化的可度量价值有人会问这样改流程是不是把简单事情变复杂了我的感受正好相反。短期看第一次对话变长了AI 会问很多问题或者输出一份计划但整体计算修改轮次、返工次数、线上事故概率之后总成本其实是下降的。我给自己做过粗略统计以前一个中型功能从开始到稳定平均要对话 10 到 15 轮其中一半是在返工引入 Superpowers 之后平均控制在 6 到 8 轮返工率明显降低。数据样本不大但方向是稳定的。AI 编程的可靠性本质上是流程设计出来的。6. 使用 Superpowers 时容易踩的坑6.1 技能没有被自动触发怎么办技能没有生效是最常见的抱怨。原因多半出在三个方面技能说明里的描述字段与当前任务匹配不上导致 AI 不认为应该调用它技能目录放错了位置客户端根本没扫描到新会话开始后技能库没有刷新仍然停留在旧状态。对策分两步。第一步是手动触发直接把技能名写进提示词里比如“请用 code-review 技能审查这段代码”看它是否会按照技能内容执行。如果手动能用说明技能文件本身没问题问题出在自动匹配上你可以把描述字段写得更具体让对方知道在哪些场景下必须使用。第二步是把常用技能写进项目的启动配置比如CLAUDE.md这类说明文件里。这样一来AI 会知道这些技能的存在和触发时机等于给它补了一块显式记忆。6.2 上下文越长技能越容易走样无论有没有技能上下文都有极限。技能不是让上下文无限变大而是让你在同样的窗口内更专注。当对话轮次很多、讨论过的问题很多时AI 可能仍然会遗忘前面确认过的约定这时候再好的技能也拦不住。我的经验是主动做上下文切割把一个大型需求拆成若干小任务每个任务用对应技能单独执行AI 每完成一个阶段要求它输出“当前状态记录”包括已完成的改动、未完成的事项、需要注意的约束下一步对话开头把这份状态记录粘贴进去让新会话接着旧状态走。这样上下文是可断层的但状态是延续的。你会损失一些历史流畅度但换来的是 AI 对关键信息的专注度。6.3 误把技能当灵丹妙药技能解决的问题是“AI 工作的过程可控”不是“AI 一定不会出错”。如果你交付的需求本身就不清晰或者代码库已经烂到无法维护技能也无法凭空让代码变好。我习惯打一个比方技能像交通规则它能让你开车更安全但不能代替你决定去哪里也不能保证路上永远不会堵车。规则的意义在于降低随机风险而不是消灭风险。6.4 团队协作时的技能版本不一致如果只有你一个人本地装了自定义技能其他人没装协作时很容易出现行为不一致你提交的代码是 AI 按某套规范生成的同事改的时候 AI 又按另一套风格输出代码库里很快会长出两种风格。建议把技能目录直接提交到项目仓库里并在文档里写明版本和修改记录。团队新人拉下来项目之后AI 的行为会自动保持在同一基准线上省去大量解释成本。7. 哪些情况下其实不需要 Superpowers以及我接下来的建议7.1 不需要的场景不是所有代码任务都要上技能体系。我总结了几个其实不用强行使用的场景一次性脚本写完就跑不会迭代那让 AI 给你一段能用的代码就够了。原型验证只看可行性只要跑通就行流程再完整也是增加成本。任务极其明确且范围很小比如“把这个函数的参数校验补一下”一个简单的提示词足矣不需要引入整套流程。在这些场景里Superpowers 带来的收益撑不起它的流程成本用普通提示词反而更高效。工具是为了解决问题不是为了让自己显得专业。7.2 如何从使用技能走向沉淀自己的技能等你熟悉了官方技能你会慢慢理解一件事AI 的可靠不是天生的而是可以通过行为约束来设计的。到了这个阶段下一步就是把你项目里的隐性规则写成自己的技能。以我自己为例团队的发布流程有固定检查项接口设计有约定数据库变更有一套评审顺序。以前这些规则靠文档和人工提醒现在我把它拆成一个内部技能命名为发布检查放进团队的技能目录里。AI 每次遇到相关任务就会自动加载过程中还会主动询问我是否跳过某项比我一遍遍口头叮嘱可靠得多。自己写技能时别一开始就想做得很大。从一个你重复次数最多的流程开始比如“如何新增一个 API 接口”。把你平时会叮嘱 AI 的每一句话都变成技能内容里的步骤和检查点。试几次之后你就会发现技能库是你自己的资产项目的可靠性会随着积累而提升。用了 Superpowers 这段时间我的体会很朴素AI 编程的快是模型给的而可靠是自己设计出来的。开源社区里优秀技能的数量已经不少与其继续依赖每次都临时手写的提示词不如把好的工作流存成技能让 AI 在每一次对话里都站在同一条稳定、可预期、可追踪的路径上。这条路走通之后你会发现 AI 编程距离真正让人放心地大规模交付并没有想象中那么远。