type
status
date
slug
summary
tags
category
icon
password
wechat_gate
Superpowers Skill 的核心价值，不是给 AI 增加某个单点功能，而是把需求澄清、方案设计、TDD、调试、代码审查和完成前验证这些工程动作固化成可复用流程。本文基于 Superpowers 与 Startup Superpowers 的素材，拆解 Skill 是什么、适合哪些开发场景、使用和不使用的差别，以及在 Claude Code 和 Codex 中如何落地。

先说结论：Skill 不是提示词，而是“流程约束”

最近看 Superpowers 相关资料时，我觉得最值得关注的不是它有多少个具体 skill，而是它试图解决一个很现实的问题：
AI coding agent 很容易“会写代码，但不一定按工程流程做事”。
你让它修 bug，它可能马上读文件、猜原因、改代码。你让它做功能，它可能直接开干，等写完才发现需求理解偏了。你让它重构，它可能顺手改了一堆相邻代码，最后风险比收益还大。
这不是模型“不会写代码”，而是软件开发本身需要流程纪律：
  1. 先弄清楚目标，而不是马上实现。
  1. 先形成可验证计划，而不是边写边想。
  1. 修 bug 要追根因，而不是猜一个补丁。
  1. 新功能要尽量测试先行，而不是完成后补测。
  1. 宣布完成前要验证，而不是凭感觉说“应该好了”。
Superpowers Skill 做的事情，就是把这些流程变成一组可加载、可组合、可复用的 agent 操作规程。它不是让 AI “更聪明”，而是让 AI 更像一个被流程约束住的工程师。

Superpowers 是什么？

从官方项目描述看，Superpowers 是一套面向 coding agents 的软件开发方法论。它建立在一组 composable skills 之上，通过初始指令确保 agent 在合适场景下调用这些 skills。
换成更工程化的说法：
Superpowers = 一套把“软件工程最佳实践”编码成 agent 工作流的 skill 框架。
它的基本思路不是“给模型一段更长的提示词”，而是把不同任务拆成不同 skill：
Skill
解决的问题
核心产出
brainstorming
需求还不清楚，不能马上写代码
经过澄清的设计方向
writing-plans
方案需要落成可执行步骤
带文件路径、任务拆分和验证方式的计划
test-driven-development
新功能或修复需要测试约束
RED-GREEN-REFACTOR 循环
systematic-debugging
bug 不能靠猜
根因假设、逐步验证、最小修复
verification-before-completion
完成不能只靠口头声明
实际运行、测试、浏览器或设备验证
requesting-code-review
提交前需要找风险
按严重程度排列的问题清单
using-git-worktrees
多任务并行需要隔离
独立工作区和干净基线
这些 skill 组合起来，覆盖了从需求讨论到最终收尾的完整开发链路。

Skill 到底是干嘛用的？

如果只看表面，Skill 像是一份说明书：什么时候该做什么，先做哪一步，验证什么结果。
但在 AI agent 场景里，它的作用更具体：

1. 把“怎么做”从对话里抽离出来

普通使用方式下，用户每次都要提醒：
这很累，而且用户一旦忘记提醒，agent 就可能退回默认行为。
Skill 的意义是把这类重复约束沉淀下来。用户只需要说“修这个 bug”或者“实现这个功能”，agent 根据任务类型加载对应 skill，自动进入调试流程、TDD 流程或计划流程。
也就是说：

2. 降低 agent 的“即兴发挥”

AI 写代码的一个常见问题是行动太快。它可以很流畅地解释、实现、补丁、总结，但流畅不等于正确。
Superpowers 的核心约束是把 agent 从“直接写代码”拉回“先走流程”：
这条链路看起来慢，但它解决的是复杂项目里最昂贵的问题：方向错、边界错、验证缺失、回归没人发现。
notion image

3. 让流程跨会话保持一致

单次对话里，你可以给 agent 很长的系统提示。但真实项目往往跨很多天、很多会话。
Skill 的价值在于：
  1. 每次会话都能重新加载最新流程。
  1. 同一类任务走同一套标准。
  1. 团队可以把流程写进仓库或插件，而不是散落在聊天记录里。
这对长期项目很重要。软件项目真正麻烦的地方往往不是某一段代码，而是“今天、明天、下周再回来时，大家是否仍然按同一套工程纪律做事”。

使用场景：什么时候值得用 Superpowers Skill？

不是所有任务都需要重流程。问一个命令、查一个小配置、改一个明显 typo，直接做就可以。
Superpowers 更适合这些场景。

场景一：新功能开发

典型输入：
没有 skill 时，agent 很可能马上找文件、写 UI、补 API、加状态字段。问题是：会员能力涉及支付、权限、状态同步、失败回滚、测试和上线风险，不适合直接开写。
使用 Superpowers 后，合理流程应该是：
  1. brainstorming：先澄清功能边界，比如套餐、试用、退款、权限降级。
  1. writing-plans：拆出数据结构、接口、UI、测试、验收步骤。
  1. test-driven-development：先写关键业务规则测试。
  1. executing-plans：按步骤实现。
  1. verification-before-completion：跑测试、走关键路径。
它不是让功能变简单，而是让风险显性化。

场景二：复杂 bug 排查

典型输入：
这种问题最怕“猜”。可能是缓存、异步竞态、状态没更新、请求失败、视图复用，也可能是测试环境问题。
systematic-debugging 的价值在这里非常明显：它会要求 agent 先列假设，再逐个验证，而不是同时改三处代码。好的调试流程一般包含：
  1. 复现现象。
  1. 建立 3-5 个根因假设。
  1. 从最简单、最可能的假设开始验证。
  1. 每次只改变一个变量。
  1. 找到根因后再做最小修复。
  1. 最后用测试或真实路径验证。
这能减少“补丁看似有效，但根因还在”的情况。

场景三：重构和架构调整

重构最容易失控。用户说“整理一下这个模块”，agent 可能改命名、拆文件、换结构、顺手修格式，最后 diff 巨大，review 成本很高。
Superpowers 的计划类 skill 可以把重构限制在清晰边界内：
  1. 为什么要重构？
  1. 哪些文件必须改？
  1. 哪些行为不能变？
  1. 先跑哪些基线测试？
  1. 每一步如何验证？
这很关键。重构不是“看起来更优雅”，而是在行为不变的前提下降低复杂度。

场景四：多 agent 并行开发

Superpowers 素材里提到 subagent-driven-development 和 dispatching-parallel-agents。这类 skill 适合把复杂任务拆给多个子 agent：
  1. 一个 agent 负责实现。
  1. 一个 agent 检查是否符合 spec。
  1. 一个 agent 做代码质量 review。
  1. 主 agent 负责汇总和推进。
但这里有一个前提：任务必须能拆清楚，交付物必须能验证。否则并行只会放大混乱。

场景五：创业想法验证

素材里的 Startup Superpowers 是另一个很好的例子。它不是普通编码流程，而是把创业验证流程做成 Claude Code 插件。
它包含这些 slash command：
Command
用途
/whats-next
判断当前阶段，推荐下一步
/competitors
梳理直接和间接竞品
/market-research
研究市场、客户、定价和趋势
/hypotheses
写下可验证假设
/interviews
设计访谈脚本并分析访谈记录
/surveys
设计问卷并管理调查
/mvp
设计最小可测试 MVP
它的特点是 local-first、file-based：所有产物都是项目目录下的 Markdown 文件。这说明 skill 不只适合写代码，也适合把某种专业工作流固化为 agent 能执行的步骤。

使用和不使用，对项目开发有什么差别？

下面这张表是我认为最实际的区别。
维度
不使用 Skill
使用 Superpowers Skill
需求澄清
容易直接实现用户第一句话
先通过 brainstorming 澄清目标和边界
计划质量
计划可能停留在高层描述
writing-plans 要求任务可执行、可验证
测试习惯
经常写完后补测，甚至不测
TDD skill 强制先写失败测试
调试方式
容易凭经验猜 patch
systematic-debugging 要求假设和证据
重构范围
容易扩大 diff
计划和验证约束改动边界
完成判断
“我已经修好了”
verification-before-completion 要求实际验证
跨会话一致性
依赖用户反复提醒
Skill 文件提供稳定流程
团队复用
经验留在某次聊天里
流程可以沉淀为插件或仓库规范
这里要讲清楚一个边界：Skill 不能保证 agent 写出的代码一定正确。它也不能替代开发者判断架构取舍。
它真正改善的是“流程型错误”：
  1. 没问清楚就实现。
  1. 没计划就大改。
  1. 没测试就声称完成。
  1. 没找根因就修 bug。
  1. 没 review 就进入下一步。
这些错误不是模型能力越强就自然消失。模型越强，写得越快，流程失控时的破坏范围反而可能越大。
notion image

一个典型开发任务应该怎么跑？

假设我们要在一个 Web 项目里增加“用户导出账单”功能。没有 Superpowers 时，agent 可能直接生成接口、按钮和下载逻辑。
更稳的 Superpowers 流程应该是这样：

第一步：Brainstorming，先问清楚需求

需要确认的问题包括：
  1. 导出的是 PDF、CSV 还是 Excel？
  1. 用户可以导出多久的数据？
  1. 是否需要权限校验？
  1. 导出是同步下载还是异步任务？
  1. 大数据量时如何处理？
  1. 失败后用户看到什么？
这一步不是拖慢进度，而是避免后面返工。

第二步：Writing Plans，把方案拆成可执行任务

一个合格计划不能只写：
它应该更像：
这里的重点是：每一步都有文件边界和验证方式。这样 agent 执行时不容易漂移。

第三步：TDD，用失败测试锁住行为

TDD skill 的意义不是“为了测试而测试”，而是先定义行为。
例如导出 CSV 的业务规则可以先写成测试：
真正的流程是：
  1. 写失败测试。
  1. 确认测试确实失败。
  1. 写最小实现。
  1. 确认测试通过。
  1. 再重构。
这比“先实现再补测”更能约束 agent。

第四步：Code Review，不只看能不能跑

代码能跑不代表可以合并。requesting-code-review 或类似 review skill 应该重点看：
  1. 是否符合原计划。
  1. 是否引入越权风险。
  1. 是否有大数据量问题。
  1. 是否有未覆盖的错误状态。
  1. 是否改动了不相关文件。
对 AI 生成代码来说，review 的价值非常高。因为 agent 很容易写出“看起来完整”的实现，但边界条件和异常路径不够严谨。

第五步：Verification，完成前必须验证

最后一步不能只说“测试通过”。不同项目需要不同验证：
项目类型
验证方式
CLI 工具
实际运行命令，检查输出
Web 应用
启动 dev server，用浏览器走关键路径
iOS 应用
优先真机验证，尤其是 IAP、StoreKit、权限和系统能力
后端服务
跑测试、类型检查、关键接口请求
SDK / Library
单元测试、集成测试、示例项目验证
这一步对应的是 Superpowers 的一个核心原则：Evidence over claims。不要让 agent 用“我认为完成了”代替“我已经验证过了”。
notion image

在 Claude Code 中怎么使用？

根据素材和 Superpowers 项目说明，Claude Code 有两种安装路径。

方式一：从官方插件市场安装

在 Claude Code 中运行：

方式二：添加 Superpowers marketplace 后安装

如果使用 Superpowers 自己的 marketplace，可以先注册：
再安装：
安装后按提示 reload 插件。如果你在多个 workspace 使用 Claude Code，需要注意插件安装范围：有些插件适合全局安装，有些更适合按项目安装。

Claude Code 里的使用方式

安装完成后，不应该把 skill 当成普通文档手动复制给模型，而是让 Claude Code 的 Skill / Plugin 机制加载它。
典型触发方式有两类：
  1. 显式命令：例如运行某个 slash command。
  1. 语义触发：用户说“帮我修 bug”“帮我做计划”“实现这个功能”时，相关 skill 介入。
素材里特别强调了一个原则：skill 检查要发生在行动之前。也就是说，遇到调试、计划、TDD 等任务时，agent 不应该先读文件、先改代码、先问一堆问题，而应该先判断是否有适用 skill。
一个合理的 Claude Code 工作流是：
这才是 Superpowers 的重点：不是多一个命令，而是改变 agent 的默认行动顺序。

在 Codex 中怎么使用？

Superpowers 也支持 Codex CLI 和 Codex App。根据 Superpowers 项目说明，Codex 侧的安装入口是官方 Codex plugin marketplace。

Codex CLI

在 Codex CLI 中打开插件界面：
搜索：
然后选择 Install Plugin。

Codex App

在 Codex App 中：
  1. 打开侧边栏的 Plugins。
  1. 在 Coding 分类里找到 Superpowers。
  1. 点击 + 并按提示安装。

Codex 里的使用方式

Codex 中的核心用法和 Claude Code 类似：安装插件后，让 Superpowers 的 skills 参与当前会话。
实际使用时可以这样理解：
  1. 用户明确点名某个 skill 或插件时，Codex 应优先读取对应 SKILL.md。
  1. 用户没有点名，但任务明显匹配某个 skill 的 description 时，也应加载对应 skill。
  1. 加载后，Codex 需要先声明正在使用哪个 skill，以及为什么使用。
  1. 执行过程中，按 skill 的 workflow 做，不要凭记忆跳步骤。
例如你可以这样发起任务：
或者：
在 Codex 的实际工程项目里，我更建议把 Superpowers 当作“任务进入方式”，而不是某种一次性提示词。也就是说，做复杂任务时先让 agent 进入正确流程，再开始读代码和修改文件。

Startup Superpowers 给我们的启发

素材里另一个项目是 Startup Superpowers。它和 Superpowers 本体不是同一个东西，但很适合作为 skill 方法论的应用案例。
Startup Superpowers 解决的不是“怎么写代码”，而是“创业想法怎么验证”。它把早期创业验证拆成：
  1. 竞品分析。
  1. 市场研究。
  1. 假设管理。
  1. 用户访谈。
  1. 问卷调查。
  1. MVP 设计。
  1. 下一步规划。
更重要的是，它把所有状态写在项目目录的 startup/ 下面，用 Markdown 存储。这有几个好处：
  1. 产物可读，不被 SaaS 锁住。
  1. 可以提交到 Git，看到想法如何演进。
  1. 可以用 Obsidian 浏览证据图谱。
  1. agent 之间可以通过文件交接，而不是依赖聊天上下文。
这说明 skill 的真正价值不是“某个模型会了某项技能”，而是把一个专业流程变成可执行、可追踪、可复盘的工作系统。

实战建议：怎么把 Superpowers 用好？

1. 不要把 Skill 当万能药

Skill 是流程约束，不是质量保证。它能减少常见流程错误，但不能替你判断产品取舍、架构边界和业务优先级。
如果需求本身不清楚，Skill 会帮助澄清；但最终取舍还是需要人做。

2. 复杂任务先走 plan，简单任务不要过度工程化

我的经验判断是：
任务
是否需要 Superpowers 重流程
改错别字、查命令
通常不需要
单文件小修
可选，至少要验证
bug 排查
建议使用 systematic-debugging
新功能
建议使用 brainstorming + writing-plans + TDD
跨模块重构
强烈建议使用 plan + verification
上线前收尾
强烈建议使用 review + verification
Skill 的目标不是让每个动作都变慢，而是在风险变大时自动提高工程纪律。

3. 让 skill 写进项目规范

如果团队长期使用 Claude Code 或 Codex，建议把下面内容写进项目级说明文件，例如 AGENTS.md、CLAUDE.md 或插件配置：
这些规则看似普通，但对 AI agent 很重要。因为 agent 默认会倾向于“完成用户请求”，而不是“最小风险地完成用户请求”。

4. 每次都重新加载，不要靠记忆

素材里有一个很实用的提醒：Skill 内容会演进，不要因为“我记得这个 skill 大概是什么”就跳过加载。
这点对 agent 尤其关键。人可以靠经验灵活处理，但 agent 的“记得”经常只是上下文里的近似印象。真正可靠的做法是读取当前 skill 文件，按当前版本执行。

5. 明确区分 Skill、Memory 和 Plan

这三个东西容易混：
概念
作用
生命周期
Skill
规定某类任务怎么做
可跨会话复用
Memory
记录用户偏好和项目背景
跨会话持久
Plan
当前任务的执行步骤
当前任务内有效
举个例子：
  1. Skill 规定“修 bug 要系统调试”。
  1. Memory 记录“这个用户偏好 bun，不喜欢 npx”。
  1. Plan 记录“这次修复要先看登录接口，再补测试，再验证”。
这三个合在一起，才会让 agent 的行为既稳定，又贴合当前项目。

常见误区

误区一：有了 Skill，就不用写清楚需求

不对。Skill 可以帮助澄清需求，但不能凭空知道真实业务。
你仍然需要提供：
  1. 目标。
  1. 约束。
  1. 优先级。
  1. 验收标准。
Skill 只是让 agent 更有纪律地追问和执行。

误区二：Skill 越多越好

也不对。Skill 太多会导致触发混乱，甚至互相冲突。
好的 skill 应该满足三个条件：
  1. 场景清晰。
  1. 触发条件明确。
  1. 流程能验证。
如果一个 skill 只是写了一堆泛泛建议，它对 agent 的实际帮助有限。

误区三：只要装了插件，agent 就一定会按流程做

不能这么理解。不同宿主的插件机制、触发规则和上下文优先级会有差异。
更稳的做法是：在关键任务开头明确要求使用对应 skill。例如：
或者：
这样可以减少 agent 误判任务类型的概率。

我会怎么在真实项目里使用它？

如果是我的项目，我会这样分层使用。

日常小任务

保持轻量。让 agent 直接改，但要求：
  1. 改动范围小。
  1. 不做无关重构。
  1. 完成后运行必要验证。

有风险的 bug

明确调用：
然后要求 agent 把验证结果写清楚：
  1. 哪个假设被排除。
  1. 哪个假设被证实。
  1. 根因是什么。
  1. 为什么这个修复是最小修复。

新功能或重构

明确调用：
计划确认后再让它进入实现阶段。实现过程中尽量让测试先行。

合并或发布前

明确调用：
这一步能挡住很多“看起来完成了”的问题。

总结

Superpowers Skill 的本质，是把软件工程流程变成 AI agent 可执行的规则系统。
它解决的不是“AI 会不会写代码”，而是：
  1. 会不会先澄清需求。
  1. 会不会制定可验证计划。
  1. 会不会测试先行。
  1. 会不会系统性调试。
  1. 会不会完成前实际验证。
  1. 会不会把复杂任务拆给合适的执行单元。
在没有 skill 的情况下，开发者需要不断提醒 agent 不要跳步骤；使用 Superpowers 后，这些提醒可以沉淀为稳定流程。
对 Claude Code 和 Codex 来说，Superpowers 的正确使用方式不是“记住一段提示词”，而是安装插件、加载 skill、让 agent 在任务开始前进入正确的工作流。复杂项目里，这种流程约束的价值会越来越明显。
如果你已经把 AI coding agent 用进真实项目，我建议至少从三个 skill 开始：
  1. systematic-debugging：防止乱猜 bug。
  1. writing-plans：防止复杂任务漂移。
  1. verification-before-completion：防止没有验证就宣布完成。
这三个 skill 不会让开发变得神奇，但会让 agent 的行为更像一个有工程纪律的合作者。

参考资料

  1. Superpowers GitHub: https://github.com/obra/superpowers
  1. Startup Superpowers GitHub: https://github.com/SergeiGorbatiuk/startup-superpowers
  1. 本文素材：素材/superpowers-skill-guide.md
  1. 本文素材：素材/obrasuperpowers An agentic skills framework & software development methodology that works..md
  1. 本文素材：素材/SergeiGorbatiukstartup-superpowers.md
2026.06.06 20:54 沪 · 赵巷
📌 声明：本文由 AI 辅助完成