Superpowers：给AI编程助手装上工作规范

AI太快，反而成了问题

如果你经常用 Trae Solo 写代码，大概率遇到过这样的场景：你只说了一句"帮我加个登录页"，AI 立刻开始改文件。几分钟后页面出来了，但路由、样式、状态管理，甚至几个你没让它动的文件也一起被改了。

这种现象并非 Trae 独有。当前主流 AI 编程助手（如 Cursor、GitHub Copilot Agent 等）普遍采用 Agentic 工作模式，即 AI 不仅生成代码片段，还能自主决定修改哪些文件、执行什么命令、甚至调用外部工具。这种自主性源于大语言模型的"指令跟随"能力——模型会将用户的模糊意图展开为一系列具体操作。问题在于，模型的"展开"逻辑基于训练数据中的统计模式，而非对当前项目架构的真正理解，因此经常出现"过度操作"：改了不该改的文件、引入了不需要的依赖、甚至破坏了已有功能。

最麻烦的不是 AI 写错——真正麻烦的是它太自信，太爱直接开写。今天要介绍的 Superpowers，就是给 AI 助手装上一套"工作规矩"，让它先问清楚、再写计划、先定验收标准、再动手实现。

Superpowers的核心理念

不是新模型，而是一套开发方法论

Superpowers 不是一个新模型，也不是一个新 IDE。你可以把它理解成一组 Skills 加上一套软件开发方法论。每个 Skill 都是一个 Markdown 文件，里面写清楚什么时候触发、触发后该怎么做。

这种 Markdown 驱动的 Skills 机制，本质上是一种结构化的系统提示词（System Prompt）管理方案。每个 Skill 文件包含触发条件（Trigger）、执行步骤（Steps）和输出格式（Output Format）等字段。这种设计借鉴了软件工程中"关注点分离"的思想——每个 Skill 只负责一个行为约束，多个 Skills 组合形成完整的工作流。相比在一条超长提示词里塞入所有规则，Markdown 文件的模块化管理更易维护、更易复用，也更容易在团队间共享和版本控制。

核心 Skills 包括：

• Brainstorming：让 AI 在写代码前先追问目标、边界和取舍
• Writing Plans：把大需求拆成小任务，每个任务都写明文件路径和验证方法
• Test Driven Development：要求先写失败测试，再写最小实现，然后重构
• Verification Before Completion：专门防止 AI 把"我觉得好了"说成"已经验证通过"

最后一个 Skill 尤其值得关注。在实际使用中，AI 说"已完成"和"真的验证过"之间往往存在巨大鸿沟。这种现象在学术界被称为"幻觉式完成"（Completion Hallucination），是大语言模型在代码生成场景中最危险的行为模式之一。其根源在于语言模型的训练目标是生成"看起来合理的文本"，而非"保证逻辑正确的程序"。当模型生成了一段代码后，它倾向于用自然语言输出一段"验证叙述"——描述代码应该如何工作——但这段叙述本身也是生成的，并未经过实际执行验证。研究表明，即使是最先进的代码模型，在声称"代码已通过测试"时，实际通过率也可能低于 70%。Verification Before Completion 这个 Skill 就是用来堵住这个漏洞的。

完整工作流：像带新人一样带AI

把这些技能连起来，Superpowers 的工作流大致如下：

1. 用户提出想法，AI 不急着写代码，先澄清需求
2. 需求清楚后，AI 给出设计草案，让你确认方向
3. 设计确认后，再写计划，把工作拆成很小的任务
4. 进入实现时，最好放在独立分支，减少误伤主线代码
5. 每个任务完成后，要有审查、要有验证
6. 最后才进入收尾，决定是合并、提交 PR，还是保留分支继续观察

这不像一个提示词技巧，更像是把资深工程师带新人的流程，写成了 AI 必须遵守的规则。

在Trae中如何使用Superpowers

截至目前，Superpowers 官方仓库还没有把 Trae 写进官方安装列表，所以 Trae 里的用法走的是社区适配路线。核心原则是：先做最小可用版，不要一上来就追求完整迁移。

四步完成基础配置

第一步：下载 Superpowers 源码。 最直接的方式是用 git clone，也可以在 GitHub 下载 ZIP。

第二步：复制 Skills 目录。 把 Superpowers 仓库里的 Skills 目录，复制到 Trae 的技能目录。不同版本路径可能不同，最好先在 Trae 的 Skills 设置里确认具体位置。

第三步：在项目里写一条规则。 让 Trae 每次开始开发任务前，先使用 Superpowers 的工作方式。规则不用很长，关键是三句话：

• 不要先写代码，先澄清需求和边界
• 输出计划，每步都有验证方法
• 完成后必须说明验证了什么

第四步：开一个新会话验证。 你可以问它："你现在有哪些 Superpowers Skills？你会如何在这个项目中使用它们？"如果它能说出 Brainstorming、Writing Plans、Test-Driven Development、Verification Before Completion 这些技能并说明触发场景，说明基本迁移成功。如果它只是泛泛地说"我会认真开发"，那就还没跑通，回去检查技能路径和项目规则。

进阶：配置子代理协作

社区方案里常见的是配置三个角色：

• Implementer：负责按任务改代码
• Spec Reviewer：负责对照需求检查是否偏题
• Code Quality Reviewer：负责看结构、边界和潜在回归

这种子代理协作模式是多智能体系统（Multi-Agent System）在 AI 编程领域的具体应用。其核心思想来自软件工程中的角色分离：就像真实团队中开发者、测试工程师、代码审查者各司其职一样，不同的 AI 代理被赋予不同的角色和权限。这种架构的理论基础是"对抗性验证"——让一个代理的输出接受另一个代理的审查，利用角色间的张力来发现问题。目前 AutoGen、CrewAI、LangGraph 等框架都在探索多代理编排，但实际落地时最大的挑战不是技术实现，而是任务边界的清晰度。

理想流程是 Solo Coder 派发小任务，实现者完成后，规格审查先看有没有偏离需求，质量审查再看代码是否稳健。

但这里要现实一点：不同 Trae 版本对子代理、脚本型技能和授权入口的支持不一定一致。如果你的界面里没有对应入口，不要硬找。可以先用手动流程——让 AI 先扮演规格审查，再扮演代码质量审查。 这不够自动化，但足够稳。工序链不完整时，稳定比炫技重要。

五条实践建议

基于 Superpowers 的方法论，以下是五条可以立刻落地的建议：

1. 让AI先问问题。 模糊需求最容易让 AI 乱猜。你越早把目标、非目标、不能碰的文件说清楚，后面越少返工。

2. 把任务拆小。 不要说"优化登录页"，要说"修改哪个文件，增加什么提示，不改什么接口，如何验证"。粒度越细，AI 越不容易跑偏。

3. 测试或验收要先行。 代码项目尽量写失败测试；文档、页面、配置类任务，也要写清检查清单。先定义"什么算完成"，再开始做。这里的"先写失败测试"正是经典的测试驱动开发（TDD）方法——Kent Beck 在 2003 年系统化提出的"红-绿-重构"循环：先写一个必然失败的测试（红），再写刚好让测试通过的最小实现（绿），最后在测试保护下重构代码。在 AI 编程场景下，TDD 获得了一层新含义——它为 AI 的输出提供了客观的验证锚点。没有测试时，AI 只能通过"自我评估"来判断代码是否正确，而大语言模型的自我评估往往过于乐观。有了预先定义的失败测试，AI 的每一步实现都有明确的通过/失败信号，大幅降低了"幻觉式完成"的概率。

4. 子代理不是越多越好。 只有当任务能被清楚切开时，子代理才有价值。如果任务本身无法被干净地切分为独立子任务，多代理之间的协调开销可能超过收益。强行拆分反而增加协调成本。

5. 完成前必须要证据。 AI 说"已完成"不算完成。它跑了什么命令、看了哪个页面、有没有截图、还有哪些没验证——这些才算证据。证据比声明重要，这是 Superpowers 的底层习惯。

Superpowers vs OpenSpec：管的不是同一件事

OpenSpec 也是 AI 编程领域很火的思路，但它和 Superpowers 的定位不同。OpenSpec 是近期在 AI 编程社区兴起的一种规格驱动开发框架，其灵感来源于传统软件工程中的需求规格说明书（SRS）和变更管理流程。OpenSpec 将一个开发任务分解为 Proposal（提案）、Specification（规格）、Design（设计）和 Tasks（任务）四层文档，每一层都有明确的模板和审批流程。它解决的核心问题是"需求可追溯性"——当项目规模增大、参与的 AI 会话增多时，如果没有统一的规格文档，不同会话之间的 AI 可能对同一个需求产生不同理解，导致实现冲突。

维度	OpenSpec	Superpowers
关注层面	规格层——做什么	流程层——怎么做
核心产物	Proposal、Spec、Design、Tasks 等变更材料	澄清、计划、测试、审查、验证等行为规范
适用场景	需求追溯、长期项目管理	约束 AI 开发行为、保证交付质量

二者不一定二选一。长期项目可以用 OpenSpec 记录"要做什么"，用 Superpowers 约束"AI 怎么做"。 它们的关系类似于"地图"和"驾驶规则"：前者告诉你去哪里，后者约束你怎么开车。小 Demo 或临时项目，不必一开始就上两套流程，先用 Superpowers 的最小闭环——问清楚、写计划、做验证——就够了。

一段可以立刻使用的开场模板

如果你想在 Trae 里立刻试，可以用这段开场提示：

请先使用 Superpowers 的工作方式。不要先写代码，先向我确认需求和边界。输出一个简短计划，每一步都要有验证方法。我确认开始执行后，你再修改文件。完成后必须说明实际验证了什么，还有什么没验证。

这段话看起来普通，但它能把 Trae Solo 从"马上开写"拉回"先确认流程"。

越快越需要慢半拍

Superpowers 的价值不是让 AI 显得更专业，而是让 AI 慢半拍：

• 先慢半拍问清楚，后面少返工
• 先慢半拍写验证，后面少踩坑
• 先慢半拍做审查，后面少背"已完成"的锅

AI 编程工具会越来越快。越是这样，我们越需要一套看得见的工作流，把"快"控制在可靠的范围里。与其让 AI 全速狂奔后反复修补，不如在起跑前花两分钟确认方向——这才是 Superpowers 真正想解决的问题。

核心要点