Superpowers：一个用规格驱动 AI 编码智能体的开源技能框架

AI 编码智能体生产力很高，但也缺乏纪律。放任它们自行判断，它们会跳过设计、在理解问题之前就动手写代码、在没有验证的情况下宣告完成。Superpowers 是一个开源框架，它通过强制执行与人类团队相同的 Spec-First 流水线来解决这个问题——只不过它让流水线成为强制性的、不可绕过的。这给出一个很朴素的结论：Spec-First 开发不是只给人用的习惯，它也是让 AI 辅助工程可追责的治理方式。

发布于 2026-04-02 · ✓ 已更新 2026-05-06 · 阅读约 10 分钟 · 作者：Daniel Marsh · 审校：编辑政策

无人监管的 AI 编码问题

给一个 AI 编码智能体一个功能需求，看看会发生什么。几秒钟之内它就开始写代码了。不是在思考问题，不是在问澄清性的问题，不是在记录假设，而是直接写代码。代码可能能用——通常确实能用。但"能用的代码"和"正确的代码"不是一回事，两者之间的差距恰恰是规格存在的意义。

失败模式是可预见的。智能体添加没人要求的字段，把函数名改成它自己的命名惯例而不是项目的，因为"更完整"而擅自扩大范围，因为没有明确提到就跳过边界情况。完成后，它根据代码是否能编译来判断成功，而不是代码是否满足实际需求。这不是假设性的问题，而是每个在没有护栏的情况下使用 AI 编码工具的团队的日常体验。

人类开发者也有同样的倾向，这正是我们发明 Spec-First 开发的原因。区别在于，人类会对社会压力、代码评审反馈和职业激励做出反应。AI 智能体只对指令做出反应。如果指令不强制执行规格纪律，智能体就不会践行它。Superpowers 就是一个编码了正确指令的框架。

Superpowers 是什么

Superpowers 是 Jesse Vincent 创建的一个开源智能体技能框架。它提供一组可组合的"技能"——AI 编码智能体加载并作为强制工作流指令遵循的 Markdown 文件。该框架适用于 Claude Code、Cursor、GitHub Copilot CLI、Gemini CLI、Codex 以及其他 AI 编码工具。截至 2026 年 3 月，它在 GitHub 上拥有超过 13 万颗星，是生态系统中采用最广泛的 AI 开发方法论项目之一。

核心理念很简单：不让 AI 智能体自行决定如何处理任务，而是由 Superpowers 规定一条流水线。这条流水线反映了高效人类工程团队已经在做的事情，但增加了强制机制，消除了智能体跳过步骤的可能性。该框架自称为"智能体技能框架和软件开发方法论"，这个描述的两半都很重要。它首先是一套方法论，其次才是一个框架。

技能系统由 14 个可组合的技能组成，按依赖链组织。流程技能（头脑风暴、调试）在实现技能（TDD、代码评审）之前执行。像 TDD 这样的刚性技能必须严格遵循，像模式应用这样的柔性技能可以根据上下文调整。优先级系统——用户指令覆盖技能，技能覆盖默认智能体行为——让框架补强人类判断，而不是替代它。

Superpowers 流水线：设计即 Spec-First

Superpowers 的工作流直接映射到我们在本站广泛讨论的 Spec-First 交付模型。以下是流水线的各个阶段，以及每个阶段存在的原因。

阶段一：头脑风暴。在任何代码或计划之前，头脑风暴技能强制智能体进入结构化的需求探索。它逐个提问，提出两到三种方案及其明确的权衡，分段展示设计以获取用户批准。然后是最容易被跳过的一步：它将正式规格文档写入持久位置（docs/superpowers/specs/）。规格不是可选的。没有规格就没有计划，没有计划就没有代码。

这直接映射到 Spec-First 的核心原则：决策应在实现开始之前显式化。头脑风暴技能甚至会派遣一个独立的规格文档评审子智能体，从五个维度验证规格：完整性、一致性、清晰度、范围和 YAGNI 合规性。规格必须通过评审后流水线才能推进。

阶段二：计划。写计划技能接收已批准的规格，将其拆解为粒度任务，每个任务预计两到五分钟完成。每个任务指定确切要修改的文件、完整的代码块（无占位符）、精确的测试命令及预期输出，以及 Git 提交指令。计划保存为持久文档，并经过自审以确保覆盖完整规格。如果计划没有覆盖完整规格，就会被拒绝。

这是弥合"我们决定了什么"和"我们要构建什么"之间差距的实现计划阶段。人类团队经常跳过这一步，直接从规格到代码。Superpowers 让跳过成为不可能，因为执行技能需要计划作为输入。

阶段三：测试驱动开发。TDD 技能强制执行严格的红-绿-重构循环。框架明确声明："没有失败的测试就不能写生产代码。"在测试之前写的代码必须删除并以测试优先的方式重写。这是一个刚性技能——在应用方式上没有任何灵活性。框架甚至列出了智能体用来跳过 TDD 的 12 种常见借口，并逐一给出了反驳论据。

阶段四：验证。完成前验证技能要求在任何成功声明之前提供新鲜证据。智能体必须确定验证命令、实时执行（不能回忆之前的结果）、读取完整输出、确认与预期匹配，然后才能报告完成。该技能列出了特定的危险信号语言模式——"应该能用""大概通过了""看起来是"——触发自动拒绝。

为什么 Spec-First 对 AI 智能体比对人类更重要

一个跳过规格的人类开发者可能仍然会构建出正确的东西。他们从站会、Slack 线程和走廊对话中获得上下文，从数月的代码库工作中积累领域知识，有社会意识在需求模糊时去问产品经理"你实际上是说 X 还是 Y？"。AI 智能体没有这些。

AI 智能体的上下文完全等于你给它的东西：提示词、它读取的文件和对话历史。如果规格没有写下来，智能体就真的无法遵循它。需求中的每一个歧义都会变成智能体默默做出的假设。而且不同于人类开发者的假设可能在代码评审中被纠正，智能体的假设被固化在代码和测试中。测试通过了，因为智能体写测试时匹配的是自己的理解，而不是真实需求。

这就是为什么 Superpowers 的强制头脑风暴阶段如此重要。通过强制智能体将假设以问题的形式浮出水面，将决策记录为规格产物，框架创建了人类团队通过对话构建的那种共识。规格不仅仅是一份计划文档，它是智能体的真理之源——关于"正确"意味着什么的唯一真理之源。

规格与测试工具的连接在这个语境下变得更要提前说清楚。当智能体根据评审过的规格编写测试时，测试验证的是需求。当智能体在没有规格的情况下编写测试时，测试验证的是它自己的假设。前者能发现缺陷，后者只会掩盖缺陷。

子智能体架构与规格合规性审查

Superpowers 最有趣的架构决策之一是它对子智能体的使用——为处理单个任务而派遣的全新 AI 智能体实例。每个子智能体获得一个干净的上下文窗口、相关的规格章节和计划中的具体任务。当子智能体完成工作后，结果经过两阶段审查：首先是规格合规性，然后是代码质量。

规格合规性审查发生在代码质量审查之前。这个顺序是刻意的。写得好但不符合规格的代码，比写得粗糙但正确的代码更糟糕。一个架构精美但解决了错误问题的功能，仍然是错误的功能。先检查规格合规性，Superpowers 把正确性放在第一关，代码质量放在第二关。

这反映了人类团队经常搞反的一个原则。代码评审倾向于关注风格、命名和结构，而对实现是否真正匹配需求关注较少。Superpowers 将正确的优先级编码化了：需求优先，工艺其次。

子智能体模型还解决了 AI 上下文窗口的一个实际问题。单个智能体处理大型功能时会积累上下文，随着时间推移会降低输出质量。通过为每个任务派遣全新的子智能体，每个智能体都有聚焦的上下文，Superpowers 在整个实现过程中保持了输出质量。规格和计划文档充当子智能体之间的协调机制——正是规格在分布于不同时区的人类团队中所扮演的角色。

人类团队可以从 Superpowers 学到什么

Superpowers 是为治理 AI 智能体而构建的，但它的设计验证了几个适用于人类工程团队的原则。框架的约束不是随意的，它们是观察智能体（无论是人工的还是人类的）在拥有过多自由跳过步骤时会出什么问题的产物。

让高风险工作的流水线不可协商。Superpowers 不会问智能体是否想写规格，不提供"跳过规格"选项。对于进入流水线的工作，每个阶段都是强制性的。人类团队可以对超过一定复杂度阈值的工作采用这种方式。何时写规格的决策框架仍然适用——但当答案是"是的，写规格"时，完整的流水线不应该是可选的。

先按规格验证，再看代码质量。Superpowers 的两阶段审查——先规格合规性后代码质量——是每个团队都应采用的模式。在实践中，这意味着代码评审中的第一个问题是"这符合规格吗？"第二个问题才是"这写得好吗？"大多数团队把这两个问题的顺序搞反了，或者只问第二个。

编写机器可读的规格。Superpowers 的规格由 AI 智能体消费，这意味着它们必须是无歧义的。没有"待定"章节，没有"酌情处理"修饰语，没有对口头协议的引用。这种精确度同样有益于人类读者。一份 AI 智能体无需澄清就能遵循的规格，也是一份初级开发者无需打断资深工程师就能遵循的规格。

使用系统性调试，而非模式匹配。系统性调试技能强制执行四阶段流程：调查、分析模式、形成假设、测试假设。如果三次或更多修复失败，就质疑架构。这与开发者基于直觉应用快速修复并寄希望于一切顺利的常见模式恰恰相反。结构化方法对 AI 智能体和人类开发者都更有效。

局限性与权衡

Superpowers 不是没有成本的。强制流水线为每个任务增加了开销。一个本该花三十秒的单行配置更改，现在要经过头脑风暴、规格编写、计划和验证。框架意识到了这个权衡——文档指出流水线适用于值得投入的工作——但强制机制不会自动区分数据库迁移和拼写修复。

框架还假设人类用户可以随时批准规格和计划。对于完全自主的智能体运行，审批关卡会成为瓶颈。这可以说是一个特性而非缺陷——框架有意阻止高风险工作的无监督自主——但它将使用场景限制在协作式人机开发，而非完全自主编码。

最后，14 个技能组成的系统有学习曲线。采用 Superpowers 的团队需要理解技能优先级系统、刚性与柔性技能的区分以及子智能体架构。这比简单地告诉 AI 智能体"写代码"然后审查输出要复杂。这份复杂度有成本，但换来的质量也是真的。

它给 Spec-First 的信号

Superpowers 最有意思的地方，不在于它又发明了一套工具，而在于它把一个假设摆到台面上：规格驱动不是单纯的方法偏好，它是协调不同执行者的方式。执行者可以是人，也可以是模型，或者两者混在一起。

当 Jesse Vincent 的团队需要让 AI 编码智能体变得可靠时，他们没有发明新方法论。他们把 Spec-First 流水线——头脑风暴、规格化、计划、TDD 实现、根据规格验证——编码为可强制执行的约束。这条流水线对 AI 智能体和人类团队同样有效，这不是巧合。这是流水线之所以有效是因为它本身正确，而非因为它是为特定类型的实施者设计的证据。

对于仍在争论 Spec-First 开发是否值得开销的团队，Superpowers 提供了一个有说服力的数据点。超过 13 万开发者采用了一个框架，其整个前提是规格必须先于代码、计划必须源于规格、实现必须根据规格验证。这样的采用规模表明，工程社区正在将规格纪律收敛为默认状态，而非例外。

AI 辅助工程的时代并没有让规格变得不那么重要，反而让规格变得不可或缺。规格不只是人和人之间的沟通工具，它也是人类意图和机器执行之间的接口。规格越清晰，输出就越好——无论读者是初级开发者还是拥有两千亿参数的语言模型。Superpowers 证明了这一点。

落地补丁：别把技能框架当成魔法按钮

我会把 Superpowers 当成一条强制流水线，而不是一包提示词。真正要写进仓库的是门槛：什么任务必须走完整 spec，什么任务只需要一个小修补单，谁有权批准跳过。没有这几条，团队很快会把“技能”用成新的口头约定。

AI-assisted task gate:
- Requires full spec: API behavior, database migration, billing, auth, data deletion
- Requires short spec: UI copy change, small validation rule, one-file refactor
- Can skip: typo, dependency metadata, dead link fix
- Evidence required: spec link, plan link, test output, reviewer name
- Stop condition: agent asks the same clarification twice or edits outside boundary

边界也要写清楚：Superpowers 不替你判断产品取舍，也不替 reviewer 承担责任。它能强迫智能体停下来写 spec，但 spec 里的取舍仍然要由人来签字。

可复制产物：AI 编码评审包

在 AI 生成 diff 进入代码评审前使用。它把提示词范围、允许变更和证据要求合并成一个可审查产物。

AI 编码评审包：Superpowers：一个用规格驱动 AI 编码智能体的开源技能框架

本次要做的决策：
- 确认 AI 只在批准范围内生成变更，并为每条验收标准提供证据。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

AI 边界：生成变更必须留在书面范围内，每条验收标准都要能找到证据。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。