1. 拆解 superpowers它到底是什么能解决什么问题第一次看到 superpowers 这个词很多人会下意识以为是某个超级英雄题材的游戏或者影视项目。但如果你最近在开发者社区、效率工具圈或者 AI 编程相关的讨论里频繁刷到它那大概率说的不是漫画而是一套围绕 AI 编程助手构建的技能增强框架。简单来说superpowers 做的事情就是给原本只会“你问我答”的 AI 编程工具装上一整套可复用的技能包让它在处理复杂任务时不再从零开始而是像一位经验丰富的工程师那样调用已经沉淀好的方法论和操作流程。这个定位非常关键。传统的 AI 编程助手无论底层模型多强本质上都是无状态的——你每次开一个新对话它就把之前积累的上下文全部忘掉你得重新解释项目结构、重新说明代码规范、重新交代技术栈偏好。superpowers 要解决的核心痛点就在这里它把那些反复要用到的能力比如代码审查、测试驱动开发、系统化调试、需求拆解、文档生成等封装成一个个独立的“技能”让 AI 在需要的时候自动加载并执行。你可以把它理解成给 AI 装了一个技能库而不是每次都靠临时提示词去碰运气。适合谁来用我梳理了一下大概有三类人受益最明显。第一类是日常重度依赖 AI 编程助手的开发者尤其是用 Codex 这类工具做项目开发的人superpowers 能显著减少重复沟通成本。第二类是技术团队的负责人或者 Tech Lead他们可以把团队的编码规范、审查流程、部署检查清单都做成技能让 AI 在辅助团队成员时自动遵循统一标准。第三类是对 AI 工作流感兴趣、想搭建自己专属技能体系的技术爱好者superpowers 提供了一套相对完整的框架和约定上手门槛不算高但扩展空间很大。从热搜词也能看出来大家最关心的几个问题集中在“怎么安装”“怎么用”“和 Codex 怎么配合”“Java 项目能不能用”这几个方向。我接下来就按照这个脉络把 superpowers 的整体设计思路、核心机制、安装配置、实操流程以及踩坑经验完整地拆一遍。不管你是刚听说这个概念还是已经装了一半卡在某个环节应该都能找到对你有用的内容。2. 整体设计思路与核心机制拆解2.1 为什么是“技能”而不是“插件”或“提示词模板”理解 superpowers 的设计哲学得先搞清楚它为什么选择“技能”这个抽象层。市面上给 AI 编程助手做增强的方案大致有三种路子一种是插件式直接对接 IDE 或者编辑器的扩展接口比如 VS Code 插件那种形态另一种是提示词模板把常用的指令写成模板文件用的时候手动引用第三种就是 superpowers 走的技能路线。插件的问题在于耦合太深。你得针对不同的编辑器、不同的 AI 工具分别适配维护成本高而且一旦底层工具更新接口插件很容易失效。提示词模板的问题则相反太轻了没有结构没有依赖管理也没有执行逻辑本质上还是一堆文本AI 用不用、怎么用全凭运气。superpowers 的技能机制取了个中间值每个技能是一个独立的目录里面有明确的元数据描述叫什么名字、什么时候触发、依赖哪些其他技能有具体的执行指令告诉 AI 按什么步骤操作还可以附带脚本、模板、参考文档等资源。AI 在运行时根据当前任务上下文自动判断该加载哪个技能然后按照技能定义的流程去执行。这个设计的精妙之处在于它把“知识”和“执行”分开了。知识部分比如“什么是测试驱动开发”“代码审查应该关注哪些维度”可以写得很详细作为参考文档存在执行部分比如“第一步先读哪些文件第二步生成什么输出”则写成明确的指令序列。AI 不需要在一次对话里理解所有知识它只需要在触发某个技能时加载对应的执行指令按步骤走就行。这大大降低了单次对话的认知负担也让技能可以无限扩展而不互相干扰。2.2 技能的生命周期从触发到执行到回收一个技能从被触发到执行完毕中间经历了好几个阶段每个阶段都有设计上的考量。我把它拆成四个环节来看。触发阶段。superpowers 的技能触发不是靠关键词匹配那么简单。它通常会结合当前对话的上下文、用户显式调用的指令、以及技能自身定义的触发条件来综合判断。比如你正在让 AI 帮你排查一个 bug对话里出现了错误堆栈、复现步骤这些信息系统化调试这个技能就可能被自动激活。你也可以手动指定比如输入某个命令强制加载某个技能。触发机制的设计目标是“该用的时候自动用上不该用的时候别乱插嘴”这需要技能作者在定义触发条件时写得很精准。加载阶段。技能被触发后AI 需要读取技能目录下的核心文件通常是技能描述文件和执行指令文件。描述文件告诉 AI 这个技能是干什么的、适用什么场景、有什么限制执行指令文件则是一步一步的操作指南。加载阶段的关键是“按需读取”不需要把技能目录下所有文件都读一遍只读当前执行需要的部分。这要求技能作者把文件组织得清晰核心指令和参考资料分开存放。执行阶段。这是技能真正发挥作用的地方。AI 按照执行指令的步骤结合当前项目的实际情况逐步完成操作。比如一个“生成单元测试”的技能执行指令可能会写第一步读取目标源文件识别所有公开方法和分支条件第二步为每个方法生成至少一个正常路径测试和一个边界条件测试第三步检查项目使用的测试框架和断言库确保生成的代码风格一致第四步把测试文件写到指定目录并运行验证。每一步都有明确的输入和输出AI 执行起来不容易跑偏。回收阶段。技能执行完毕后AI 需要把执行结果反馈给用户同时清理掉本次加载的技能上下文避免影响后续对话。这个阶段容易被忽略但很重要。如果技能上下文不清理后续对话可能会被之前加载的技能指令干扰导致 AI 在不该用某个技能的时候还在用。superpowers 通常会在技能定义里写明“执行完毕后释放”具体实现方式取决于底层 AI 工具的支持程度。2.3 技能之间的依赖与组合为什么需要编排单个技能能解决的问题有限真正复杂的工作流往往需要多个技能串联。比如你要给一个现有项目添加新功能可能涉及需求拆解技能把模糊需求变成明确任务列表、代码生成技能按照项目规范写代码、测试生成技能为新代码写测试、代码审查技能检查代码质量、文档更新技能同步更新 README 和 API 文档。这些技能之间有先后依赖关系也有数据传递关系。superpowers 处理这种场景的方式是技能编排。它允许在技能定义里声明依赖比如“代码审查技能依赖代码生成技能的输出”。当 AI 执行到某个技能时如果发现它依赖的前置技能还没执行会自动触发前置技能。这种依赖关系形成一张有向图AI 按照拓扑顺序依次执行。编排机制让 superpowers 从一个“技能集合”升级成了“工作流引擎”这是它区别于普通提示词模板的核心竞争力。不过依赖编排也带来了复杂性。技能作者需要仔细设计依赖关系避免循环依赖AI 在执行时需要维护一个执行状态表记录哪些技能已完成、哪些在进行中、哪些还没开始。对于简单的单技能场景这套机制是透明的用户感知不到对于复杂的多技能工作流它则保证了执行的有序性和可追溯性。3. 安装与配置从零把 superpowers 跑起来3.1 环境准备与前置条件检查在动手安装之前有几项前置条件需要确认。这些条件不满足的话装到一半大概率会卡住。首先是 AI 编程工具本身。superpowers 不是独立运行的程序它依附于支持技能机制的 AI 编程助手。目前社区讨论最多的是和 Codex 的配合所以你需要先有一个可用的 Codex 环境并且确认它支持加载外部技能目录。不同版本的 Codex 对技能机制的支持程度不一样建议先查一下你所用版本的文档确认技能加载相关的配置项存在。其次是运行环境。superpowers 的技能目录里可能包含脚本文件这些脚本通常用 Node.js 或 Python 编写所以你的机器上需要装好对应的运行时。Node.js 建议用 18 以上的 LTS 版本Python 建议 3.10 以上。版本太低可能导致脚本语法不兼容报一些莫名其妙的错误。第三是目录权限。superpowers 需要把技能目录放到 AI 工具能够读取的位置通常是用户主目录下的某个配置文件夹。你需要确认当前用户对该目录有读写权限。在 Linux 和 macOS 上一般没问题Windows 上如果开了某些安全软件可能会拦截文件写入需要提前加白名单。第四是网络条件。安装过程中可能需要从代码仓库拉取技能包如果你的网络环境访问某些源比较慢可以提前配置好镜像或者代理。不过这里要注意配置代理时只针对包管理工具本身不要影响其他正常网络访问。3.2 安装步骤详解三种方式对比superpowers 的安装方式主要有三种我分别说一下适用场景和具体操作。方式一包管理器安装。这是最省事的方式适合大多数用户。如果你的环境里有 npm 或者 pip可以直接通过包管理器拉取 superpowers 的技能包。以 npm 为例命令大概是这样的npm install -g superpowers-skills安装完成后包管理器会把技能文件放到全局目录下你需要在 AI 工具的配置里指向这个目录。这种方式的优点是版本管理方便升级的时候一条命令搞定缺点是技能目录的位置由包管理器决定有时候不太好找而且全局安装可能和项目本地的其他依赖产生冲突。方式二手动克隆仓库。如果你需要定制技能或者想随时修改技能内容手动克隆更合适。操作步骤如下git clone https://github.com/your-org/superpowers.git ~/.superpowers克隆完成后技能目录就在~/.superpowers/skills下面。你可以在 AI 工具的配置文件里把这个路径加进去。手动克隆的好处是透明所有文件你都能看到、能改缺点是升级需要手动拉取而且如果你改过技能文件升级时可能会有冲突需要处理。方式三项目内嵌。如果你希望技能跟着项目走而不是全局生效可以把技能目录直接放到项目根目录下比如./.superpowers/skills。然后在项目级的 AI 工具配置里指向这个相对路径。这种方式适合团队协作技能配置可以随代码仓库一起提交团队成员拉取项目后自动获得相同的技能集。缺点是每个项目都要单独配置项目多了管理起来比较麻烦。三种方式没有绝对优劣看你的使用场景。我个人建议个人日常使用选方式一需要深度定制选方式二团队统一规范选方式三。3.3 配置文件怎么写关键参数逐项说明安装完技能包之后还需要在 AI 工具的配置里做几项设置技能才能真正生效。不同工具的配置格式不一样但核心参数是类似的。我以常见的 JSON 配置为例逐项说明每个参数的作用。{ skills: { enabled: true, paths: [ ~/.superpowers/skills ], autoLoad: true, maxConcurrent: 3, logLevel: info } }enabled是总开关设为 true 才会启用技能机制。有些工具默认关闭需要手动打开。paths是技能目录的搜索路径可以配多个。AI 工具会按顺序扫描这些目录找到所有技能定义文件。如果你同时装了全局技能和项目级技能可以把两个路径都写进去项目级的放前面这样同名技能会优先使用项目级的版本。autoLoad控制是否自动加载技能。设为 true 时AI 会根据上下文自动判断该用哪个技能设为 false 时只有你显式调用才会加载。新手建议先设为 false手动控制等熟悉了再开自动。maxConcurrent限制同时加载的技能数量。设太大可能导致上下文过载AI 反而容易混乱设太小又可能影响复杂工作流的执行效率。一般 3 到 5 之间比较合适具体看你的 AI 工具上下文窗口大小。logLevel是日志级别调试阶段可以设为 debug能看到技能加载和执行的详细过程日常使用设为 info 或 warn 就行避免日志刷屏。配置改完之后记得重启 AI 工具或者重新加载配置让改动生效。有些工具支持热加载改完直接生效不用重启这个看具体实现。4. 核心技能实操从代码审查到系统化调试4.1 代码审查技能让 AI 像资深工程师一样看代码代码审查是 superpowers 里使用频率最高的技能之一。它解决的问题很实际AI 生成的代码或者团队成员的提交怎么保证质量靠人工逐行看效率太低靠简单的 lint 工具又只能查格式问题查不出逻辑缺陷和设计问题。代码审查技能的目标是让 AI 按照一套结构化的检查清单对代码进行多维度审查。这个技能的执行流程通常分四步。第一步是上下文收集AI 需要读取目标文件、相关的测试文件、以及项目的代码规范配置。这一步很关键如果 AI 不了解项目用的什么框架、什么设计模式审查意见就会脱离实际。第二步是静态检查AI 逐行扫描代码检查命名规范、注释完整性、函数长度、圈复杂度这些可以量化的问题。第三步是逻辑审查AI 分析代码的控制流和数据流找出潜在的边界条件遗漏、空指针风险、资源泄漏、并发问题等。第四步是生成审查报告把发现的问题按严重程度分级给出具体的修改建议。我在实际使用中总结了几条经验。第一审查范围要明确。如果你不告诉 AI 审查哪些文件它可能会把整个项目都扫一遍耗时不说还容易产生大量无关紧要的意见。最好在触发技能时指定文件路径或者变更范围。第二严重程度分级要合理。有些 AI 会把所有问题都标成“严重”导致真正严重的问题被淹没。你可以在技能配置里调整分级标准比如把命名不规范标为“建议”把空指针风险标为“严重”。第三审查意见要可操作。好的审查意见不仅指出问题还给出修改后的代码示例。你可以在技能指令里明确要求 AI 提供修改建议而不仅仅是描述问题。注意代码审查技能的输出质量高度依赖项目上下文的完整度。如果项目里没有代码规范文档建议先补一份或者在技能配置里内置一套通用规范否则 AI 的审查标准会飘忽不定。4.2 测试驱动开发技能先写测试再写实现测试驱动开发TDD是一种被广泛认可但实际执行起来很难坚持的实践。难在哪难在写测试本身就很枯燥而且要先于实现写测试对开发者的抽象能力要求很高。superpowers 的 TDD 技能试图降低这个门槛让 AI 帮你完成从需求到测试用例的转换。这个技能的执行逻辑是这样的你给 AI 一段需求描述比如“实现一个函数输入一个整数数组返回其中所有偶数的平方和”。AI 首先分析需求识别出输入类型、输出类型、边界条件空数组、全奇数、包含负数等。然后为每个条件生成对应的测试用例包括正常路径和异常路径。测试用例写完之后AI 会运行一遍确认它们全部失败因为实现还没写。接着 AI 生成实现代码再次运行测试直到全部通过。最后 AI 会检查测试覆盖率如果某些分支没覆盖到补充测试用例。这个流程的价值在于它强制把“需求理解”和“代码实现”分开了。很多时候 bug 的产生不是因为代码写错了而是因为对需求的理解有偏差。先写测试相当于把需求翻译成可执行的断言如果理解错了测试就会失败问题在早期就暴露出来。实操中有几个细节要注意。第一测试框架要匹配。不同语言、不同项目用的测试框架不一样Java 项目可能用 JUnitPython 项目可能用 pytestJavaScript 项目可能用 Jest。你需要在技能配置里指定项目使用的框架否则 AI 生成的测试代码可能跑不起来。第二测试粒度要控制。AI 有时候会生成过于细碎的测试一个简单函数写十几个测试用例维护成本很高。你可以在技能指令里限制每个函数的测试用例数量比如“正常路径不超过 3 个边界条件不超过 5 个”。第三mock 的使用要谨慎。对于依赖外部服务的函数AI 可能会生成大量 mock 代码这些 mock 本身也需要维护。建议只在必要时使用 mock能集成测试的就集成测试。4.3 系统化调试技能从错误现象到根因定位调试是开发过程中最耗时的环节之一。很多开发者调试的方式是“猜”——猜哪里可能出问题加日志运行看输出再猜。这种方式效率低而且容易漏掉真正的根因。系统化调试技能的目标是让 AI 按照一套结构化的排查流程从错误现象出发逐步缩小范围最终定位到根因。这个技能的排查流程通常分五个阶段。第一阶段是现象收集AI 需要你提供错误信息、复现步骤、运行环境、相关日志。信息越完整后续排查越顺利。第二阶段是假设生成AI 根据现象和代码上下文列出所有可能导致该问题的原因按可能性排序。第三阶段是假设验证针对每个假设AI 设计验证方案比如加日志、写最小复现用例、检查配置项等。第四阶段是根因确认当某个假设被验证为真时AI 进一步分析为什么会这样是代码逻辑问题、配置问题、还是环境问题。第五阶段是修复方案AI 给出具体的修改建议并说明修改后如何验证问题已解决。我在使用这个技能时踩过几个坑。第一个坑是信息给太少。只丢一句“程序报错了”AI 只能靠猜生成的假设列表又长又不准。后来我养成了习惯触发调试技能时至少提供错误堆栈、复现步骤、最近改动的代码这三个信息。第二个坑是过早下结论。AI 有时候会抓住第一个看起来合理的假设就往下走忽略了其他可能性。你可以在技能指令里要求 AI“至少列出三个假设并说明每个假设的验证方法”强制它做全面排查。第三个坑是修复方案治标不治本。比如空指针异常AI 可能建议加个判空就完事了但根本原因可能是上游数据传递逻辑有问题。你需要在技能配置里强调“修复方案必须针对根因而不是掩盖症状”。4.4 需求拆解技能把模糊需求变成可执行任务需求拆解是很多开发者的痛点。产品经理给一句话需求你得把它变成技术方案、任务列表、工时估算。这个过程依赖经验新手容易漏掉关键点。需求拆解技能的作用是让 AI 按照一套框架把模糊需求逐步细化。这个技能的拆解框架通常包括几个维度。功能维度这个需求涉及哪些功能模块每个模块的输入输出是什么。数据维度需要新增或修改哪些数据结构数据从哪来到哪去。接口维度需要新增或修改哪些 API请求和响应的格式是什么。异常维度哪些情况可能出错出错后怎么处理。性能维度有没有性能要求数据量大了会不会有问题。安全维度有没有权限控制、数据校验、敏感信息处理的要求。AI 按照这些维度逐一分析产出一份结构化的需求拆解文档。文档里包含任务列表、依赖关系、风险点、待确认问题。你拿着这份文档去和产品经理对齐比空口讨论高效得多。实操建议第一拆解前先让 AI 复述一遍需求确认它理解正确。第二拆解结果要人工审核AI 可能会遗漏业务规则或者过度设计。第三待确认问题要单独列出来这些是需求里模糊的地方需要和需求方确认清楚再动手。5. 常见问题与排查技巧实录5.1 技能不生效从配置到权限的完整排查路径技能装了但没反应这是新手最常遇到的问题。排查思路可以按下面的顺序走。先检查配置文件路径对不对。AI 工具读取配置文件的路径可能和你以为的不一样比如有些工具读的是用户主目录下的隐藏文件夹有些读的是项目根目录。你可以在工具文档里确认配置文件的加载顺序或者用工具的调试命令打印当前生效的配置。再检查技能目录结构对不对。superpowers 对技能目录的结构有约定比如每个技能必须有一个描述文件文件名和格式要符合规范。如果目录结构不对AI 扫描的时候会直接跳过。你可以手动列一下技能目录的内容对照文档确认结构无误。然后检查权限。AI 工具的运行用户需要对技能目录有读权限如果技能里有脚本需要执行还需要执行权限。在 Linux 和 macOS 上用ls -la看一下权限位Windows 上检查文件夹的安全属性。最后检查日志。把日志级别调到 debug重新触发一次技能看日志里有没有加载技能相关的记录。如果日志显示“skill not found”或者“failed to load”根据具体错误信息进一步排查。5.2 技能冲突多个技能同时触发怎么办当你开启了自动加载而且装了多个技能时可能会遇到多个技能同时被触发的情况。比如你正在写代码代码生成技能和代码审查技能可能同时激活一个想生成新代码一个想审查现有代码指令互相打架。解决思路有三个。第一调整触发条件的优先级。在技能定义里可以设置优先级优先级高的先执行执行完毕后如果上下文已经满足低优先级的就不再触发。第二手动控制加载。把 autoLoad 设为 false需要哪个技能就手动调哪个避免自动触发带来的冲突。第三合并技能。如果两个技能经常一起使用可以考虑把它们合并成一个复合技能内部按顺序执行而不是让它们各自为政。5.3 性能问题技能加载慢、执行卡顿的优化技能多了之后加载和执行可能会变慢。优化方向有几个。减少技能数量。只保留常用的技能不常用的可以归档或者删除。技能目录越大扫描和加载的时间越长。精简技能内容。技能描述文件和执行指令文件不要写得太长核心指令控制在几百行以内。参考资料可以拆成单独的文件按需读取而不是一股脑全加载。调整 maxConcurrent。同时加载的技能越多上下文越大AI 处理起来越慢。适当降低这个值让技能串行执行虽然总时间可能差不多但稳定性更好。升级硬件。如果技能里包含大量脚本执行CPU 和内存会成为瓶颈。这个就看预算了不是必须的。5.4 常见问题速查表问题现象可能原因排查方法解决方案技能完全不触发配置未启用或路径错误检查配置文件 enabled 和 paths修正配置并重启工具技能触发但无输出技能文件缺失或格式错误查看 debug 日志中的加载记录补全技能文件或修正格式多个技能指令冲突自动加载导致同时触发观察日志中同时加载的技能关闭自动加载或调整优先级技能执行中途卡住依赖技能未满足或脚本超时检查依赖声明和脚本执行日志补全依赖或增加超时时间生成的代码风格不一致项目规范未正确加载检查技能是否读取了规范文件在技能配置中指定规范文件路径测试用例运行失败测试框架不匹配确认项目使用的测试框架在技能配置中指定正确的框架6. 进阶玩法定制专属技能与团队协作6.1 从零写一个自己的技能用熟了现成技能之后你可能会想写一个贴合自己项目或团队需求的技能。写技能没有想象中那么难核心是把你知道的流程用结构化的方式表达出来。一个技能目录通常包含这几个文件skill.json是元数据定义技能名称、描述、触发条件、依赖关系instructions.md是执行指令用自然语言写清楚每一步做什么resources/目录放参考资料比如代码模板、检查清单、示例文件scripts/目录放可执行脚本比如自动化检查工具。写技能的关键是“指令要具体不要模糊”。比如“检查代码质量”这种指令太笼统AI 不知道从哪下手。改成“第一步读取目标文件第二步检查每个函数是否超过 50 行第三步检查是否有未处理的异常分支第四步生成检查报告”AI 执行起来就明确多了。另一个关键是“提供示例”。在参考资料里放一两个正确示例和一个错误示例AI 参照示例执行输出质量会稳定很多。6.2 团队技能库的维护与版本管理团队使用 superpowers 时技能库的维护是个绕不开的话题。我的建议是把技能库当成代码来管理用 Git 仓库存储技能文件每次修改都走提交和审查流程版本号遵循语义化版本规范。技能库的目录结构可以按领域划分比如skills/coding/放编码相关技能skills/testing/放测试相关技能skills/deployment/放部署相关技能。每个技能目录下再按前面说的结构组织文件。版本管理方面建议给技能库打 tag比如v1.0.0、v1.1.0。团队成员在配置里可以指定使用哪个版本避免因为技能更新导致行为不一致。升级技能库时先在个人环境验证确认没问题再推给团队。6.3 和 Codex 配合的实战经验Codex 是目前和 superpowers 配合讨论最多的 AI 编程工具。我在实际使用中总结了几个配合要点。第一Codex 的上下文窗口有限技能加载要克制。不要一次性加载太多技能按需加载用完就释放。第二Codex 对技能指令的遵循程度和指令的清晰度强相关。指令写得越具体Codex 执行得越准确。第三Codex 在执行技能时可能会“自作主张”比如跳过某个步骤或者合并两个步骤。你可以在技能指令里加上“必须按顺序执行每一步不得跳过”这样的约束。第四Codex 的输出格式可以通过技能指令控制。如果你希望它输出 Markdown 表格就在指令里明确写“以 Markdown 表格形式输出”。6.4 Java 项目中的特殊注意事项Java 项目使用 superpowers 时有几个特殊点需要注意。Java 的构建工具通常是 Maven 或 Gradle技能里如果涉及编译和测试需要指定正确的构建命令。比如 Maven 项目用mvn testGradle 项目用gradle test。测试框架方面JUnit 4 和 JUnit 5 的 API 差异很大技能配置里要明确项目用的是哪个版本。Java 的包结构和命名规范比较严格代码生成技能需要读取项目的包声明和导入语句确保生成的代码放在正确的包下。另外Java 的异常处理机制和别的语言不一样检查异常必须显式处理技能在生成代码时要特别注意这一点。还有一个容易忽略的点是编码格式。Java 项目通常用 UTF-8但有些老项目可能用 GBK。技能在读写文件时要指定正确的编码否则中文注释会乱码。7. 我踩过的坑与实操心得装好 superpowers 只是第一步真正用起来顺不顺手取决于你对它的理解程度和配置的精细程度。我把自己踩过的几个坑分享一下希望能帮你少走弯路。第一个坑是贪多。刚开始我把能找到的技能全装上了结果 AI 每次对话都要扫描一大堆技能加载慢不说还经常触发不相关的技能输出一堆没用的内容。后来我做了减法只保留日常真正用到的五六个技能效率反而高了。技能这东西质量比数量重要。第二个坑是技能指令写得太抽象。我写第一个自定义技能时指令里写的是“检查代码是否符合规范”结果 AI 每次检查的标准都不一样有时候查命名有时候查注释有时候查异常处理完全没有一致性。后来我把指令改成具体的检查项列表每条都写清楚检查什么、怎么判断、不合格怎么处理输出才稳定下来。第三个坑是忽略技能之间的依赖。我有两个技能一个负责生成代码一个负责生成测试。我本来以为它们会各干各的结果生成测试的技能需要读取生成代码技能的输出但我没在技能定义里声明依赖导致测试技能经常在代码还没生成的时候就触发了生成一堆针对空文件的测试。后来补上依赖声明问题就解决了。第四个坑是不看日志。有段时间技能老是执行到一半就停了我以为是技能本身有问题折腾了半天。后来把日志级别调到 debug 一看发现是某个脚本执行超时被系统杀掉了。调整超时时间后一切正常。所以遇到问题先看日志能省很多瞎猜的时间。第五个坑是团队协作时技能版本不一致。我们团队一开始每个人用自己的技能库结果同一个技能在不同人那里行为不一样代码审查标准也不统一。后来我们把技能库统一到一个 Git 仓库用版本号管理每个人配置里指定同一个版本问题才解决。团队用 superpowers统一版本这件事一定要尽早做。最后分享一个小技巧技能写完之后别急着在正式项目里用。先找一个测试项目把技能跑几遍观察 AI 的执行过程看看有没有跳步、有没有理解偏差、输出格式对不对。测试项目跑顺了再放到正式项目里能避免很多尴尬。
