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 的过程中我总结出几个有意思的结论:
- 很多 Skill 都在约束 AI 不要“偷懒”,原来偷懒不仅是碳基生命的本性,硅基生命也喜欢偷懒。
- 有些 Skill 也在约束 AI 不要对人类过于谄媚,这其实是反直觉的(甚至可以说是‘反AI性’的),因为现在的大模型在对齐训练时往往被设定为‘讨好用户’,而工程化要求它必须具备‘说不’的技术骨气。
- 这些Skill 明显也是在标准化某个特定的流程,大家也都知道标准化会提示质量减少方差,也就意味着我们可以用一个成本更低的AI模型替换成本高的AI模型了(笑)
- 在使用 superpowers 进行开发的过程中,仍然需要大量人工介入,尤其是在 brainstorming 环节。这也意味着,它仍处在迈向 AGI 的中间阶段。不过,这也是未来程序员保住饭碗最重要的一点:AI负责确定性的执行,人类负责不确定性的决策和边界探索。掌握这种协作模式,才是AI时代不被淘汰的护城河。
回到 superpowers 上,我还是很推荐大家安装使用。我无法量化说明用它和不用它的差别,但从个人体感来看,以前 AI 编程更像是把任务交给一个实习生(当然这个实习生也很聪明,比如 claude-opus、deepseek……这些顶级模型)。但有了 superpowers 之后,我更感觉像是把任务交给了一个专业的研发团队。
最后附上本文的信息图,供大家参考:




![[翻译]我在谷歌14年学到的21堂课-XINDOO](https://xindoo-1254046096.cos.ap-beijing.myqcloud.com/img/uPic/iShot_2026-01-21_下午11.21.45fewv0C.jpg)


