如果你用过AI编程工具大概率有过这种体验让它写个函数它能写得又快又像样但让它从零开始做一个完整功能它就容易东一榔头西一棒子改了这个忘了那个代码前后对不上。我一度以为是模型理解能力不行直到我接触了superpowers才意识到问题出在“做事的方法”上。superpowers是一套开源的技能集合专门给AI编程终端里的模型补充结构化的软件工程能力。它不是给你一段更长的提示词而是给AI配了一整套“工作手册”什么时候该问需求、怎么拆任务、怎么写测试、怎么验证改动每一个环节都有对应的技能文件和明确的执行步骤。对正在折腾AI辅助开发的人来说这套东西能把AI从“快问快答的聊天机器人”变成一个“按流程办事的开发助手”。后面我会把安装方式、核心技能清单、实际使用流程和踩坑记录一次性讲清楚。1. 这套“超能力”到底解决了什么问题1.1 提示词越写越长效果却越来越差先说个现象。很多人跟我一样一开始调教AI靠的是“堆提示词”。AI写得不对就追加几句“你再想想”“注意边界条件”“先写测试”……结果提示词越来越长AI的表现却不升反降。原因并不复杂大模型的上下文窗口是有限的你把大量“过程指令”塞进去真正留给代码和项目信息的空间就变少了而且零散的指令没有体系模型执行完一条就忘了下一条根本谈不上稳定。还有一个更隐蔽的问题提示词是“一次性”的。你这次说了“记得先写测试”下次换个会话它又忘了。项目一复杂靠临时对话约束AI行为完全不可持续。我当时试过把一整套开发规范写进系统提示词效果比什么都没有强但一旦项目变大提示词长度先撑不住了。1.2 superpowers把“做事的方法”打包成了技能superpowers的做法完全不同。它把软件开发里的高频动作拆成了一个个独立的“技能文件”每个技能包含三样东西技能的名字、什么时候用这个技能的描述、以及触发后AI要一步步执行的完整流程。这些技能文件放在固定目录里AI通过一个很简单的声明就能知道它们存在但不会把全部内容一次性读进上下文。真要用了它才打开对应的技能文件按里面的流程走。这样设计最大的好处是知识是“按需加载”的。平时AI的上下文只保留一份技能索引占不了多少空间当任务进入“写代码”阶段它再去读writing-code或implementing的完整动作不会因为指令太多而精神分裂。我做了一个粗浅的类比普通提示词等于每次开工前口头交代一堆要求superpowers等于给AI发了一套SOP手册它接到任务后自己去翻对应章节按手册执行。1.3 和普通提示词的区别我不太喜欢把“技能”说得太玄列个表格对比一下就很清楚了。对比项普通提示词superpowers技能存储位置写在对话里或系统提示词中独立的SKILL.md文件加载方式一次性全部进入上下文按需加载用时才读完整内容可复用性换个会话基本失效全局或项目级持久生效执行约束靠模型自觉容易遗漏步骤带编号的步骤逐条核对推进维护成本提示词越长越难维护每个技能独立更新互不干扰典型效果偶尔惊艳稳定性差稳定规范可预期这个表做完你大概能理解为什么社区里把这套东西叫“超能力”。它不是让AI变聪明而是让AI的工作方式变得有章法。2. 安装与引入三步把技能包挂上2.1 先确认环境和前置条件安装之前先确认几件事。superpowers是个第三方开源技能集合所以你需要一个支持技能机制的AI编程终端比如Claude Code这个是硬前提。没有这个环境后面的文件就算放了也不会被加载。另外你的机器上需要装好Git因为安装过程本质上是把一个Git仓库clone到本地。我没有在Windows上完整跑过但目录结构逻辑是一样的用WSL或者Git for Windows都能搞定。版本方面没有特别苛刻的要求我在终端工具比较新的版本上都试过加载正常。如果你用的版本太老建议先升级否则可能识别不了技能文件的元数据格式。这个坑我后面会写到。2.2 全局安装还是项目安装superpowers支持两种挂载级别全局和项目级。全局安装就是把技能放到了你用户目录下的全局技能文件夹里比如~/.claude/skills/。这样不管你打开哪个项目AI都能看到这套技能。好处是“一次安装处处可用”坏处是有些技能在A项目用得上、在B项目未必合适全局挂着会造成一点上下文索引上的噪音不过实际影响不算大。项目级安装则是把技能放进具体项目的.claude/skills/目录里只对当前项目生效。这种方案适合你有定制需求、经常切换不同类型项目的情况。我自己的习惯是通用开发技能走全局把个性化流程放进项目里。新手我建议先全局装等用熟了再按项目拆分不然一开始就要维护两套目录容易乱。2.3 具体安装步骤这里给一套我验证过多次的安装流程。第一步确保你的用户目录下存在技能目录mkdir -p ~/.claude/skills第二步把仓库克隆到全局技能目录里git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers如果你访问GitHub不稳定也可以直接把仓库的zip包下载下来解压后放进~/.claude/skills/效果一样。注意文件夹名字要保持superpowersAI是根据路径去索引技能文件的。第三步确认目录结构已经就位ls ~/.claude/skills/superpowers/skills正常情况下你会看到一大串以技能命名的子目录比如brainstorming、implementing、test-driven-development、writing-documentation等等。看到这些目录说明文件层面已经好了。2.4 让AI能“看到”技能文件放好了只是第一步还要让AI知道“这里有技能可用”。常见做法是在当前项目或全局的CLAUDE.md文件里写一行引用。CLAUDE.md是AI在会话启动时自动读取的说明文件相当于“给AI看的README”。在里面加上superpowers/skills如果你走的是项目级安装也可以使用指向项目内技能的相对路径。加好之后重启一下AI会话让它重新加载配置然后你可以在对话里直接问“你现在能看到哪些技能”它应该会列出一堆带名称和用途的技能。这里有个很容易踩的坑如果你只加了引用但没有重启会话AI大概率还是“看不到”新技能因为它是在会话开始时扫描技能目录的不会中途动态刷新。3. 都有哪些技能分别什么时候用3.1 规划类技能动手之前先想清楚superpowers里最让我惊喜的不是写代码的技能反而是动手之前的规划技能。kickoff一般是项目刚开始时用的。它会引导AI询问项目目标、范围、约束条件帮你把一个模糊的想法变成初步的项目骨架。brainstorming更适合需求还不明确的时候它会主动和你来回讨论探索各种可能性而不是急着给结论。我试过让它帮我梳理一个番茄钟应用的功能边界它把专注时长、休息提醒、任务列表、数据统计这些点全问了个遍最后才落成一个需求草案——这个过程像是有个资深同事在旁边追着问你“然后呢还有呢这里要不要考虑异常情况”。planning和scoping则用于把大目标拆成可执行的任务清单。planning产出的是带有优先级的实施计划scoping更偏“定义这次改动到底包含什么、不包含什么”。这两个技能特别适合项目中期AI能根据现有代码自动分析改动范围而不是拍脑袋给你列一堆任务。我遇到过最典型的一次是重构老模块AI直接用scoping把“无副作用的纯重构”和“顺带修bug”分开避免了一次范围蔓延。3.2 编码类技能把写代码变成流水线编码相关的技能数量最多也最实用。writing-code是基础的代码编写技能它强调先了解现有代码风格、接口约定再动手。implementing则更高级负责把一个具体功能完整落地。实际用下来implementing和test-driven-development经常是搭配出现的因为implementing会引导AI按TDD循环来先写一个失败测试运行确认测试失败再写最少代码让它通过最后重构。这个过程模拟了正经软件开发的节奏而不是一上来就闷头写一大堆。refactoring技能专治“代码能跑但不舒服”的情况。它不会直接帮你把整个文件重写一遍而是会先分析依赖关系告诉你哪些操作是安全的哪些需要额外测试保护。writing-tests可以单独使用用来给现有代码补测试它会根据代码路径和分支自动列出需要覆盖的场景。我用这些技能最大的感受是AI的产出质量确实变稳定了。以前让它加个功能它可能直接给你甩两百行代码里面一半是不需要的现在它自己会先看测试再动手改改完还要跑一遍验证。这个习惯一旦建立项目质量肉眼可见地上升。3.3 审查与验证类技能写完不等于完事写代码只是开发的一半superpowers里专门有一组技能管“事后验证”。reviewing-code会把AI变成一个代码审查员逐行检查改动关注点包括逻辑错误、边界条件、命名一致性、安全隐患以及是否和现有代码风格冲突。它产出的意见不是“我觉得这里可以优化”这种含糊话而是带具体行号和改进建议的清单。verifying-work更像一个“验收员”会检查需求是否真正满足、测试是否通过、有没有遗漏的文件改动。linting则聚焦在语法规范层面能按项目的lint配置检查代码风格。我第一次用reviewing-code审查自己刚写完的改动时被它提出来的几个边界问题搞得有点不好意思——那些确实是我急着提交时漏掉的。所以现在我的习惯是AI实现完功能后强制让它进入审查技能过一遍比自己肉眼盯着代码高效太多。3.4 文档与辅助类技能这部分容易被低估但真到写文档和交接的时候你会觉得真香。writing-documentation会先问清楚读者是谁、文档用途是什么再组织结构。它产出的README或接口说明比我手写工整得多基本可以直接用。explaining-code专门解释一段代码的逻辑适合你接手别人写的老模块时快速梳理脉络。reading-code则更进一步它会先建立调用关系再逐层深入最后给你一张“代码地图”。另外还有几个很实用的辅助技能比如creating-and-reviewing-technical-designs在动手写大功能前先产出技术设计文档choosing-the-open-source-license帮你分析该选哪种开源协议git-workflow和using-git用来约束提交习惯包括小步提交、规范commit message、及时开分支。不要小看这些“非写码”技能它们恰恰是普通AI最容易忽略的部分。3.5 常用技能速查整理一个常用技能速查表方便你按场景查找。场景推荐技能作用需求模糊想聊清楚brainstorming多轮提问收敛需求新项目启动kickoff创建项目骨架与方向拆解实施计划planning / scoping产出任务清单与范围写新功能implementing按TDD循环完整实现补测试writing-tests自动覆盖代码路径优化代码结构refactoring安全重构现有代码提交前检查reviewing-code代码审查并给出修改建议确认改动符合预期verifying-work验收功能与测试结果写README和文档writing-documentation生成结构化文档理解陌生代码reading-code / explaining-code梳理代码脉络与逻辑管理提交规范git-workflow规范Git操作流程这张表只是起点技能数量很多用几次之后你自己会有偏好。关键是找准“在哪个阶段调哪个技能”用得比装得多才有意义。4. 实战工作流从一个需求到提交代码4.1 阶段一用brainstorming把需求聊明白我拿一个实际的例子走一遍完整流程。假设我要给一个内部工具加“批量导入用户”功能。如果放在以前我大概率直接跟AI说“帮我写一个批量导入用户的功能”然后它就开始写CSV解析、去重逻辑、错误提示……搞得跟真的一样但需求里的关键问题一个都没问。用superpowers之后我先把brainstorming调出来让它主导讨论。它问了我大概十来个问题包括导入文件的格式是什么、字段映射规则、重复数据怎么处理、导入失败要不要提供回滚、是否需要进度条、批量大小限制是多少、有没有权限控制。这些问题我在脑子里确实有答案但如果没有被问到写出来的东西大概率缺漏。聊完之后AI还会基于结论输出一份简洁的需求描述这段描述可以直接作为下一步实施计划的输入。如果你觉得这些讨论步骤繁琐想直接进入编码阶段用scoping做一遍范围裁剪就行。它能根据你的回答判断哪些细节可以暂时忽略哪些必须在本次实现中考虑。我用下来的体会是这个追问环节值得你多花五到十分钟省的是后面返工的两小时。4.2 阶段二用planning把任务拆出来需求明确之后下一步是让AI生成实施计划。我调用planning技能把刚才brainstorming阶段的需求描述丢给AI。它会基于这些输入生成一个分步骤的实施方案包含大概的代码结构、涉及的文件、前后置依赖。输出通常长这样新增CSV解析工具模块定义字段映射规则实现批量校验逻辑跳过不符合格式的行编写用户创建服务处理去重与幂等在管理接口中接入导入端点限制单次导入上限补充错误处理与部分成功导入场景的提示为以上逻辑添加自动化测试看到这个清单我心里是有底的。因为它是按“可独立验证的成果”拆的不是按代码文件拆的。每个任务完成之后都可以单独测试很方便后续检查。这一步产出的计划我建议直接贴进会话上下文或写成项目内的短期todo文件方便AI在后续实施过程中持续对照防止跑偏。4.3 阶段三implementing TDD把代码写出来计划有了就可以正式进编码阶段了。我常用的姿势是直接说“用implementing技能开始执行第1到第3个任务”。这里有个小细节implementing并不建议“一口气全做完”它会自己按TDD循环推进每完成一个子任务就停下来看测试结果。我第一次用的时候AI会先为CSV解析模块写测试用例然后运行测试确认它们失败再补充实现代码让测试通过。看到模型真的在“先红后绿”我当时还是挺震撼的因为这不是提示词偶尔碰出来的行为而是它的固定流程。如果中途某个测试一直失败它不会硬写实现去糊弄而是会停下来分析失败原因必要时还会调用investigating去查相关代码的调用方式。这轮跑完批量导入的用户创建逻辑、接口接入、错误提示基本都有了。过程中我的角色更像是Reviewer偶尔出来确认几个细节其余的交给流程。4.4 阶段四reviewing verifying收尾最后收尾我是用一套组合拳先让AI用reviewing-code检查所有改动再跑verifying-work做全面验收。reviewing-code检查完列出来几个问题有一处CSV解析时表头大小写没做归一化、一个边界情况会导致空行被当成有效数据、导入接口缺少对超限请求的拦截。这些问题都很小但自动检查抓出来比事后测试暴露省事得多。我让AI逐个修复之后又跑了第二遍reviewing-code确认干净。verifying-work的验收维度更偏整体需求的每个点是否都有对应实现、测试是否全绿、有没有遗漏未提交的文件。它会贴一份类似checklist的结果逐项打勾。这个习惯帮我避免了至少两次“以为做完了、其实漏了一个文件没提交”的尴尬。4.5 实战心得技能怎么串起来才顺手走完一遍之后我给自己的工作流定了型brainstorming处理模糊需求scoping控制范围planning拆任务implementing按TDD实现reviewing和verifying收尾。这个流程跟传统软件开发的阶段其实一一对应区别只在于AI是主要的执行者而我是审核者和拍板人。一个值得说的细节是这些技能不要求你手动“结束”一个再启动下一个。你完全可以做完planning之后直接把结果丢给implementingAI会自己识别当前处于哪个阶段并读取对应的技能文件继续行动。你只需要在关键节点介入确保方向没跑偏。5. 常见问题与排查实录5.1 装完技能却完全不生效这是被问得最多的一个问题。技能装好了、目录结构也正常但AI就是不响应技能调用回复风格和以前完全没有区别。我遇到的情况多半是忘了在CLAUDE.md里加引用。技能不是装了就自动激活的你必须让AI在会话初始化时看到“这里有一批技能可用”。检查顺序先看技能目录路径是否在AI的默认搜索范围内再看CLAUDE.md里的引用路径是否拼写正确最后重启会话。如果你的终端工具带“重新加载配置”之类的命令直接执行也可以。还有一个容易被忽略的情况~/.claude/skills下面多了一层嵌套。有人clone下来之后发现技能目录变成了~/.claude/skills/superpowers/skills然后在CLAUDE.md里写错了路径自然加载不到。路径差一级都差很多建议用绝对路径写引用不要凭感觉猜。5.2 技能之间互相覆盖或冲突有时候你发现两个技能描述很接近AI不知道用哪个。比如writing-code和implementing都会指导写代码reviewing-code和verifying-work也有些重叠。这不算是bug而是技能设计上各有侧重前者更基础后者更完整流程。实际用的时候尽量把话说明白不要只喊“写代码”而是说“用implementing技能按TDD流程实现这个功能”。指令里的技能名越明确AI选错的可能性越小。如果多个技能仓库同时装了而且有同名技能一般是越靠前的优先。遇到这种情况把你不需要的那个仓库从技能目录移走或改名优先级就清楚了。我自己吃过一次亏同时挂了两套技能包结果同一类任务老是触发“懒洋洋的通用版”后来只主用superpowers问题就消失了。5.3 老版本升级和仓库同步superpowers迭代速度不算慢作者会不定期往里面加技能或修正已有技能的步骤描述。老版本和当前AI终端版本之间偶尔会出现兼容小问题比如技能元数据格式识别不对、技能描述里提到的指令已经改名。升级方法很简单只需要进到技能仓库目录里拉一下最新代码cd ~/.claude/skills/superpowers git pull origin main拉完代码后建议重启AI会话。我的习惯是每隔一两周拉一次保持技能库新鲜。如果你用zip包安装的就重新下载解压覆盖一次记得先备份你本地改过的技能文件否则会被覆盖掉。5.4 superpowers和内置技能、MCP工具怎么共存这个我特意提一下因为很多人问“superpowers会不会和机器人自带的技能冲突”。实际上它是独立的技能集合和内置技能、MCP工具不在一个层面内置技能解决“模型基础能力”superpowers解决“软件开发工作流规范”MCP工具解决“连接外部系统数据”。三者可以同时存在互不排斥。举个例子MCP可以给AI提供数仓表结构查询、Github操作能力superpowers则确保AI在修改代码前先看测试、在提交前先做审查。没有superpowersMCP工具用起来像“有手但没脑子”两者组合起来才是完整的开发体验。唯一要注意的是技能描述里如果涉及外部工具调用确保对应的MCP服务已经挂载否则AI会按步骤走到一半发现工具不可用卡在那里。5.5 技能被跳过或者“先斩后奏”如果你发现AI在实现时没有严格执行技能流程而是直接写了一大段代码大概率是它没有在任务开始时加载技能文件。可以检查一下任务描述里是否明确提到了技能名如果没有AI会选择默认的生成式响应路径。我的经验是想让流程被遵守你需要在第一条指令里就把技能名和具体任务绑定在一起最好也说明“先做planning再进入implementing”。一旦AI在中途跳出流程你可以明确要求“回到implementing技能流程从第3步开始”。这种强约束在前期很有效等它形成习惯后你会省力很多。我自己现在已经在常用项目里把这套工作流固定下来了效果比裸用AI好了不止一个档次。如果你正为“AI总是不按套路出牌”而头疼我建议从最小的场景开始试先给AI装好技能在下一次写代码时强制让它走一遍brainstorming-planning-implementing-reviewing感受一次完整的流程约束再判断要不要深入用。只要试过一次你大概就回不去了。 
长河君 · 2026/10/8 12:03:14 · 阅读 1.2k AI编程总跑偏？superpowers用技能文件把AI变成工程化助手
如果你用过AI编程工具大概率有过这种体验让它写个函数它能写得又快又像样但让它从零开始做一个完整功能它就容易东一榔头西一棒子改了这个忘了那个代码前后对不上。我一度以为是模型理解能力不行直到我接触了superpowers才意识到问题出在“做事的方法”上。superpowers是一套开源的技能集合专门给AI编程终端里的模型补充结构化的软件工程能力。它不是给你一段更长的提示词而是给AI配了一整套“工作手册”什么时候该问需求、怎么拆任务、怎么写测试、怎么验证改动每一个环节都有对应的技能文件和明确的执行步骤。对正在折腾AI辅助开发的人来说这套东西能把AI从“快问快答的聊天机器人”变成一个“按流程办事的开发助手”。后面我会把安装方式、核心技能清单、实际使用流程和踩坑记录一次性讲清楚。1. 这套“超能力”到底解决了什么问题1.1 提示词越写越长效果却越来越差先说个现象。很多人跟我一样一开始调教AI靠的是“堆提示词”。AI写得不对就追加几句“你再想想”“注意边界条件”“先写测试”……结果提示词越来越长AI的表现却不升反降。原因并不复杂大模型的上下文窗口是有限的你把大量“过程指令”塞进去真正留给代码和项目信息的空间就变少了而且零散的指令没有体系模型执行完一条就忘了下一条根本谈不上稳定。还有一个更隐蔽的问题提示词是“一次性”的。你这次说了“记得先写测试”下次换个会话它又忘了。项目一复杂靠临时对话约束AI行为完全不可持续。我当时试过把一整套开发规范写进系统提示词效果比什么都没有强但一旦项目变大提示词长度先撑不住了。1.2 superpowers把“做事的方法”打包成了技能superpowers的做法完全不同。它把软件开发里的高频动作拆成了一个个独立的“技能文件”每个技能包含三样东西技能的名字、什么时候用这个技能的描述、以及触发后AI要一步步执行的完整流程。这些技能文件放在固定目录里AI通过一个很简单的声明就能知道它们存在但不会把全部内容一次性读进上下文。真要用了它才打开对应的技能文件按里面的流程走。这样设计最大的好处是知识是“按需加载”的。平时AI的上下文只保留一份技能索引占不了多少空间当任务进入“写代码”阶段它再去读writing-code或implementing的完整动作不会因为指令太多而精神分裂。我做了一个粗浅的类比普通提示词等于每次开工前口头交代一堆要求superpowers等于给AI发了一套SOP手册它接到任务后自己去翻对应章节按手册执行。1.3 和普通提示词的区别我不太喜欢把“技能”说得太玄列个表格对比一下就很清楚了。对比项普通提示词superpowers技能存储位置写在对话里或系统提示词中独立的SKILL.md文件加载方式一次性全部进入上下文按需加载用时才读完整内容可复用性换个会话基本失效全局或项目级持久生效执行约束靠模型自觉容易遗漏步骤带编号的步骤逐条核对推进维护成本提示词越长越难维护每个技能独立更新互不干扰典型效果偶尔惊艳稳定性差稳定规范可预期这个表做完你大概能理解为什么社区里把这套东西叫“超能力”。它不是让AI变聪明而是让AI的工作方式变得有章法。2. 安装与引入三步把技能包挂上2.1 先确认环境和前置条件安装之前先确认几件事。superpowers是个第三方开源技能集合所以你需要一个支持技能机制的AI编程终端比如Claude Code这个是硬前提。没有这个环境后面的文件就算放了也不会被加载。另外你的机器上需要装好Git因为安装过程本质上是把一个Git仓库clone到本地。我没有在Windows上完整跑过但目录结构逻辑是一样的用WSL或者Git for Windows都能搞定。版本方面没有特别苛刻的要求我在终端工具比较新的版本上都试过加载正常。如果你用的版本太老建议先升级否则可能识别不了技能文件的元数据格式。这个坑我后面会写到。2.2 全局安装还是项目安装superpowers支持两种挂载级别全局和项目级。全局安装就是把技能放到了你用户目录下的全局技能文件夹里比如~/.claude/skills/。这样不管你打开哪个项目AI都能看到这套技能。好处是“一次安装处处可用”坏处是有些技能在A项目用得上、在B项目未必合适全局挂着会造成一点上下文索引上的噪音不过实际影响不算大。项目级安装则是把技能放进具体项目的.claude/skills/目录里只对当前项目生效。这种方案适合你有定制需求、经常切换不同类型项目的情况。我自己的习惯是通用开发技能走全局把个性化流程放进项目里。新手我建议先全局装等用熟了再按项目拆分不然一开始就要维护两套目录容易乱。2.3 具体安装步骤这里给一套我验证过多次的安装流程。第一步确保你的用户目录下存在技能目录mkdir -p ~/.claude/skills第二步把仓库克隆到全局技能目录里git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers如果你访问GitHub不稳定也可以直接把仓库的zip包下载下来解压后放进~/.claude/skills/效果一样。注意文件夹名字要保持superpowersAI是根据路径去索引技能文件的。第三步确认目录结构已经就位ls ~/.claude/skills/superpowers/skills正常情况下你会看到一大串以技能命名的子目录比如brainstorming、implementing、test-driven-development、writing-documentation等等。看到这些目录说明文件层面已经好了。2.4 让AI能“看到”技能文件放好了只是第一步还要让AI知道“这里有技能可用”。常见做法是在当前项目或全局的CLAUDE.md文件里写一行引用。CLAUDE.md是AI在会话启动时自动读取的说明文件相当于“给AI看的README”。在里面加上superpowers/skills如果你走的是项目级安装也可以使用指向项目内技能的相对路径。加好之后重启一下AI会话让它重新加载配置然后你可以在对话里直接问“你现在能看到哪些技能”它应该会列出一堆带名称和用途的技能。这里有个很容易踩的坑如果你只加了引用但没有重启会话AI大概率还是“看不到”新技能因为它是在会话开始时扫描技能目录的不会中途动态刷新。3. 都有哪些技能分别什么时候用3.1 规划类技能动手之前先想清楚superpowers里最让我惊喜的不是写代码的技能反而是动手之前的规划技能。kickoff一般是项目刚开始时用的。它会引导AI询问项目目标、范围、约束条件帮你把一个模糊的想法变成初步的项目骨架。brainstorming更适合需求还不明确的时候它会主动和你来回讨论探索各种可能性而不是急着给结论。我试过让它帮我梳理一个番茄钟应用的功能边界它把专注时长、休息提醒、任务列表、数据统计这些点全问了个遍最后才落成一个需求草案——这个过程像是有个资深同事在旁边追着问你“然后呢还有呢这里要不要考虑异常情况”。planning和scoping则用于把大目标拆成可执行的任务清单。planning产出的是带有优先级的实施计划scoping更偏“定义这次改动到底包含什么、不包含什么”。这两个技能特别适合项目中期AI能根据现有代码自动分析改动范围而不是拍脑袋给你列一堆任务。我遇到过最典型的一次是重构老模块AI直接用scoping把“无副作用的纯重构”和“顺带修bug”分开避免了一次范围蔓延。3.2 编码类技能把写代码变成流水线编码相关的技能数量最多也最实用。writing-code是基础的代码编写技能它强调先了解现有代码风格、接口约定再动手。implementing则更高级负责把一个具体功能完整落地。实际用下来implementing和test-driven-development经常是搭配出现的因为implementing会引导AI按TDD循环来先写一个失败测试运行确认测试失败再写最少代码让它通过最后重构。这个过程模拟了正经软件开发的节奏而不是一上来就闷头写一大堆。refactoring技能专治“代码能跑但不舒服”的情况。它不会直接帮你把整个文件重写一遍而是会先分析依赖关系告诉你哪些操作是安全的哪些需要额外测试保护。writing-tests可以单独使用用来给现有代码补测试它会根据代码路径和分支自动列出需要覆盖的场景。我用这些技能最大的感受是AI的产出质量确实变稳定了。以前让它加个功能它可能直接给你甩两百行代码里面一半是不需要的现在它自己会先看测试再动手改改完还要跑一遍验证。这个习惯一旦建立项目质量肉眼可见地上升。3.3 审查与验证类技能写完不等于完事写代码只是开发的一半superpowers里专门有一组技能管“事后验证”。reviewing-code会把AI变成一个代码审查员逐行检查改动关注点包括逻辑错误、边界条件、命名一致性、安全隐患以及是否和现有代码风格冲突。它产出的意见不是“我觉得这里可以优化”这种含糊话而是带具体行号和改进建议的清单。verifying-work更像一个“验收员”会检查需求是否真正满足、测试是否通过、有没有遗漏的文件改动。linting则聚焦在语法规范层面能按项目的lint配置检查代码风格。我第一次用reviewing-code审查自己刚写完的改动时被它提出来的几个边界问题搞得有点不好意思——那些确实是我急着提交时漏掉的。所以现在我的习惯是AI实现完功能后强制让它进入审查技能过一遍比自己肉眼盯着代码高效太多。3.4 文档与辅助类技能这部分容易被低估但真到写文档和交接的时候你会觉得真香。writing-documentation会先问清楚读者是谁、文档用途是什么再组织结构。它产出的README或接口说明比我手写工整得多基本可以直接用。explaining-code专门解释一段代码的逻辑适合你接手别人写的老模块时快速梳理脉络。reading-code则更进一步它会先建立调用关系再逐层深入最后给你一张“代码地图”。另外还有几个很实用的辅助技能比如creating-and-reviewing-technical-designs在动手写大功能前先产出技术设计文档choosing-the-open-source-license帮你分析该选哪种开源协议git-workflow和using-git用来约束提交习惯包括小步提交、规范commit message、及时开分支。不要小看这些“非写码”技能它们恰恰是普通AI最容易忽略的部分。3.5 常用技能速查整理一个常用技能速查表方便你按场景查找。场景推荐技能作用需求模糊想聊清楚brainstorming多轮提问收敛需求新项目启动kickoff创建项目骨架与方向拆解实施计划planning / scoping产出任务清单与范围写新功能implementing按TDD循环完整实现补测试writing-tests自动覆盖代码路径优化代码结构refactoring安全重构现有代码提交前检查reviewing-code代码审查并给出修改建议确认改动符合预期verifying-work验收功能与测试结果写README和文档writing-documentation生成结构化文档理解陌生代码reading-code / explaining-code梳理代码脉络与逻辑管理提交规范git-workflow规范Git操作流程这张表只是起点技能数量很多用几次之后你自己会有偏好。关键是找准“在哪个阶段调哪个技能”用得比装得多才有意义。4. 实战工作流从一个需求到提交代码4.1 阶段一用brainstorming把需求聊明白我拿一个实际的例子走一遍完整流程。假设我要给一个内部工具加“批量导入用户”功能。如果放在以前我大概率直接跟AI说“帮我写一个批量导入用户的功能”然后它就开始写CSV解析、去重逻辑、错误提示……搞得跟真的一样但需求里的关键问题一个都没问。用superpowers之后我先把brainstorming调出来让它主导讨论。它问了我大概十来个问题包括导入文件的格式是什么、字段映射规则、重复数据怎么处理、导入失败要不要提供回滚、是否需要进度条、批量大小限制是多少、有没有权限控制。这些问题我在脑子里确实有答案但如果没有被问到写出来的东西大概率缺漏。聊完之后AI还会基于结论输出一份简洁的需求描述这段描述可以直接作为下一步实施计划的输入。如果你觉得这些讨论步骤繁琐想直接进入编码阶段用scoping做一遍范围裁剪就行。它能根据你的回答判断哪些细节可以暂时忽略哪些必须在本次实现中考虑。我用下来的体会是这个追问环节值得你多花五到十分钟省的是后面返工的两小时。4.2 阶段二用planning把任务拆出来需求明确之后下一步是让AI生成实施计划。我调用planning技能把刚才brainstorming阶段的需求描述丢给AI。它会基于这些输入生成一个分步骤的实施方案包含大概的代码结构、涉及的文件、前后置依赖。输出通常长这样新增CSV解析工具模块定义字段映射规则实现批量校验逻辑跳过不符合格式的行编写用户创建服务处理去重与幂等在管理接口中接入导入端点限制单次导入上限补充错误处理与部分成功导入场景的提示为以上逻辑添加自动化测试看到这个清单我心里是有底的。因为它是按“可独立验证的成果”拆的不是按代码文件拆的。每个任务完成之后都可以单独测试很方便后续检查。这一步产出的计划我建议直接贴进会话上下文或写成项目内的短期todo文件方便AI在后续实施过程中持续对照防止跑偏。4.3 阶段三implementing TDD把代码写出来计划有了就可以正式进编码阶段了。我常用的姿势是直接说“用implementing技能开始执行第1到第3个任务”。这里有个小细节implementing并不建议“一口气全做完”它会自己按TDD循环推进每完成一个子任务就停下来看测试结果。我第一次用的时候AI会先为CSV解析模块写测试用例然后运行测试确认它们失败再补充实现代码让测试通过。看到模型真的在“先红后绿”我当时还是挺震撼的因为这不是提示词偶尔碰出来的行为而是它的固定流程。如果中途某个测试一直失败它不会硬写实现去糊弄而是会停下来分析失败原因必要时还会调用investigating去查相关代码的调用方式。这轮跑完批量导入的用户创建逻辑、接口接入、错误提示基本都有了。过程中我的角色更像是Reviewer偶尔出来确认几个细节其余的交给流程。4.4 阶段四reviewing verifying收尾最后收尾我是用一套组合拳先让AI用reviewing-code检查所有改动再跑verifying-work做全面验收。reviewing-code检查完列出来几个问题有一处CSV解析时表头大小写没做归一化、一个边界情况会导致空行被当成有效数据、导入接口缺少对超限请求的拦截。这些问题都很小但自动检查抓出来比事后测试暴露省事得多。我让AI逐个修复之后又跑了第二遍reviewing-code确认干净。verifying-work的验收维度更偏整体需求的每个点是否都有对应实现、测试是否全绿、有没有遗漏未提交的文件。它会贴一份类似checklist的结果逐项打勾。这个习惯帮我避免了至少两次“以为做完了、其实漏了一个文件没提交”的尴尬。4.5 实战心得技能怎么串起来才顺手走完一遍之后我给自己的工作流定了型brainstorming处理模糊需求scoping控制范围planning拆任务implementing按TDD实现reviewing和verifying收尾。这个流程跟传统软件开发的阶段其实一一对应区别只在于AI是主要的执行者而我是审核者和拍板人。一个值得说的细节是这些技能不要求你手动“结束”一个再启动下一个。你完全可以做完planning之后直接把结果丢给implementingAI会自己识别当前处于哪个阶段并读取对应的技能文件继续行动。你只需要在关键节点介入确保方向没跑偏。5. 常见问题与排查实录5.1 装完技能却完全不生效这是被问得最多的一个问题。技能装好了、目录结构也正常但AI就是不响应技能调用回复风格和以前完全没有区别。我遇到的情况多半是忘了在CLAUDE.md里加引用。技能不是装了就自动激活的你必须让AI在会话初始化时看到“这里有一批技能可用”。检查顺序先看技能目录路径是否在AI的默认搜索范围内再看CLAUDE.md里的引用路径是否拼写正确最后重启会话。如果你的终端工具带“重新加载配置”之类的命令直接执行也可以。还有一个容易被忽略的情况~/.claude/skills下面多了一层嵌套。有人clone下来之后发现技能目录变成了~/.claude/skills/superpowers/skills然后在CLAUDE.md里写错了路径自然加载不到。路径差一级都差很多建议用绝对路径写引用不要凭感觉猜。5.2 技能之间互相覆盖或冲突有时候你发现两个技能描述很接近AI不知道用哪个。比如writing-code和implementing都会指导写代码reviewing-code和verifying-work也有些重叠。这不算是bug而是技能设计上各有侧重前者更基础后者更完整流程。实际用的时候尽量把话说明白不要只喊“写代码”而是说“用implementing技能按TDD流程实现这个功能”。指令里的技能名越明确AI选错的可能性越小。如果多个技能仓库同时装了而且有同名技能一般是越靠前的优先。遇到这种情况把你不需要的那个仓库从技能目录移走或改名优先级就清楚了。我自己吃过一次亏同时挂了两套技能包结果同一类任务老是触发“懒洋洋的通用版”后来只主用superpowers问题就消失了。5.3 老版本升级和仓库同步superpowers迭代速度不算慢作者会不定期往里面加技能或修正已有技能的步骤描述。老版本和当前AI终端版本之间偶尔会出现兼容小问题比如技能元数据格式识别不对、技能描述里提到的指令已经改名。升级方法很简单只需要进到技能仓库目录里拉一下最新代码cd ~/.claude/skills/superpowers git pull origin main拉完代码后建议重启AI会话。我的习惯是每隔一两周拉一次保持技能库新鲜。如果你用zip包安装的就重新下载解压覆盖一次记得先备份你本地改过的技能文件否则会被覆盖掉。5.4 superpowers和内置技能、MCP工具怎么共存这个我特意提一下因为很多人问“superpowers会不会和机器人自带的技能冲突”。实际上它是独立的技能集合和内置技能、MCP工具不在一个层面内置技能解决“模型基础能力”superpowers解决“软件开发工作流规范”MCP工具解决“连接外部系统数据”。三者可以同时存在互不排斥。举个例子MCP可以给AI提供数仓表结构查询、Github操作能力superpowers则确保AI在修改代码前先看测试、在提交前先做审查。没有superpowersMCP工具用起来像“有手但没脑子”两者组合起来才是完整的开发体验。唯一要注意的是技能描述里如果涉及外部工具调用确保对应的MCP服务已经挂载否则AI会按步骤走到一半发现工具不可用卡在那里。5.5 技能被跳过或者“先斩后奏”如果你发现AI在实现时没有严格执行技能流程而是直接写了一大段代码大概率是它没有在任务开始时加载技能文件。可以检查一下任务描述里是否明确提到了技能名如果没有AI会选择默认的生成式响应路径。我的经验是想让流程被遵守你需要在第一条指令里就把技能名和具体任务绑定在一起最好也说明“先做planning再进入implementing”。一旦AI在中途跳出流程你可以明确要求“回到implementing技能流程从第3步开始”。这种强约束在前期很有效等它形成习惯后你会省力很多。我自己现在已经在常用项目里把这套工作流固定下来了效果比裸用AI好了不止一个档次。如果你正为“AI总是不按套路出牌”而头疼我建议从最小的场景开始试先给AI装好技能在下一次写代码时强制让它走一遍brainstorming-planning-implementing-reviewing感受一次完整的流程约束再判断要不要深入用。只要试过一次你大概就回不去了。