很多人在刚接触 AI 辅助工作的时候都会陷入一个困惑同一个模型有时候回答得漂漂亮亮有时候却像突然失忆一样答非所问。问题往往不在模型本身而在于我们喂给它的“协作方式”太粗暴。superpowers 这个项目本质上就是解决这个问题的——它把零散、临时的提示词整理成一套可复用、可组合、有章法的“技能包”skills让 AI 真正变成带说明书的高级工具。这篇文章我会从项目机制拆到环境安装、技能引入、实战场景和排错经验把整个闭环讲清楚。适合那些已经玩过 ChatGPT、Claude 或类似工具但觉得输出不稳定、想系统化落地 AI 工作流的人。1. 项目机制拆解superpowers 的设计哲学与本质1.1 它到底解决了什么问题先说一个很容易被忽略的事实绝大多数人和 AI 协作靠的是“一次性提示词”。想到什么问什么问完就扔下次重新组织语言。这个模式有两个致命弱点。第一每次都要重新解释背景和目标浪费大量上下文窗口第二输出质量完全取决于你当时的措辞状态同样一个需求换个问法结果可能差十万八千里。superpowers 的思路不一样。它把“如何正确使用 AI”这件事本身做成了一套标准化流程。每个技能skill都是一份精心编写的 Markdown 文件里面写清楚了这个技能在什么场景下触发、需要哪些输入信息、按什么步骤执行、最终输出什么结构、有哪些自检清单。AI 读到这份文件就不再是“猜你想要什么”而是“按既定流程办事”。说白了它不是在增强模型而是在增强“人跟模型之间的接口”。用生活化类比就是同一个人你给他一张清晰的任务工单和你说“随便弄一下”他交付出来的东西完全是两个水准。superpowers 就是那份任务工单的生成器。1.2 skills 体系的结构与分类打开项目仓库你会发现它的核心资产不是代码而是大量结构化的文档目录。每个 skill 通常遵循一个稳定的内部模板我拆开看的话大致包含四层元信息层技能名称、适用场景、触发条件、预期效果。输入定义层需要用户提供哪些材料或参数哪些是必填项哪些是可选项。执行流程层从理解需求到拆解任务、再到分步产出的完整操作步骤。质量标准层交付前要核对哪些点常见错误怎么规避如何自我检查。这个结构本身就是一个特别好的写作范式。哪怕你完全不用这个项目单学这套“怎么写 AI 技能说明”的方法就已经值回票价。因为你会发现当你把任务定义、执行步骤、验收标准都写清楚的时候AI 的稳定性和专业度会直线上升。按使用目的来分社区和官方整理出的技能大体覆盖三大类。一类是内容生产类比如写文章、做摘要、润色翻译一类是工程执行类比如拆需求、写代码、设计测试方案还有一类是分析决策类比如风险排查、竞品拆解、优劣势评估。每一类下面又有细分的变体实操中你可以根据项目需求组合调用。1.3 为什么采用“技能包”而非“一次性提示词”这个问题我琢磨了很久。最核心的答案是可复用性和可迭代性。一次性提示词用一次就没了写得好不好完全靠当时的状态也很难沉淀。但技能包是文件它可以被反复调用、持续修订。你今天发现某个技能输出结构有问题直接改那个 Markdown 文件下次调用就生效了这本质上是把“调教 AI 的经验”变成了可积累的资产。另外技能包之间还能组合。比如你有一个“文档拆解技能”又有一个“写摘要技能”那你完全可以让 AI 先调用前者把材料拆开再调用后者逐块产出摘要。一个个技能就像积木搭出复杂的工作流。这是单个提示词做不到的——它既难维护也难拼接。所以我理解 superpowers 的底层逻辑不是提供“更聪明的咒语”而是提供一套“让 AI 稳定发挥的工程规范”。它把不可控的对话变成可控的流程把个人经验变成团队资产。2. 环境准备与安装实操2.1 安装前需要准备什么在动手装之前先盘一下你的基础环境。这个项目本身不挑操作系统Windows、macOS、Linux 都能跑因为它本质上是“复制文件 告诉 AI 去哪里读”。你需要准备的东西很简单一个支持自定义指令或技能机制的 AI 工具。主流的几款都能用关键看它能不能读取你指定的外部文档作为参考。一个能拉取仓库的命令行环境或者干脆直接在网页端下载压缩包。后者对新手更友好。基本的文件管理能力至少要能看懂目录结构知道把文件放到哪个文件夹。我见过不少人卡在安装第一步其实是卡在“不知道该把技能文件放在哪”。这个跟具体工具有关但思路是一致的找到 AI 工具读取用户配置的目录把它当作你的技能根目录。有的工具叫 skills 文件夹有的叫 instructions 文件夹本质上都是同一回事。2.2 完整安装步骤整个安装过程用一条龙形容也不夸张。下面是我实测顺手的步骤拿到项目仓库地址用 git clone 拉一份到本地或者直接在网页下载 zip 包解压。打开解压后的目录找到 skills 文件夹。这个文件夹里面每一个子目录就是一个独立技能。确认你的 AI 工具支持自定义技能目录。如果支持把 skills 文件夹路径填到工具的配置项里如果不支持目录引用就把你需要的技能文件内容以文本方式放到工具的自定义指令区。保存配置重新打开一个对话窗口让新配置生效。这里有一个特别容易踩的坑很多工具不会自动扫描新增的技能文件你必须重启会话甚至完全退出重进它才会重新加载配置。如果你发现技能不生效第一反应不应该是怀疑技能文件写错了而是检查会话到底刷新了没有。2.3 装完后第一时间要做的验证安装完之后别急着做大事先跑一个小任务验证链路通不通。我的建议是找个输入输出都很明确的技能比如“文章摘要生成”随便给一小段文字让它按技能的格式产出。验证的时候重点看三个维度。第一它有没有用上你指定的技能说明里的术语和步骤第二输出结构是不是按技能模板来的比如该有“摘要/要点/行动项”有没有齐全第三它的执行过程是不是更像“按程序办事”而不是自由发挥。如果三个维度都符合说明技能链路已经通了后面就可以放心组合使用了。如果不符合大概率是配置路径没指对或者会话没刷新回上一步排查。3. skills 的引入与管理3.1 有哪些值得先装的 skills很多人上来就想把仓库里所有技能一口气装上我的建议恰恰相反先装三五个高频场景的就够。按照社区讨论度和我自己实测的体感下面这几个是值得优先试水的深度文档拆解技能给一份长文档它能把内容拆成背景、核心观点、关键论据、可执行项和遗留问题。项目规划技能把模糊的想法变成有里程碑、有依赖关系、有风险提示的项目计划。代码审查技能给一段代码它按正确性、可读性、性能、安全性几个维度输出审查意见。需求澄清技能在任务开始之前主动追问缺失信息把模糊需求拧成明确规格。理由很简单。这些技能覆盖了最日常、最容易出效果的场景而且产出格式都特别清晰一眼就能看出有没有生效。等用顺手了再根据自己在做的事往里面加更垂直的技能。3.2 引入技能到指定 AI 工具的三种方式引入方式不是只有一种不同工具支持的机制不一样我整理了三种最常见的第一种是“目录引用”。这种最干净AI 工具本身支持读取某个文件夹下的所有 Markdown 文件你只要把技能文件放进去它就能在需要时找到。适合技能数量多的用户。第二种是“文本注入”。把技能文件里的内容直接复制到工具的自定义指令或系统提示词里。适合工具不支持目录扫描的情况但这种方式有长度限制技能多的时候会把指令区撑爆。第三种是“按需粘贴”。平时不配置等真正用到某个技能的时候再把对应的技能文件内容手动贴到对话里。灵活度最高但每次都要操作适合偶尔用一两次的技能。很多工具其实支持多种方式共存。我的实践经验是高频技能用目录引用或文本注入常驻低频技能按需粘贴这样既稳定又省上下文空间。3.3 skill 目录的管理建议技能多了以后管理就成了新问题。我吃了不少乱放文件的亏总结下来有三条建议。第一目录命名要带场景前缀。比如 doc-summary、code-review、project-plan 这种不要叫 aaa、test 之类的临时名字。因为技能目录名会直接影响 AI 的检索效率命名越语义化它越容易在需要时找到对应的技能。第二技能内容要写“触发条件”。每个技能文件开头最好明确写上一句仅当用户要求做 XX 任务时才使用本技能。没有这句话AI 可能会在无关场景下强行套用反而拖垮输出质量。第三定期做减法。我发现很多技能装的时候觉得有用实际一次都没用过。这种占着上下文空间的鸡肋技能该删就删别心疼。技能的价值在于精不在于多。4. 核心场景实战让 superpowers 真正跑起来4.1 场景一用 skill 做深度文档拆解我说一个我最常用的场景把一篇三四千字的技术方案丢给 AI让它做深度拆解。没装技能之前我可能会说“帮我总结一下这篇文章”然后得到一堆泛泛而谈的要点看了等于没看。引入文档拆解技能后整个流程变成了这样我先调用“需求澄清”细节告诉 AI 这篇文章的使用场景是什么、读者是谁、我最终要产出什么。它会把缺失信息问清楚然后才进入拆解环节。拆解输出不是简单的“第一点第二点”而是沿着技术方案的骨架走要解决什么问题、核心设计思路是什么、技术选型的理由是什么、风险和副作用有哪些、下一步实施建议是什么。每个部分都有原文依据看着就踏实很多。这里的关键是不要跳步。很多人装完技能就急着只用最后的输出但真正提升质量的是前面那几步——先澄清需求再分步执行。跳过澄清就等于把技能当普通提示词用效果打折一大半。4.2 场景二把“写代码”变成“定义任务 引用技能”还有一个我特别喜欢的玩法是让 AI 写代码。以前我直接说“帮我写个脚本处理日志”它给的代码经常是能跑但很“飘”缺少错误处理和边界判断。后来我换成技能驱动的模式。先引用“需求澄清”技能把输入输出、异常情况、性能要求全部敲定再引用“代码生成”技能让 AI 按照“理解需求→设计模块→分步实现→自测清单”的流程走。出来的代码明显结构完整还带着自测建议比自己瞎调提示词稳定得多。我后来复盘原因其实很简单。直接要代码的时候AI 的目标是“尽快给一段看起来像样的代码”。加了技能流程之后它的目标是“按工程规范产出一段可交付的代码”。目标不同路径完全不同。当然写代码这件事AI 给的结果永远不要直接上线。至少人工过一遍逻辑理解它为什么这么写再决定是否采纳。技能只是让输出更规范它代替不了人的判断。4.3 场景三打造个人知识库工作流这个场景是后面扩展出来的。我每周会收集不少文章、报告和零散的笔记以前都堆在收藏夹里吃灰。引入超级技能体系后我给自己搭了一个简单的知识处理流水线。每周把收集的材料丢给 AI调用文档拆解技能做结构化提炼然后再调用一个自制的“知识卡片”技能把提炼结果转成统一的格式包括主题、核心观点、适用场景、关联话题。最后我只需要把这些卡片归档到自己的笔记工具里。这套流程跑顺之后最大的改变不是“整理得更快”而是“积累的东西真的能复用”。每张知识卡片都是可检索的写项目方案的时候直接翻卡片找关联观点比从头搜索效率高太多了。4.4 组合技能的进阶玩法单个技能用熟之后可以开始玩组合。我常用的一个组合是“需求澄清 方案拆解 行动清单”。先让 AI 把模糊需求澄清成明确规格再做方案拆解梳理几条路径最后输出可落地的行动清单。三个技能各管一段衔接起来就是一整套从想法到执行的流程。组合的时候要注意一个坑技能之间最好有清晰的输入输出边界。比如“需求澄清”的输出要能直接作为“方案拆解”的输入。如果两个技能定义的输出结构互相冲突AI 会无所适从。解决办法是定义技能时预留“输出可作为 XX 技能输入”的字段让技能之间天然衔接。另一个进阶技巧是“自带示例”。给技能文件里加上一个输入输出示例AI 在理解技能时会更精准尤其是复杂流程类技能效果立竿见影。5. 常见问题与排查技巧实录5.1 技能不生效的三种典型原因用了一段时间之后我发现所有“技能不生效”的问题基本可以归到三类。照着排查能解决九成情况。第一类路径配置不对。技能文件没放在工具会扫描的目录里或者你改了文件名但没改引用路径。这类问题最隐蔽因为工具一般不会报错只是默默忽略。第二类元信息缺失或写错。技能文件里没有注明触发条件或者 YAML 头格式错了AI 拿不准这个技能是干嘛的干脆不调用。我遇到过好几次辛辛苦苦写的技能就是因为头部字段拼写错误一直没被触发。第三类上下文被截断。技能文件太大或者一次加载了太多技能导致真正执行时技能内容已经被上下文窗口截掉一半。这种情况表现为“技能好像生效了但输出细节完全不对”。排查的顺序我建议是先看会话有没有刷新再看配置路径对不对再看技能文件头部格式最后看技能文件大小和加载数量。按这个顺序查基本不会漏掉问题。5.2 与工具版本、模型兼容性的坑同一个技能文件在不同的工具和模型上表现可能完全不一样。我实测下来指令遵循能力强的模型对技能的还原度更高能力弱一些的模型可能会把技能里的步骤当成“参考建议”而不是“必须执行的流程”。遇到这种情况两个解决办法。第一把技能文件里的命令式语句写得更明确比如“必须按以下步骤执行”比“可以按以下步骤执行”要好用得多。第二减少一次加载的技能数量让模型集中注意力执行核心的那一个。另外要注意很多工具会自动更新而更新之后技能目录的读取规则可能变之前好好的技能会突然失效。这种时候不用慌回退配置或者去工具更新日志里看有没有改动相关文档格式的说明通常都能找到答案。5.3 新手最容易犯的 5 个错误我列一个速查清单都是新手期比较容易翻车的地方不看使用说明直接复制仓库里全部技能文件导致上下文爆炸。技能文件和普通笔记混在一起工具没法区分哪些是技能。装完技能不重启会话问了半天没效果以为是项目坏了。技能里不写触发条件AI 什么任务都尝试套用技能输出反而更差。拿一个技能当万能钥匙不做场景拆解和技能组合期望过高然后失望。这五个错误我全部犯过不止一遍。每踩一个坑都让我更理解这个项目设计的本质——它不是放一堆咒语让你念而是逼着你把任务想清楚、把流程写清楚、把验证做清楚。所以遇到问题别急着怀疑工具先回头检查自己是不是又绕过了哪一步。5.4 排查思路速查表症状可能原因快速验证方法解决办法技能完全不生效路径配置错误 / 会话未刷新开新会话输入触发句测试检查技能目录路径重启会话技能被部分忽略文件太长被截断降低技能体积或数量精简内容一次只加载核心技能输出格式不对元信息错误 / 触发条件模糊检查文件头字段修正 YAML 头写明触发场景技能时好时坏模型版本更新 / 上下文漂移用最短输入反复测试固定版本减少变量用技能组合技能互相干扰触发条件重叠看哪些技能同时加载给技能加使用边界拆分职责我个人经验是把这张表贴在一个随时能看到的地方。等你排查过两三轮基本就能看懂整个项目在工具里是怎么工作的了。6. 从使用到自建把 superpowers 变成自己的东西6.1 什么时候开始写自己的技能很多人用了别人的技能包之后会冒出同一个念头我也要写自己的技能。这个想法非常好但时机要注意。如果你的日常工作场景里还没有反复出现“同一个流程要用很多次”的情况那先别急着写写了也是鸡肋。什么时候开始当你在某个任务上第三次手工重复同样的操作步骤时就是写技能的最好时机。把每次操作的模式提炼出来补齐“输入是什么、步骤是什么、输出是什么”一个技能就诞生了。另外写技能不用从零开始。拿一个现有的技能文件当模板改掉里面场景化、个人化的部分替换成自己的流程比自己空想快得多。这也是为什么项目里那些结构清晰的技能特别有参考价值——它们本身就是最好的模板。6.2 用 markdown 写一个最小可用的技能掌握了模板之后写一个最小可用技能非常简单。你只需要一个 Markdown 文件里面按固定结构写清楚四个部分第一技能名称和触发条件。让人一眼就知道什么时候该用。第二输入要求。列出完成任务所需的信息。第三执行步骤。按顺序写清楚该做什么。第四输出格式。说明最终结果要长什么样。啊具体而言你可以这样写技能名称日志错误分析触发条件当用户要求分析日志内容或排查程序报错时使用本技能。输入要求程序日志全文运行环境和最近变更信息。执行步骤先识别错误级别和关键词再按时间线归因最后列出根因概率排序和验证方案。输出格式错误摘要、重点问题清单、根因假设、验证步骤。写完之后放到技能目录里开个新会话测试一遍根据效果再迭代。一个技能能稳定跑通三回就算合格了。写技能的过程很上瘾因为它让你把隐性经验显性化了。以前你脑袋里知道该怎么做但说不清楚写完技能之后你不仅说清楚了还能让 AI 替你做那种感觉非常爽。这也是我最后想特别强调的一点这个项目的终局不是用完别人的技能而是让你成为技能的创作者把你的独特经验封装成可复制、可累积的资产。