随着 Claude Code、Codex、Cursor、Gemini CLI、Pi、OpenCode 等 AI 编程工具功能增多,AI 已经可以参与从需求分析到测试、调试的多个开发环节。
但很多开发者实际使用后都会发现一个问题:模型本身很强,并不意味着它总能采用可靠的软件工程流程。
面对一个稍微复杂的需求,AI 很容易直接开始写代码,遗漏需求细节;遇到 Bug 时反复修改,却没有真正找到根因;开发完成后又没有充分测试,最后得到的代码虽然“能跑”,却可能留下大量技术债务。
Superpowers 针对的正是这个问题。
Superpowers 是一个面向 AI 编程代理(Coding Agent)的软件开发方法论 + Skills 技能框架。它不是一个新的大语言模型,也不是单独的 IDE,而是通过一套可组合的技能和工作流程,让 AI 编程代理更系统地完成需求分析、设计、规划、实现、测试、代码审查和交付。
截至本文撰写时,Superpowers 仓库列出了 Claude Code、Antigravity、Codex App、Codex CLI、Cursor、Devin CLI、Factory Droid、Gemini CLI、GitHub Copilot CLI、Grok Build CLI、Kimi Code、OpenCode、Pi、Hermes Agent 等适配对象,并采用 MIT License 开源。官方 GitHub 仓库目前拥有约 27.6 万颗 Star,是 AI 编程工作流领域非常受关注的开源项目。
一、Superpowers 到底是什么?¶
Superpowers 官方对它的定位是:
一个完整的软件开发方法论,建立在一组可组合的 Skills 和初始化指令之上,为 Coding Agent 提供更加系统的软件开发流程。
这里有两个关键词:
Skills(技能)
以及
Workflow(工作流)。
传统的 AI 编程通常类似于:
用户提出需求
↓
AI 理解需求
↓
AI 开始写代码
↓
出现问题
↓
AI 修改代码
↓
继续测试
Superpowers 希望把它变成更加接近正规软件工程的过程:
需求
↓
头脑风暴 / 澄清需求
↓
设计方案
↓
用户确认
↓
建立独立开发环境
↓
制定详细实现计划
↓
TDD 测试驱动开发
↓
实现功能
↓
代码审查
↓
验证结果
↓
完成分支
官方 README 描述的核心流程也是从 brainstorming 开始,在设计确认后制定 implementation plan,然后使用 subagent-driven development 或执行计划进行实现,并在开发过程中强调 TDD、YAGNI、DRY 等软件工程原则。
因此,Superpowers 解决的主要是流程问题,而不是模型本身的能力问题。
二、为什么 AI 编程需要 Superpowers?¶
AI 写代码最大的优势是速度。
但速度同时也会放大一些问题。
例如你对 AI 说:
帮我给网站增加一个用户注册功能。
普通 AI 可能马上开始:
好的,我来创建 User 表、注册接口、登录接口……
但一个真正的软件项目可能还涉及:
- 用户需求到底是什么
- 是否需要邮箱验证
- 密码应该如何存储
- 是否支持手机号
- 是否需要验证码
- 登录状态如何保存
- 是否需要限流
- 错误信息如何处理
- 数据库迁移如何处理
- 如何测试
- 如何与现有项目兼容
如果 AI 在没有充分理解需求之前就开始写代码,就很容易出现“实现速度很快,但方向一开始就错了”的问题。
Superpowers 的理念恰恰是:
先不要急着写代码。
先理解需求,再设计,再计划,最后实现。
三、Superpowers 最核心的工作流程¶
Superpowers 的核心工作流可以概括为:
Brainstorming
↓
Design
↓
Git Worktree
↓
Implementation Plan
↓
TDD
↓
Implementation
↓
Code Review
↓
Verification
↓
Finish Branch
官方 README 当前列出的基础流程包括 brainstorming、using-git-worktrees、writing-plans、subagent-driven-development / executing-plans、test-driven-development,以及后续的代码审查和分支收尾等环节。
下面分别介绍。
四、Brainstorming:写代码之前先搞清楚要做什么¶
这是 Superpowers 非常重要的一环。
当你提出:
我想给这个项目增加一个搜索功能。
Superpowers 不应该立即开始修改代码,而是先帮助你明确:
- 搜索什么内容?
- 搜索页面在哪里?
- 用户如何输入关键词?
- 是全文搜索还是标题搜索?
- 数据量有多大?
- 是否需要分页?
- 是否需要模糊匹配?
- 搜索结果如何排序?
- 有没有性能要求?
- 是否需要移动端适配?
它通过类似“苏格拉底式”的方式逐步澄清需求,并形成设计方案。
官方 README 对 brainstorming 的描述是:在开始编码之前,通过问题进一步明确真正想解决的问题,探索不同方案,并把设计分段呈现给用户确认。
很多所谓的“AI 写错代码”,根源并不是编程能力不足,而是需求没有定义清楚。
五、Writing Plans:把需求变成真正可以执行的开发计划¶
需求确定以后,Superpowers 不会简单地告诉 AI:
开始实现吧。
而是进一步生成详细的 implementation plan。
官方的 writing-plans 技能强调把工作拆分成较小、可执行的任务,并明确相关文件、实现内容和验证方式。
例如,一个普通的计划可能只是:
1. 增加用户认证
2. 修改数据库
3. 增加 API
4. 增加前端页面
5. 测试
而 Superpowers 更强调把任务拆得足够具体,例如:
Task 1
修改 src/models/user.ts
- 增加 User 模型字段
- 增加唯一索引
- 添加对应迁移
- 运行数据库测试
Task 2
修改 src/api/auth.ts
- 增加注册接口
- 校验邮箱
- 对密码进行安全哈希
- 增加重复邮箱测试
这样可以把“要实现什么”转换成明确的执行路线,减少遗漏和返工。
六、Git Worktrees:让不同开发任务彼此隔离¶
Superpowers 还强调使用 Git Worktree。
传统开发方式可能是:
main
└── 当前工作目录
如果 AI 在当前目录里修改大量代码,一旦方向出现问题,恢复起来会比较麻烦。
Worktree 则可以让不同任务拥有独立的工作目录:
项目
├── main
├── feature-login
├── feature-search
└── bugfix-payment
Superpowers 中的 using-git-worktrees 技能会在设计确认后帮助建立隔离的开发环境,并在开始开发前检查项目状态及测试基线。
这样特别适合 AI 编程。
因为 AI 很可能一次修改几十个文件。
有了独立 Worktree:
主分支
│
├── 原始代码
│
└── 独立功能分支
│
├── AI 修改
├── AI 测试
└── AI 提交
即使 AI 最后把代码改得不满意,也不会直接污染主分支。
七、TDD:Superpowers 为什么特别强调测试驱动开发?¶
Superpowers 一个非常鲜明的特点,就是强调:
Test-Driven Development(TDD)
也就是:
RED
↓
GREEN
↓
REFACTOR
1. RED¶
先写一个会失败的测试。
测试新功能
↓
运行
↓
失败
2. GREEN¶
然后实现最少量的代码,让测试通过。
修改代码
↓
运行测试
↓
通过
3. REFACTOR¶
最后在保持测试通过的前提下优化代码。
重构
↓
测试
↓
通过
Superpowers 的 test-driven-development 技能明确要求遵循 RED-GREEN-REFACTOR,并强调先看到失败测试,再实现代码,随后验证测试通过。
这和一些 AI 编程工具常见的方式差异很大。
普通方式:
AI 写代码
↓
AI 觉得应该可以
↓
“应该没问题”
Superpowers 更强调:
提出验证条件
↓
运行测试
↓
看到事实
↓
修改代码
↓
再次验证
因此它的另一个核心理念就是:
Evidence over claims —— 用证据代替“我认为已经完成”。
八、Systematic Debugging:不要看到 Bug 就开始乱改代码¶
Superpowers 还非常强调系统化调试。
例如网站出现:
登录失败
普通 AI 很容易直接:
修改登录接口
然后:
还是失败
继续修改:
增加 try/catch
修改数据库查询
修改 JWT
增加日志
最终可能修改了大量代码,却没有找到真正的问题。
Superpowers 的 systematic-debugging 思路则要求先进行系统化调查,寻找根因,而不是进行无依据的猜测式修改。官方技能库也把 systematic-debugging、root-cause-tracing、defense-in-depth、condition-based-waiting 等作为相关调试能力的一部分。
理想流程应该更接近:
发现 Bug
↓
重现 Bug
↓
收集证据
↓
定位根因
↓
提出假设
↓
验证假设
↓
修复
↓
验证
这对于复杂项目尤其重要。
九、Subagent-driven Development:让不同 AI Agent 协同工作¶
Superpowers 的另外一个重要特点是:
Subagent-driven development
也就是把一个较大的开发任务分配给多个独立的子代理。
例如一个大型功能可以拆成:
主 Agent
│
├── Subagent A:数据库
│
├── Subagent B:后端 API
│
├── Subagent C:前端
│
└── Subagent D:测试
完成任务以后,再由其他 Agent 进行检查。
官方文档明确提到,Subagent-driven development 可以为不同工程任务派发新的 subagent,并进行两阶段审查:先检查是否符合需求,再检查代码质量。
也就是说,不只是:
Agent 写代码
而可以变成:
Agent A 写
↓
Agent B 检查是否符合需求
↓
Agent C 检查代码质量
↓
主 Agent 汇总
这在大型任务中尤其有用,但也会增加模型调用和协调成本。
十、代码审查:让 AI 不只是“自己写、自己说没问题”¶
Superpowers 的技能体系中还包含:
requesting-code-reviewreceiving-code-reviewverification-before-completion
等流程。
其中一个重要思想是:
不要让负责实现代码的 Agent 成为唯一的评判者。
因为 AI 很容易出现:
写代码
↓
自己运行一次
↓
自己判断
↓
“完成”
而更加严格的流程可以变成:
实现
↓
测试
↓
代码审查
↓
修复问题
↓
重新测试
↓
最终验证
官方技能列表把代码审查、验证以及最终完成前的检查都纳入完整开发流程。
十一、Superpowers 的 Skills 到底是什么?¶
Superpowers 并不是一个巨大的 Prompt。
它主要由大量独立的 SKILL.md 组成。
例如:
skills/
├── brainstorming/
├── writing-plans/
├── executing-plans/
├── test-driven-development/
├── systematic-debugging/
├── using-git-worktrees/
├── subagent-driven-development/
├── requesting-code-review/
├── receiving-code-review/
├── verification-before-completion/
└── ...
每一个 Skill 都对应一种能力或者一种工作流程。
例如:
brainstorming
负责需求和设计。
writing-plans
负责制定实施计划。
test-driven-development
负责 TDD。
systematic-debugging
负责系统化排查问题。
using-git-worktrees
负责隔离开发环境。
这种设计的一个重要优势是:
Skills 可以组合,而不是把所有行为写进一个超级 Prompt。
十二、Superpowers 为什么能支持这么多 Coding Agent?¶
这套跨平台适配主要依赖核心 Skills 与具体 Coding Agent 工具的分离。
官方文档把核心 Skills 与具体 Coding Agent 的工具进行了分离。
核心 skills/ 中的内容是尽量与具体 Agent 无关的,例如:
读取文件
创建文件
运行命令
调用子代理
创建任务
不同 Coding Agent 再把这些抽象动作映射到自己的工具。
官方的跨 Harness 文档明确指出,Superpowers 的核心技能内容在不同 Harness 中共享,而每个 Harness 只需要提供一层适配,将抽象动作映射到自己的工具系统。
因此可以把它理解成:
Superpowers
│
┌─────────────┼──────────────┐
│ │ │
Skills Workflow Methodology
│
↓
┌──────┼──────┬─────────┬─────────┐
↓ ↓ ↓ ↓ ↓
Claude Codex Cursor OpenCode Pi
这为适配不同 Coding Agent 提供了基础。
十三、哪些 AI 编程工具可以使用 Superpowers?¶
截至本文撰写时,官方 README 列出的适配对象包括:
| Coding Agent | Superpowers 支持 |
|---|---|
| Claude Code | ✅ |
| Antigravity | ✅ |
| Codex App | ✅ |
| Codex CLI | ✅ |
| Cursor | ✅ |
| Devin CLI | ✅ |
| Factory Droid | ✅ |
| Gemini CLI | ✅ |
| GitHub Copilot CLI | ✅ |
| Grok Build CLI | ✅ |
| Kimi Code | ✅ |
| OpenCode | ✅ |
| Pi | ✅ |
| Hermes Agent | ✅ |
官方仓库提供了各平台对应的安装说明。
需要特别注意的是:
不同 Coding Agent 的安装方式并不相同。
而且如果你同时使用 Claude Code、Codex、OpenCode、Pi 等多个工具,需要分别安装,因为它们是不同的 Harness。官方 OpenCode 文档也明确说明,即使你已经在其他 Harness 中使用 Superpowers,OpenCode 仍需要单独安装。
十四、Claude Code 安装 Superpowers¶
Claude Code 是目前使用 Superpowers 比较方便的平台之一。
官方提供两种主要安装方法。
方法一:Anthropic 官方插件市场¶
在 Claude Code 中运行:
/plugin install superpowers@claude-plugins-official
这是官方 README 当前提供的安装方式。
方法二:Superpowers Marketplace¶
先添加 Marketplace:
/plugin marketplace add obra/superpowers-marketplace
然后:
/plugin install superpowers@superpowers-marketplace
同样由官方仓库提供。
安装完成后启动新的 Claude Code 会话,然后可以尝试:
帮助我设计一个用户登录功能
如果 Superpowers 正常加载,它应该在适当的时候触发相关 Skill,而不是简单地直接开始写代码。
十五、Codex CLI 安装 Superpowers¶
对于 Codex CLI,目前官方 README 提供了插件市场安装方式。
在 Codex CLI 中输入:
/plugins
搜索:
superpowers
然后选择:
Install Plugin
官方 README 当前把 Codex CLI 的官方插件市场安装作为主要方式。
手动安装方式¶
如果你的 Codex 环境无法使用插件市场,也可以使用官方文档中的手动方式。
首先:
git clone https://github.com/obra/superpowers.git ~/.codex/superpowers
然后创建 Skills 目录并建立链接:
mkdir -p ~/.agents/skills
ln -s ~/.codex/superpowers/skills ~/.agents/skills/superpowers
Windows 可以使用目录 Junction:
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.agents\skills"
cmd /c mklink /J "$env:USERPROFILE\.agents\skills\superpowers" "$env:USERPROFILE\.codex\superpowers\skills"
官方 Codex 文档明确提供了 Windows 下使用 Junction 的方案,因为它通常不要求开启 Developer Mode。
完成后重启 Codex。
十六、Cursor 安装方法¶
目前 Superpowers 已经可以通过 Cursor Agent 的插件市场安装。
在 Cursor Agent Chat 中使用:
/add-plugin superpowers
或者直接在插件市场搜索:
superpowers
然后进行安装。
十七、OpenCode 安装方法¶
OpenCode 使用自己的 Plugin 机制。
官方推荐的方法是让 OpenCode 获取安装说明:
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md
OpenCode 文档当前给出的典型配置方式是在 opencode.json 中加入:
{
"plugin": [
"superpowers@git+https://github.com/obra/superpowers.git"
]
}
然后重新启动 OpenCode。
也可以通过 OpenCode 的 Skill 工具检查技能:
use skill tool to list skills
然后加载某个技能:
use skill tool to load brainstorming
官方文档同时指出,OpenCode 项目的 Skills 优先级是:
Project Skills
>
Personal Skills
>
Superpowers Skills
这意味着你可以在项目内部定义自己的 Skill,并覆盖通用行为。
十八、Pi Coding Agent 安装 Superpowers¶
如果你正在使用 Pi Coding Agent,那么 Superpowers 同样已经提供了原生支持。
安装:
pi install git:github.com/obra/superpowers
官方 README 当前就是这样安装。
如果只是本地开发或测试,可以:
pi -e /path/to/superpowers
官方说明指出,Pi 版本的 Superpowers 会加载 Superpowers Skills,并通过一个扩展在会话启动以及上下文压缩后重新注入 using-superpowers bootstrap。
需要注意:
Pi 本身具有原生 Skills,因此不需要兼容性的 Skill 工具。
但 Subagent 和任务列表等能力仍然可以通过 Pi 的其他配套包提供。
十九、Hermes Agent 安装 Superpowers¶
Hermes Agent 目前也已经进入官方支持列表。
安装:
hermes plugins install obra/superpowers --enable
安装完成后重启正在运行的 Hermes 会话。
官方还特别提醒:
Hermes 目前没有 post-compaction hook。
因此,在一个非常长的会话里,如果第一次上下文压缩之后 Skills 开始无法触发,建议直接开启新的会话。
二十、一个真实的 Superpowers 使用示例¶
假设我们要开发一个功能:
给我的网站增加一个暗色模式。
普通 AI 编程方式可能是:
修改 CSS
增加 dark class
增加按钮
保存 localStorage
完成
而使用 Superpowers 后,流程应该更加完整。
第一步:Brainstorming¶
你告诉 AI:
我想给网站增加暗色模式。
AI 会进一步明确:
暗色模式应该默认关闭还是跟随系统?
需要支持手动切换吗?
用户选择是否保存?
页面刷新后是否保持?
是否所有页面都支持?
是否需要处理第三方组件?
移动端是否需要特殊处理?
经过沟通后形成设计。
第二步:设计确认¶
最终确定:
1. 默认跟随系统
2. 用户可以手动切换
3. 用户选择保存到 localStorage
4. 页面刷新后保持
5. 所有主要页面支持
此时才进入下一步。
第三步:建立独立 Worktree¶
创建:
feature/dark-mode
并确保当前项目测试基线通过。
第四步:制定 Implementation Plan¶
例如:
Task 1
创建 theme 状态管理模块
Task 2
实现 localStorage 持久化
Task 3
增加主题切换按钮
Task 4
定义 dark theme CSS variables
Task 5
更新组件颜色
Task 6
增加测试
Task 7
执行完整验证
第五步:TDD¶
先写:
theme.test.ts
验证:
用户没有设置 → 跟随系统
用户设置 dark → 保存 dark
重新加载 → 恢复 dark
用户选择 light → 保存 light
第一次测试失败。
这是正常的:
RED
然后实现代码:
GREEN
最后:
REFACTOR
第六步:Code Review¶
开发完成以后,再检查:
是否满足需求?
是否有重复代码?
是否影响旧页面?
是否有测试遗漏?
是否存在浏览器兼容问题?
第七步:最终验证¶
最后不要只说:
已经完成。
而是实际运行:
npm test
npm run build
并检查最终结果。
Superpowers 与简单的“AI 写代码”流程的差别,主要就在过程、验证和可重复性。
二十一、Superpowers 与普通 Prompt 有什么区别?¶
这是一个非常值得理解的问题。
假设你写了一个 Prompt:
你是一名高级软件工程师。
写代码之前先分析需求。
一定要测试。
遇到问题先分析根因。
不要写不必要的代码。
看起来已经不错。
但问题是:
Prompt 只是告诉模型应该怎么做,而 Superpowers 把这种行为拆成具体的 Skills 和工作流程。
例如:
需求分析
↓
brainstorming
实施计划
↓
writing-plans
隔离环境
↓
using-git-worktrees
开发
↓
test-driven-development
调试
↓
systematic-debugging
协作
↓
subagent-driven-development
完成前验证
↓
verification-before-completion
这意味着 Superpowers 更像一个:
AI 软件工程流程系统
而不是简单的一段“超级提示词”。
二十二、Superpowers 与 MCP 有什么区别?¶
很多新用户容易把两者混淆。
实际上它们解决的问题不同。
MCP¶
MCP 主要负责:
AI
↓
连接外部工具 / 数据 / 服务
例如:
GitHub
数据库
浏览器
搜索
第三方 API
文件系统
Superpowers¶
Superpowers 更关注:
AI
↓
应该如何完成软件开发
例如:
先需求分析
↓
设计
↓
计划
↓
实现
↓
测试
↓
审查
↓
验证
因此两者完全可以一起使用。
可以把它理解成:
MCP = AI 能用什么工具
Superpowers = AI 应该怎么工作
二十三、Superpowers 与 Agent Skills 有什么区别?¶
Superpowers 本质上也是基于 Skills 的体系。
因此它并不是和 Skills 对立的东西。
更准确地说:
Agent Skills
↓
一种让 Agent 掌握特定行为 / 方法的机制
Superpowers
↓
大量经过设计的软件开发 Skills
+
工作流
+
不同 Coding Agent 的适配
所以可以把 Superpowers 看成一个面向软件工程的 Skills 集合与方法论。
二十四、Superpowers 最适合什么人?¶
Superpowers 特别适合下面几类用户。
1. 经常让 AI 开发完整功能的人¶
如果只是让 AI:
帮我写一个正则表达式
Superpowers 的价值有限。
但如果是:
给我的项目增加会员系统
那么它就很有价值。
2. 经常使用 Claude Code、Codex、Cursor 等 Coding Agent 的开发者¶
尤其是复杂项目。
因为任务越复杂:
需求理解
代码修改
测试
调试
Review
之间的关系就越重要。
3. 希望 AI 更自主工作的开发者¶
Superpowers 一个很明显的目标就是:
让 AI 在明确计划之后能够自主完成大量工作。
官方 README 甚至描述了通过 subagent-driven development,让 Agent 可以在较长时间内按照既定计划连续工作。
当然,这并不意味着可以完全放任 AI。
越大的任务,越应该保留:
设计确认
计划确认
最终代码审查
二十五、哪些情况没有必要使用 Superpowers?¶
Superpowers 并不是所有任务都需要。
例如:
帮我解释一下 Python 的 map()
没有必要。
帮我写一个 10 行 Shell 脚本。
通常也没有必要。
帮我把这段代码改成 async。
也未必需要。
但是:
给项目增加支付系统
重构整个用户权限系统
修复一个长期存在的复杂 Bug
把旧项目迁移到新的框架
这些任务就非常适合使用系统化流程。
二十六、Superpowers 的优点¶
1. 让 AI 少一点“直接开干”¶
这是最重要的价值。
复杂项目最怕:
AI 很勤奋
但方向错了。
Superpowers 强迫流程更加重视需求和设计。
2. 更强调测试¶
不是:
AI 说完成
而是:
测试证明完成
3. 更适合复杂任务¶
简单任务优势可能不明显。
但任务变复杂之后:
计划
任务拆分
Subagent
Review
验证
这些能力的价值会越来越高。
4. 支持多个 Coding Agent¶
Superpowers 并不绑定单一模型或单一产品。
这意味着你可以根据需要使用:
Claude Code
Codex
Cursor
OpenCode
Pi
Gemini CLI
Kimi Code
Hermes Agent
...
而核心开发方法保持相似。
5. 开源¶
Superpowers 使用 MIT License。
这意味着开发者可以查看其 Skills、工作流和适配代码,并根据项目需求进行研究和扩展。
二十七、Superpowers 的局限性¶
Superpowers 能约束开发流程,但不会让 AI 在安装后变成不会犯错的程序员。
需要注意几个问题。
1. 流程本身也会增加时间¶
如果一个任务原本 30 秒完成,现在先 Brainstorming、写计划、测试、Review,肯定会增加额外步骤。
因此:
小任务 → 不一定值得完整流程
大任务 → 更值得使用
2. AI 还是可能犯错¶
Superpowers 可以改善工作流程,但不能消除模型错误。
AI 仍可能:
理解错误
生成错误代码
遗漏边界条件
测试覆盖不足
所以最终的人类审查仍然很重要。
3. Subagent 会产生额外成本¶
使用多个 Agent 意味着:
更多模型调用
更多上下文
更多 Token
因此对于大型任务,应该合理安排 Agent,而不是为了“多 Agent”而多 Agent。
4. 不同 Harness 的支持能力并不完全相同¶
Superpowers 的核心 Skills 尽量保持一致,但具体 Coding Agent 的工具能力不同。
例如不同平台:
Subagent
Task List
Plugin
Skill
Hook
Worktree
实现方式可能不一样。
官方文档也特别指出,不同 Harness 所需要的适配层和工具映射有所不同。
所以实际效果可能会有所差异。
二十八、第一次使用 Superpowers,应该怎么测试?¶
不要一安装就把整个生产项目交给 AI。
建议先用一个小型测试任务。
例如:
给这个项目增加一个 /health 接口。
要求:
1. 返回 JSON
2. 返回服务状态
3. 增加测试
4. 不修改现有 API
然后观察 AI 是否会:
检查 Superpowers
↓
Brainstorming
↓
制定设计
↓
写计划
↓
实现
↓
测试
↓
验证
如果整个流程运行正常,再尝试较复杂的任务。
二十九、如何充分发挥 Superpowers 的作用?¶
安装只是第一步。
任务描述仍然很重要。
相比:
做一个登录功能
建议这样描述:
我需要给现有项目增加用户登录功能。
请先理解现有项目结构,不要立即修改代码。
先使用 Superpowers 的 brainstorming 流程分析需求,
确认设计后再制定 implementation plan。
登录需要:
- 邮箱 + 密码
- 密码安全存储
- 登录状态持久化
- 登录失败处理
- 单元测试
- 不影响现有用户数据
在真正修改代码前先让我确认设计方案。
这样更容易让 AI 按照完整流程执行。
三十、Superpowers 的核心思想,可以浓缩成一句话¶
如果把整个项目压缩成一句话,可以理解为:
不要让 AI 只是“写代码”,而是让 AI 像一个遵循软件工程流程的开发团队一样工作。
它强调:
先理解
↓
再设计
↓
再计划
↓
再编码
↓
先测试
↓
再验证
↓
再审查
↓
最后交付
而不是:
想到哪写到哪
三十一、Superpowers 值得安装吗?¶
对于经常使用 AI Coding Agent 的开发者来说,Superpowers 值得尝试。
尤其是你经常使用:
- Claude Code
- Codex CLI
- Codex App
- Cursor
- OpenCode
- Pi
- Gemini CLI
- Kimi Code
- Hermes Agent
这类工具进行实际项目开发时,Superpowers 可以为原本比较自由的 AI 编程过程增加更加严格的工程方法。
它的价值不在于让 AI 多写几行代码,而在于让 AI 面对复杂任务时:
少一点冲动式编码,多一点分析;少一点猜测,多一点验证;少一点“应该完成了”,多一点真正的测试和审查。
对于只需要 AI 修改几行代码的小任务,这套流程可能显得过重;但对于一个需要持续开发几十分钟、几小时甚至更长时间的复杂功能,Superpowers 的价值会明显提升。
结语¶
AI 编程正在从“AI 帮我补代码”逐渐发展到“AI 独立完成软件工程任务”。
在这个过程中,真正限制 AI 的有时候已经不再只是模型能力,而是如何让模型可靠、持续、可验证地完成复杂工作。
Superpowers 选择的路线并不是继续堆叠一个更长的 Prompt,而是把成熟的软件工程方法拆解成可以由 Coding Agent 自动调用的 Skills,并通过 brainstorming、planning、TDD、systematic debugging、subagent-driven development、code review 和 verification 等环节,将 AI 编程变成一套更加系统化的工作流程。
对于已经使用 Claude Code、Codex、Cursor、OpenCode、Pi 等工具的开发者来说,Superpowers 可以理解为一套附加的软件工程工作流。
它要解决的不是“AI 会不会写代码”,而是“AI 能否按可检查的流程完成复杂的软件任务”。
官方资源¶
- Superpowers GitHub:https://github.com/obra/superpowers
- 官方文档目录:https://github.com/obra/superpowers/tree/main/docs
- Skills 目录:https://github.com/obra/superpowers/tree/main/skills
本文内容依据 Superpowers 官方 GitHub 仓库及其当前各平台安装文档整理,相关安装命令和支持平台可能随着项目更新而变化,实际使用时建议优先以官方仓库最新内容为准。