Superpowers使用指南：把Claude Code和Codex变成真正会按流程工作的开发Agent

很多人第一次看到 Superpowers 这个词，会以为它是某个官方新功能，或者某个插件按钮。

但如果用大白话说，我理解里的 Superpowers 更像这样一件事：

它不是一个单点能力，而是一套把 AI 从“会聊天”升级成“会按流程干活”的增强方法。

也就是说，它关心的不是：

  • 模型会不会写一段代码
  • AI 能不能回答一个问题
  • 它偶尔能不能给你一个还不错的建议

它真正关心的是：

  • AI 能不能进入一个明确的工作流
  • 能不能在不同阶段拿到不同上下文
  • 能不能按规则调用工具、脚本和资料
  • 能不能把一次经验沉淀成以后可复用的能力

这也是为什么我会把 Superpowers 放在 Skill扫盲 和 dev-skill 之间来讲。

  • Skill 解释的是能力单元是什么
  • Superpowers 解释的是这些能力怎么真正跑起来
  • Agent Team 解释的是多个 AI 怎么协作
  • dev-skill 解释的是这一整套能力怎么仓库化、工程化、治理化

一、为什么我会单独写一篇 Superpowers

因为很多人现在已经走到了同一个阶段：

  • 会写 Prompt 了
  • 会给 AI 喂上下文了
  • 也开始接触 Rules、Skill、MCP、命令脚本这些东西

但真正一上手，还是经常会遇到几个很真实的问题：

  • AI 回答得挺聪明，但不会自己走流程
  • 每次都要重新解释项目背景，重复劳动很重
  • 上下文一多就乱，关键资料反而被淹没
  • 任务一复杂，AI 又退回成“会说不会做”

这时候你会发现，问题不是“模型不够强”，而是缺了一层工作方法。

Superpowers 讲的就是这一层。

它本质上是在回答一个问题：

如果我希望 AI 像一个真正的开发搭子，而不是一次性聊天机器人，我到底应该怎么组织它？

二、什么是 Superpowers

如果要我给它一个尽量接地气的定义，我会这样说：

Superpowers = 规则 + 技能 + 工具 + 路由 + 记忆 + 治理 的组合增强。

单独看这里面的每一项，其实都不新鲜。

  • Rules 不是新概念
  • Skill 也已经越来越常见
  • 工具调用、命令执行、MCP 也都有人在用

但一旦你把它们组合起来，AI 的工作方式就会发生质变。

从“会答题”到“会做事”

没有 Superpowers 的时候，AI 更像一个临场发挥型选手：

  • 你问什么，它答什么
  • 你提醒一步，它走一步
  • 你不提醒，它就不会主动进入正确流程

有了 Superpowers 以后，它更像一个带 SOP 的搭子：

  • 先识别这是什么任务
  • 再加载对应能力
  • 再按约定顺序推进
  • 需要工具时去调工具
  • 做完后给出可复盘、可交付的结果

这张图其实就已经说明了 Superpowers 的核心味道：

它不是让 AI 更会“说”，而是让 AI 更会“按流程推进任务”。

三、Superpowers 到底增强了什么

我把它拆成 5 个最关键的能力。

1. 任务路由能力

AI 最怕的一件事，就是一上来把所有信息都吞进去，然后开始“自由发挥”。

Superpowers 的第一步，不是立刻干活，而是先判断：

  • 这是开发任务
  • 还是排障任务
  • 还是代码审查
  • 还是写文档
  • 还是查 JIRA、查日志、查链路

只有先分流，后面的上下文和工具才不会乱。

这也是为什么现在越来越多体系里，会把：

  • skill description
  • 路由器 skill
  • 命令入口
  • workflow orchestrator

这些东西放在最前面。

因为它们本质上是在帮 AI 做“任务分诊”。

2. 渐进式上下文加载能力

这一点和 Skill 是强相关的。

普通做法里，我们很容易把一大堆背景全部塞给 AI：

  • 项目规范
  • 业务背景
  • 常见坑位
  • 各类文档链接
  • 一堆脚本说明

结果是：

  • token 越来越贵
  • 有用信息密度越来越低
  • 真到关键任务时，上下文已经被冲散了

而 Superpowers 更像一层“按需读取机制”：

  1. 先只让 AI 看到能力目录
  2. 判断相关后再读 SKILL.md
  3. 真要落地时再读 references/
  4. 有脚本就直接执行，而不是让模型硬背

这一步一旦做好，AI 的行为会稳定很多。

3. 工具闭环能力

AI 真正有战斗力，不是因为它能“猜”，而是因为它能“查”和“做”。

所以 Superpowers 很重要的一环，就是把它和真实工具链接起来。

比如：

  • 用 shell 查代码、跑测试、起服务
  • 用脚本做统计、同步、校验
  • 用 MCP 去读平台资源、文档、数据库、监控
  • 用 Git 操作让结果真正落盘

你会发现，一旦 AI 不只是生成文本，而是能进入工具闭环，它就开始像一个执行系统了。

4. 多 Agent 协作能力

很多任务不是一个脑袋就能顺滑做完的。

比如一篇完整的技术文章，常常可以拆成：

  • 一个 Agent 负责梳理主题结构
  • 一个 Agent 负责搜集现有仓库和文章联动
  • 一个 Agent 负责检查 Hexo 渲染和链接是否正常

这就是为什么我会把 Superpowers 和 Agent Team 放在同一条链路里。

它们不是同一个概念，但天然互补：

  • Superpowers 解决“单个 Agent 怎么更会做事”
  • Agent Team 解决“多个 Agent 怎么分工协作”

5. 治理和沉淀能力

这一层其实最容易被低估。

很多人会把一次成功的 AI 使用经验，当作“这次运气不错”。

但如果你想让它长期可复用，就得继续往后走：

  • 把方法写成 Skill
  • 把脚本放进 scripts/
  • 把说明写进文档
  • 把使用记录沉淀成统计
  • 把常见入口做成标准工作流

从这个角度看，Superpowers 不是一招鲜，而是一套可以持续积累的能力系统。

四、它和 Skill、Rules、MCP、Agent Team 分别是什么关系

这一块特别容易混，我直接用一句话版本先讲：

  • Rules：长期静态背景
  • Skill：某类任务的能力说明书
  • MCP / Tools：让 AI 能查、能做、能执行
  • Superpowers：把上面这些东西真正组织起来的使用方法
  • Agent Team：把多个 Agent 编排成协作流水线

一张图看懂它们的分工

如果非要说它们谁更底层，我会这么理解：

  • Rules 负责“别跑偏”
  • Skill 负责“这类事怎么做”
  • Tool 负责“真干活靠什么”
  • Superpowers 负责“把这几样按流程串起来”

所以 Superpowers 更像是一套编排思想，而不是单一组件。

五、真实使用里，我会怎么给 Claude Code / Codex 上 Superpowers

这一段是最偏实操的，也是最容易直接照着做的。

第一步：全局 Rules 只保留长期有效的信息

不要把所有操作细节都塞进全局 Rules。

全局层更适合放：

  • 仓库基本背景
  • 协作习惯
  • 风格约束
  • 安全边界
  • 输出要求

一句话说就是：放长期有效、跨任务通用、每次都可能用到的东西。

第二步：把任务方法拆成 Skills

别把“如何做代码审查”“如何查日志”“如何写技术方案”全塞进一个大 Prompt。

把它们拆成独立 Skill 的好处是：

  • 描述更清楚
  • 触发更精准
  • 可以挂对应脚本和参考资料
  • 后续能独立演进

第三步：给常见任务做路由入口

比如：

  • 日常开发走一个入口
  • JIRA 闭环走一个入口
  • 排障诊断走一个入口
  • 文档写作走一个入口

这样 AI 不用每次从零猜你的意图。

第四步：能用脚本的地方，尽量别靠模型硬编

这是一个非常重要的经验。

如果某个动作本来就能脚本化，比如：

  • 查询统计
  • 生成模板
  • 同步文件
  • 执行标准检查

那就尽量让 AI 去调脚本，而不是自己现场“想象一个做法”。

这样稳定性会高很多。

第五步：把结果反向沉淀

每次遇到这些场景，都值得考虑是否沉淀：

  • 某个提示词反复有效
  • 某条执行顺序总是有用
  • 某个脚本特别省事
  • 某类问题总会重复出现

这时候最好的动作不是收藏聊天记录，而是把它升格成：

  • Rules
  • Skill
  • Script
  • Template
  • 文档

这条闭环一旦转起来，AI 的成长就不再只靠记忆，而是靠外部化沉淀。

六、结合我自己的 dev-skill 仓库，Superpowers 是怎么落地的

如果只讲概念，Superpowers 很容易显得有点虚。

但放到我自己的 dev-skill 仓库里，它就会非常具体。

我现在更愿意把这个仓库看成一套“能力中台”：

  • skills/dev/ 负责开发主流程
  • skills/cr/ 负责代码审查和测试相关流程
  • skills/zan/ 负责有赞内部平台能力接入
  • skills/platform/ 负责安装、同步、统计、工作树等平台支撑
  • skills/writing/ 负责文档、图表、PDF、方案协作

这其实就是把 Superpowers 变成了工程化结构。

它不是“很多 Skill 的堆叠”

更准确地说，它在做三件事：

  1. 把高频任务拆成标准能力单元
  2. 把能力单元接到真实脚本和平台上
  3. 把使用过程继续纳入统计、治理和迭代

一条典型链路长什么样

比如一个“JIRA -> 排查 -> 改代码 -> CR”的闭环，大致可以是这样：

你会发现，这已经不是“问一句答一句”的玩法了。

它更像一条围绕 AI 构建的微型研发流水线。

七、哪些场景最值得用 Superpowers

如果你刚开始搭，不用一上来就全都做。

我更建议从这 4 类任务开始：

1. 高频重复任务

比如：

  • 提交代码
  • 起分支
  • 写周报
  • 查 JIRA
  • 写技术方案模板

这类任务最适合先做标准化。

2. 容易出错的流程任务

比如：

  • 多仓库联动提交
  • 子模块提交顺序
  • 发布前检查
  • 排障链路分析

因为这些任务最需要“别漏步骤”。

3. 对上下文依赖很强的任务

比如：

  • 业务问题排查
  • 大型项目代码修改
  • 架构文档补全

这类任务只靠临场对话很容易失真。

4. 适合长期积累的方法任务

比如：

  • Code Review
  • 技术文章写作
  • 测试策略生成
  • 知识沉淀与复盘

因为做得越多，后面的复用收益越高。

八、一个很重要的认知：Superpowers 不是魔法，是工程

我很想强调这一点。

很多人听到 Superpowers，容易下意识理解成：

有没有什么神奇配置，一开就能让 AI 突然变得特别厉害？

真实情况恰恰相反。

它更像软件工程：

  • 你要拆分职责
  • 要控制上下文
  • 要规范输入输出
  • 要把可自动化的部分外置
  • 要给能力做版本化和治理

所以它不是“神秘技巧合集”，而是一套很朴素但很有效的工程方法。

说得再直白一点：

Superpowers 的核心，不是给模型加法术，而是给 AI 接流程、接制度、接工具、接沉淀。

九、如果你也想开始，可以直接照这个最小方案来

如果你不想一口气搞太重，我建议先从这个最小闭环开始：

  1. 写一份简短但稳定的全局 Rules
  2. 为 3 个最高频任务拆出独立 Skill
  3. 每个 Skill 只挂最必要的文档和脚本
  4. 给这 3 个任务各做一个清晰入口
  5. 每周回看一次，补沉淀、删噪音、修描述

这个版本就已经足够有感知了。

你会明显感受到的变化

  • AI 不再每次都要重头讲规则
  • 它更容易走进正确工作流
  • 产出结果更稳定
  • 你自己也更容易复盘“为什么这次做得好”

十、最后一句话

如果用一句话总结我理解里的 Superpowers，我会这么说：

它是把 AI 从“聪明回答者”升级成“流程化执行者”的那套方法。

它不等于某个产品功能，也不等于某个单独 Skill。
它是一整套围绕：

  • 上下文管理
  • 能力路由
  • 工具执行
  • 经验沉淀
  • 协作治理

建立起来的工作方式。

而一旦这套东西跑顺了，AI 才真的开始像一个能长期共事的开发 Agent。

延伸阅读