Superpowers Skill 的核心价值，不是给 AI 增加某个单点功能，而是把需求澄清、方案设计、TDD、调试、代码审查和完成前验证这些工程动作固化成可复用流程。本文基于 Superpowers 与 Startup Superpowers 的素材，拆解 Skill 是什么、适合哪些开发场景、使用和不使用的差别，以及在 Claude Code 和 Codex 中如何落地。
先说结论：Skill 不是提示词，而是“流程约束”
最近看 Superpowers 相关资料时，我觉得最值得关注的不是它有多少个具体 skill，而是它试图解决一个很现实的问题：
AI coding agent 很容易“会写代码，但不一定按工程流程做事”。
你让它修 bug，它可能马上读文件、猜原因、改代码。你让它做功能，它可能直接开干，等写完才发现需求理解偏了。你让它重构，它可能顺手改了一堆相邻代码，最后风险比收益还大。
这不是模型“不会写代码”，而是软件开发本身需要流程纪律：
- 先弄清楚目标，而不是马上实现。
- 先形成可验证计划，而不是边写边想。
- 修 bug 要追根因，而不是猜一个补丁。
- 新功能要尽量测试先行，而不是完成后补测。
- 宣布完成前要验证，而不是凭感觉说“应该好了”。
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 流程或计划流程。
也就是说：
没有 Skill：用户反复教 agent 怎么做。有 Skill：用户只描述要做什么，Skill 约束 agent 怎么做。2. 降低 agent 的“即兴发挥”
AI 写代码的一个常见问题是行动太快。它可以很流畅地解释、实现、补丁、总结，但流畅不等于正确。
Superpowers 的核心约束是把 agent 从“直接写代码”拉回“先走流程”：
粗略需求 ↓brainstorming 澄清目标 ↓writing-plans 拆成可执行任务 ↓test-driven-development 约束实现 ↓requesting-code-review 检查风险 ↓verification-before-completion 完成前验证这条链路看起来慢，但它解决的是复杂项目里最昂贵的问题：方向错、边界错、验证缺失、回归没人发现。
3. 让流程跨会话保持一致
单次对话里，你可以给 agent 很长的系统提示。但真实项目往往跨很多天、很多会话。
Skill 的价值在于：
- 每次会话都能重新加载最新流程。
- 同一类任务走同一套标准。
- 团队可以把流程写进仓库或插件，而不是散落在聊天记录里。
这对长期项目很重要。软件项目真正麻烦的地方往往不是某一段代码，而是“今天、明天、下周再回来时，大家是否仍然按同一套工程纪律做事”。
使用场景：什么时候值得用 Superpowers Skill？
不是所有任务都需要重流程。问一个命令、查一个小配置、改一个明显 typo，直接做就可以。
Superpowers 更适合这些场景。
场景一：新功能开发
典型输入：
帮我给这个项目加一个会员订阅功能。没有 skill 时，agent 很可能马上找文件、写 UI、补 API、加状态字段。问题是：会员能力涉及支付、权限、状态同步、失败回滚、测试和上线风险，不适合直接开写。
使用 Superpowers 后，合理流程应该是：
brainstorming：先澄清功能边界，比如套餐、试用、退款、权限降级。
writing-plans：拆出数据结构、接口、UI、测试、验收步骤。
test-driven-development<
