尧图网站建设 
1. superpowers到底解决了什么问题AI会写代码但不会干活说实话我最初注意到superpowers的时候第一反应是又一个提示词合集这类东西我见多了把几条花哨的prompt塞进一个仓库包装成AI提效神器实际用起来跟直接问模型没多大差别。但真正上手用了一周之后我得承认自己判断错了——它解决的并不是提示词不够好的问题而是模型不知道什么叫把事情做完的问题。1.1 从能回答问题到能执行任务的那道坎用过各类代码助手的同学应该都有感触你让AI帮我优化一下这个函数它能给你写得漂漂亮亮但如果你让它把这个模块的重构做了包括拆文件、补测试、更新调用方、跑一遍全量检查它很容易做到一半就停住或者漏掉某个步骤假装自己已经做完了。这不是模型笨而是任务本身超出了一次问答的粒度。模型擅长的是在你给出明确指令后生成一个看上去合理的回答但真实工程里的任务是一连串有依赖关系的动作先分析现状再定方案然后动手接着验证最后回归。这些动作之间有顺序、有校验点、有验收标准。普通聊天式交互给不了模型这套操作框架所以它只能凭感觉临场发挥。superpowers做的事情就是把临场发挥变成按流程执行。它不会替模型思考也不会提升模型的代码能力但它会给模型一套可复用的技能包每个技能对应一类经典任务里面写着任务怎么拆解、先做什么后做什么、做到什么程度算完成、输出什么格式的交付物。模型拿到技能之后整个人的工作方式会从答一题算一题变成按SOP走一遍流程。听起来不玄乎但这正是工程场景里最需要的稳定性。1.2 技能不是提示词它是一套带验收标准的工作流很多人有个误解觉得superpowers里的skills就是更长的提示词。我第一次翻开源码之前也是这么想的打开之后才发现每个技能本质上是一个结构化的Markdown文档里面包含几个关键部分前置条件这个技能适合在什么场景下用以及使用前必须确认哪些信息。比如做系统化调试之前先要复现问题、收集错误日志否则后面全是瞎猜。执行步骤一套有顺序的、带明确意图的操作流程每一步都告诉模型这一步的目标是什么。验收标准做完之后怎么判断结果是对的。这比请确保代码质量这种空话有用得多。输出模板最终交付物长什么样比如一份带时间线的问题分析报告、一张依赖关系图、一段提交信息。你可以把技能理解成岗位SOP它是一个可复用的、带质量门槛的流程而不是一次性聊天记录。提示词用完就没了技能却可以反复调用、甚至可以像写代码一样被维护和更新。这也是我后来愿意把项目工作流往superpowers上迁的核心原因——它把个人经验变成了团队资产。2. 安装之前必须想清楚的事这玩意儿不是插件商店里的普通扩展我见过不少人在安装阶段就翻车不是因为命令复杂而是因为他们没有理解superpowers的运行模型。它不是一个独立软件也不是某个IDE的插件它是一套技能框架 CLI工具 技能仓库的组合。安装之前你先想清楚三件事你的环境里有没有Node和Git你用的是哪个AI编程助手以及你准备把技能放在哪个层级来管理。2.1 环境自查node、git、shell一个都不能少superpowers的CLI是一个Node包所以第一件事就是确认你本机的Node版本。我自己的经验是用nvm管理Node常年保持在18以上如果你还在用Node 14建议先升级不然装完很容易在解析依赖时报错。其次是Git因为技能的安装和更新本质上是把远程仓库里的技能文件拉到本地Git版本太低或者没有配置SSH Key拉取的时候会卡在认证环节。Windows用户建议用Git Bash或者PowerShell 7别用老版本的cmd很多路径处理和权限问题会让你怀疑人生。然后是shell环境。macOS默认zsh没问题Linux用户如果是bash也没问题但如果你装了fish这种特殊shell注意看一下CLI的输出会不会有兼容问题。我自己在fish里遇到过路径变量没生效的情况最后是切回bash跑命令才正常。2.2 安装命令与最小化验证环境确认没问题之后安装其实就一步npx superpowerslatest install这条命令会在你的用户目录下创建一个技能根目录比如~/.superpowers/同时把CLI命令注册到全局。装完之后我建议你不要急着往项目里塞技能先做最小化验证superpowers doctor superpowers list第一条命令检查你的运行环境是否满足所有前提包括Node版本、Git可用性、技能目录权限。第二条命令列出当前已经装好的技能。如果你看到的是一个空列表或者只包含几个内置技能说明安装成功可以开始往里加东西了。这里要提醒一句如果你之前装过别的AI技能管理工具先去检查~/.superpowers/skills里有没有残留目录。不同框架的技能目录结构不一样混着用可能会出现技能识别不出来的奇怪问题。我的做法是全新环境里先清空再装省得后面排查半天。2.3 装完后先搞明白技能目录长什么样很多人装完就急着用结果出了问题不知道怎么排查。我建议你至少花五分钟看一下目录结构。默认情况下技能存放在两个层级用户级目录~/.superpowers/skills/所有项目都能调用的全局技能。项目级目录.superpowers/skills/只对当前项目生效的本项目技能。一个技能就是一个子目录目录里必须有SKILL.md文件。比如~/.superpowers/skills/ ├── brainstorming/ │ └── SKILL.md ├── planning/ │ └── SKILL.md └── systematic-debugging/ └── SKILL.md这个结构意味着技能的本质是可读的文件你可以直接打开看它的完整内容也可以自己改。这跟黑盒插件完全是两码事。我后来自定义技能的时候就是先把系统自带技能读了一遍模仿它的写法两天就上手了。3. 核心技能清单这些skills分别干什么什么时候该用装好之后你大概率会对着技能列表发呆这么多skills到底哪些该用哪些是噱头我按照实际使用频率和价值把superpowers里比较核心的技能整理成了一张表你先有个全局认识后面再谈具体怎么用。技能名称典型触发场景核心产出brainstorming需求模糊、方案不明确、需要探索多种可能一份列出多个候选方案的对比分析planning需求已明确需要拆解成可执行的任务序列带任务依赖关系和验收标准的计划书spec-driven-development开始写代码前需要先定义行为可验收的规格说明再进入编码red-green-refactor用TDD流程写新功能先写失败测试再让实现通过最后重构systematic-debugging面对难以复现或原因不明的bug一份记录假设、验证、结论的排查报告code-review提交代码前或审查他人代码按严重程度分级的审查意见清单refactoring需要改善既有代码结构但不改变行为逐步重构的方案和每一步的验证方式dependency-analysis升级依赖前想搞清楚影响范围依赖关系、版本差异、风险点对比security-audit上线前想快速过一遍安全隐患按风险等级列出的安全问题列表documentation代码写完要补文档或README带示例和边界说明的文档草稿3.1 规划与执行类把想法变成可追踪的任务我最常用的两个技能是brainstorming和planning。听起来有点虚但它们解决的是AI一开始就闷头写代码这个老大难问题。以前我让AI实现一个功能它经常直接甩给我一堆代码里面可能方案选错了、边界情况没考虑整得我review的时候血压飙升。用了brainstorming之后AI会先强迫自己不写代码而是只列方案这个需求有哪几种实现路径每种路径的优缺点是什么成本如何风险在哪然后我从中选一条它才会继续往下走。planning则是把选定的方案拆成任务列表每个任务都标注了依赖关系和验收标准。这一步特别有用因为它让AI在执行过程中有了检查点——做完这一步先对照验收标准自查通过了再进下一步。这让它在多步任务里的完成率明显提升不会再出现做到一半跑题的情况。3.2 质量与调试类让代码出错时不再瞎猜systematic-debugging是我第二佩服的技能。以前遇到难缠的bugAI经常直接给一个可能是XX导致的猜测然后扔一段改好的代码让你试试完不行再猜下一轮。这种情况不仅浪费时间还会让你对AI的判断力失去信任。这个技能会强制AI走正规排查流程先复现问题再收集现场信息然后列出所有可能原因按可能性排序接着设计一个能验证某个原因的实验跑完之后根据结果排除或确认再进入下一轮。你会发现它的输出从我觉得是内存泄漏变成了根据堆内存曲线和GC日志我可以确认不是泄漏因为……下一步我来验证线程池配置这种有依据的推理链条。用这个技能做过两次线上问题排查之后我就回不去那种瞎猜模式了。red-green-refactor则适合TDD场景。如果你想让AI先写测试再写实现这个技能会给它一套节奏先写一个会失败的测试跑一遍确认失败原因是功能缺失而非测试写错然后写最小实现让测试变绿最后再做重构。每次步骤切换还要解释自己在做什么。这套节奏对工程质量提升立竿见影缺点是比较费token适合核心逻辑不适合简单CRUD。3.3 维护与交付类文档、审查、重构一条龙code-review是我团队现在每次合并请求之前的必选项。它的价值不在于AI审得比人好而在于它逼着AI按固定维度过一遍代码安全性、可读性、性能、边界条件、测试覆盖、命名一致性。人类reviewer经常会漏掉某些维度但技能不会。它产出的审查意见还会按严重程度分级我只需要先看Critical和High的部分。documentation这个技能我原来觉得鸡肋后来发现真香。你让它给一个模块写文档它会先问清楚读者是谁、使用场景是什么、有没有示例可以参考然后产出一份带目录结构、边界说明、示例代码的文档草稿。它不是从零瞎编而是先从代码里提取接口和用法再组织成文所以准确性比让模型自由发挥高很多。3.4 怎么选先给你的工作流做体检看到这里你可能会想这么多技能是不是全装上都用我的建议是别。技能选用的原则只有一个看你的日常流程里哪一步最容易出问题。你review代码时总发现低级错误那就只装code-review。你写功能时经常需求不清就动手那就只装brainstorming和planning。你被难缠bug折磨得死去活来那就先装systematic-debugging其他以后再说。把技能当成工具不要当成收藏品。装一堆用不上的技能不仅浪费目录空间还会增加AI在上下文里挑选技能的负担下一节我会专门讲这个。4. 引入技能的正确姿势从会装到会调度安装技能只是第一步真正影响效果的是你以什么方式把技能引入到工作流里。我见过很多人把技能装上之后发现AI完全没按照技能执行然后就开始骂框架不行。其实问题多半出在引入方式上。4.1 三种引入方式全局、项目级、会话级第一种是全局引入就是把技能装到用户级目录所有项目都能用。适合那些跟具体业务无关、属于通用工作方式的技能比如brainstorming、planning、systematic-debugging。这样你在任何项目里都能让AI用调试技能排查问题它都能识别到。第二种是项目级引入就是把技能装到项目的.superpowers/skills/目录下。适合那些跟项目强相关的流程比如这个项目的发布检查清单、这个项目的数据迁移操作手册。项目级技能可以由团队通过Git共享每个人clone仓库之后技能自然就位非常适合作团队的过程资产。第三种是会话级引入严格来说不算安装而是在当前对话里通过提示词显式指定。比如你直接告诉AI使用systematic-debugging技能来处理这个问题即使该技能没装到全局AI也可能根据提示策略临时套用。这种方式灵活但对模型本身理解能力要求高稳定性不如前两种。我的经验是通用技能装全局项目流程技能装项目级临时需求在会话里指定。三个层级各司其职尽量不要混。4.2 让AI自己挑技能 vs 手动指定技能这是新手最容易困惑的地方。superpowers的机制是AI读取了技能目录之后会在遇到任务时自动判断应该用哪个技能。这个自动选择看起来方便但我实测下来它并不是完美的。在任务边界特别清晰的情况下比如帮我把这个报错修一下AI通常能自动选中systematic-debugging效果不错。但在任务比较综合、涉及多步骤的时候AI有可能会选错或者在一个任务里频繁切换多个技能导致上下文里充满无关内容。所以我的习惯是重要任务我手动指定技能。比如我会说先使用 brainstorming 技能把这个需求的三种实现方案列出来 再用 planning 技能把选定方案拆成任务清单。这么做的原因很简单自动选择依赖模型对技能描述的语义理解模型越强理解越准但与其赌模型的理解力不如在关键节点上把流程定死。技能的作用是降低不确定性如果选择技能这一步本身就是不确定的那整个链路的质量就打了折扣。4.3 写一个自己的技能从重复劳动到一次性解决用熟了之后你一定会遇到系统自带技能不够用的时刻。这时候就该自己写技能了。其实写技能没那么神秘我建议先从记录重复劳动开始。回想一下你最近一个月哪类事情你重复做了三遍以上比如把一段Python脚本改造成FastAPI接口、给新服务写一套标准的日志和监控配置、每次发布前按固定清单核对配置。这些流程完全可以固化成技能。一个技能目录长这样.my-team/skills/standard-api-setup/ ├── SKILL.md └── examples/ └── example-output.mdSKILL.md的开头是YAML格式的元信息里面定义了技能名称和描述正文则用清晰的标题把步骤列出来。我写第一个技能时参考了系统自带技能的写法保持一个原则每一步都要有操作意图和验收标准。不要写优化代码质量这种没法验收的句子要写确认所有公开函数都有参数类型注解并且通过了mypy检查这种可以明确判断对错的句子。写好之后放进去重启会话AI就能识别到这个新技能。后续再遇到同类任务你只需说一句用standard-api-setup技能来搭这个服务整套流程直接跑起来。5. 实际用下来最容易被忽略的三个坑最后这一部分我想集中聊聊那些我踩过的、而且不太容易在文档里看出来的坑。这些东西可能不会让你的系统直接崩掉但会在长期使用中持续消耗你的效率和耐心。5.1 技能不是越多越好上下文预算与选择噪音我有一段时间非常上头把所有技能全装上了看到列表里二十多个技能感觉特别踏实觉得AI什么都会了。但实际用下来效果反而变差了。原因是AI每次处理任务时都要扫描一遍技能列表然后在上下文里做一个该用哪个技能的判断。技能一多这个判断本身就变成了噪音。更麻烦的是很多技能之间有语义重叠。比如code-review和security-audit面对同一段代码时AI可能拿不准该用哪个结果把两个技能的部分步骤混着执行输出质量反而不如只用一个。另外所有技能的描述都会占一定的上下文预算技能太多留给实际代码的预算就少了。我现在只保留10个以内的高频技能其他都卸载或用项目级目录按需引入。这就像你的命令行工具装太多用不上的包命令补全都会变慢。5.2 同名覆盖与版本漂移技能也会悄悄变旧技能是文件文件就会遇到覆盖和版本问题。有一次我在项目级目录放了一个自定义的planning技能结果发现AI执行规划任务时的行为和以前明显不一样排查了半天才发现是项目级技能覆盖了全局同名技能而且两个版本的步骤差异很大。superpowers的加载规则通常是就近优先但如果你没意识到这一点很容易被为什么行为变了这种问题折磨。我的建议是尽量保持全局技能的稳定项目级目录里只放那些全局没有的自定义技能如果确实要覆盖同名技能干脆把全局那个卸载掉不要留着混淆源。另外技能仓库会更新你安装的旧版本可能已经落后。定期跑一下技能更新命令同时留意更新日志里有没有破坏性变更。我踩过最痛的一次是某个调试技能更新后把收集日志和提出假设两个步骤调换了顺序结果我基于旧流程写的复盘文档全部对不上。5.3 流程僵化别让AI为了走流程而走流程技能最大的优点是有流程最大的风险也是流程。AI一旦被技能绑定有时候会表现得非常死板明明某种情况不需要走完整流程它却坚持按步骤来或者某一步的前提已经不再满足它也不告诉你而是硬着头皮执行。我遇到过一个典型情况使用planning技能拆解一个非常小的修复任务时AI花了大量token产出计划书实际修复只用了几行代码。这就是过度流程化。解决办法是在对话里给一项判断豁免权。我会在指定技能时额外加一句使用 planning 技能拆解这个任务如果任务规模在 20 行代码以内 可以直接跳过计划书给出简明实施步骤即可。让AI在技能流程和现场判断之间保持平衡。技能是地图不是轨道。5.4 我现在的日常用法说完了坑分享一下我目前稳定跑了一个月的使用姿势。我现在工作流分三层日常小改动直接对话不指定技能靠模型的自然能力处理中型任务手动指定一两个核心技能比如brainstorming定方案、red-green-refactor写实现大型项目先用planning把任务拆成里程碑再为每一个里程碑嵌入对应的技能链。自定义技能现在成了我的团队协作里最好用的部分。我写了几个跟项目发布流程相关的技能放进项目目录commit到Git仓库。新同学clone项目之后不需要我反复讲流程直接用技能就能让AI辅助他走完发布检查。这个过程让我真切感受到superpowers最大的价值不是让AI更聪明而是让经验可以被复制。如果你正准备入坑我的建议是从最痛苦的问题入手你当前最频繁、最费神、最容易出错的那类任务就是你的第一个技能场景。装上用起来然后根据自己的习惯改它直到它真正贴合你的工作流。这玩意儿说到底是一把刀磨不磨得锋利还得看拿刀的人怎么用。 superpowers实战：把AI编程助手从“回答问题”变成“执行工程任务”
1. superpowers到底解决了什么问题AI会写代码但不会干活说实话我最初注意到superpowers的时候第一反应是又一个提示词合集这类东西我见多了把几条花哨的prompt塞进一个仓库包装成AI提效神器实际用起来跟直接问模型没多大差别。但真正上手用了一周之后我得承认自己判断错了——它解决的并不是提示词不够好的问题而是模型不知道什么叫把事情做完的问题。1.1 从能回答问题到能执行任务的那道坎用过各类代码助手的同学应该都有感触你让AI帮我优化一下这个函数它能给你写得漂漂亮亮但如果你让它把这个模块的重构做了包括拆文件、补测试、更新调用方、跑一遍全量检查它很容易做到一半就停住或者漏掉某个步骤假装自己已经做完了。这不是模型笨而是任务本身超出了一次问答的粒度。模型擅长的是在你给出明确指令后生成一个看上去合理的回答但真实工程里的任务是一连串有依赖关系的动作先分析现状再定方案然后动手接着验证最后回归。这些动作之间有顺序、有校验点、有验收标准。普通聊天式交互给不了模型这套操作框架所以它只能凭感觉临场发挥。superpowers做的事情就是把临场发挥变成按流程执行。它不会替模型思考也不会提升模型的代码能力但它会给模型一套可复用的技能包每个技能对应一类经典任务里面写着任务怎么拆解、先做什么后做什么、做到什么程度算完成、输出什么格式的交付物。模型拿到技能之后整个人的工作方式会从答一题算一题变成按SOP走一遍流程。听起来不玄乎但这正是工程场景里最需要的稳定性。1.2 技能不是提示词它是一套带验收标准的工作流很多人有个误解觉得superpowers里的skills就是更长的提示词。我第一次翻开源码之前也是这么想的打开之后才发现每个技能本质上是一个结构化的Markdown文档里面包含几个关键部分前置条件这个技能适合在什么场景下用以及使用前必须确认哪些信息。比如做系统化调试之前先要复现问题、收集错误日志否则后面全是瞎猜。执行步骤一套有顺序的、带明确意图的操作流程每一步都告诉模型这一步的目标是什么。验收标准做完之后怎么判断结果是对的。这比请确保代码质量这种空话有用得多。输出模板最终交付物长什么样比如一份带时间线的问题分析报告、一张依赖关系图、一段提交信息。你可以把技能理解成岗位SOP它是一个可复用的、带质量门槛的流程而不是一次性聊天记录。提示词用完就没了技能却可以反复调用、甚至可以像写代码一样被维护和更新。这也是我后来愿意把项目工作流往superpowers上迁的核心原因——它把个人经验变成了团队资产。2. 安装之前必须想清楚的事这玩意儿不是插件商店里的普通扩展我见过不少人在安装阶段就翻车不是因为命令复杂而是因为他们没有理解superpowers的运行模型。它不是一个独立软件也不是某个IDE的插件它是一套技能框架 CLI工具 技能仓库的组合。安装之前你先想清楚三件事你的环境里有没有Node和Git你用的是哪个AI编程助手以及你准备把技能放在哪个层级来管理。2.1 环境自查node、git、shell一个都不能少superpowers的CLI是一个Node包所以第一件事就是确认你本机的Node版本。我自己的经验是用nvm管理Node常年保持在18以上如果你还在用Node 14建议先升级不然装完很容易在解析依赖时报错。其次是Git因为技能的安装和更新本质上是把远程仓库里的技能文件拉到本地Git版本太低或者没有配置SSH Key拉取的时候会卡在认证环节。Windows用户建议用Git Bash或者PowerShell 7别用老版本的cmd很多路径处理和权限问题会让你怀疑人生。然后是shell环境。macOS默认zsh没问题Linux用户如果是bash也没问题但如果你装了fish这种特殊shell注意看一下CLI的输出会不会有兼容问题。我自己在fish里遇到过路径变量没生效的情况最后是切回bash跑命令才正常。2.2 安装命令与最小化验证环境确认没问题之后安装其实就一步npx superpowerslatest install这条命令会在你的用户目录下创建一个技能根目录比如~/.superpowers/同时把CLI命令注册到全局。装完之后我建议你不要急着往项目里塞技能先做最小化验证superpowers doctor superpowers list第一条命令检查你的运行环境是否满足所有前提包括Node版本、Git可用性、技能目录权限。第二条命令列出当前已经装好的技能。如果你看到的是一个空列表或者只包含几个内置技能说明安装成功可以开始往里加东西了。这里要提醒一句如果你之前装过别的AI技能管理工具先去检查~/.superpowers/skills里有没有残留目录。不同框架的技能目录结构不一样混着用可能会出现技能识别不出来的奇怪问题。我的做法是全新环境里先清空再装省得后面排查半天。2.3 装完后先搞明白技能目录长什么样很多人装完就急着用结果出了问题不知道怎么排查。我建议你至少花五分钟看一下目录结构。默认情况下技能存放在两个层级用户级目录~/.superpowers/skills/所有项目都能调用的全局技能。项目级目录.superpowers/skills/只对当前项目生效的本项目技能。一个技能就是一个子目录目录里必须有SKILL.md文件。比如~/.superpowers/skills/ ├── brainstorming/ │ └── SKILL.md ├── planning/ │ └── SKILL.md └── systematic-debugging/ └── SKILL.md这个结构意味着技能的本质是可读的文件你可以直接打开看它的完整内容也可以自己改。这跟黑盒插件完全是两码事。我后来自定义技能的时候就是先把系统自带技能读了一遍模仿它的写法两天就上手了。3. 核心技能清单这些skills分别干什么什么时候该用装好之后你大概率会对着技能列表发呆这么多skills到底哪些该用哪些是噱头我按照实际使用频率和价值把superpowers里比较核心的技能整理成了一张表你先有个全局认识后面再谈具体怎么用。技能名称典型触发场景核心产出brainstorming需求模糊、方案不明确、需要探索多种可能一份列出多个候选方案的对比分析planning需求已明确需要拆解成可执行的任务序列带任务依赖关系和验收标准的计划书spec-driven-development开始写代码前需要先定义行为可验收的规格说明再进入编码red-green-refactor用TDD流程写新功能先写失败测试再让实现通过最后重构systematic-debugging面对难以复现或原因不明的bug一份记录假设、验证、结论的排查报告code-review提交代码前或审查他人代码按严重程度分级的审查意见清单refactoring需要改善既有代码结构但不改变行为逐步重构的方案和每一步的验证方式dependency-analysis升级依赖前想搞清楚影响范围依赖关系、版本差异、风险点对比security-audit上线前想快速过一遍安全隐患按风险等级列出的安全问题列表documentation代码写完要补文档或README带示例和边界说明的文档草稿3.1 规划与执行类把想法变成可追踪的任务我最常用的两个技能是brainstorming和planning。听起来有点虚但它们解决的是AI一开始就闷头写代码这个老大难问题。以前我让AI实现一个功能它经常直接甩给我一堆代码里面可能方案选错了、边界情况没考虑整得我review的时候血压飙升。用了brainstorming之后AI会先强迫自己不写代码而是只列方案这个需求有哪几种实现路径每种路径的优缺点是什么成本如何风险在哪然后我从中选一条它才会继续往下走。planning则是把选定的方案拆成任务列表每个任务都标注了依赖关系和验收标准。这一步特别有用因为它让AI在执行过程中有了检查点——做完这一步先对照验收标准自查通过了再进下一步。这让它在多步任务里的完成率明显提升不会再出现做到一半跑题的情况。3.2 质量与调试类让代码出错时不再瞎猜systematic-debugging是我第二佩服的技能。以前遇到难缠的bugAI经常直接给一个可能是XX导致的猜测然后扔一段改好的代码让你试试完不行再猜下一轮。这种情况不仅浪费时间还会让你对AI的判断力失去信任。这个技能会强制AI走正规排查流程先复现问题再收集现场信息然后列出所有可能原因按可能性排序接着设计一个能验证某个原因的实验跑完之后根据结果排除或确认再进入下一轮。你会发现它的输出从我觉得是内存泄漏变成了根据堆内存曲线和GC日志我可以确认不是泄漏因为……下一步我来验证线程池配置这种有依据的推理链条。用这个技能做过两次线上问题排查之后我就回不去那种瞎猜模式了。red-green-refactor则适合TDD场景。如果你想让AI先写测试再写实现这个技能会给它一套节奏先写一个会失败的测试跑一遍确认失败原因是功能缺失而非测试写错然后写最小实现让测试变绿最后再做重构。每次步骤切换还要解释自己在做什么。这套节奏对工程质量提升立竿见影缺点是比较费token适合核心逻辑不适合简单CRUD。3.3 维护与交付类文档、审查、重构一条龙code-review是我团队现在每次合并请求之前的必选项。它的价值不在于AI审得比人好而在于它逼着AI按固定维度过一遍代码安全性、可读性、性能、边界条件、测试覆盖、命名一致性。人类reviewer经常会漏掉某些维度但技能不会。它产出的审查意见还会按严重程度分级我只需要先看Critical和High的部分。documentation这个技能我原来觉得鸡肋后来发现真香。你让它给一个模块写文档它会先问清楚读者是谁、使用场景是什么、有没有示例可以参考然后产出一份带目录结构、边界说明、示例代码的文档草稿。它不是从零瞎编而是先从代码里提取接口和用法再组织成文所以准确性比让模型自由发挥高很多。3.4 怎么选先给你的工作流做体检看到这里你可能会想这么多技能是不是全装上都用我的建议是别。技能选用的原则只有一个看你的日常流程里哪一步最容易出问题。你review代码时总发现低级错误那就只装code-review。你写功能时经常需求不清就动手那就只装brainstorming和planning。你被难缠bug折磨得死去活来那就先装systematic-debugging其他以后再说。把技能当成工具不要当成收藏品。装一堆用不上的技能不仅浪费目录空间还会增加AI在上下文里挑选技能的负担下一节我会专门讲这个。4. 引入技能的正确姿势从会装到会调度安装技能只是第一步真正影响效果的是你以什么方式把技能引入到工作流里。我见过很多人把技能装上之后发现AI完全没按照技能执行然后就开始骂框架不行。其实问题多半出在引入方式上。4.1 三种引入方式全局、项目级、会话级第一种是全局引入就是把技能装到用户级目录所有项目都能用。适合那些跟具体业务无关、属于通用工作方式的技能比如brainstorming、planning、systematic-debugging。这样你在任何项目里都能让AI用调试技能排查问题它都能识别到。第二种是项目级引入就是把技能装到项目的.superpowers/skills/目录下。适合那些跟项目强相关的流程比如这个项目的发布检查清单、这个项目的数据迁移操作手册。项目级技能可以由团队通过Git共享每个人clone仓库之后技能自然就位非常适合作团队的过程资产。第三种是会话级引入严格来说不算安装而是在当前对话里通过提示词显式指定。比如你直接告诉AI使用systematic-debugging技能来处理这个问题即使该技能没装到全局AI也可能根据提示策略临时套用。这种方式灵活但对模型本身理解能力要求高稳定性不如前两种。我的经验是通用技能装全局项目流程技能装项目级临时需求在会话里指定。三个层级各司其职尽量不要混。4.2 让AI自己挑技能 vs 手动指定技能这是新手最容易困惑的地方。superpowers的机制是AI读取了技能目录之后会在遇到任务时自动判断应该用哪个技能。这个自动选择看起来方便但我实测下来它并不是完美的。在任务边界特别清晰的情况下比如帮我把这个报错修一下AI通常能自动选中systematic-debugging效果不错。但在任务比较综合、涉及多步骤的时候AI有可能会选错或者在一个任务里频繁切换多个技能导致上下文里充满无关内容。所以我的习惯是重要任务我手动指定技能。比如我会说先使用 brainstorming 技能把这个需求的三种实现方案列出来 再用 planning 技能把选定方案拆成任务清单。这么做的原因很简单自动选择依赖模型对技能描述的语义理解模型越强理解越准但与其赌模型的理解力不如在关键节点上把流程定死。技能的作用是降低不确定性如果选择技能这一步本身就是不确定的那整个链路的质量就打了折扣。4.3 写一个自己的技能从重复劳动到一次性解决用熟了之后你一定会遇到系统自带技能不够用的时刻。这时候就该自己写技能了。其实写技能没那么神秘我建议先从记录重复劳动开始。回想一下你最近一个月哪类事情你重复做了三遍以上比如把一段Python脚本改造成FastAPI接口、给新服务写一套标准的日志和监控配置、每次发布前按固定清单核对配置。这些流程完全可以固化成技能。一个技能目录长这样.my-team/skills/standard-api-setup/ ├── SKILL.md └── examples/ └── example-output.mdSKILL.md的开头是YAML格式的元信息里面定义了技能名称和描述正文则用清晰的标题把步骤列出来。我写第一个技能时参考了系统自带技能的写法保持一个原则每一步都要有操作意图和验收标准。不要写优化代码质量这种没法验收的句子要写确认所有公开函数都有参数类型注解并且通过了mypy检查这种可以明确判断对错的句子。写好之后放进去重启会话AI就能识别到这个新技能。后续再遇到同类任务你只需说一句用standard-api-setup技能来搭这个服务整套流程直接跑起来。5. 实际用下来最容易被忽略的三个坑最后这一部分我想集中聊聊那些我踩过的、而且不太容易在文档里看出来的坑。这些东西可能不会让你的系统直接崩掉但会在长期使用中持续消耗你的效率和耐心。5.1 技能不是越多越好上下文预算与选择噪音我有一段时间非常上头把所有技能全装上了看到列表里二十多个技能感觉特别踏实觉得AI什么都会了。但实际用下来效果反而变差了。原因是AI每次处理任务时都要扫描一遍技能列表然后在上下文里做一个该用哪个技能的判断。技能一多这个判断本身就变成了噪音。更麻烦的是很多技能之间有语义重叠。比如code-review和security-audit面对同一段代码时AI可能拿不准该用哪个结果把两个技能的部分步骤混着执行输出质量反而不如只用一个。另外所有技能的描述都会占一定的上下文预算技能太多留给实际代码的预算就少了。我现在只保留10个以内的高频技能其他都卸载或用项目级目录按需引入。这就像你的命令行工具装太多用不上的包命令补全都会变慢。5.2 同名覆盖与版本漂移技能也会悄悄变旧技能是文件文件就会遇到覆盖和版本问题。有一次我在项目级目录放了一个自定义的planning技能结果发现AI执行规划任务时的行为和以前明显不一样排查了半天才发现是项目级技能覆盖了全局同名技能而且两个版本的步骤差异很大。superpowers的加载规则通常是就近优先但如果你没意识到这一点很容易被为什么行为变了这种问题折磨。我的建议是尽量保持全局技能的稳定项目级目录里只放那些全局没有的自定义技能如果确实要覆盖同名技能干脆把全局那个卸载掉不要留着混淆源。另外技能仓库会更新你安装的旧版本可能已经落后。定期跑一下技能更新命令同时留意更新日志里有没有破坏性变更。我踩过最痛的一次是某个调试技能更新后把收集日志和提出假设两个步骤调换了顺序结果我基于旧流程写的复盘文档全部对不上。5.3 流程僵化别让AI为了走流程而走流程技能最大的优点是有流程最大的风险也是流程。AI一旦被技能绑定有时候会表现得非常死板明明某种情况不需要走完整流程它却坚持按步骤来或者某一步的前提已经不再满足它也不告诉你而是硬着头皮执行。我遇到过一个典型情况使用planning技能拆解一个非常小的修复任务时AI花了大量token产出计划书实际修复只用了几行代码。这就是过度流程化。解决办法是在对话里给一项判断豁免权。我会在指定技能时额外加一句使用 planning 技能拆解这个任务如果任务规模在 20 行代码以内 可以直接跳过计划书给出简明实施步骤即可。让AI在技能流程和现场判断之间保持平衡。技能是地图不是轨道。5.4 我现在的日常用法说完了坑分享一下我目前稳定跑了一个月的使用姿势。我现在工作流分三层日常小改动直接对话不指定技能靠模型的自然能力处理中型任务手动指定一两个核心技能比如brainstorming定方案、red-green-refactor写实现大型项目先用planning把任务拆成里程碑再为每一个里程碑嵌入对应的技能链。自定义技能现在成了我的团队协作里最好用的部分。我写了几个跟项目发布流程相关的技能放进项目目录commit到Git仓库。新同学clone项目之后不需要我反复讲流程直接用技能就能让AI辅助他走完发布检查。这个过程让我真切感受到superpowers最大的价值不是让AI更聪明而是让经验可以被复制。如果你正准备入坑我的建议是从最痛苦的问题入手你当前最频繁、最费神、最容易出错的那类任务就是你的第一个技能场景。装上用起来然后根据自己的习惯改它直到它真正贴合你的工作流。这玩意儿说到底是一把刀磨不磨得锋利还得看拿刀的人怎么用。