最近在体验各类 AI 编码工具时,我发现了一个有趣的现象:大多数人和 AI 的交互方式其实都是"推送模式"(Push)——用户提出问题,AI 填空作答。但真正高效的协作应该是"拉取模式"(Pull)——用户描述情况和目标,AI 反向提问,一步步逼出需求的真实面貌。最近发现的这个 11 万+ Star 的开源项目 Superpowers,恰好将这套交互理念系统化了,值得一看。

项目概览
Superpowers 是一套完整的软件开发工作流程框架,核心思想是通过组合式的"技能模块"(共 17 个 skills)来规范 AI 编码代理的工作方式。项目地址:https://github.com/obra/superpowers
这套系统的与众不同之处在于:它改变了传统"用户提需求→AI 直接写代码"的流程。取而代之的是一套苏格拉底式追问的前置阶段,通过结构化的问题澄清,确保 AI 真正理解用户的需求边界。

核心工作流(七步制)
整套流程可以分解为以下七个阶段:
1. 需求澄清阶段
不立即开始编码,而是进行深入的头脑风暴。通过逐个问题的追问方式,逐步明确:目标定义、应用场景、约束条件、成功标准和边界范围。官方原文对任务粒度的定义很直白——拆分到"足以让一个热情但品味差、缺乏判断力、不了解项目背景且讨厌测试的初级工程师来执行"的程度。
2. 工作空间隔离
使用 git worktree 创建独立开发分支,将本次开发工作与主分支完全隔离,确保实验性开发不影响现有代码。
3. 计划拆分阶段
将澄清后的需求拆解为细粒度的具体任务,每个任务都应该是自包含、可独立执行的单元。
4. 分布式执行
为每个拆分后的任务分配一个独立的 sub-agent 执行,并行处理多个子任务,提高整体效率。
5. TDD 驱动开发
严格遵循测试驱动开发(Test-Driven Development)范式:先编写测试用例→观察测试失败→编写实现代码→验证测试通过。
6. 自动审查机制
每个任务完成后自动触发两层审查:首先检查功能是否符合规格定义,其次进行代码质量评审。
7. 最终决策
全量测试通过后,根据结果决策是否进行合并、提交 PR、保留分支或丢弃。
技能模块详解
Superpowers 包含 17 个可组合的技能模块,覆盖开发周期的各个阶段:
- 前置技能:需求分析、设计验证
- 执行技能:代码编写、测试编写、调试
- 协作技能:代码审查、文档生成
- 元技能:包括教 AI 如何创建新技能的能力
这种模块化设计意味着不同团队可以根据自身需求组合不同的技能集合。
与同类产品对比
| 维度 | Superpowers | Cursor | GitHub Copilot |
| 工作流程设计 | 系统化流程框架 | 编辑器集成 | 补全/建议型 |
| 需求澄清机制 | 内置苏格拉底式追问 | 人工启动 | 无 |
| 任务分解能力 | 自动细粒度拆分 | 需手动指导 | 不支持 |
| 测试驱动支持 | 强制 TDD 流程 | 可选 | 可选 |
| 适合场景 | 复杂功能开发 | 快速迭代编码 | 代码补全 |
支持平台与安装
Superpowers 支持多个主流 AI 编码平台:
- Claude Code
- Cursor
- Codex
- Gemini CLI
安装方式简洁——一行命令即可完成部署,开源免费。这种开箱即用的设计降低了使用门槛。
实践建议
如果你想手动实现类似的交互模式,可以直接向 AI 丢出以下提示词:
"请你在回答前,先问我问题。要求:1. 一次只问我一个问题。2. 根据我的回答继续追问,不要并行甩出一堆问题。3. 先帮我澄清目标、场景、限制条件、成功标准和边界。4. 直到你有 95% 的把握理解我的真实需求后,再给我方案。5. 如果你发现我的需求本身有问题,直接指出来,并继续追问。"
不过,Superpowers 的优势在于将这套方法论编程了可复用的系统,省去每次都要手动输入提示词的麻烦。
应用场景拓展
这套工作流不仅限于编码领域。其核心的"澄清→拆分→执行→审查"范式可扩展到:
- 产品设计:先通过追问明确设计目标,再进行设计方案拆分
- 技术方案设计:在架构评审前做充分的需求澄清
- 内容创作:通过结构化追问优化选题和内容框架
总结
Superpowers 的核心价值不在于使用了多么先进的 AI 模型,而在于用系统化的流程重塑了人与 AI 的协作方式。它将模糊的需求澄清过程显式化、结构化,用逻辑追问替代盲目填空,用细粒度拆分降低单个任务的复杂度。

对于经常使用 AI 编码工具的团队来说,这套框架提供的是一种可复用、可传播的协作范式。与其期待 AI 模型本身变得更聪明,不如先优化人与 AI 的交互方式——这往往能获得更直接、更稳定的效率提升。
如果你正在用 AI 处理复杂的开发任务,不妨先从这套流程的前两个阶段开始尝试——你可能会发现,大多数"需求不清"问题的根源,其实在于澄清阶段做得不够充分。