一个让开发者集体沸腾的 GitHub 项目#

兄弟们，这周的 GitHub Trending 榜上有一个项目直接杀疯了——Superpowers，短短几天就冲到了全站热度第一的位置。

如果你打开 GitHub Trending 页面，会看到一排熟悉的老面孔：MoneyPrinterTurbo、nanochat、Hermes Agent……但 Superpowers 硬是在这群”老将”中杀出了一条血路，Star 增长速度堪比火箭升空。

这个项目到底是什么来头？简单说，Superpowers 是一套 Agentic Skills 框架 + 软件开发方法论，它要解决的是当前 AI 编程工具最核心的痛点——“AI 写出来的代码为什么会跑偏？“

痛点直击：为什么你的 AI 助手总是不靠谱？#

先来聊聊大家共同的血泪史。

你用 Cursor 也好，Claude Code 也好，Copilot 也好，大概率遇到过这种场景：

1
// 你写了一个需求：创建一个用户注册表单，包含邮箱验证和密码强度检测
2
// AI 帮你生成了：
3
function RegisterForm() {
4
  return (
5
    <form>
6
      <input type="email" placeholder="邮箱" />
7
      <input type="password" placeholder="密码" />
8
      <button>注册</button>
9
    </form>
10
  );
11
}
12
// 表面看没问题，但仔细一查——
13
// ❌ 没有邮箱格式校验
14
// ❌ 没有密码强度检测
15
// ❌ 没有表单状态管理
16
// ❌ 没有错误处理
17
// ❌ 没有提交逻辑
18
// ❌ 没有 CSRF Token

为什么会这样？因为当前的 AI 编程助手本质上是在”一句话需求 → 直接生成代码”的流水线上工作。它缺乏需求分析、架构设计、方案评审、分步执行等关键环节的约束。

Superpowers 的创始人 Obra 对此有一个很经典的比喻：

“让 AI 直接写代码，就像让一个建筑师跳过设计图纸直接盖楼。有时候能盖出来，但大多数时候你会得到一个结构奇怪的违章建筑。“

Superpowers 的核心设计：Skill 驱动的工作流#

Superpowers 的核心概念很简单——把软件开发过程拆解为一系列可复用的 Skills（技能），每个 Skill 是一个结构化的 AI 工作流，包含明确的目标、输入、输出和质量标准。

来看一个实际的 Skill 定义：

1
name: implement-api-endpoint
2
version: 1.0.0
3
description: 基于 OpenAPI 规范实现一个完整的 API 端点
4

5
inputs:
6
  - name: spec_path
7
    description: OpenAPI 规范文件的路径
8
    type: string
9
  - name: method
10
    description: HTTP 方法 (GET/POST/PUT/DELETE)
11
    type: string
12
  - name: path
13
    description: API 路径
14
    type: string
15

16
steps:
17
  - name: parse-spec
18
    description: 解析 OpenAPI 规范，提取请求/响应模型
19
    prompt: |
20
      读取 {spec_path} 中的 {method} {path} 定义。
21
      提取以下信息：
22
      1. 请求参数（query/body/path）
23
      2. 响应模型（success/error）
24
      3. 认证要求
25
      4. 业务规则（如字段校验、权限）
26

27
  - name: generate-validator
28
    description: 生成请求参数验证器
29
    prompt: |
30
      根据上一步提取的参数定义，生成 Zod/OpenAPI 验证 schema。
31
      确保覆盖：
32
      - 字段类型验证
33
      - 必填项验证
34
      - 枚举值验证
35
      - 自定义业务规则
36

37
  - name: implement-handler
38
    description: 实现 API 处理器函数
39
    prompt: |
40
      根据已验证的参数和业务规则，实现 {method} {path} 处理器。
41
      需要包含：
42
      - 参数解构和验证
43
      - 业务逻辑实现
44
      - 错误处理和状态码
45
      - 日志记录
46
      - 响应格式化
47

48
quality_checks:
49
  - 所有参数都有类型声明
50
  - 错误路径有对应的 HTTP 状态码
51
  - 敏感操作有权限检查
52
  - 响应格式符合 OpenAPI 规范

这个 Skill 做了什么？它把”实现一个 API 端点”这个看似简单的任务，拆成了三个有明确边界的子步骤：

1. 解析规范（Parse Spec） — 让 AI 先理解 API 的全貌，而不是直接写代码
2. 生成验证器（Generate Validator） — 先定义约束，再写实现
3. 实现处理器（Implement Handler） — 在充分理解需求和约束后，生成高质量的代码

每个步骤都有独立的 Prompt 和验证条件，这就像给 AI 戴上了一个”思考-验证-执行”的安全锁。

实战：用 Superpowers 重构一个糟糕的 AI 生成结果#

光说不练假把式，我们来看看用了 Superpowers 和没用 Superpowers 的区别。假设我们想让 AI 实现一个”文章评论系统”的 API：

1
# AI 直接输出：
2
from flask import Flask, request, jsonify
3

4
app = Flask(__name__)
5

6
@app.route('/api/comments', methods=['POST'])
7
def create_comment():
8
    data = request.json
9
    # 表面看起来没问题
10
    comment = {
11
        'id': 1,
12
        'content': data['content'],
13
        'author': data['author'],
14
        'created_at': '2026-06-11'
15
    }
16
    return jsonify(comment), 201

1
# Step 1: 解析需求 → AI 生成文档
2
"""
3
API: POST /api/comments
4
需求分析：
5
- 需要 JWT 认证（用户必须登录才能评论）
6
- 评论内容需要 HTML 转义防 XSS
7
- 需要敏感词过滤
8
- 支持@用户通知
9
- 支持 Markdown 格式（部分标签白名单）
10
- 每分钟每个用户最多 10 条评论
11
"""
12

13
# Step 2: 生成验证器
14
from pydantic import BaseModel, Field, validator
15
import re
16

17
class CreateCommentRequest(BaseModel):
18
    content: str = Field(..., min_length=1, max_length=2000)
19
    parent_id: int | None = Field(None, description="父评论 ID，支持嵌套")
20

21
    @validator('content')
22
    def sanitize_html(cls, v):
23
        # 只允许安全的 Markdown 标签
24
        allowed_tags = {'b', 'i', 'code', 'pre', 'a', 'img'}
25
        # 转义所有 HTML，再恢复白名单标签
26
        from bleach import clean
27
        return clean(v, tags=allowed_tags, strip=True)
28

29
    @validator('content')
30
    def check_sensitive_words(cls, v):
31
        blocked = ['spam', 'advert', '恶意链接']
32
        for word in blocked:
33
            if word in v.lower():
34
                raise ValueError('评论包含违规内容')
35
        return v

安装和使用#

Superpowers 的安装非常简单：

1
# 克隆项目
2
git clone https://github.com/obra/superpowers.git
3
cd superpowers
4

5
# 安装依赖
6
pnpm install
7

8
# 运行初始化向导
9
pnpm superpowers init
10

11
# 查看可用技能列表
12
pnpm superpowers skills list
13

14
# 使用特定技能生成代码
15
pnpm superpowers run skill:implement-api-endpoint \
16
  --input spec_path=./api/openapi.yaml \
17
  --input method=POST \
18
  --input path=/api/comments

社区生态与未来#

Superpowers 的社区正在快速成长，目前已经贡献了超过 200 个社区 Skills，覆盖了从 Spring Boot 后端到 React 前端、从 Terraform 基础设施到 CI/CD 流水线的各个领域。每个 Skill 都是一个可复用的最佳实践模板。

更令人兴奋的是，Superpowers 的 Skills 并不局限于代码生成——它还可以用于：

• 代码审查和重构建议
• 测试用例生成
• 文档编写和更新
• 数据库迁移脚本生成
• 部署配置生成

对于团队来说，Superpowers 最大的价值在于把团队的架构经验和最佳实践沉淀为可复用的 Skills。新人加入项目不再需要”师傅带徒弟”式的口口相传，只需要执行对应的 Skills，AI 就能按照团队的标准生成代码。

写在最后#

Superpowers 的火爆不是偶然的。它代表了 AI 编程从”投机取巧”到”方法论驱动”的重大转变。如果你还在用”一句话指令”让 AI 帮你写代码，强烈建议你试试 Superpowers——给它一个规范，它还你一份工程级的代码。

项目地址：https://github.com/obra/superpowers

别忘了 Star 支持一下，这种真正在解决问题的开源项目，值得每一个开发者的关注。

深入理解 Superpowers 的技能生命周期#

讲了这么多 Superpowers 的优势，我们再深入一点看看它的技能生命周期管理。这是 Superpowers 区别于其他 AI 框架最核心的特性。

每个 Skill 在执行时，Superpowers 会维护一个完整的执行上下文，包括输入参数的校验、中间产物缓存、错误重试策略和最终输出的质量门禁。这套机制借鉴了软件工程中”流水线”的概念，把 AI 生成过程变成了可审计、可回放、可调试的结构化流程。

比如说你运行一个”生成 RESTful API”的 Skill，Superpowers 会在每一步记录下 AI 的思考过程和决策依据。如果生成的代码有 bug，你可以回溯到具体的步骤，看看是需求理解出了问题，还是实现方案有偏差。这种可追溯性对于团队协作来说简直是救星——你再也不用对着 AI 生成的代码抱怨”这玩意儿到底是怎么想出来的”。

Skill 之间还支持依赖和组合。你可以定义一个”生成完整微服务”的顶级 Skill，它内部按顺序调用”初始化项目结构”、“实现数据模型”、“实现 API 端点”、“生成测试用例”、“编写文档”这五个子 Skill。每个子 Skill 本身又可以被其他顶级 Skill 复用。这种嵌套组合的设计，让团队的架构经验和最佳实践可以像乐高积木一样灵活拼接。

而且每个 Skill 都可以设置不同的”温度”参数。代码生成类 Skill 用低温度（0.1-0.2）保证一致性，创意文案类 Skill 用高温度（0.7-0.9）激发多样性，架构设计类 Skill 用中等温度（0.4-0.5）在创新和稳定之间找到平衡。这种精细化的控制粒度，让 AI 不再是”一刀切”的黑盒子。

最后值得一提的是，Superpowers 的 Skills 可以导出和分享。社区正在建设一个类似 npm 的 Skills 注册中心，你可以发布自己打磨好的 Skills，也可以使用别人贡献的高质量 Skills。想象一下，一个新框架刚发布，社区里就已经有对应的”最佳实践 Skill”——你只需要运行一条命令，AI 就能按照社区公认的最佳方式生成代码。

如果你对 AI 编程的”工程化”感兴趣，Superpowers 值得深入研究。它代表着 AI 辅助开发的未来方向——不是取代开发者，而是让开发者的经验和智慧通过可复用的 Skills 得以传承和放大。

从 Superpowers 看 AI 编程的未来方向#

Superpowers 的走红让我想起了当年 GitHub Copilot 刚发布时的情形。那时候大家都在讨论”AI 会不会取代程序员”，四年过去了，答案已经很清楚——AI 没有取代程序员，但不会用 AI 的程序员正在被取代。Superpowers 代表的不是简单的”AI 帮你写代码”，而是一种全新的软件开发范式。

在这种新范式下，开发者的角色从”写代码的人”变成了”定义 AI 工作流的人”。你不再需要一行一行地写代码，而是需要设计出高质量的 Skill：定义清晰的输入输出边界、设计合理的执行步骤、设置有效的质量检查点、处理各种边界条件和异常情况。这其实比直接写代码更难，但对业务的价值也更大——因为一个设计良好的 Skill 可以被反复使用，团队里每个人都能从中受益。

我预测未来两年会出现大量的”AI 工作流工程师”岗位，他们不直接写业务代码，而是专门为团队设计和维护 AI Skills。这些 Skills 会成为团队的核心知识资产，就像今天的组件库和工具函数一样普遍。而 Superpowers 这样的框架，就是这种新范式的第一个成熟工具。

还有一个值得关注的方向是 Skills 的标准化和互操作性。如果不同团队的 Skills 采用不同的定义格式和接口规范，就没法形成一个健康的生态。Superpowers 的社区正在推动 Skills 标准化的工作，希望能够像 OpenAPI 规范统一了 API 描述格式一样，统一 AI 工作流的描述格式。如果这个目标实现，未来你可以在 Skills Marketplace 上搜索、下载和组合来自全球开发者的 Skills，就像今天安装 npm 包一样简单。

总之，Superpowers 不仅仅是又一个 GitHub 热门项目。它代表着 AI 编程从”帮忙写代码”到”系统化工程”的一次范式跃迁。我强烈建议每个团队的 Tech Lead 都去研究一下 Superpowers 的设计理念，好好想想怎样把这些思路应用到自己的项目中去。

写在最后的一些思考#

写了这么多关于 Superpowers 的技术细节，最后我想聊聊一个更深层的话题——当我们把更多决策权交给 AI 的时候，开发者的核心竞争力在哪里？

我觉得这个问题的答案很清晰：开发者的核心竞争力正在从”写代码的速度”转向”定义问题的能力”。过去十年，一个优秀程序员的核心优势是能够快速、准确地写出高质量的代码。但到了 2026 年，AI 工具已经能在几秒钟内生成一个人需要写一整天的代码。单纯比拼”手速”已经没有意义了。

真正有价值的技能变成了：你能不能把一个模糊的业务需求拆解成明确定义的子任务？你能不能识别出 AI 生成的方案中隐藏的架构缺陷？你能不能设计出高质量的工作流模板让整个团队受益？这些能力比”会写代码”更难培养，也更值钱。

Superpowers 这样的工具，本质上是在帮助开发者完成这个角色转变——从”执行者”变成”设计者”。它不要求你放弃写代码，而是要求你把精力从”怎么写”转移到”写什么”和”为什么写”上来。对于有经验的工程师来说，这是一个机遇远大于挑战的方向。对于刚入行的新人来说，你们的任务不是和 AI 比编程速度，而是学会如何驾驭 AI、定义 AI、引导 AI。

技术会变，工具会变，但”解决问题的能力”和”对业务的理解深度”永远不会过时。保持学习，保持思考，这比学会任何一个新框架都重要。

补充阅读#

如果你对 Superpowers 感兴趣，建议你去 GitHub 上看看它的 Skills 目录，里面有大量现成的 Skill 定义可以直接使用。同时也可以关注一下社区里正在讨论的”Skill 标准化”提案，参与这些讨论本身就是对 AI 编程生态的一种贡献。开源的魅力就在于此——你不仅是一个使用者，更可以成为一个建设者。把你自己的编程经验沉淀为 Skills，分享出去，帮助更多的人提高效率。这才是 Superpowers 真正的愿景——让每个人的经验都能被复用，让每个团队都能站在前人的肩膀上看得更远。随着越来越多的开发者和团队加入这个生态，我们有理由相信 AI 辅助编程的未来会更加光明。与其被动等待，不如主动参与，你今天写的一个 Skill 可能会在明天帮助到成千上万的开发者。如果你觉得 AI 编程的未来与你有关，现在就是最好的入场时机。从今天开始，试着把你的日常工作流拆解成可复用的 Skills，把 AI 从一个”帮忙写代码的工具”变成”你团队中最靠谱的工程师”。这条路需要时间，但方向绝对正确。