Superpowers插件：通过结构化工作流提升Agent开发体验

最近一直在聊Agent、聊Vibe Coding。 但是在给越来越多的朋友安利的时候，发现其实，一直有一个问题被忽略了。 就是，真正卡住大多数人的，是自己没有一个标准的工作流程。 特别在创造一个你想要的软件或者程序的时候，没有标准流程，其实是一件非常可怕的事情。 所以，我想给大家分享一个我自己在vibe coding的时候，一直在用的一个超好用的帮我提高Coding体验的一个插件，也基本上是我推荐所有人都必装的一个，基本上Claude Code、Codex、OpenCode、Cursor啥的全都适配，都可以装的。 它在Github上，已经有11万的star数了。 名字叫，Superpowers。 GitHub 链接在此： https://github.com/obra/superpowers 也是Claude官方的认证插件，上架了Anthropic的官方插件市场，安装量冲到了23万，排名第二。 第一名就是那个大名鼎鼎的让你的设计变得更有品味的超牛逼的Skill，Frontend Design。 Superpowers其实不太能算一个传统意义上的工具，我觉得他更应该被定义为一套指导Agent如何完成任务的系统。 因为坦诚的讲，绝大数的Agent，在进行任务的时候，天然都倾向于拿到任务就开始写代码，会跳过设计、跳过测试、跳过 review，然后产出一坨不可维护的东西。 而Superpowers会强行在Agent的链路里面插入一套结构化的工作流，再结合着14个skills的组合，能让你最终的任务产出质量，上升几个档次。 我做了一张图，可以简单的让大家看看这些Skills，每个有啥用，以及是怎么组合的，不用细看，大概知道原理就行。 所以其实可以看出来，Superpowers本质上，是一个由14个Skills组成的工作流系统，而且，这个系统，并不止可以用在开发上，因为创造一个东西的本质上都是类似的。 都是规划 - 拆解 - 执行 - 审查 - 复盘。 所以，你也完全可以拿来做营销方案、做PPT、做数据分析等等，基本都是相通的。 非常的好用。 我觉得可以先给大家看看，如果不用Superpowers的时候，我们拿Claude Code或者Codex开发产品的原生流程会是什么样子的。 一般流程，其实都非常的简单，都是要先写需求文档，也就是做规划再开发。 我们拿Claude Code举例子，在这里面，规划就是Plan模式。 比如说，团队有个小伙伴跟老罗一样，有ADHD，经常看文章就很容易容易分心，最近我们就在说，是不是可以做个阅读辅助的小东西。 就这个需求，我们打开Claude code，在对话框里面敲个/plan，进入到规划模式。 把需求简单的描述一下，帮我做一个面向 ADHD 用户的中文网页阅读器应用。 让他来开始去做一个计划。 然后，他会先调研一轮，一口气甩出好几个问题让你回答，这些问题其实你会发现，他们是并行的，之间没有前后因果关系。 比如它问我使用场景、技术栈偏好，还有要加哪些ADHD友好特性，这块我选了仿生阅读，就是加粗每个单词前几个字母，一个比较经典的缓解ADHD的方法。 我回答了一下，然后它就直接开干了。 几分钟之后，就直接做出来了，给了你一个东西，也没有审查啥的。 我们现在看的话，是不是好像没啥问题？ 但，其实有大问题。。。 因为这个仿生阅读，其实是为英语设计的。 英文阅读这么做没问题，但是你中文，是完全不行的话，阅读起来直接乱套了。 原因很简单，英文单词之间有空格，能找到边界，中文字和字之间没有空格，根本找不到词的边界，效果就会很别扭。 除了样式它不太行，它对国内用户的适配也很差。 我们读中文，用得最多的是公众号、知乎这些平台，结果这个插件根本没法正常读取。 跟我想要的阅读器差了十万八千里。 不过坦诚的讲，这确实也怪不到Claude Code头上。 因为ADHD阅读辅助本身就是个专业领域，需要做针对性的调研，还得考虑中文场景的适配、国内平台的兼容。 它问我的那几个简单的不痛不痒的问题，就肯定覆盖不了全部需求，那也很难做出你心中想要的答案。 而大多数的用户呢，心里也就是只有一个模糊的想法，他知道他要解决一个具体的问题，但是具体要做成啥样、该用什么路径去实现、边界在哪，大多数人，是真的想不清楚的。 其中有一个Prompt心法，就是叫做苏格拉底式提问法，用一段Prompt，让AI在动手之前，先一个问题一个问题地拷打和追问你，直到把需求聊透了再开始。 【你的问题/需求】请你在回答前，先问我问题。要求：一次只问一个问题。根据我的回答，继续追问。直到你有95%的信心理解我的真实需求和目标。然后才给出方案 在Agent时代，其实也差不多，只不过从一个Prompt，升级到了流程中的一个Skill。 我们再用Superpowers这个东西，再来开发试一下。 首先自然是安装这个插件了。 你直接跟你的Agent说一句话就行了： 帮我下载并安装这个插件：https: //github.com/obra/superpowers 安装完以后，记得要重启一下才能生效，不是热加载。 还是那个ADHD阅读器，我们再试试。 一模一样的Prompt发过去。 你就能看到，开始调用Superpowers和工作流了。 它做的第一件事，是先问我用户会怎么用，这一步就直接解决了那些抓取不到的墙的问题。 但跟刚才Plan模式的并行提问完全不一样，Superpowers一次只问一个问题，你答完这个，它才决定下一个问什么，就是刚才说的苏格拉底式提问，这样才能保证这些问题真的能够非常深入而不是浮于表面。 我选了浏览器扩展，然后它又问了核心功能，到这一步的时候，我看着这些选项愣了一下，因为我自己也没那么熟，所以我说直接我都不是很了解，你去给我查一查吧。 它就真的去查了，回来给了我一份调研结果。 然后给了我一个建议，整理出了核心功能优先级的清单。 比如仿生阅读，就是上次加粗前几个字母的方案，它直接标了弱但用户喜欢，还引用了研究说这玩意对ADHD用户中文阅读并没有显著的改善。 我就继续让它帮我选了几个功能。 之后他就继续往下拷打我，逼着我想清楚，比如目标浏览器是哪个？中文分词库有没有偏好？UI语言和风格？ 也就是逼着你想清楚。 这个演示的项目其实不是很复杂，但是当你开发一个大型的项目的时候，你就会真正的发现，那种被拷打的汗流浃背的感觉了。 在问题你都回答完之后，AI它也大概知道了你的需求。 这时候，它跟Plan模式不一样的点，就是它会提出三个架构方案，每个方案的优缺点、适用场景列得清清楚楚。 让你来挑一个，当然你也可以直接用它推荐的。 我直接选了B，我不想要混合方案。 然后它又让我挨个确认不同的细节。 整体架构、功能模块的详细设计、控制面板、数据流与存储等等等等。。。。 又一次确认的我汗流浃背，感觉到了自己在AI面前的菜鸡与渺小。 等所有东西都确认完以后，他才终于，把整份的设计文档给写好，放在了本地。 巨长巨详细的一份。 所以很多朋友在开发的时候，感觉最后开发的东西不是你想要的，其实真的不是AI菜逼，是你的需求并没有说清楚。 规划2小时，执行10分钟，我现在越来越觉得，执行真的没有那么重要，前期的规划想清楚，才是最最最最最重要的。 我们自己做AIFUT的票务小程序的时候，其实就是因为盲目自大以及AI辅助流程不规范，很多用户需求前期没有考虑清楚就直接上线了，边界风险考虑的也不清楚，这其实就是前期的规划问题。 所以现在我的感受是，AI来开发已经够快了，真正该花时间的地方是动手之前。 你需要不断的被拷打，不断的跟团队分析所有的边界情况，还必须有老师傅坐镇和把关，最后才能出来一个能真正向用户交付的东西。 说回Superpowers，第一步的规划其实就全部OK了，上面的所有的东西，其实都还只是，Superpowers流程中的第一个Skill。 也就是brainstorming（头脑风暴）。 对，第一个。 设计文档确认之后，你是不是以为，它应该开始直接写代码了？ 但这个时候，第二个skill开始接入，用using-git-worktrees这个Skill，创建了一个隔离的工作区。 就是从主分支拉出一个新分支，所有后续的开发都在这个新分支上进行。主分支的代码不受影响，新分支上不管怎么折腾都不会波及原有的东西。做完了觉得没问题，再合并回去。 这就是做隔离，很多人都是直接就在之前的项目上改，然后没有版本隔离，就直接全部改炸了，那其实是个很不好的坏习惯。 再接下来，第三个Skill，writing-plans skill登场了。 注意啊，这一步依旧还是没有写代码。 它干的事情是，把刚才那份设计文档拆解成一步一步的开发任务的清单，而且是拆成2～5分钟就能完成的开发任务清单计划。 这个特别有意思，因为他们的目标，原话是：“让一个没有品味、没有判断力、没有项目上下文、而且厌恶测试的热情初级工程师也能照着做。” 当时看到给我笑乐了。 所以啊，你用了Superpowers，其实并不是只能用Claude Opus 4.6，其实越是能力一般的模型，反而得到的加持会越大，这就是这个Skill发挥的作用。 而且拆细了还有一个好处，就是每完成一个小任务就能验证一次，出了问题马上能发现，不用等整个项目写完了才发现直接爆炸了。 这一点，到了执行阶段体现得更明显。 这一步完事了以后，终于，要到了写代码的执行阶段。 这时候，它会调用subagent-driven-development这个Skill。 直接开了好几个子Agent，去做上面所有的事情。 每个任务开发完，也不是直接就扔给你了，而是会过两道检查。 第一轮派一个独立的审查Agent，看这个任务到底有没有按需求来，该做的有没有做到，不该做的有没有瞎加，有没有神经病一样整出一堆毫无意义的过度设计。 第二轮再派一个审查Agent，查的是代码质量，这一轮主要就看代码写得规不规范，好不好维护。 两道审查都不通过就打回修改，改完再审，然后如此循环，直到都通过为止。 这10个小任务，终于开发完了，审查还没完，下一个环节，requesting-code-review这个skill会派一个最终审查Agent出来，把所有代码从头到尾通看一遍。 之前每个任务的审查，盯的是局部，这一轮盯的是全局，看模块之间能不能集成、有没有遗漏、整体一不一致。 最后收尾，跑一遍验证，确认所有测试通过，没有残留问题，然后把代码合并回主分支，清理工作区。 最后，终于，做完了。 我们看下这个阅读器的效果。 它有两种很实用的阅读模式。 一种是词性着色，会把名词、动词、形容词用不同颜色标出来，句子结构会清楚很多。 还有一种模式是段落聚焦，正在阅读的这一段会被高亮，其他段落会压暗，适合读长段落，能明显减少周围文字带来的干扰，避免跑神。 对ADHD用户来说，最大的敌人就是注意力被周围的文字分散。 这个阅读器，就是把阅读重点变得更清楚，让该看的内容更容易被看见，周围干扰少一点，整篇读下来就不会那么累了。