1. 从“superpowers”这个热词说起它到底是什么最近“superpowers”这个词在技术圈和效率工具圈里被反复提起很多人第一次看到它是在某个开源项目的讨论区或者是在朋友转发的一条“效率翻倍”的分享里。简单来说superpowers 是一套面向 AI 辅助开发场景的能力扩展框架它的核心思路是把零散的提示词、工作流、工具调用规则打包成可复用、可组合的“能力模块”让 AI 在具体任务中表现得像一个有经验的老手而不是每次都要从头调教。它解决的问题很实际你不需要每次都写一大段提示词去告诉 AI 该怎么干活而是直接调用已经封装好的能力包让 AI 按既定套路输出稳定结果。我第一次接触这个概念是在一个自动化脚本项目里当时团队里有人把常用的代码审查、日志分析、接口调试这几件事做成了独立的“能力单元”每个单元有自己的触发条件、执行逻辑和输出格式。后来发现这套思路可以扩展到更多场景比如文档生成、数据清洗、甚至日常的会议纪要整理。superpowers 适合谁如果你经常用 AI 辅助写代码、做分析、处理重复性文本任务或者你是一个喜欢把工作流自动化的效率控那这套东西值得花时间研究。它不要求你懂多深的算法但需要你对任务流程有清晰的拆解能力。提示superpowers 不是一个具体的软件产品而是一种组织 AI 能力的方式。不同团队、不同项目里的实现可能长得不一样但底层逻辑是相通的。2. 为什么需要 superpowers从“每次重来”到“一次封装反复调用”2.1 传统 AI 辅助模式的三个痛点在没有 superpowers 这类框架之前大多数人用 AI 的方式是“对话式”的打开一个对话框输入一段描述等结果不满意就改描述再等结果。这种方式在简单任务上没问题但一旦任务变复杂问题就暴露了。第一个痛点是提示词重复劳动。比如你每天都要让 AI 帮你写一段格式固定的周报每次都要把“请按照以下格式输出包含本周完成事项、下周计划、风险点”这一长串话重新打一遍或者从历史记录里翻出来复制。时间久了这些重复的提示词本身就成了负担。第二个痛点是输出不稳定。同样的提示词今天问和明天问AI 给出的格式可能不一样有时候多一段解释有时候少一个字段。对于需要结构化输出的场景这种波动很让人头疼。第三个痛点是能力无法沉淀。你花了很多时间调教出一套好用的提示词组合但它只存在于你的聊天记录里换一个人、换一个项目就用不上了。团队协作时每个人都在重复造轮子。2.2 superpowers 的解决思路能力模块化superpowers 的核心思路可以用一句话概括把“怎么问”和“问什么”分开。具体来说它把每个任务拆成三个部分触发条件什么情况下该调用这个能力。比如“当用户输入包含‘审查代码’且附带了代码片段时”。执行逻辑这个能力内部具体怎么做。可能是一段固定的提示词模板也可能是一串工具调用步骤比如先读文件、再分析、最后输出报告。输出规范结果应该长什么样。是纯文本、JSON、还是 Markdown 表格字段有哪些顺序如何。这样拆开之后你只需要在触发条件里做一次判断后面的执行和输出都是标准化的。下次遇到同类任务直接命中触发条件AI 就按既定套路走不需要你重新描述。2.3 一个生活化类比从“每次现炒”到“预制菜”你可以把传统方式想象成每次做饭都要从洗菜切菜开始而 superpowers 像是把常做的几道菜做成了预制包。想吃的时候拆开一包按说明加热一下就行。预制包不是万能的复杂的新菜还是得现做但日常高频的那几道效率提升非常明显。注意superpowers 的“预制”不是死板的。好的能力模块会留出参数入口比如你可以传入不同的文件路径、不同的输出格式要求模块内部会根据参数做调整。这就像预制菜也可以选择加辣还是不加辣。3. 核心细节解析superpowers 的四个关键组件3.1 能力描述文件让 AI 知道“我会什么”每个 superpower 都需要一个描述文件通常是一个结构化的文本文件比如 YAML 或 JSON 格式。这个文件里写清楚能力的名称、用途、输入参数、输出格式。我见过最简单的描述文件只有三行名称、触发词、提示词模板。复杂一点的会包含参数校验规则、依赖的工具列表、错误处理逻辑。为什么需要这个文件因为 AI 本身不知道你封装了哪些能力。你得先告诉它“你有这些技能”它才能在合适的时机调用。这就像给一个新员工一份岗位说明书他才知道自己该干什么。3.2 触发与路由机制什么时候用哪个能力触发机制是 superpowers 里最考验设计功力的部分。太敏感了AI 会频繁调用不相关的能力干扰正常对话太迟钝了该用的时候又用不上。常见的做法是关键词匹配加语义判断双重校验。举个例子你封装了一个“代码审查”能力触发词是“审查”“检查代码”“review”。如果用户只是说“我昨天审查了一个方案”关键词命中了但语义上并不是要调用代码审查能力。这时候就需要第二层判断上下文里有没有代码片段用户是不是在请求执行某个动作只有两层都通过才真正触发。3.3 执行引擎能力内部怎么跑执行引擎负责把能力描述文件里的逻辑变成实际动作。最简单的执行就是替换提示词模板里的变量然后发给 AI 模型。复杂一点的会涉及多步操作比如读取用户指定的文件提取关键信息调用外部工具做格式转换把结果按模板组装输出最终内容每一步都可能出错所以执行引擎还需要有错误捕获和回退机制。比如文件读不到时是报错还是用默认值工具调用超时了是重试还是跳过这些细节决定了 superpowers 在实际使用中靠不靠谱。3.4 输出格式化让结果可以直接用输出格式化经常被忽视但它直接影响使用体验。如果 AI 返回的是一大段自然语言你还得手动整理成表格或代码块那自动化的价值就打折扣了。好的 superpowers 会在输出阶段做强制约束比如要求 AI 按 JSON Schema 输出或者用模板引擎渲染成固定格式。我自己的习惯是凡是需要后续程序处理的结果一律要求 JSON 输出凡是给人看的报告一律用 Markdown 表格加要点列表。这样拿到结果就能直接用不需要二次加工。4. 实操过程从零搭建一个自己的 superpower4.1 第一步选一个高频重复任务不要一上来就搞复杂的能力。先找一个你每天或每周都要做、步骤固定、输出格式也固定的任务。比如“把一段会议记录整理成待办事项列表”或者“检查一段代码有没有明显的空指针风险”。任务越具体封装起来越容易效果也越明显。我第一个封装的 superpower 是“日志关键字提取”。每天都要从几百行日志里找错误和警告手动翻很费时间。封装之后只需要把日志文件路径传进去它自动过滤出 ERROR 和 WARN 级别的行按时间排序输出一个简洁列表。整个过程从原来的十分钟缩短到十秒。4.2 第二步写清楚能力描述文件以“日志关键字提取”为例描述文件大概长这样name: log-keyword-extractor description: 从日志文件中提取错误和警告信息 trigger: keywords: [日志, log, 错误, 警告] context: 用户提供了文件路径或粘贴了日志内容 input: - name: source type: string description: 日志文件路径或日志文本 - name: levels type: array default: [ERROR, WARN] description: 要提取的日志级别 output: format: markdown_table columns: [时间, 级别, 内容]这个文件里触发条件、输入参数、输出格式都写清楚了。AI 读到这个描述就知道什么时候该调用它以及调用时该怎么处理。4.3 第三步设计执行逻辑执行逻辑可以写在描述文件里也可以单独放在一个脚本里。我倾向于把复杂逻辑放在外部脚本描述文件只做声明。这样修改逻辑时不用动描述文件职责更清晰。日志提取的执行逻辑大概是判断 source 是文件路径还是文本内容如果是文件路径读取文件如果是文本直接使用按行分割过滤出包含指定级别的行解析每行的时间戳和内容按时间排序渲染成 Markdown 表格每一步都有对应的代码整体不超过五十行。关键是错误处理文件不存在怎么办日志格式不标准怎么办这些都要在脚本里考虑到。4.4 第四步测试与调优封装完成后不要直接投入日常使用。先拿几组真实数据测试看看触发是否准确、输出是否符合预期。我通常会准备三类测试数据标准格式的、格式略有偏差的、完全不符合格式的。观察 superpower 在这三种情况下的表现。调优的重点通常是触发条件。如果发现误触发太多就收紧关键词如果发现该触发的时候没触发就放宽条件或者增加同义词。这个过程可能需要反复几次但一旦调好后面就很省心了。实操心得触发条件里加一个“否定词”列表很有用。比如“不要在我只是讨论日志格式的时候触发提取能力”把“格式”“规范”“讨论”这些词加入否定列表能减少很多误触发。5. 常见问题与排查技巧实录5.1 触发不灵敏该调用的时候没反应这是最常见的问题。原因通常有三个关键词覆盖不够、上下文判断太严格、能力描述文件没被正确加载。排查顺序建议从简到繁。先检查描述文件是否在正确的目录下很多框架要求文件放在特定文件夹里才会被扫描到。然后检查关键词列表是不是用户用了同义词但你没收录。最后看上下文判断逻辑是不是条件写得太死比如要求必须同时出现三个词才触发。我遇到过一次用户说“帮我看看这段代码”但我的能力触发词里只有“审查”和“检查”没有“看看”。加上“看看”“瞅瞅”“过一下”这些口语化表达后触发率明显提升。5.2 输出格式错乱结果不是想要的样式输出格式问题通常出在模板渲染阶段。可能是模板里的变量名和实际数据字段对不上也可能是 AI 在生成时没有严格遵守格式要求。解决办法有两个方向。一是加强输出约束在提示词里明确写“只输出 JSON不要任何额外解释”并且给出一个示例。二是加一层后处理拿到 AI 的输出后用程序做格式校验和修正。我一般两个都用提示词约束做第一道防线后处理做兜底。5.3 执行超时或卡死能力跑了一半没动静如果能力内部涉及外部工具调用或文件读写超时是常见问题。排查时先看日志确认卡在哪一步。如果是文件读写检查路径权限如果是网络请求检查目标服务是否可达。预防措施是在执行逻辑里加超时设置。比如读取文件最多等 5 秒调用外部工具最多等 30 秒。超时后要么返回部分结果要么给出明确的错误提示不要让用户干等。5.4 常见问题速查表问题现象可能原因排查动作解决方向该触发时不触发关键词不全或上下文过严检查描述文件关键词列表补充同义词放宽上下文条件不该触发时乱触发关键词太宽泛查看触发日志增加否定词提高语义判断阈值输出格式不对模板变量不匹配对比模板和实际数据字段修正模板增加后处理校验执行卡住外部依赖超时查看执行日志定位卡点加超时设置增加错误回退结果不稳定提示词约束不够多次运行对比输出强化格式要求提供输出示例避坑技巧每次修改能力描述文件后一定要重新加载或重启服务。很多框架不会自动热更新改了文件不生效白白浪费排查时间。6. 进阶玩法把多个 superpowers 串成工作流单个 superpower 解决的是单点问题真正威力大的是把多个能力串起来。比如一个完整的“代码提交前检查”工作流可以包含代码风格检查、单元测试运行、变更影响分析、提交信息生成。每个环节都是一个独立的 superpower串在一起就成了一条自动化流水线。串联的关键是定义好能力之间的输入输出契约。前一个能力的输出格式必须能直接作为后一个能力的输入。如果格式不匹配就需要加一个转换步骤。我通常会在工作流层面做一个“适配器”负责把上游输出转换成下游能接受的格式。另一个进阶方向是让 superpowers 具备学习能力。比如记录每次调用的结果和用户反馈定期分析哪些触发条件容易误判哪些输出格式用户经常手动修改。根据这些数据自动调整能力描述文件里的参数。这个做起来复杂一些但效果很显著。7. 我踩过的坑和最后分享几个小技巧第一个坑是贪多。一开始就想封装十几个能力结果每个都做得不精触发混乱输出也不稳定。后来砍到三个最常用的反复打磨反而整体效率提升更明显。少即是多这句话在 superpowers 上特别适用。第二个坑是忽视版本管理。能力描述文件改来改去有时候改坏了想回退发现没有历史记录。后来我把所有描述文件纳入版本控制每次修改都写清楚改了什么、为什么改。这样出问题能快速定位也能看到能力的演进过程。第三个坑是输出格式过于复杂。一开始追求大而全的表格列了十几列结果 AI 经常漏字段后处理也麻烦。后来改成只保留最核心的三到五列需要更多信息时再单独查询。输出越简洁稳定性越高。最后分享一个小技巧给每个 superpower 加一个“调试模式”。开启后它会输出触发判断的详细过程、每一步的执行耗时、以及原始输出内容。平时关着不影响性能出问题时打开排查效率翻倍。这个功能我是在第三次重构时才加上的后悔没早点做。另外如果你在团队里推广 superpowers建议先从一个人用起来跑顺了再分享给其他人。一上来就搞全员推广大家遇到问题都来找你反而容易卡住。等你的能力包足够稳定别人看到效果自然会来问那时候再分享接受度高很多。