AI工具人
提示词工程师

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

AI 编程已经不能说是“火”了,而是切切实实改变了程序员的工作方式(低情商:已经在抢程序员的工作了)。就拿博主我自己来说,作为一个在互联网摸爬滚打 10 年的“资深老兵”,过去半年里我也已经从手写代码转向 AI Coding 了,说实话,真的很香。

在工作中,我用 AI 提效,同样的工作量所需时间大幅缩短,也就有了更多时间学习(moyu)。工作之外,我也借助 AI 尝试了不少小项目,其中一个 AI 翻译项目已经在 GitHub 获得了 3k 个 star……

劝大家做 AI 转型的话,今天就不多说了。有兴趣可以看下我几个月前的一篇博客 《AI时代程序员转型的3个方向》

今天我想给大家推荐一个非常好用的 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 之后,我更感觉像是把任务交给了一个专业的研发团队。

最后附上本文的信息图,供大家参考:

赞(0) 打赏
未经允许不得转载:XINDOO » GitHub Trending霸榜!深度解析AI Coding辅助神器 Superpowers

评论 抢沙发

觉得文章有用就打赏一下文章作者

非常感谢你的打赏,我们将继续给力更多优质内容,让我们一起创建更加美好的网络世界!

支付宝扫一扫

微信扫一扫