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-developmentAI 写代码很快但写测试很慢或者直接跳过。这个技能用铁律强制没有先失败的测试就不能写生产代码。AI 倾向于认为代码写好了就应该工作但 TDD 要求必须先看到测试失败证明测试实际上测试了某些东西。关键要点铁律没有先失败的测试就没有生产代码先写代码后写测试删除它重新开始红-绿-重构循环写失败测试 → 看着它失败 → 写最小代码通过 → 看着它通过 → 清理保持测试绿色测试立即通过你在测试现有行为修复测试之后写的测试立即通过证明不了任何东西systematic-debuggingAI 的调试方式通常是看到错误 → 随机改点什么 → 看看好了没 → 不行就再改点别的。因为 AI 可以快速尝试很多次它会觉得反正试得快总能试对。但这种方法经常修复症状而不是根因还会引入新 bug。这个技能强制不找到根因不许修复。关键要点铁律没有先根因调查就没有修复四个阶段必须按顺序完成根因调查 → 模式分析 → 假设和测试 → 实现在多组件系统中先添加诊断工具收集证据显示在哪里失败再调查那个特定组件如果 3 修复失败停止并质疑架构红色标志“现在快速修复稍后调查”、“只是尝试更改 X 看看它是否工作”——所有这些都意味着停止返回根因调查verification-before-completionAI 最常说的话之一是“应该工作了”、“完成了”、“完美”——但没有任何证据。人类开发者会谨慎但 AI 倾向于过度自信。因为 AI 没有被打脸的概念它会随意声称成功。这个技能强制没有证据不能声称完成。关键要点铁律没有新鲜验证证据就没有完成声称门限函数识别 → 运行 → 阅读 → 验证 → 只有那时才声称常见失败测试通过需要测试命令输出构建成功需要构建命令退出 0代理完成需要 VCS 差异显示更改红色标志使用应该、“可能”、“似乎”在验证前表达满意信任代理成功报告receiving-code-reviewAI 倾向于“你说的都对我马上改”——不去验证反馈是否正确。人类开发者会批判性地思考但 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 之后我更感觉像是把任务交给了一个专业的研发团队。最后附上本文的信息图供大家参考