1. 项目概述与核心价值1.1 这个项目解决什么问题最近几个月AI编程助手几乎成了我每天的标配。写个脚本、补个测试、重构一段逻辑只要把需求往对话框里一扔几秒钟就能拿到能跑的代码。但用久了你会发现一个尴尬的问题AI写小东西很利索一碰到稍微有点规模的需求就开始“飘”。什么叫“飘”就是你让它给一个页面加个表单校验它顺手就把整个页面的样式改了你让它修一个接口超时的bug它给你重构了半个模块你让它实现一个用户注册功能它不管三七二十一先甩给你一坨代码连字段约束、异常分支、边界条件都没想清楚。结果就是代码能跑但改起来处处是雷验收时一堆隐性隐患。问题出在哪出在AI没有“软件工程套路”。传统项目里需求分析、设计评审、任务拆解、编码规范、验收测试每一步都有人盯着把大问题切成小问题把模糊问题变成明确问题。但AI编程助手没有这一套你给它一个模糊指令它就直接跳到“写代码”这一步中间全跳过了。就像让一个刚毕业的实习生直接上手一个老项目核心模块他大概率会先写出一堆让你血压升高的代码。Superpowers这个框架就是冲着这个问题去的。它是一套基于Claude Code的技能框架核心思路特别朴素与其每次都要用人话去教育AI“你先理需求、再定方案、再动手”不如把一整套软件工程工作流预先封装成“技能包”让AI接到任务后自动走完这些流程。实测下来AI的输出质量真的上了一个台阶至少不会一言不合就甩代码了。1.2 适合谁来用先说说这个项目适合谁。如果你属于下面几类人Superpowers大概率能帮到你每天高频使用Claude Code、Codex这类终端型AI编程工具的重度用户受够了AI“答非所问式”的代码输出。带团队做项目的技术负责人想让AI按团队统一的编码规范、提交流程、测试标准来干活而不是每个人调教出来的AI风格千奇百怪。正在学习软件工程流程的开发者想看看“需求分析→设计→编码→验证”这套流程如何被拆成可执行的动作让AI一步步走给你看。对AI编程上限好奇的玩家想试试把AI从“代码生成器”升级成“AI开发工程师”是什么体验。不过有一点得说清楚Superpowers不是那种装了就能用的“银弹”。它像一个“流程框架”需要你花半小时理解它的技能组织方式再根据自己的项目特点做少量定制。但回报也很直接——当你发现AI居然会在动手前先跟你说“我需要明确一下验收标准”的时候那种感觉还挺奇妙的。2. 核心机制拆解AI编程助手为什么需要“技能包”2.1 从“闲聊式对话”到“技能式工作流”要理解Superpowers先要理解Claude Code本身的工作方式。Claude Code是一个跑在终端里的AI编程工具它能在你的命令行里读取文件、写代码、执行测试命令甚至帮你提交Git变更。用过的人都知道它的自然语言理解能力很强但缺一个东西——结构化流程。普通模式下你和Claude的交互是“闲聊式”的你说一句它答一句它很少主动反问“你的验收标准是什么”“这个需求涉及哪些模块”。而Superpowers做的事情就是把Claude Code的能力重新组织成一套“技能系统”。每个技能是一个拥有独立提示词、工作流程、输出规范的小型“认知模块”类似给AI装上了一个个岗位说明书。这里面最精髓的设计是它不是用一段长提示词来约束AI而是用一套分层的技能文件来引导AI。Claude Code支持在项目里放一个.claude/skills/目录里面每个子目录对应一个技能技能目录里有一个SKILL.md文件里面写着这个技能的完整定义——包括适用场景、执行步骤、输入输出要求。当对话中触发某个技能时Claude会主动加载这个技能的定义然后按照里面的步骤来工作。你想想这意味着什么它不再是一个什么都能聊两句的“通用助手”而是一个清楚自己“当前该干什么”“下一步干什么”“干到什么程度算完”的执行者。这个思路其实和工程上的“BPM流程编排”有异曲同工之妙只不过被编排的对象不是人工任务而是AI的思考路径。2.2 技能目录里到底装了什么Superpowers把技能分成了两大类用两种不同的引用方式触发第一类是前置引用技能Slash Commands以.md文件形式散落在项目根目录的skills/文件夹里。这些技能通常是你主动调用的比如输入/superpowers就能弹出一个“主菜单”让AI说明自己掌握了哪些技能输入/frontend就能进入“前端开发专用工作流”AI会先和你确认技术栈、设计规范再进入实现阶段。第二类是自动发现技能存放在.claude/skills/目录里。这些技能不需要你手动调用Claude Code在读代码时会自动加载它们。比如你打开一个Python项目AI可能会自动调用Skill: python-linter相关技能检查代码有没有违反PEP 8规范然后按规范来写新代码。我翻了下它的技能清单覆盖范围还是相当完整的技能名称触发方式核心作用Bootstrap Superpowers安装时自动执行把整个框架注入项目生成初始技能文件Skill: frontend自动/手动接管前端开发的完整流程从需求确认到UI落地Skill: execute-script自动在执行脚本前确认参数、影响范围、安全风险Skill: superpowersSlash命令让AI展示全部技能列表并选择工作模式Skill: test-driven-development自动引导走“先写失败测试→再写实现→最后重构”的TDD流程Skill: writing-plans自动生成策划文档把大需求拆成可执行的任务清单Skill: system-config-analyzer自动分析当前系统环境辅助排查环境导致的异常这套技能组合起来基本上覆盖了一个正经软件项目从分析、设计、编码到验证的全部环节。关键是它把这些环节固化成了AI的“肌肉记忆”不需要你每次苦口婆心地交代。2.3 为什么“过程管理”比“结果管理”更靠谱我之前的习惯是给AI一个明确的结果指令“帮我写一个用户登录接口用JWT做鉴权”。结果它确实写出来了但没写输入校验、没处理token过期、没考虑密码加密方式。你让它补充它再补一层但可能又引入别的坑。这种“挤牙膏式”的开发本质是结果导向——你只给了它目标没有给它过程约束。Superpowers的厉害之处在于它把“软件开发的质量保障机制”前置到了AI的思考过程里。比如前端技能流水线里AI在写任何组件之前会先输出一份规范文档里面写清楚“这个页面的设计模式是什么”“状态管理放在哪一层”“组件拆分的粒度标准是什么”。这些规范不是摆设它们在后续每一步都会被AI自己引用。换句话说AI在被“逼着”做设计决策而不是闷头堆代码。这个思路解决了一个我一直觉得AI编程最大的隐患AI的上下文窗口是有限的它的工作记忆只能装下最近几十条消息。如果它在动手前不把关键约束写进文件里写到一半大概率就把你最开始的要求忘了。而Superpowers通过强制前置的规范文档和计划文档把这些约束“外置”到文件系统里随时可以回去翻。这个设计真的懂软件工程。3. 实操过程从零安装到跑通第一个前端需求3.1 准备阶段与安装步骤实际动手之前先说下前提Superpowers依赖Claude Code所以你电脑上要先装好Claude Code并完成登录。Node.js环境建议16以上实测20基本没有兼容问题。操作系统方面macOS和Linux体验最好Windows下如果你用的是PowerShell有些脚本可能跑得没那么顺畅。安装分两步。第一步把框架本体拉下来。官方推荐的方式是直接克隆仓库或用installer脚本装完后你会得到一个skills/目录里面是全套技能模板。第二步在Claude Code里发起对话让AI执行“Bootstrap Superpowers”这个动作。它会把框架的核心技能文件复制到你的项目目录并根据项目语言自动生成定制化的技能配置。这里有个容易踩的坑框架安装后你的项目目录下会多出不少技能文件。我第一次装完发现目录突然变乱一度以为安装出问题了。后来才明白这些就是AI的“工作准则文件”是刻意放在项目里的不用管它们甚至提交到Git仓库里都没关系。团队协作时这些文件反而能保证所有人的AI按同一套规范干活。3.2 初始化配置与第一个技能调用装完框架后打开Claude Code建议先输入/superpowers。这时候AI会列出它掌握的全部技能并询问你这次任务的工作模式。你选一个就相当于给AI“安排了一个岗位”。我实际操作时的对话大概是这样的我/superpowers AI我已加载技能库当前可用的工作模式包括快速任务模式直接执行小需求、完整开发模式从需求分析到验收全流程、TDD测试驱动模式、计划撰写模式。请告诉我本次任务类型以及你期望的完成标准。这个交互很关键因为它在强迫你——是的是“强迫”——先想清楚需求边界。如果你只说“帮我写个页面”AI会继续追问技术栈是什么、目标用户是谁、有没有设计稿或参考页面这种追问其实就是在帮你做需求澄清这个动作传统项目管理里叫“需求评审”现在由AI来执行了。我第一次完整调用的是前端工作流交互路径是这样的我告诉它“我想给现有项目加一个商品列表页支持搜索和分页”。它没有直接写代码而是先输出了一份“前端实现计划”列明了组件结构、状态管理方案、接口约定、样式规范。我确认后它才进入编码阶段一个文件一个文件地实现。每个文件写完后它还主动提示我可以运行测试或预览。整个流程走下来最大的感受就是AI的代码输出突然变得“有章法”了每个文件都有自己的角色和边界不再是一坨逻辑纠缠在一起的“面条代码”。3.3 前端工作流从规范文档到UI落地既然前端是我觉得变化最大的部分就多写几句这里面的细节。Superpowers的前端工作流定义了一个“规范优先”的管线写代码之前先写规范文档写规范之前先确认需求。它实际操作中大概分四步第一步需求框定。AI会向你确认几个核心问题页面是移动端优先还是桌面端优先、有没有设计系统或UI组件库、项目现有的代码风格是什么。这一步看起来啰嗦但信息价值很大因为它决定了后面所有代码的风格取向。第二步生成规范文档。AI会在项目里生成类似docs/frontend-standards.md的文件里面记录刚才确认的技术决策。这个文档之后会作为“宪法”被AI反复引用保证整个项目所有页面的一致性。第三步组件化拆解。AI会把你需要的页面拆成若干个小组件并定义每个组件的props和事件接口。我在测试时发现它居然会主动分辨“哪些组件是通用组件应该抽出来”“哪些是页面私有组件应该就近放置”分解逻辑和团队里资深前端的判断基本一致。第四步编码实现。这个阶段AI才会开始写代码而且是按组件逐个推进完成一个确认一个。整个过程全程可审查、可回退不会再出现“一改改一大片”的情况。这套流程跑下来我对“AI编程”的认知改变了不少。以前觉得关键是让AI写出能跑的代码现在觉得真正值钱的是让AI以对的方式思考——思考需求边界、思考模块划分、思考利益相关者的验收期望。3.4 计划撰写与TDD工作流的搭配使用如果只是写前端页面Superpowers的普通工作流已经够用。但如果你想让它做更复杂、更容易出bug的任务我强烈建议组合使用“计划撰写”和“TDD测试驱动开发”这两个技能。“计划撰写”技能会引导AI在动代码之前先生成一个完整的工作计划包括背景与目标、任务拆解、依赖分析、验收标准、风险点。这个计划不是走过场AI在后续实现时会逐条对照计划未完成的任务会继续跟踪已完成的任务会标记。有几次我甚至觉得它的计划管理能力比一些刚入行的项目经理还强。TDD技能则是强迫AI走“红-绿-重构”循环先写一个失败的测试用例再写最简代码让测试通过最后重构优化。这个过程对AI来说其实是“逆天”的因为AI天然倾向于直接给你完整实现。但有了技能约束后它会一步步来。实测下来虽然整个开发耗时变长但最终的代码质量确实高很多尤其适合业务逻辑复杂的模块比如订单状态机、支付回调处理这种“边界条件一箩筐”的场景。4. 核心技能深度解析与定制经验4.1 Skill: frontend 与 Skill: execute-script 的分工逻辑Superpowers里有两个技能我觉得特别能体现设计者的用心一个是Skill: frontend一个是Skill: execute-script。这两个技能一个管“怎么写”一个管“怎么跑”正好对应了软件工程里“编码规范”和“变更控制”两个核心概念。先说Skill: frontend。这个技能的完整提示词我没展开看全部但它的执行模式非常有代表性它不是“一个万能前端AI”而是“一个按照规范流水线作业的前端实现器”。它要求AI在实现功能时遵循一个“黄金路径”先寻找类似功能的实现作为参考再检查现有代码的约定然后才动手修改。这其实就是工程上讲的“最小改动原则”和“一致性原则”。再说Skill: execute-script。这个技能管的是“执行脚本”这件事。平时我们让AI跑个脚本它可能会直接执行风险极大。但有了这个技能后AI在执行任何脚本之前会先跟你确认三件事这个脚本是干什么的、会修改哪些文件、有没有风险评估。确认之后它还会先做一个“dry-run”预演把将执行的命令完整展示给你看等你说“执行”它才会动手。这个设计对我这种要管理生产环境的人来说简直太有用了。以前每次让AI帮忙改个线上配置都得盯着它生怕它一把梭把整个环境搞挂。现在相当于给AI上了一道“变更审批流程”多了一重保险。4.2 如何评估和定制技能包Superpowers默认带了几十个技能但你在实际项目中不一定全部用得上。技能包这种东西属于“按需装配”。我的建议是分三步做定制。第一步先跑一遍/superpowers把技能全列出来识别哪些是当前项目刚需。比如纯后端项目frontend技能就可以剔除纯脚本工具项目test-driven-development暂时用不上。第二步针对刚需技能细读SKILL.md文件理解它的工作流程。你会发现每个技能都写得极其详细连“对话开场白应该问哪些问题”这种细节都有定义。如果某些默认行为不符合你的习惯可以直接改这个文件——它就是一份给AI看的需求说明书。第三步根据项目特点新增技能。比如我们团队的项目要求所有接口必须写OpenAPI文档我就自己写了一个Skill: api-doc-generator定义好文档格式和校验规则放进.claude/skills/目录里。从此以后AI只要写了接口就会自动生成配套的API文档再也不用我提醒。定制技能的门槛比你想的低它本质就是写好一个Markdown文件讲清楚“什么时候用、怎么用、输出什么”。但内容质量要求很高因为提示词写得不清晰AI执行起来就会变形。我的经验是写技能文件的技巧接近于写一套“操作说明书”少说空话多给步骤尽量给可验证的输出物作为完成标准。4.3 技能爆炸之后如何防止AI“乱套”技能多了以后会不会出现“多个技能打架”的情况比如AI既想走TDD流程又收到前端工作流的规范约束到底听谁的我在实践中遇到过这个困惑。Superpowers的解法很聪明技能是有优先级和上下文的。SKILL.md里写明了触发条件和与其他技能的分工边界。比如test-driven-development技能会明确“本技能核心关注测试先行前端规范遵循frontend技能的约束”。在具体执行时AI会判断当前任务的类型来选择合适的技能调用顺序类似一个“路由分发”机制。但如果你自己新加了技能就得格外注意技能之间的依赖关系不要定义一个“万能技能”把所有事都管了。我见过有人在自定义技能里写“当用户提出任何需求时先进行安全审查、再制定计划、再编码、再测试、再写文档”结果AI每次干活都走一遍超长流程连改个Readme都要折腾半天。技能设计讲究“单一职责”一个技能管好一件事组合调用才是正途。5. 常见问题与排查技巧实录5.1 安装与加载类问题问题一装完框架后Claude Code没有任何变化。排查思路先看技能文件是否真的放对了位置。Superpowers的技能文件必须放在Claude Code能扫描到的目录里路径不对就完全加载不到。其次是确认版本兼容性太旧的Claude Code版本可能不支持SKILL.md自动加载。我建议装完框架后直接问AI“你现在加载了哪些技能”如果它答不上来说明技能没装进去。问题二技能只生效了一部分有的技能能触发有的不行。排查思路检查技能文件名和SKILL.md的开头格式。Claude Code对技能文件的格式要求比较严格SKILL.md里必须有准确的name字段和description字段AI才能正确识别。我踩过一次坑手动复制技能目录时漏了一个横杠导致AI始终无法正确识别技能名排查半天才发现是命名问题。问题三项目里技能目录被Git忽略导致团队成员拉代码后AI“失忆”。排查思路在.gitignore里确认是否误忽略了.claude/目录。如果你希望团队共享同一套AI工作规范技能文件必须进版本库。但项目内生成的临时规范文档和输出物可以视情况忽略。5.2 工作流执行类问题问题四AI在写完规范文档后直接跳到了代码阶段跳过了中间的计划确认环节。排查思路这是典型的“流程被跳过”问题。原因通常是你给了AI一个特别明确、特别“小”的任务让它觉得没有必要走完整流程。解决办法是主动声明“请走完整开发工作流不要省略任何步骤”。也有一种原因是你在对话中过早给出了“应该怎么做”的指示AI认为你已经替它做了设计决策所以简化了流程。问题五AI执行计划时偏离了原定方案引入了计划外的新逻辑。排查思路这种情况通常发生在计划文档不够具体时。软件工程里有一句话“计划不够细执行必走样”AI也一样。我后来学到的做法是在计划确认阶段明确要求AI把“明确不做的事情”也写进计划比如“本次不重构现有接口”“不修改数据库结构”。有了边界约束AI就不会随便越界加戏。问题六自定义技能加载了但AI不按技能要求执行。排查思路把技能文件写好后你可以在Claude Code里直接问“你会如何执行xxx技能”让AI复述一遍技能的内容。如果AI的回答与技能文件有出入说明你的技能定义存在歧义。常见原因是描述部分写得太泛AI触发时不知道你到底要什么。记住一个原则技能描述里的每一个动词都要可执行不要出现“分析一下”“优化一下”这种不可验证的模糊措辞。5.3 效果调优类经验经验一不是所有任务都适合完整工作流。这是我最想对所有刚接触Superpowers的人说的一句话。如果你只是想让AI帮忙“把这段Python列表推导式改成普通循环”你完全没有必要让它先走一遍需求分析、计划撰写、TDD流程。杀鸡用牛刀反而会让AI束手束脚效率变低。Superpowers的quick-task模式就是为这类小需求准备的。经验二Token消耗比普通对话高不少。因为整个流程很长AI在走完整开发工作流时消耗的Token要比直接对话多得多。我跑过一次“前端页面接口联调”的完整需求Token消耗大概是普通模式的3到4倍。如果你用的是付费API这笔账得自己算清楚。但换个角度想花三倍的Token换来的是“不用返工”和“质量稳定”值不值就看个人取舍了。经验三把技能文件当成团队知识库的一部分持续迭代。用了一段时间后我们团队的技能文件已经和初始版本有了很大的不同。我们把各种“踩过的坑”“团队的代码风格偏好”“接口文档模板”都写进了技能文件里。这样一来不管哪个同事用AI干活输出都遵循同一套标准。这个价值已经超越了“让AI写代码”本身它成了团队经验沉淀的载体。每次打补丁修Bug时想明白的新规则都可以随手沉淀进去AI会被持续塑造得越来越“懂你”。6. 这套框架对AI编程范式的启示Superpowers这套东西的价值我觉得不在于“多会写代码”而在于它示范了一种思路把软件工程的方法论注入AI的工作流程。这个思路拓展之后影响力远超“AI编程助手”本身。想一想传统软件工程花了半个世纪积累下来的方法论——需求分析、设计文档、代码评审、测试驱动、持续集成——这些东西本质上都是“对抗复杂性”的武器。而AI编程助手最大的问题恰恰就是“天然回避复杂性”你让它干嘛它就干嘛它不会主动去管理复杂性。Superpowers做的就是强行把复杂性管理机制塞回AI的思考过程里。这个模式如果成熟了行业影响会很深远。往小了说AI在大型代码库里的表现会稳定一大截不再是一个“能写单点代码、但不适合大型项目”的工具。往大了说这等于给所有使用AI的开发团队提供了一条标准化的道路与其每个人用对话“调教”AI不如把团队的统一规范固化成一个“技能包”让所有AI统一执行。这种模式很可能成为未来企业级AI开发工具的主流形态。想跟进这个方向的话除了看Superpowers的设计思路还可以关注一下Anthropic官方发布的Agent Skills规范——它是一个更通用的AI技能标准。Superpowers相当于是这套标准在“软件工程”这个垂直领域里一个做得特别扎实的实践样本。理解了Superpowers你就理解了Agent Skills的核心逻辑。更妙的是Superpowers本身就把Agent Skills做了重新编排凝聚在它那套开箱即用的工作流里。最后分享一个我琢磨出来的小技巧用Superpowers时不要把它当成一个“让AI自动干活的工具”要把它当成一个“让AI学会用工程方式思考的训练器”。每次走完完整工作流你都可以观察AI在规范阶段生成了什么文档、在计划阶段拆了什么任务。这里面包含的信息量往往比最终代码本身更有价值。我的习惯是每跑完一个完整需求就把AI生成的计划文档留下来当作项目资产下次遇到类似需求时直接拿来复用连讨论都省了。这套流程用习惯了之后你会慢慢发现“AI自动干活”和“AI规范地自动干活”之间的差距到底有多大。后者才是真正能放心交付的那种。
