Superpowers 工作流工程化：从 Prompt 到可测试可部署的 AI 函数

最新推荐文章于 2026-06-22 14:27:05 发布

原创

最新推荐文章于 2026-06-22 14:27:05 发布 · 438 阅读

1. 从“调提示词”到“建工作流”：Superpowers 的本质不是魔法，而是工程化控制

我第一次在团队 Slack 里看到同事发来一段用 Superpowers 写的 Python 脚本时，下意识点开想看看他用了什么惊人的 prompt——结果发现那根本不是一段 prompt，而是一个带注释的 YAML 文件，里面定义了三步操作：先从 GitHub API 拉取最近 30 天的 issue 列表，再用一个叫 summarize_issues 的 skill 过滤出含 “bug” 或 “crash” 关键词的条目，最后调用 generate_report_md 把结果格式化成 Markdown 表格。整个过程没有一行自然语言指令，也没有反复重试、改写、加温度值。它跑完就生成了一份可直接贴进周会文档的报告。

那一刻我才真正意识到：Superpowers 不是让你把提示词写得更“强”，而是帮你把 AI 编程这件事，从“靠运气猜对模型心思”的玄学，拉回到“定义输入-处理-输出”的确定性工程轨道上。它解决的从来不是“怎么让 AI 听懂人话”，而是“怎么让人能稳稳地指挥 AI 做事”。

这和我们过去十年做后端服务的思路一模一样——没人会把业务逻辑硬塞进 HTTP 请求体里靠模型自己猜，而是拆成 Controller → Service → Repository 的清晰分层。Superpowers 就是给 AI 编程装上了这套分层架构。它不改变底层模型（Codex、Claude Code、甚至本地 Llama3），但彻底重构了人与模型之间的协作协议：你不再提交“一句话需求”，而是交付一份可版本管理、可单元测试、可灰度发布的 AI 工作流定义 。

关键词里的 skills 、 workflows 、 Codex 其实都在指向同一个事实：Superpowers 的核心价值不在它自己有多聪明，而在于它提供了一套标准化的“插槽”（slot），让任何开发者都能把任意能力——无论是调用 REST API、执行 Shell 命令、解析 PDF 表格，还是调用另一个大模型——封装成一个可复用、可组合、可审计的 skill 。而 workflow 就是把这些 skill 像乐高积木一样按需拼接的蓝图。你不需要懂模型原理，但必须懂接口契约；你不需要调参，但必须设计数据流向。

所以如果你还在搜索“superpowers 使用教程”却只找到一堆 prompt 示例，说明你已经站在了错误的起点上。真正的入门，不是学怎么写 prompt，而是学怎么定义一个 skill.yaml ，怎么声明它的输入 schema，怎么写它的执行逻辑，怎么测试它在边界条件下的行为。这就像当年学 Git，重点不是 memorize git add -A ，而是理解 staging area 和 commit graph 的语义。

提示：别被“superpowers”这个词迷惑。它不是超能力，而是“super-powered workflows”的缩写——强调的是工作流被增强，而非人被赋能。这个命名本身就暗示了它的工程属性：能力来自结构，而非个体天赋。

2. Skills 不是插件，是 AI 时代的函数签名：从定义到落地的完整闭环

很多人把 Superpowers 的 skills 理解成 VS Code 插件或浏览器扩展，这是最危险的认知偏差。插件是运行在宿主环境里的黑盒程序，而 skill 是一个严格契约化的 AI 可调用函数 。它的存在意义，是让大模型能像调用 Math.sqrt() 一样，可靠地调用 github.list_issues(owner="myorg", repo="backend", days=30) 。要实现这一点， skill 必须满足三个硬性条件：可发现、可验证、可隔离。

2.1 Skill 的物理形态：YAML + 代码的双轨制

一个典型的 skill 目录结构长这样：

skills/
├── github_list_issues/
│   ├── skill.yaml          # 契约定义：名称、描述、输入参数、输出结构
│   ├── handler.py          # 执行逻辑：纯 Python，无框架依赖
│   └── test_handler.py     # 单元测试：覆盖正常流、空响应、HTTP 404 等

skill.yaml 是灵魂。它不是配置文件，而是接口说明书。以 github_list_issues 为例，它的关键字段是：

name: github_list_issues
description: "List issues from a GitHub repository within specified time range"
input_schema:
  type: object
  properties:
    owner:
      type: string
      description: "GitHub organization or username"
    repo:
      type: string
      description: "Repository name"
    days:
      type: integer
      description: "Number of days to look back"
      default: 30
output_schema:
  type: array
  items:
    type: object
    properties:
      number:
        type: integer
      title:
        type: string
      state:
        type: string
        enum: ["open", "closed"]

注意这里没有写“如何实现”，只声明“能接受什么、返回什么”。这和 OpenAPI Spec 的设计哲学完全一致——契约先行，实现后置。模型在规划 workflow 时，只读取 skill.yaml 就能知道能否调用它、需要传什么参数、得到什么结构的数据。 handler.py 里具体是用 requests.get() </

标签