我想给大家分享一个我自己在vibe coding的时候，一直在用的一个超好用的帮我提高Coding体验的一个插件，也基本上是我推荐所有人都必装的一个，基本上Claude Code、Codex、OpenCode、Cursor啥的全都适配，都可以装的。它在Github上，已经有12万的star数了。
名字叫，Superpowers。GitHub 链接在此：github.com/obra/superp…，也是Claude官方的认证插件，上架了Anthropic的官方插件市场，安装量冲到了23万，排名第二。
Superpowers其实不太能算一个传统意义上的工具，我觉得他更应该被定义为一套指导Agent如何完成任务的系统。因为坦诚的讲，绝大数的Agent，在进行任务的时候，天然都倾向于拿到任务就开始写代码，会跳过设计、跳过测试、跳过 review，然后产出一坨不可维护的东西。
1 安装：
安装Superpowers的过程，本身就体现了它“系统化”的哲学。我发现，不同平台的安装方式，恰好反映了各自生态的成熟度。
对于最主流的Claude Code，安装最为优雅。你只需要在终端输入一条命令：
/plugin marketplace add obra/superpowers-marketplace
然后安装插件即可。安装成功后，输入/help，你会看到新增的/superpowers:brainstorm等命令。这就像给IDE装了一个功能强大的插件，无缝集成。
而如果你在使用Codex或OpenCode，过程则更具“AI原生”色彩。你不需要手动执行复杂步骤，只需告诉你的智能体：
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.codex/INSTALL.md
2 Superpowers skill介绍
Superpowers本质上，是一个由14个Skills组成的工作流系统，而且，这个系统，并不止可以用在开发上，因为创造一个东西的本质上都是类似的。都是规划 - 拆解 - 执行 - 审查 - 复盘。
项目建立在四个核心原则之上：
测试驱动开发（TDD） ：永远先写测试。没有看到测试失败，就不能确定测试是否真正测试了正确的行为。
系统化而非临时化：用流程替代猜测。每个技能都有明确的决策流程图（用 DOT/GraphViz 语法定义），作为"可执行规范"。
复杂度削减：以简洁为首要目标。技能中反复强调 YAGNI（You Aren't Gonna Need It）原则，积极删除不必要的功能。
证据而非声明：在宣布任务完成之前，必须验证。看到测试通过，看到代码运行，而不是"我觉得应该可以了"。
所以很多朋友在开发的时候，感觉最后开发的东西不是你想要的，其实真的不是AI菜逼，是你的需求并没有说清楚。规划2小时，执行10分钟，我现在越来越觉得，执行真的没有那么重要，前期的规划想清楚，才是最最最最最重要的。所以现在我的感受是，AI来开发已经够快了，真正该花时间的地方是动手之前。你需要不断的被拷打，不断的跟团队分析所有的边界情况，还必须有老师傅坐镇和把关，最后才能出来一个能真正向用户交付的东西。
3 使用示例
从“头脑风暴”到“详细计划”的需求澄清
安装完成后，我迫不及待地想试试。我对Claude Code说：“读取docs\plans\2026-03-26-channel-cross-design.md，准备设计数据库断面表”
如果是往常，它会立刻开始生成建立断面。但这次，它停了下来，进入了“头脑风暴”模式。它没有直接写代码，而是像一位资深的产品经理，开始向我提问：
我读完了。现在语义已经明确分成两层：channelCross 是沿 actual_geom 的分析断面，
spatial_line_section 是落在折点上的设计剖面，所以“断面表”如果不先定范围，后面很容易把两层混在一
起。
你这次要我优先设计哪一层数据库表？
1. channelCross 分析断面表
2. spatial_line_section 设计剖面表
3. 两层一起设计，并补上它们之间的映射/来源关系表
我回答1
那这轮先聚焦 channelCross 分析断面表。
下一问只确认表边界：这张表你希望做成哪一种？
1. 纯分析主表
只存断面定位、原始/投影坐标、桩号、分析结果，不放任何设计落地字段
2. 分析主表 + 预留映射字段
在 channelCross 表里顺手放上 mapped_line_section_id、is_active_source 这类设计侧关联字段
3. 分析主表 + 独立映射表
channelCross 只保留分析语义，和 spatial_line_section 的来源/生效关系单独建表
我当前更偏向 3，边界最干净。
我选3
边界已经定下来了：channelCross 保持分析侧主表，和 spatial_line_section 的关系单独建映射表。现在
最关键的是它到底挂在哪个父对象上，这会直接决定主键、外键和后续重定位流程。
• 下一问只确认归属锚点。
channelCross 主表你希望挂在哪一层？
1. 直接挂 spatial_line_id
优点是简单；缺点是同一时间序列里线一旦复制换新 ID，断面要跟着改绑
2. 挂 (seq_time_id, catalog_id)
表示“这个时间序列里的这条逻辑线”，再通过 snapshot_build_relation 找当前生效的
spatial_line_id
3. 直接挂 snapshot_build_relation.id
最贴近“当前序列下的当前线条目”，实现上最直接
我当前更偏向 3，因为它天然就是“时间序列里的线实例入口”。
它一次只问一个问题，并给出清晰的选项。这个过程强迫我厘清自己模糊的想法。确认所有设计后，它会将方案分成200-300字的小节让我逐一确认，最终生成一份设计文档。
紧接着，进入“编写计划”阶段。AI不会生成一个笼统的“实现权限系统”任务，而是将其拆解成一系列原子任务，例如：
- 创建
Permission实体与数据库迁移（预计2分钟） - 实现
assignPermission服务方法及单元测试（预计3分钟） - 创建权限检查中间件（预计4分钟）
每个任务都精确到了文件路径、代码片段和验证步骤。这份计划的详细程度，足以让一个不了解项目的初级工程师严格执行。我意识到，把大目标拆解成不可再分的小任务，是克服开发焦虑、确保进度的关键。Superpowers在这里做的，就是把资深工程师的项目管理经验，变成了AI的默认行为。
执行计划，观看子智能体自动完成开发
最让我震撼的是“执行计划”阶段。当我批准计划并下达执行指令后，Superpowers并没有让原来的AI一口气干完。
它会为计划中的每个原子任务，派遣一个全新的“子智能体”去执行。这个设计非常精妙：每个子代理都是“新鲜”的，没有上下文污染，只专注于当前的小任务。完成后，会触发两阶段审查：
1. 规格符合性审查：代码是否100%符合计划要求？有没有多做或少做？
2. 代码质量审查：只有通过第一阶段，才检查代码是否整洁、测试是否充分。
如果审查发现问题，会进入“修复→再审查”的循环，直到通过。在这个过程中，我可以看到Claude Code自主工作，在测试失败（RED）、编写代码（GREEN）、重构优化（REFACTOR）的循环中迭代，完全遵循TDD纪律。
我就像一个项目总监，看着一支训练有素的AI工程团队，按照严格的SOP并行推进任务。所有任务完成后，它会验证全部测试，并给我清晰的选项：合并、创建PR或是丢弃。整个流程结束时，不仅功能实现了，代码库还比开始时更干净、测试更完备。
强制TDD流程：确保每行代码都有测试覆盖
Superpowers最让我震撼的，是它对测试驱动开发（TDD）的强制性执行。这不仅仅是“建议”，而是编码成不可绕过的规则。
在传统AI编程中，模型可能会先写实现，再“补”测试，甚至直接跳过。Superpowers的test-driven-development技能彻底杜绝了这一点。它的核心规则是： “先写测试失败的代码？删掉，重新来。” 流程被严格锁定在“红-绿-重构”循环中：
1. 红：AI必须先根据需求描述，生成一个必然会失败的测试用例。我必须亲眼看到测试运行失败，这才能证明测试确实在验证正确的行为。
2. 绿：接着，AI才能编写能让这个测试通过的最少量代码。
3. 重构：测试通过后，再进行代码优化，同时确保测试始终保持绿色。
我发现，这种强制流程带来了两个根本性改变。第一，它倒逼需求清晰化。在写测试之前，AI必须和我反复确认函数的精确输入、输出和边界条件。第二，它将“可测试性”内置于代码的DNA中。代码从诞生起就自带验证标准，这为后续的维护和重构提供了坚实的安全网。资料中提到，项目甚至包含了testing-anti-patterns技能来识别和避免常见的测试陷阱，比如过于复杂的测试或依赖外部服务
Git工作树隔离：安全实验，不污染主代码库
在尝试新功能或大规模重构时，我最怕的就是把主分支搞乱。Superpowers通过using-git-worktrees技能，优雅地解决了这个后顾之忧。
在开发开始前，AI会自动创建一个基于新功能分支的独立Git工作树。
这样做的好处显而易见：
* 主分支永远干净：无论实验成功与否，主代码库都不会受到任何污染。
* 失败成本为零：如果新功能开发失败，直接删除这个独立的工作树即可，没有任何心理负担。
* 支持并行开发：可以同时为多个功能创建不同的工作树，彼此互不干扰。
我意识到，这个机制将“敢于实验”的心理门槛降到了最低。它鼓励我进行更大胆的尝试和重构，因为我知道有一个安全的“撤销”按钮。当所有测试在隔离环境中通过后，AI才会提供清晰的选项：合并、创建拉取请求或直接丢弃，整个过程可控且整洁。
写到这里，我想到，Superpowers的这些机制，本质上是在用自动化的“流程刚性”来弥补AI在工程判断上的“思维柔性”。它不试图让AI变得更“聪明”，而是通过架构设计，让它变得更“可靠”。对于追求代码质量和项目可维护性的开发者来说，这套机制提供的不是便利，而是保障。
适用场景：原型构建、功能迭代与大型重构
从我的实践来看，Superpowers的威力并非均匀分布。
在构建全新原型或独立功能模块时，它的优势最为明显。我只需要说“我想做一个用户积分系统”，brainstorming技能就会引导我厘清积分规则、数据模型和API设计。之后，AI在隔离的Git工作树中，严格按照TDD循环一步步生成代码和测试。整个过程无需我反复查阅文档或手动搭建测试框架，AI自动完成了从设计到可运行代码的“脚手架”搭建，这确实极大地加速了从0到1的过程。
对于大型、高风险的重构任务，Superpowers的价值在于其系统性的风险控制。比如，我需要将一个庞大的单体函数拆分为微服务。如果手动操作或仅靠普通AI助手，很容易遗漏边缘情况或破坏现有功能。而Superpowers的writing-plans技能会将重构分解为数十个“2-5分钟”的原子任务，每个任务都包含精确的修改位置和验证步骤。子智能体按计划执行，并在每个环节后自动审查。这相当于为重构过程装上了“防错护栏” ，虽然单步不快，但避免了推倒重来的巨大时间浪费，整体周期反而可能更短。
