Superpowers——给 AI 编程装一套“工作纪律“

coder Ethan

625人浏览 · 2026-07-23 08:00:00

coder Ethan · 2026-07-23 08:00:00 发布

概述

有时候我们使用AI写代码时，比如你告诉它帮我加个搜索功能，它二话不说就开始写。也不问你搜索范围是什么、用什么排序、要不要分页。等你看到结果，方向已经跑偏了，你花的时间不是在想怎么设计，而是在纠正它自作主张写出来的东西。

Superpowers 就是治这个的。

它是一个开源的技能框架，作者是 Jesse Vincent（做过 Request Tracker 那个工单系统，也参与过 Perl 5 语言发布）。框架的本质是一组 SKILL.md 文件，装到你的 AI 编程助手上之后，AI 的行为方式会变：不再一上来就写代码，而是先跟你聊清楚要做什么、怎么做，确认了再动手。

GitHub 上目前 230k+ stars，MIT 协议，完全免费。支持的平台包括 Claude Code、Codex（CLI 和 App）、Cursor、Gemini CLI、OpenCode、GitHub Copilot CLI、Kimi Code 等十几种。

Superpowers 的核心是一个强制性的工作流。装好之后，AI 帮你做功能时会走这几个阶段：

头脑风暴（brainstorming）：AI 不急着写代码，先跟你讨论你要做什么，一段一段地确认设计细节，直到你明确同意方案
创建隔离工作区（git worktree）：在新分支上建一个独立的工作目录，不碰你的主分支
写实现计划（writing plans）：把任务拆成一个个 2-5 分钟的小任务，每个任务都写清楚要改哪个文件、代码大概长什么样、怎么验证
分派子 Agent 执行（subagent-driven-development）：每个小任务用一个全新的子 Agent 来做，做完后有两轮审查——先看是否符合规范，再看代码质量
TDD（测试驱动开发）：写代码之前先写失败测试，看到测试红了再写实现，测试绿了再提交

整个流程自动触发，你不需要手动调命令。AI 检测到你开始做新功能时，自动就进入了这个流程。
在这里插入图片描述

适合场景：

适合：功能开发、模块重构、跨多个文件的改动、你想让 AI 自主跑一两个小时的长任务。这些事情如果方向跑偏了，返工成本很高，花 10-20 分钟先对齐设计是值得的。
不适合：改两行代码的 bug 修复、随手试试想法的实验性编码。强制走一遍头脑风暴加计划纯属浪费时间。Superpowers 自己也知道这一点，简单请求可能不会触发完整流程，但如果你不放心，小任务直接不开插件也行。

各个 Skill 介绍

上面我们说了Superpowers框架的本质是一组 SKILL.md 文件。

Superpowers 里有 20 多个 Skill，按功能分几类。下面挑重点讲。

核心工作流 Skill

这几个 Skill 串起来就是 Superpowers 的主干流程，也是自动触发的。

brainstorming（头脑风暴）

检测到你要开始做新东西时自动激活。它不是简单问你"你想做什么"，而是用苏格拉底式对话来挖你的真实需求。它会追问边界条件、架构取舍、你想没想到的场景。设计方案会分成几个小节展示给你，每节你确认了才往下走。只有你明确同意了，才会生成一份设计文档进入下一步。

这一步的目的就是挡住"一上来就写代码"的冲动。很多最贵的 bug 不是代码写得不好，而是方向一开始就错了。

using-git-worktrees（Git 工作树）

设计确认后自动激活。它会在一个新分支上创建 git worktree，给你一个完全隔离的工作目录。你的 main 分支不受影响，你可以在主分支上继续干别的事。它还会跑一遍项目初始化，确认测试基线是干净的，才开始写代码。

writing-plans（写计划）

根据确认的设计文档，生成一份粒度非常细的实现计划。每个任务都写得像给一个"热情但没有判断力的初级工程师"看的：精确的文件路径、预期的完整代码片段、验证步骤。每个任务控制在 2-5 分钟的工作量。

计划写得这么细看起来啰嗦，但它的用意是逼出所有假设。写到一半才发现"这里到底用 A 方案还是 B 方案"是最贵的返工。在计划阶段用文字讨论，成本几乎为零。

subagent-driven-development（子 Agent 驱动开发）

在有子 Agent 能力的平台上（目前主要是 Claude Code 和 Codex），每个任务由一个全新的子 Agent 执行。新 Agent 意味着没有上下文污染——它不会带着前面任务里积累的无关信息来做当前任务。

做完之后有两轮审查。第一轮看是否符合规范和计划，第二轮看代码质量。两轮都过了才算完成。

这个机制解决了长会话里"上下文漂移"的问题：AI 跑久了会逐渐偏离原始需求，用子 Agent 就每次都是干净的起点。

executing-plans（执行计划）

在不支持子 Agent 的平台上（Cursor、Gemini CLI 等），用这个替代。它按顺序执行任务，设了人工检查点。没有子 Agent 的并行和上下文隔离优势，但基本流程是一样的。

test-driven-development（测试驱动开发）

实现阶段全程强制 RED-GREEN-REFACTOR。先写一个会失败的测试，确认它失败了，再写最少的代码让测试通过，然后提交。如果 AI 试图在写测试之前先写实现代码，这个 Skill 会把代码删掉重来。

听起来严格，但这就是 TDD 该有的样子。AI 默认的倾向是"先写实现再补测试"，这等于在验证自己已经写对的东西，而不是用测试驱动设计。

requesting-code-review（请求代码审查）

在任务之间自动触发。它会对照计划做一轮审查，按严重程度报告问题。关键问题会阻止继续往下走。

finishing-a-development-branch（完成开发分支）

所有任务做完后激活。它会验证测试是否通过，然后给你选项：合并到主分支、创建 PR、保留分支、还是丢弃。最后清理 worktree。

调试相关 Skill

systematic-debugging（系统化调试）

一个四阶段的根因分析流程。不是那种"改一行试试看"的随机调试，而是先收集证据、形成假设、验证假设、再修复。里面还包含了 root-cause-tracing（根因追踪）、defense-in-depth（纵深防御）和 condition-based-waiting（基于条件的等待）几个子技术。

verification-before-completion（完成前验证）

修完 bug 后强制验证。不是 AI 说"我改好了"就算完了，要跑测试、看输出、确认问题真的消失了。

协作相关 Skill

dispatching-parallel-agents（分派并行 Agent）

多个子 Agent 同时干活。适合任务之间互相独立的场景，比如同时审查安全性、并发性、测试覆盖率。

receiving-code-review（接收代码审查）

别人（或另一个 Agent）给了审查意见之后，AI 该怎么处理反馈。不是一股脑接受所有建议，而是按优先级和合理性来判断。

元 Skill

writing-skills（写 Skill）

教你怎么写新的 Skill。如果你想给 Superpowers 加自定义的工作流（比如"每次改数据库 migration 时的固定检查清单"），看这个。

using-superpowers（使用 Superpowers）

介绍 Skill 系统本身。它在每次 session 启动时注入，告诉 AI：“如果有 Skill 适用于你当前的任务，你必须用它，这不是建议，是强制的。”

安装

不同平台安装方式不一样。下面看下

Claude Code（最推荐的平台）

两种装法。从 Anthropic 官方插件市场装：

/plugin install superpowers@claude-plugins-official

或者从 Superpowers 自己的市场装：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

装完直接能用。Session 启动时会自动注入 using-superpowers 这个主 Skill。

Codex App

在 Codex 应用的侧边栏点 Plugins，找到 Coding 分类下的 Superpowers，点 + 号安装。

Cursor

在 Cursor Agent 的聊天框里：

/add-plugin superpowers

或者在插件市场搜 superpowers 安装。

注意 Cursor 不支持子 Agent，所以执行阶段会走 executing-plans 而不是 subagent-driven-development。

其他平台

Gemini CLI、Copilot、Antigravity、Factory Droid、Kimi Code、OpenCode、Pi 也都支持，具体安装命令可以看 GitHub README，每个平台都有对应说明。

更新

大多数平台上更新是自动的。手动更新的话重新执行安装命令就行，插件会拉最新的 skills。

使用案例

案例一：给电商系统加优惠券功能

假设你要给一个电商项目加优惠券系统。没有 Superpowers 的话，你可能直接说"帮我加个优惠券功能"，AI 就开始写代码了。

有 Superpowers 的对话大概是这样：

你：帮我加一个优惠券功能

AI（brainstorming 自动激活）：
  优惠券系统范围挺大的，我需要先搞清楚几件事：
  - 优惠券是固定金额折扣还是百分比折扣？两种都支持？
  - 有使用次数限制吗？
  - 能叠加吗？
  - 过期机制是什么？
  - 后台管理需要哪些操作？

你：百分比折扣，每个码限用一次，不能叠加，设个过期时间就行

AI：
  明白了。那我来整理一下设计方案——

  ## 数据模型
  Coupon 表：code（唯一）、discount_percent、expires_at、used_at、order_id
  
  ## 核心逻辑
  - 下单时输入 code，校验有效性和过期时间
  - 折扣金额 = 订单总额 × discount_percent / 100
  - 使用后记录 used_at 和 order_id，不可再次使用
  
  ## 不做的事
  - 不做叠加
  - 不做后台批量管理界面（后续需求再加）
  
  这个设计可以吗？

你：可以

AI（writing-plans 自动激活）：
  已生成实现计划，共 6 个任务：
  1.1 创建 Coupon 模型和 migration
  1.2 写 Coupon 有效性校验函数（先写测试）
  1.3 在下单流程中集成优惠券扣减
  ...

然后每个任务由子 Agent 独立完成，走 TDD，做完有审查。整个过程可能跑一两个小时，你中间只需要确认几次。

案例二：重构一个 600 行的函数

你有个函数越长越难维护，想拆开。直接让 AI 拆它可能改坏调用方。

你：src/order/process.ts 里的 processOrder 函数有 600 多行，帮我拆一下

AI（brainstorming）：
  我看了一下这个函数，它做了四件事：
  1. 校验订单状态
  2. 计算价格（含各种折扣逻辑）
  3. 扣库存
  4. 发通知
  
  我建议拆成这四个函数，放在 src/order/ 下的独立文件里。
  processOrder 本身变成一个编排函数，依次调用这四步。
  
  有几个问题需要确认：
  - 扣库存失败时要不要回滚价格计算？
  - 通知是同步发还是异步发？
  
你：不用回滚，通知改成异步的

AI：好，我来出计划。

后续的计划阶段会把每一步拆成小任务，每个都有 TDD。拆完之后主函数变成了一个清晰的流程编排器，四个子函数各自独立可测。

案例三：调试一个偶发的支付回调失败

你：支付回调偶尔会失败，帮我查一下

AI（systematic-debugging 自动激活）：
  好的，我先收集证据，不急着改代码。
  
  1. 能把最近的失败日志贴给我吗？
  2. 失败时的请求参数是什么样的？
  3. 大概多久出现一次？
  4. 有没有规律（比如特定金额、特定支付方式）？

它不会上来就改代码，而是先走四阶段的根因分析：收集证据、形成假设、验证假设、确认修复。