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 之后，我更感觉像是把任务交给了一个专业的研发团队。
最后附上本文的信息图，供大家参考：
