GitHub Trending霸榜！深度解析AI Coding辅助神器 Superpowers

今天我想给大家推荐一个非常好用的 Agent Skill。如果你还不知道什么是 Skill，可以先看下我另外一篇博客 《最近AI领域爆火的 Agent Skills 是什么？》。

我想推荐的这个 Skill，是辅助 AI Coding 的 Superpowers。它更像是一套为“AI 编程”准备的加强包：你在用 Claude、Codex、Cursor……这些 AI Coding Agent 时，都可以安装这套 Skill，来提升 Agent 的软件工程能力。这个开源项目最近在 GitHub 上非常火，我也是在 GitHub Trending 上看到的，它霸榜好多天，star 增速也很猛。

具体安装方式可以直接看 GitHub，我这里就不再赘述。接下来我们重点解析这个 Skill，看看它到底是怎么设计的！ 为什么会很有用！

概览

实际上 superpowers 不是单一的一个 Skill，而是由 14 个 Skill 组成的。它非常像是传统软件开发的过程，涵盖从需求调研→设计方案→代码编写→Debug→代码测试→代码评审→生产部署，将这一系列的软件开发流程分别提炼成 AI 可以使用的 Skill。更重要的是，它不是只教你“怎么写代码”，而是反复在提醒你：在任何阶段都要用工程化方式做事。比如需求阶段要把边界问清楚，编码阶段要写计划和测试，完成阶段要先验证再宣称完成，合并前要做评审。

如果你曾经用过一些 AI 编程助手，会发现它们很容易出现两类问题：

• 为了快而跳步骤：不写测试，直接改一大堆代码，然后告诉你“搞定了”。
• 为了自洽而编结果：命令没跑，日志没看，就拍脑袋说通过了。

superpowers 的核心价值，就是用一套“流程护栏”强迫 AI 把这些偷懒路径堵住，让它回到人类成熟团队里那套可靠的交付方式。

下面这张表我把 14 个 Skill 的触发时机和核心原则做了一个中文化梳理。

技能名称	触发时机	核心功能	关键原则
using-superpowers	任何对话开始时	技能系统入门，告诉 AI 在做事前先检查适用技能	用户指令 > 技能 > 默认系统提示
brainstorming	任何创造性工作之前	通过苏格拉底式对话将想法转化为设计和规格	先设计再编码，展示设计并获批准后才能实现
using-git-worktrees	开始功能工作或执行计划前	创建隔离的 Git 工作树，设置依赖，验证测试基线	系统化目录选择 + 安全验证 = 可靠隔离
writing-plans	有多步骤任务规格时，接触代码前	编写详细实现计划，包含精确文件路径、代码、验证步骤	每个任务 2-5 分钟，DRY、YAGNI、TDD、频繁提交
subagent-driven-development	在当前会话执行实现计划时	为每个任务派遣新子代理，两阶段评审（先规格后质量）	新子代理/任务 + 两阶段评审 = 高质量、快速迭代
executing-plans	有书面计划需在单独会话执行时	加载计划、批判性评审、执行所有任务、完成时报告	严格按计划步骤执行，验证前不跳过
dispatching-parallel-agents	面对 2+ 独立任务时	为每个独立问题域派遣一个代理，并发工作	一个代理/独立问题域，让它们并发工作
test-driven-development (TDD)	实现任何功能或 bug 修复时	红-绿-重构循环：先写失败测试，看着失败，写最小代码通过	没有先失败的测试就没有生产代码
systematic-debugging	遇到任何 bug、测试失败或意外行为时	四阶段调试：根因调查 → 模式分析 → 假设测试 → 实现	没有先根因调查就没有修复
verification-before-completion	声称工作完成、修复或通过时	运行验证命令，阅读输出，然后才能声称完成	证据在前，声称在后，始终验证
requesting-code-review	完成任务、实现主要功能或合并前	派遣代码评审子代理在问题级联前捕获问题	早评审，常评审
receiving-code-review	接收代码评审反馈时	技术评估而非情感表现，验证前不实现	实现前验证，假设前询问，技术正确性高于社交舒适
finishing-a-development-branch	实现完成、所有测试通过时	验证测试，展示 4 个选项，执行选择，清理工作树	验证测试 → 展示选项 → 执行选择 → 清理
writing-skills	创建新技能、编辑现有技能或部署前验证时	将 TDD 应用于流程文档，先基线测试再写技能	没有先失败测试就没有技能

上面的表格不够直观，这里我把 Superpowers 加持下的完整 AI Coding流程画了出来。

这里就能很直观地看到，在 Superpowers 的加持下，整个代码开发过程更像是一个专业、资深的团队在推进；相比以往“用户一个指令下去，AI 凭借自己的理解就开干”的方式，发生了质的变化。过去的方式高度依赖用户的输入和模型本身的能力，但在复杂项目里，这两点往往并不稳定：用户需求可能表达不清，模型也可能为了“给出答案”而省略验证步骤。superpowers 做的事情，本质上是把不稳定的“聪明”变成可复用的“流程”。

换句话说，它不是在教 AI 变得更厉害，而是在给 AI 加一套“交付纪律”。当你把它用在真实的工程里，能明显降低两类成本：

• 返工成本：因为前期问清边界、写出计划和测试，后面少走弯路。
• 信任成本：因为每一步都有可验证的证据，团队更敢让 AI 参与关键链路。

接下来我挑几个我认为最重要的 Skill（有设计巧思），其他的Skill大家有兴趣可以自行阅读下对应SKILL.md文件。

重点 Skill 解读

using-superpowers

这是 Superpowers 系统的元技能，可以把它理解为 14 个技能的“总开关”。它会强制 AI 在做任何事情之前先停下来，检查是否有适用的技能。AI 的本能是拿到任务就立刻执行，不会先想“我应该用什么流程”。这个技能相当于在最外层加了一道安全护栏，确保其他技能有机会被触发。

关键要点：

• 只要有 1% 的可能性适用，就必须调用技能检查
• 用户指令 > Superpowers 技能 > 默认系统提示
• 流程技能优先（brainstorming、debugging），实现技能其次

brainstorming

这个技能阻止 AI 最常见的坏习惯：拿到需求直接跳去写代码。人类开发者会自然地先思考再动手，但 AI 倾向于"动作导向"——写代码就是动作，思考不是动作。这个技能用一个"硬门槛"强制 AI：不设计，不许编码。

关键要点：

• 硬门槛：展示设计并获得用户批准之前，绝对不能写代码
• 9 步检查清单：探索 → 可视化伴侣 → 澄清问题 → 提方案 → 展示设计 → 写文档 → 规格评审 → 用户评审 → 过渡到实现
• 一次一个问题，不要 overwhelm 用户
• 无情 YAGNI：从所有设计中删除不必要的功能

test-driven-development

AI 写代码很快，但写测试很慢（或者直接跳过）。这个技能用铁律强制：没有先失败的测试，就不能写生产代码。AI 倾向于认为"代码写好了，就应该工作"，但 TDD 要求必须先看到测试失败，证明测试实际上测试了某些东西。

关键要点：

• 铁律：没有先失败的测试就没有生产代码，先写代码后写测试？删除它，重新开始
• 红-绿-重构循环：写失败测试 → 看着它失败 → 写最小代码通过 → 看着它通过 → 清理（保持测试绿色）
• 测试立即通过？你在测试现有行为，修复测试
• 之后写的测试立即通过，证明不了任何东西

systematic-debugging

AI 的调试方式通常是：看到错误 → 随机改点什么 → 看看好了没 → 不行就再改点别的。因为 AI 可以快速尝试很多次，它会觉得"反正试得快，总能试对"。但这种方法经常修复症状而不是根因，还会引入新 bug。这个技能强制：不找到根因，不许修复。

关键要点：

• 铁律：没有先根因调查就没有修复
• 四个阶段（必须按顺序完成）：根因调查 → 模式分析 → 假设和测试 → 实现
• 在多组件系统中，先添加诊断工具，收集证据显示在哪里失败，再调查那个特定组件
• 如果 3+ 修复失败，停止并质疑架构
• 红色标志："现在快速修复，稍后调查"、"只是尝试更改 X 看看它是否工作"——所有这些都意味着停止，返回根因调查

verification-before-completion

AI 最常说的话之一是："应该工作了"、"完成了"、"完美！"——但没有任何证据。人类开发者会谨慎，但 AI 倾向于过度自信。因为 AI 没有"被打脸"的概念，它会随意声称成功。这个技能强制：没有证据，不能声称完成。

关键要点：

• 铁律：没有新鲜验证证据就没有完成声称
• 门限函数：识别 → 运行 → 阅读 → 验证 → 只有那时才声称
• 常见失败："测试通过"需要测试命令输出，"构建成功"需要构建命令退出 0，"代理完成"需要 VCS 差异显示更改
• 红色标志：使用"应该"、"可能"、"似乎"，在验证前表达满意，信任代理成功报告

receiving-code-review

AI 倾向于："你说的都对！我马上改！"——不去验证反馈是否正确。人类开发者会批判性地思考，但 AI 倾向于讨好和顺从。因为 AI 没有"技术立场"的概念，它会无条件接受反馈。这个技能强制：验证前不实现，技术正确性高于社交舒适。

关键要点：

• 核心原则：验证前不实现，假设前询问，技术正确性高于社交舒适
• 禁止的响应："你绝对正确！"、"好点！"、"让我现在实现那个"
• 响应模式：阅读 → 理解 → 验证 → 评估 → 响应 → 实现
• 如果任何项目不清楚，先不实现任何东西，询问不清楚的项目的澄清
• 来自外部评审者：检查对这个代码库技术上正确吗？破坏现有功能吗？评审者理解完整上下文吗？

……

我这里仅挑选了几个我认为比较重要或者有特点的 Skill，其他的 Skill 大多也是同一套“流程护栏”思路：用明确的触发条件把 AI 拉回到可验证、可评审的路径上。你可以把它理解成把资深工程团队的共识，写成一组可以被重复调用的“作业指导书”。当项目越复杂、协作链路越长，这类指导书的价值就越高。

总结

阅读所有 Skill 的过程中我总结出几个有意思的结论：

1. 很多 Skill 都在约束 AI 不要“偷懒”，原来偷懒不仅是碳基生命的本性，硅基生命也喜欢偷懒。
2. 有些 Skill 也在约束 AI 不要对人类过于谄媚，这其实是反直觉的（甚至可以说是‘反AI性’的），因为现在的大模型在对齐训练时往往被设定为‘讨好用户’，而工程化要求它必须具备‘说不’的技术骨气。
3. 这些Skill 明显也是在标准化某个特定的流程，大家也都知道标准化会提示质量减少方差，也就意味着我们可以用一个成本更低的AI模型替换成本高的AI模型了（笑）
4. 在使用 superpowers 进行开发的过程中，仍然需要大量人工介入，尤其是在 brainstorming 环节。这也意味着，它仍处在迈向 AGI 的中间阶段。不过，这也是未来程序员保住饭碗最重要的一点：AI负责确定性的执行，人类负责不确定性的决策和边界探索。掌握这种协作模式，才是AI时代不被淘汰的护城河。

回到 superpowers 上，我还是很推荐大家安装使用。我无法量化说明用它和不用它的差别，但从个人体感来看，以前 AI 编程更像是把任务交给一个实习生（当然这个实习生也很聪明，比如 claude-opus、deepseek……这些顶级模型）。但有了 superpowers 之后，我更感觉像是把任务交给了一个专业的研发团队。

最后附上本文的信息图，供大家参考：