superpowers 技能框架：Agent 能力增强

<blockquote><p>&quot;The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.&quot;<br>Agent 在执行任何任务之前，先检查自己有没有对应的技能。这些是强制工作流，不是建议。</p><p>——Jesse Vincent, Superpowers 作者, 2025 年</p></blockquote><p>gstack 用二十三个角色和七个 Sprint 阶段构建流程驱动的虚拟工程团队。CEO 审方向，工程经理锁架构，QA 测功能，安全官审漏洞——每个角色在固定阶段做固定的事。</p><p>superpowers 走相反的路。</p><p>superpowers 不定义任何角色。不强制任何 Sprint 阶段。它只做一件事：给你十四个 Skill，让 Agent 自己在合适的时机调用合适的那个。不靠流程锁住质量——靠每个 Skill 足够好用，Agent 自己愿意用它们。</p><p>201K+ Stars。当你不信任流程、只信任工具时，AI 软件工程能做多大——这个数字就是答案。</p><span id="more"></span><h2 id="6-1-一个拒绝流程的系统"><a href="#6-1-一个拒绝流程的系统" class="headerlink" title="6.1 一个拒绝流程的系统"></a>6.1 一个拒绝流程的系统</h2><p>superpowers 的作者是 Jesse Vincent，Prime Radiant 的创始人。他给这个项目起的名字——&quot;超能力&quot;。让一个普通 AI Agent 变成一个有方法论的 Agent 的十四种超能力。</p><p><img src="/images/image-20260530011124325.png"></p><p>2025 年 10 月发布，不到一年冲到 201K+ Stars。这个数字在所有 AI 编程方法论相关仓库里排第一——超过 gstack（约 5K），超过 OpenSpec（约 49K），超过 Ralph Loop 所有实现的总和。</p><p>从 README 第一段就能看出来：</p><blockquote><p>&quot;It starts from the moment you fire up your coding agent. As soon as it sees that you&#39;re building something, it <em>doesn&#39;t</em> just jump into trying to write code. Instead, it steps back and asks you what you&#39;re really trying to do.&quot;</p></blockquote><p>Agent 启动时不写代码。它退一步，先问你想做什么。这个行为是 Skill 自动触发的——Agent 检测到自己即将开始开发工作时，<code>brainstorming</code> 技能自动激活，强制走一轮需求澄清。</p><p>gstack 的流程是人类驱动的——你手动调用 <code>/office-hours</code>，然后 <code>/plan-ceo-review</code>，然后 <code>/autoplan</code>。superpowers 的流程是 Agent 驱动的——你只需要打开 Agent 开始工作，它在合适的时机自动加载合适的 Skill。你不说&quot;先做设计&quot;，Agent 自己知道要先做设计。</p><p>两条路。gstack 要的是控制——流程固定，角色明确，每个阶段的输出和输入都有明确的合约。superpowers 要的是自主——给 Agent 十四种能力，让它自己判断什么时候该用什么。</p><h2 id="6-2-核心机制：自动触发-强制门控"><a href="#6-2-核心机制：自动触发-强制门控" class="headerlink" title="6.2 核心机制：自动触发 + 强制门控"></a>6.2 核心机制：自动触发 + 强制门控</h2><p>superpowers 的十四个 Skill 并不新。brainstorming、TDD、systematic-debugging——这些概念第二章的 Pocock Skills 里都有。superpowers 的不同在两个地方。</p><h3 id="6-2-1-自动触发：Agent-自己决定用什么-Skill"><a href="#6-2-1-自动触发：Agent-自己决定用什么-Skill" class="headerlink" title="6.2.1 自动触发：Agent 自己决定用什么 Skill"></a>6.2.1 自动触发：Agent 自己决定用什么 Skill</h3><p>Pocock 的系统里，用户手动调用 <code>/tdd</code>、<code>/diagnose</code>、<code>/grill-me</code>。gstack 里，用户手动走 Sprint 阶段。</p><p>superpowers 的设计是：每个 Skill 的 <code>description</code> 字段里写了触发条件。Agent 在执行任务前检查所有已加载 Skill 的 description，匹配当前场景就自动激活。比如 Agent 准备写代码时，<code>brainstorming</code> 的 description 是&quot;你必须在任何创造性工作之前使用此技能&quot;，Agent 读到这句话，强制自己先做需求澄清。</p><p>一个文本匹配机制，Agent 会跳过吗？效果出奇地好。关键在 description 的措辞。它不说&quot;建议使用此技能&quot;，说&quot;在任何创造性工作之前必须使用此技能&quot;。不说&quot;可以考虑 TDD&quot;，说&quot;强制执行红-绿-重构：先写会失败的测试，看着它失败，写最少代码让它通过，看着它通过，提交。删除在测试之前写的任何代码。&quot;命令式的、不可协商的语言，Agent 就会遵守。</p><h3 id="6-2-2-硬门控：HARD-GATE-标签"><a href="#6-2-2-硬门控：HARD-GATE-标签" class="headerlink" title="6.2.2 硬门控：HARD-GATE 标签"></a>6.2.2 硬门控：HARD-GATE 标签</h3><p>有些 Skill 里嵌了一段特殊代码：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br></pre></td><td class="code"><pre><span class="line">&lt;HARD-GATE&gt;</span><br><span class="line">Do NOT invoke any implementation skill, write any code, scaffold any project,</span><br><span class="line">or take any implementation action until you have presented a design and the</span><br><span class="line">user has approved it.</span><br><span class="line">&lt;/HARD-GATE&gt;</span><br></pre></td></tr></table></figure><p>HARD-GATE 是给 Agent 的行为约束——在进入下一个阶段之前，必须先完成当前阶段的硬性条件。<code>brainstorming</code> 有它——设计没被批准，一行代码都不准写。<code>test-driven-development</code> 有它——测试没写、没看到它失败，不准写实现代码。</p><p>gstack 用 PreToolUse hooks 在系统层面锁住 commit 按钮。superpowers 用 prompt 内嵌的指令在 Agent 认知层面锁住行动。前者是操作系统的强制，后者是心理的强制。都有效，但原理不同。hooks 在你的平台不支持时就失效了。HARD-GATE 在任何平台上都有效——它只是 prompt 里的一段文本。但它也更软——依赖 Agent 遵循指令的能力。在 Claude 4.x 上表现良好，在更弱的模型上可能被跳过。</p><h2 id="6-3-十四种超能力"><a href="#6-3-十四种超能力" class="headerlink" title="6.3 十四种超能力"></a>6.3 十四种超能力</h2><p>superpowers 把十四个 Skill 分成了五组。</p><p><img src="/images/image-20260530011432368.png"></p><h3 id="6-3-1-规划组：动手前先想清楚"><a href="#6-3-1-规划组：动手前先想清楚" class="headerlink" title="6.3.1 规划组：动手前先想清楚"></a>6.3.1 规划组：动手前先想清楚</h3><p><strong><code>brainstorming</code></strong>（头脑风暴）。这是整个系统的入口 Skill。Agent 检测到开发任务时自动激活，执行九步流程：探索项目上下文 → 询问视觉需求 → 逐个澄清问题 → 提出 2-3 个方案并推荐 → 分段展示设计 → 用户批准 → 写入设计文档 → 自审 → 用户复审 → 进入实施计划阶段。</p><p>它强制 Agent &quot;一次只问一个问题&quot;（Only one question per message）。这个约束防止了 Agent 一次性抛出十几个问题让用户不知所措——AI 常见的&quot;过度热情&quot;在这种设计下被抑制了。每一步都要等用户回答，节奏是人类控制的。</p><p>Skill 的态度很明确：每个项目都要走这个流程。todo list、一个函数、一个配置修改——全部要。简单的项目设计可以很短（几句话），但必须被呈现和批准。</p><p><strong><code>writing-plans</code></strong>（编写计划）。设计被批准后激活。把设计方案拆成 2-5 分钟能完成的小任务。每个任务包含精确的文件路径、完整的代码框架、验证步骤。粒度设计有一个清晰的标准：一个任务必须小到可以被一个子 Agent 在隔离的上下文中独立完成。</p><p><strong><code>executing-plans</code></strong>（执行计划）。按计划逐个任务执行，每个任务完成后检查点暂停等待用户确认。和下面的 <code>subagent-driven-development</code> 是互斥的两条路径——前者适合需要人在循环中的场景，后者适合自主执行的场景。</p><h3 id="6-3-2-开发组：质量的底层保障"><a href="#6-3-2-开发组：质量的底层保障" class="headerlink" title="6.3.2 开发组：质量的底层保障"></a>6.3.2 开发组：质量的底层保障</h3><p><strong><code>test-driven-development</code></strong>（测试驱动开发）。红-绿-重构的严格执行——先写会失败的测试，看着它失败，写最少代码让它通过，看着它通过，提交。最狠的规则：删除在测试之前写的任何代码。断了&quot;先写实现再补测试&quot;这条路。</p><p>红-绿-重构是 TDD 的核心循环。<strong>红</strong>——先写一个会失败的测试，确认测试确实失败了（不是假通过）。<strong>绿</strong>——写最少量的代码让测试通过，不求优雅，只求过关。<strong>重构</strong>——测试全绿后，清理代码结构，消除重复，改善命名，测试必须保持绿色。然后下一个循环。三步顺序不能乱：先有失败的测试，才有资格写实现代码。</p><p><strong><code>systematic-debugging</code></strong>（系统化调试）。四阶段根因分析：复现 → 定位 → 假设 → 修复。包含三个子技术：根因追踪（不只修症状）、纵深防御（修 bug 同时加固相关路径）、条件等待（不靠 sleep 轮询）。</p><p><strong><code>subagent-driven-development</code></strong>（子 Agent 驱动开发）。这是 superpowers 最具原创性的 Skill。核心逻辑：每个任务派一个全新的子 Agent 去实现，主 Agent 只负责协调。每个任务完成后两阶段审查：先审规格符合性（代码是不是做了该做的事），再审代码质量（代码写得好不好）。子 Agent 上下文是干净的——主 Agent 精确构造子 Agent 需要的上下文，不把整个会话历史塞进去。主 Agent 自己的上下文窗口留给协调工作。</p><p>这直接回应了第 4 章 Ralph Loop 的一个已知问题：循环膨胀。一个 Agent 在同一个会话中连续迭代十几次，上下文中的噪音（失败的尝试、被废弃的思路、旧的代码片段）越积越多，决策质量逐渐下降。子 Agent 模式通过&quot;每个任务一个新 Agent&quot;解决了这个问题——每个子 Agent 的上下文都是干净的，只包含完成当前任务所需的最小信息。</p><p><strong><code>verification-before-completion</code></strong>（完成前验证）。声称&quot;做完了&quot;之前必须跑验证——系统地检查每个验收标准是否被满足，不满足于&quot;测试跑过一次通过了&quot;。这和 Ralph Loop 的 completion promise 做的事一样：阻止 Agent 在没做完的时候说自己做完了。</p><h3 id="6-3-3-审查组：两道防线"><a href="#6-3-3-审查组：两道防线" class="headerlink" title="6.3.3 审查组：两道防线"></a>6.3.3 审查组：两道防线</h3><p><strong><code>requesting-code-review</code></strong>（请求代码审查）。任务之间自动触发。对照计划审查，按严重程度分级报告问题。关键问题阻塞进度。</p><p><strong><code>receiving-code-review</code></strong>（接收代码审查）。处理审查反馈的行为规范——如何分类反馈、如何回应、什么情况下可以拒绝修改建议。Agent 响应审查反馈的方式和质量也需要训练。</p><h3 id="6-3-4-工具组：工程基础设施"><a href="#6-3-4-工具组：工程基础设施" class="headerlink" title="6.3.4 工具组：工程基础设施"></a>6.3.4 工具组：工程基础设施</h3><p><strong><code>dispatching-parallel-agents</code></strong>（派遣并行 Agent）。多个独立任务同时启动子 Agent 并行执行。适合计划中有明显无依赖关系的任务组。</p><p><strong><code>using-git-worktrees</code></strong>（Git Worktree 使用）。设计被批准后自动激活——创建隔离的 git worktree，在新分支上工作，跑项目初始化，验证测试基线。和第 10 章的 Harness Engineering 一脉相承——用 git worktree 实现进程级隔离，而不是依赖 Agent 的自我约束。</p><p><strong><code>finishing-a-development-branch</code></strong>（完成开发分支）。所有任务完成后激活。验证所有测试通过，给出四个选项：合并到主分支、创建 PR、保留分支、丢弃分支。清理 worktree。</p><h3 id="6-3-5-元技能组：制造超能力的超能力"><a href="#6-3-5-元技能组：制造超能力的超能力" class="headerlink" title="6.3.5 元技能组：制造超能力的超能力"></a>6.3.5 元技能组：制造超能力的超能力</h3><p><strong><code>writing-skills</code></strong>（编写 Skill）。教 Agent 怎么样创建一个新 Skill。包含测试方法论——新 Skill 写完后必须通过行为验证。有了 <code>writing-skills</code>，superpowers 就成了一个可以自我扩展的系统。</p><p><strong><code>using-superpowers</code></strong>（使用 Superpowers）。介绍整个系统的新手指南。Agent 第一次加载 superpowers 时自动激活。</p><h2 id="6-4-superpowers-zh：中文生态的本地化"><a href="#6-4-superpowers-zh：中文生态的本地化" class="headerlink" title="6.4 superpowers-zh：中文生态的本地化"></a>6.4 superpowers-zh：中文生态的本地化</h2><p>superpowers-zh 由 jnMetaCode 开发，3.6K+ Stars。完整汉化，加六个中国原创 Skill。</p><p>六个原创 Skill 瞄准的是中文开发者自己的场景：</p><p><code>chinese-code-review</code> 适配了国内团队的代码审查文化——审查报告的措辞、评论的优先级标注、修改建议的表达方式，都按国内工程师习惯的交流方式重新设计，不是简单翻译英文版。<code>chinese-git-workflow</code> 支持 Gitee、CODING、极狐 GitLab、CNB 等国内代码托管平台——git worktree 的创建、PR&#x2F;MR 的提交和合并流程都做了适配。<code>chinese-documentation</code> 强制中文排版规范——中英文之间的空格、标点符号的使用、技术术语的翻译标准。<code>chinese-commit-conventions</code> 将 Conventional Commits 规范适配到中文团队的实践——中英混合的 commit message 格式、中文 Issue 引用格式。<code>mcp-builder</code> 直接教 Agent 如何构建 MCP 服务器。<code>workflow-runner</code> 提供了多角色的 YAML 编排能力——弥补了 superpowers 原生不支持流程编排的短板。</p><p>目前支持十六款 AI 编码工具，从 Claude Code 到通义灵码（Qwen Code），一键安装自动检测平台。superpowers-zh 进一步扩大了跨平台兼容性——原版不支持的中国本土工具也被加了进来。</p><h2 id="6-5-实战：用-superpowers-开发网页版贪吃蛇"><a href="#6-5-实战：用-superpowers-开发网页版贪吃蛇" class="headerlink" title="6.5 实战：用 superpowers 开发网页版贪吃蛇"></a>6.5 实战：用 superpowers 开发网页版贪吃蛇</h2><p>同一个贪吃蛇。第五种体验。</p><h3 id="6-5-1-启动：Agent-拒绝写代码"><a href="#6-5-1-启动：Agent-拒绝写代码" class="headerlink" title="6.5.1 启动：Agent 拒绝写代码"></a>6.5.1 启动：Agent 拒绝写代码</h3><p>打开 Claude Code（已安装 superpowers），输入：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">做一个贪吃蛇网页游戏。纯前端单文件。</span><br></pre></td></tr></table></figure><p>在 Pocock Skills 下，Agent 可能直接开始写代码。在 gstack 下，你会手动调用 <code>/office-hours</code>。在 superpowers 下，Agent 的行为是自动的——<code>brainstorming</code> 技能检测到&quot;creating features, building components&quot;的场景，自动激活：</p><blockquote><p><strong>Agent:</strong> 在我开始之前，我需要先了解一些关键问题。你是想做一个完整的游戏，还是更偏向一个技术演示？（一次只问一个问题）</p><p>用户：演示项目。展示 AI 编码能力。</p><p><strong>Agent:</strong> 了解了。演示项目意味着代码需要干净、可读、可展示。那么核心体验上——你希望这个游戏&quot;看起来不错&quot;更重要，还是&quot;代码结构清晰&quot;更重要？</p><p>用户：代码清晰更重要。</p><p><strong>Agent:</strong> 明白了。那验收标准上——哪些行为是必须的，哪些是可以省略的？</p><p>用户：蛇能动，能吃食物，撞墙或撞到自己会死，死了能重来。最高分用 localStorage 存。</p><p><strong>Agent:</strong> 好的。让我确认几个技术偏好：纯单文件 HTML&#x2F;CSS&#x2F;JS，不依赖任何框架？</p></blockquote><p>五个问题后，Agent 产出一份设计文档，存入 <code>docs/superpowers/specs/</code>。然后自动过渡到 <code>writing-plans</code>——把设计拆成四个任务：</p><ol><li>HTML 结构与 Canvas 渲染（20×20 网格，初始蛇 3 格，红色食物）</li><li>游戏循环与状态管理（requestAnimationFrame，150ms&#x2F;步，nextDirection 缓冲防反向）</li><li>碰撞检测与食物系统（墙壁、自身、食物随机生成且不与蛇身重叠）</li><li>分数系统与 UI 状态（当前分&#x2F;最高分、HTML modal 弹窗、localStorage、空格键重置）</li></ol><p>每个任务标注了文件路径、实现要点、验证步骤。然后 Agent 开始执行。</p><h3 id="6-5-2-子-Agent-驱动的实现过程"><a href="#6-5-2-子-Agent-驱动的实现过程" class="headerlink" title="6.5.2 子 Agent 驱动的实现过程"></a>6.5.2 子 Agent 驱动的实现过程</h3><p><code>subagent-driven-development</code> 激活。主 Agent 为每个任务派一个全新的子 Agent：</p><p><strong>任务 1</strong>——派子 Agent A，只给 HTML 结构和 Canvas 渲染的上下文。子 Agent 在干净的环境中写代码，跑验证，提交。主 Agent 派审查子 Agent 做两阶段审查（规格符合性 → 代码质量），通过。</p><p><strong>任务 2</strong>——派子 Agent B，只给任务 2 的上下文加上已完成的文件结构。子 Agent 实现了游戏循环和方向控制。审查子 Agent 发现了一个问题：方向缓冲的默认值没初始化，蛇可能在按键前就开始移动。打回修改。子 Agent B 修好，重新审查，通过。</p><p><strong>任务 3</strong>——派子 Agent C，加碰撞检测和食物系统。审查通过。</p><p><strong>任务 4</strong>——派子 Agent D，加分数系统和 modal 弹窗。审查子 Agent 提出：modal 弹窗出现时键盘事件没拦截，死了还能控制蛇。这是第 5 章 gstack 实战中 Review 阶段才发现的问题——在 superpowers 的流程里，子 Agent 审查阶段就揪出来了。子 Agent D 修复，重新审查，通过。</p><p>整个过程约十五分钟，人类参与了两次——回答 <code>brainstorming</code> 的五个问题，确认设计方案。其余全自动。</p><h3 id="6-5-3-验证和交付"><a href="#6-5-3-验证和交付" class="headerlink" title="6.5.3 验证和交付"></a>6.5.3 验证和交付</h3><p><code>verification-before-completion</code> 激活。Agent 逐条对照验收标准验证：蛇能动 ✓ 能吃食物 ✓ 撞墙死 ✓ 撞自己死 ✓ 分数更新 ✓ 最高分持久化 ✓ 空格键重置 ✓。全部通过后 Agent 报告完成。</p><p><code>finishing-a-development-branch</code> 激活。Agent 给出四个选项，用户选择创建 PR。Agent 生成 commit（Conventional Commits 格式），推送到远程，创建 PR。</p><h3 id="6-5-4-superpowers-和其他方法论的对比"><a href="#6-5-4-superpowers-和其他方法论的对比" class="headerlink" title="6.5.4 superpowers 和其他方法论的对比"></a>6.5.4 superpowers 和其他方法论的对比</h3><p>同一个贪吃蛇，五种方法论：</p><table><thead><tr><th>维度</th><th>Pocock Skills</th><th>OpenSpec</th><th>Ralph Loop</th><th>gstack</th><th>superpowers</th></tr></thead><tbody><tr><td><strong>启动方式</strong></td><td>手动调用 Skill</td><td>手动写 proposal</td><td>手动写 prompt</td><td>手动运行 <code>/office-hours</code></td><td>Agent 自动激活 brainstorming</td></tr><tr><td><strong>人类参与度</strong></td><td>全程驾驶</td><td>每步写文档</td><td>写 prompt 后放手</td><td>逐个阶段运行命令</td><td>回答设计问题后放手</td></tr><tr><td><strong>Agent 自主性</strong></td><td>低</td><td>中</td><td>高</td><td>中</td><td>高</td></tr><tr><td><strong>审查机制</strong></td><td>Skill 内建验证</td><td>Spec 验收标准</td><td>自动重试+测试</td><td>四个角色分维度审查</td><td>子 Agent 两阶段审查（规格+质量）</td></tr><tr><td><strong>上下文管理</strong></td><td>单 Agent 累积</td><td>单 Agent 累积</td><td>单 Agent 累积</td><td>多角色但同一会话</td><td>每个任务新子 Agent，上下文隔离</td></tr><tr><td><strong>流程强制力</strong></td><td>引导</td><td>柔性门</td><td>自动循环</td><td>系统 hooks</td><td>认知门控（HARD-GATE）</td></tr><tr><td><strong>最佳场景</strong></td><td>日常小任务</td><td>有规格的功能</td><td>可自动验证的任务</td><td>从零到一的完整项目</td><td>中等复杂度的独立功能</td></tr></tbody></table><p>superpowers 在贪吃蛇上只花了约十五分钟——比 gstack 的七个阶段快，比 Ralph Loop 的四轮迭代质量高（子 Agent 审查抓到了 Ralph 第 4 轮才抓到的 modal 焦点问题）。人类的参与时间约五分钟。</p><p>superpowers 没有 gstack 那种&quot;CEO 审方向 → 工程经理锁架构 → 设计师审 UI&quot;的全景角色覆盖。它依赖十四种工具覆盖足够多的场景——如果某个场景没有对应的 Skill，Agent 就没有那个维度的审查能力。gstack 的二十三个角色覆盖了产品、工程、设计、安全、运维的全部维度。superpowers 的十四个 Skill 更多地集中在工程实现环节，产品思考和安全管理相对薄弱。</p><h2 id="6-6-设计哲学：自动化的代价"><a href="#6-6-设计哲学：自动化的代价" class="headerlink" title="6.6 设计哲学：自动化的代价"></a>6.6 设计哲学：自动化的代价</h2><p>superpowers 和 gstack 是两条路。核心差异不在 Skill 数量——14 vs 35+。在谁驱动流程。</p><p>gstack 是<strong>人驱动流程</strong>。你判断什么时候进入 Think 阶段，你调用 <code>/office-hours</code>。你判断什么时候进入 Plan 阶段，你调用 <code>/autoplan</code>。流程的节奏和方向在你手上。好处是你能在每一步做出判断——CEO 审查结论否决了难度曲线功能，你知道为什么，你同意这个决定。坏处是你必须在每一步都参与——七个 Sprint 阶段走一遍，意味着你要在电脑前坐几个小时。</p><p>superpowers 是<strong>Agent 驱动流程</strong>。Agent 判断自己即将开始开发，自动激活 <code>brainstorming</code>。Agent 判断自己需要写实现计划，自动激活 <code>writing-plans</code>。流程是 Agent 自己推进的。好处是你只需要在关键决策点参与——设计批准时看一眼，方案选择时给个意见——剩下的 Agent 自己跑。坏处是 Agent 可能在你不注意的时候做出你不同意的决策。</p><p>两套系统对&quot;信任&quot;的假设相反。gstack 的假设是：你不能信任 AI 的自我判断——它会在应该先做设计时直接写代码，会在没做完时声称做完了。所以用系统级别的门控来强制执行。superpowers 的假设是：你可以部分信任 AI——给它好用的工具和清晰的行为约束（HARD-GATE），它会在大多数时候做出正确的选择。</p><p>哪种假设更接近现实？取决于你用的模型和任务的复杂度。Claude 4.x 上 superpowers 的自动触发表现良好——Agent 确实会在应该先做设计时停下来问问题。但在更弱的模型上，HARD-GATE 只是一段文本，Agent 可能直接跳过。gstack 的 hooks 门控在任何模型上都有效，但只在支持 hooks 的平台上有效。</p><p>Jesse Vincent 对这个问题的回答很务实：superpowers 不支持弱模型。项目明确要求 Claude 4.x 或同等能力的模型。如果你用的是弱模型，superpowers 不提供保障——它假设 Agent 有基本的指令遵循能力。</p><h2 id="6-7-适用边界"><a href="#6-7-适用边界" class="headerlink" title="6.7 适用边界"></a>6.7 适用边界</h2><p>superpowers 不像 gstack 那样有明确的&quot;绿野项目&quot;&quot;治理轨迹&quot;&quot;单人团队&quot;三类最佳场景。它的适用逻辑更简单——看任务类型。</p><p><img src="/images/image-20260530011922442.png"></p><p><strong>最适合：</strong></p><ul><li><strong>中等复杂度的功能开发。</strong> 一个独立的 CRUD 模块、一个 UI 组件的重构、一个数据处理的管道——任务足够复杂，值得走 brainstorming → plan → subagent 实现的完整流程；任务又足够独立，不需要跨系统的架构决策。这是 superpowers 的最佳区间。</li><li><strong>需要长时间自主执行的场景。</strong> subagent-driven-development 的核心优势是上下文隔离——每个子 Agent 带着最少的、最精确的上下文开始工作，不会被前面十几个任务的噪音干扰。这让 Agent 可以连续工作数小时而不偏离计划。</li><li><strong>跨平台使用者。</strong> superpowers 支持 Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode 等八个平台。你在一个平台上写的 Skill 可以直接在另一个平台上用。这一点 gstack 也在做（支持十款 AI 编码工具），但 superpowers 的跨平台兼容性更成熟——它的 Skill 格式更标准化，触发机制不依赖平台特有的 hooks 系统。</li></ul><p><strong>不适合：</strong></p><ul><li><strong>从零到一的绿野项目。</strong> 没有 CEO 角色审产品方向、没有设计师角色审用户体验、没有安全官角色审计漏洞——superpowers 缺乏 gstack 那种全景角色覆盖。做一个全新产品，你仍然需要自己判断&quot;该不该做&quot;和&quot;做给谁用&quot;。</li><li><strong>需要完整治理轨迹的项目。</strong> superpowers 的设计文档存在 <code>docs/superpowers/specs/</code> 下，但没有像 gstack 或 OpenSpec 那样的结构化审查记录和审计轨迹。合规性行业的需求它满足不了。</li><li><strong>小修小补。</strong> brainstorming 流程强制&quot;每个项目都要走设计流程&quot;，但改一个按钮颜色不值得九步设计流程。superpowers 的流程成本对小任务来说偏高——不像 Pocock Skills 那样可以单 Skill 快速调用。</li></ul><p>一个实用的判断：任务是&quot;写一个新功能&quot;——superpowers 值回票价。任务是&quot;做一个新产品&quot;——gstack 更完整。任务是&quot;修一个小 bug&quot;——Pocock Skills 更快。</p><h2 id="6-8-与前后章节的关系"><a href="#6-8-与前后章节的关系" class="headerlink" title="6.8 与前后章节的关系"></a>6.8 与前后章节的关系</h2><p><strong>superpowers 与 Skills（第 2 章）。</strong> superpowers 的十四个 Skill 在格式上和 Pocock 的 Skill 没什么区别——都是 SKILL.md 文件，都有 metadata + description + body。核心差异在触发机制。Pocock 的 Skill 是手动调用的——你不说 <code>/tdd</code>，Agent 不用。superpowers 的 Skill 是自动触发的——Agent 读 description 匹配当前场景，自己决定激活哪个。Pocock 把控制权留给人，superpowers 把判断权交给 Agent。</p><p><strong>superpowers 与 Ralph Loop（第 4 章）。</strong> superpowers 的 <code>subagent-driven-development</code> 和 Ralph Loop 有相似的目标——让 Agent 自主完成多轮工作。但实现方式完全不同。Ralph Loop 是同一个 Agent 在同一个会话中反复迭代——Stop Hook 拦截退出，重新注入 prompt，Agent 看到自己上一轮的产出并改进。superpowers 是新 Agent 新上下文——每个任务派一个全新的子 Agent，上下文干净，不带历史噪音。前者的优势是可以累积理解，劣势是上下文膨胀。后者的优势是上下文干净，劣势是每个子 Agent 需要被精确构造上下文，对主 Agent 的协调能力要求更高。</p><p><strong>superpowers 与 gstack（第 5 章）。</strong> gstack 是人驱动流程，superpowers 是 Agent 驱动流程。gstack 靠角色覆盖质量，superpowers 靠工具覆盖质量。gstack 用系统 hooks 做门控，superpowers 用 prompt 内嵌指令做门控。两个系统解决的是同一个问题（如何让 AI Agent 高质量产出），走了相反的设计路径。</p><p><strong>superpowers 与 autoresearch（第 7 章）。</strong> autoresearch 的多 Agent 轮转和 superpowers 的子 Agent 派遣都涉及多 Agent 协作。但协作模式不同。autoresearch 是审查式协作——Agent A 实现，Agent B 审查并修复，Agent C 再审查并修复。superpowers 是分工式协作——每个子 Agent 负责一个独立任务，主 Agent 协调和审查。第 7 章会详谈这两种协作模式的差异。</p><h2 id="6-9-小结"><a href="#6-9-小结" class="headerlink" title="6.9 小结"></a>6.9 小结</h2><p>superpowers 拿到 201K+ Stars，不是因为运气——它的设计方向确实对：不靠流程锁住质量，靠足够多的 Skill 覆盖足够多的场景，靠自动触发让 Agent 在合适的时机用对的工具。</p><p>它的核心设计三条：</p><ol><li><p><strong>自动触发替代手动调用。</strong> Skill 不是斜杠命令——你不需要记住什么时候该用什么。Agent 在读 description 时自己判断。技能的使用不再靠人类记忆，靠 Agent 自觉。</p></li><li><p><strong>子 Agent 隔离替代上下文累积。</strong> 每个任务一个全新的子 Agent，上下文只包含完成当前任务所需的最小信息。这解决了 Ralph Loop 的循环膨胀问题——上下文不会随着迭代次数线性增长，每个子 Agent 都在干净的环境中工作。</p></li><li><p><strong>认知门控替代系统门控。</strong> gstack 用 PreToolUse hooks 在系统层面锁住行为。superpowers 用 <code>&lt;HARD-GATE&gt;</code> 标签在 prompt 层面锁住行为。前者更强但依赖平台，后者更软但跨平台通用。两条路线验证了同一个结论：AI Agent 需要门控——它不能在任何时候做任何事。门控的实现在哪里（系统层还是 prompt 层），取决于你的平台能力和对 Agent 的信任程度。</p></li></ol><p>gstack 是流程集成——二十三个角色在七个 Sprint 阶段中协作，输出靠流程结构保证。superpowers 是工具覆盖——十四个 Skill 在自动触发中组合，输出靠工具质量保证。第 7 章讲 autoresearch：连子 Agent 的协调也不要人了，从 Issue 到 PR 全自动，行不行？</p>