用了三个月 Superpowers：我才明白 204K Star 背后真正解决的是什么问题

时间：2026-07-02 08:52:47 来源：互联网

在使用Claude Code编写超过500行代码的过程中，许多开发者都曾经历过一个共同的困境。

你向Claude描述了一个需求，它迅速生成了一大段看起来相当合理的代码。代码能够运行，也撰写了一些测试用例，功能似乎也正确。然而，两周之后，当你向同一个模块添加新功能时，才发现之前那段代码的假设存在错误——没有测试覆盖到那个边界条件，导致修复工作比重写还要困难重重。

这并不是Claude写得不好，而是因为你们两个从一开始就没有就“这段代码要对什么负责”达成过共识。

这正是Superpowers所要解决的问题。它的目标并非让AI变得更聪明，而是为AI赋予一套严谨的工程纪律。

截至2026年5月，这个由Jesse Vincent（obra）维护的框架已经累积了204K的GitHub Stars和18.2K的Forks，在Anthropic官方插件市场上的安装量超过了68万次，成为Claude Code生态系统中增长最为迅速的插件。其v5.1.0版本于2026年4月30日发布，目前仍在快速迭代之中。

它到底是什么？本质上是一个可组合的Skill执行器

大多数人初次听说Superpowers时，会误以为它是Claude的某种微调版本，或者是一个专属的Agent框架。但实际上，这些都不是。

Superpowers的全部实现就是一套SKILL.md文件。 每一个SKILL.md文件都代表了一套流程规范，以Markdown格式编写，任何人都可以轻松阅读理解。整个框架没有自己的运行时环境，不锁定特定的模型，也不依赖私有API——本质上，它是一套被编码进文本中的工程方法论。

当前版本总共包含了14个核心技能，这些技能被划分为三大类别：

开发流程类： brainstorming（需求澄清）、writing-plans（任务拆解）、executing-plans（计划执行）、subagent-driven-development（子Agent并行）、using-git-worktrees（工作区隔离）、finishing-a-development-branch（分支收尾）

质量保证类： test-driven-development（TDD强制执行）、requesting-code-review（发起代码评审）、receiving-code-review（处理评审意见）、verification-before-completion（完成前验证）

调试与元技能类： systematic-debugging（系统化调试）、writing-skills（编写新Skill）、using-superpowers（Superpowers激活恢复）、dispatching-parallel-agents（并行Agent调度）

当会话启动时，该框架会通过Claude Code的hook机制注入一个引导文档（大小不超过2000 tokens），这告诉Claude在开始任何任务之前，应当先读取相关的Skill。这一设计使得整个框架极为轻量：它不限制你使用哪个模型，不需要自己的运行时，并且能够跨Claude Code、Cursor、Gemini CLI、GitHub Copilot CLI以及Codex CLI等多个工具工作。

这里有一个设计取舍值得注意：2000 tokens的引导注入确实能够有效节省上下文——但它也带来了一个已知问题。子Agent在启动时不会自动继承这个上下文注入，这导致子Agent有时会跳过像TDD这样的约束而直接开始编写代码。目前，框架通过SubagentStart hook部分缓解了这个问题，但在v5.1.0版本中这仍然是一个已知问题。遇到这种情况时，可以手动触发using-superpowers skill来将其拉回正轨。

整个框架是完全透明的，你可以修改任何一个Skill来适配自己团队的规范——这是一个刻意的设计决策，旨在将工程文化编码成文件，而不是将其锁在一个平台里。

图：Superpowers的架构本质——14个可组合的Markdown Skill文件通过Hook注入到Agent会话，形成工程约束层

7阶段工作流：从「能跑」到「可维护」

Superpowers将软件开发的一次完整迭代分解为7个强制执行的阶段。每个阶段都对应一个或多个Skill，框架要求不允许跳过其中任何一个阶段。

阶段1：Brainstorming（需求澄清）

这并非闲聊，而是一种苏格拉底式的对话。Claude会主动提问：这个功能的边界在哪里？有哪些已有的代码可能受到影响？你期望接受什么样的输出形式？边界条件具体是什么？

大多数工程师会觉得这一步有些啰嗦，并希望直接进入编码阶段。然而，这一步的设计目的非常明确：让Claude在编写代码之前，先暴露它对需求的各种假设。我个人在使用裸Claude Code时踩过的坑，有60%的根源都在于省略了这一步骤——需求没有说清楚，Claude就开始猜测，而它猜测的方向往往会在你不知情的地方与其他模块产生冲突。Brainstorming就是在编码之前，将这些隐式的假设逼出来，让你进行确认或纠正。

阶段2：Git Worktree隔离

在编写任何代码之前，首先需要创建一个干净的worktree分支。这并非噱头，而是为了防止Claude在主分支上进行试验性修改，从而污染你的工作区。那些在生产环境中经历过“Claude顺手修改了三个文件导致功能故障”的工程师，会深刻理解这一步的价值。在v5.1.0版本中，worktree skill经过了重写，加入了环境检测和基于同意的工作区创建逻辑，相比之前的版本更加稳定。

阶段3：Writing Plans（任务分解）

将设计分解成2到5分钟就能完成的原子任务，每个任务都明确了文件路径、预期的改动以及验证步骤。这一步的输出是一份计划文档，你需要对其进行评审并确认。

这里有一个反直觉的建议：不要让Claude在写完计划之后立刻开始执行。 最好新开一个会话再来执行计划，这样可以防止写计划过程中累积的上下文污染执行阶段的判断。这是社区中许多重度用户总结出的经验，框架文档本身也提到了这一点。

阶段4：Subagent-Driven Development（子Agent并行执行）

这是Superpowers架构中最为关键的设计。每个原子任务都会被分配给一个全新的子Agent，该子Agent只知道与自己当前任务相关的上下文，执行完毕后将结果报告给协调Agent。

这背后的逻辑是：长时间运行的单一Agent上下文会“腐化”——随着对话轮数的增加，早期的假设可能会被遗忘，新的错误也越来越难以发现。而一个全新的子Agent拥有干净的上下文，其判断也因此更为清晰。这是Superpowers最核心的工程假设，也是它在长周期开发任务中与裸Claude Code拉开差距最大的地方。

阶段5：TDD（测试驱动）

这是整个框架中最为“强硬”的一环。规则只有一条：没有失败的测试，就没有实现代码。 这并非“尽量先写测试”，也不是“写完后再补测试”，而是字面意义上的——如果发现子Agent在没有失败测试的情况下编写了实现代码，Superpowers要求删除那段代码，并回到测试先行的状态。遵循RED→GREEN→REFACTOR的循环，不跳过任何一个步骤。

阶段6：Code Review（代码评审）

在任务之间穿插进行代码评审，一旦发现critical级别的问题，将会阻断后续任务的执行。这里的“critical”有明确的定义：指逻辑错误、安全漏洞以及与spec不符——而非代码风格问题。在v5.1.0版本中，code review功能经过了整合，去掉了命名Agent的方式，改为更简洁的自包含模板，从而减少了角色混乱的问题。

阶段7：Branch Finishing（分支收尾）

提供四个选项供你选择：合并到主分支、创建PR、保留分支或丢弃分支。这一步强制你对这次迭代的结果做出一个明确的决策，而不是简单地“先放着不管”。

TDD强制化的背后：AI写代码为什么不加测试会出问题

很多人会觉得“TDD感觉没什么必要”，我想就这一点再多说几句，因为AI写代码的场景与人类写代码的场景存在着本质上的区别。

人类工程师跳过测试直接写代码，通常是因为偷懒，但在他们的脑海里，仍然存有关于“这段代码应该对什么负责”的隐式知识。他们之后补测试的时候，大概率还能记得那些边界条件。这是人类的记忆系统在发挥作用。

AI写代码则不具备这种“隐式记忆”。 Claude生成的代码仅仅是当前上下文下的最优解。然而，“当前上下文”并不等同于“完整的需求”。

测试本质上是一种合约——它迫使你在编写实现代码之前，将“这段代码要保证什么”明确地以文字形式写出来。这个合约以机器可验证的方式存在于代码库中。如果没有这个合约，两周后Claude面对新的需求时，就无从知晓那个合约的存在，它可能会完全合理地违反这个合约。

我见过一个非常典型的例子：一个负责订单状态流转的模块，使用裸Claude Code编写，运行了三周都没有出现问题。然后，当添加一个退款逻辑时，Claude顺手重构了状态机，将一个边界状态合并了——因为在新的上下文里，那个状态“看起来是多余的”。然而，那个状态是用来处理异常支付渠道的，在生产环境中大约有0.3%的触发概率。由于没有测试覆盖，这个错误悄悄发生了，直到上线后客服系统报警才被发现。

这并非模型的bug，而是系统设计层面的架构隐患。一个缺乏上下文记忆的AI系统，在长周期的迭代过程中，会天然地侵蚀那些没有显式约束覆盖的代码区域。

有数据可以支撑这一点。chardet（一个Python字符编码检测库）的维护者使用Superpowers重写了v7.0.0版本，跑完了2161个测试文件，覆盖了99种编码，最终实现了性能提升41倍，准确率从94.5%提升到96.8%。这个数字的来源并不是Superpowers拥有什么神奇的算法，而是由于TDD的强制执行——“每次代码变动都必须先有失败的测试通过才能保留”，这意味着Claude可以进行大胆的重构，因为回归测试会立刻捕获所有破坏性的更改。这正是TDD在AI编写代码场景下的核心价值：让激进的优化变得安全可靠。

Superpowers将测试覆盖目标设定在85%到95%之间，这并非“有测试就行”那么简单。这个数字并非凭空决定——低于80%的覆盖率，在第二次迭代时回归（regression）的概率会显著增加；而高于95%的覆盖率，编写测试所投入的时间成本将超过其带来的收益。85%到95%是一个基于经验数值得出的合理区间。

TDD强制化，正是针对AI编写代码场景中“上下文无记忆”这一根本问题的系统性解决方案。

图：Superpowers强制TDD循环的执行逻辑——代码先于测试存在时，框架要求删除实现代码重来

30分钟上手实战：从零跑完完整工作流

讲了这么多原理，现在我们来实际演练一遍完整的操作过程。以一个简单的小需求为例：编写一个Python函数，根据输入的月份和日期，返回对应的星座名称。 这个需求足够简单，但涵盖了边界条件处理和错误输入验证——能够完整展示Superpowers工作流的每一个环节。

第0步：安装

首先，在Claude Code中安装Superpowers：

/plugin install superpowers@claude-plugins-official

这是来自Anthropic官方插件市场的安装命令。安装完成后，重启Claude Code，并在新会话中输入/help，如果能看到Superpowers的命令列表，则说明安装成功。

如果由于网络问题无法通过官方市场安装，可以使用备选方案，即社区市场：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

第1步：触发Brainstorming Skill

在Claude Code中输入：

/superpowers:brainstorming 我想写一个Python函数，输入月份和日期，返回对应的星座名称

Claude并不会立刻开始编写代码。它首先会询问一系列澄清性问题，大致如下：

这就是Brainstorming的核心价值所在：它能够将你的隐式假设清晰地摆到台面上。在对这些问题做出回答之后：

现在，Claude已经拥有了一个清晰的合约。

第2步：生成计划

/superpowers:writing-plans

Claude会将实现过程分解为多个原子任务：

任务1（约3分钟）：定义星座边界数据结构
  文件：zodiac.py
  内容：创建ZODIAC_DATES常量，包含12个星座的月日范围
  验证：数据结构完整，覆盖全年365天无遗漏任务2（约3分钟）：实现核心查找逻辑
  文件：zodiac.py
  内容：实现get_zodiac(month: int, day: int) -> str函数
  验证：基本星座返回正确任务3（约2分钟）：实现输入验证
  文件：zodiac.py
  内容：验证month 1-12，day 1-31，无效输入raise ValueError
  验证：边界值测试通过

重点提示：请在新会话中执行这份计划。 不要在与生成计划相同的会话里直接让Claude开始执行。请打开一个新的Claude Code会话，将计划粘贴进去后再开始操作。

第3步：TDD执行——先写失败的测试

/superpowers:test-driven-development

Claude的首要动作是编写测试文件，而不是实现代码：

# test_zodiac.py
import pytest
from zodiac import get_zodiacclass TestGetZodiac:
    """根据月日返回星座名称的函数测试"""    # 每个星座的典型日期
    def test_aries(self):
        assert get_zodiac(4, 1) == "白羊座"    def test_taurus(self):
        assert get_zodiac(5, 1) == "金牛座"    def test_gemini(self):
        assert get_zodiac(6, 1) == "双子座"    def test_cancer(self):
        assert get_zodiac(7, 1) == "巨蟹座"    def test_leo(self):
        assert get_zodiac(8, 1) == "狮子座"    def test_virgo(self):
        assert get_zodiac(9, 1) == "处女座"    def test_libra(self):
        assert get_zodiac(10, 1) == "天秤座"    def test_scorpio(self):
        assert get_zodiac(11, 1) == "天蝎座"    def test_sagittarius(self):
        assert get_zodiac(12, 1) == "射手座"    def test_capricorn(self):
        assert get_zodiac(1, 1) == "摩羯座"    def test_aquarius(self):
        assert get_zodiac(2, 1) == "水瓶座"    def test_pisces(self):
        assert get_zodiac(3, 1) == "双鱼座"    # 边界日期测试（关键！）
    def test_boundary_capricorn_to_aquarius(self):
        """1月19日是摩羯，1月20日是水瓶"""
        assert get_zodiac(1, 19) == "摩羯座"
        assert get_zodiac(1, 20) == "水瓶座"    def test_boundary_pisces_to_aries(self):
        """3月20日是双鱼，3月21日是白羊"""
        assert get_zodiac(3, 20) == "双鱼座"
        assert get_zodiac(3, 21) == "白羊座"    # 错误输入测试
    def test_invalid_month_zero(self):
        with pytest.raises(ValueError):
            get_zodiac(0, 1)    def test_invalid_month_thirteen(self):
        with pytest.raises(ValueError):
            get_zodiac(13, 1)    def test_invalid_day_zero(self):
        with pytest.raises(ValueError):
            get_zodiac(1, 0)    def test_invalid_day_thirty_two(self):
        with pytest.raises(ValueError):
            get_zodiac(1, 32)

此时运行测试，全部会失败（RED状态）——因为zodiac.py这个文件根本不存在：

pytest test_zodiac.py -v

ERROR collecting test_zodiac.py
ModuleNotFoundError: No module named 'zodiac'

这是一个正确的状态。Superpowers框架要求在看到测试失败之后，才允许开始编写实现代码。

第4步：最小实现（GREEN状态）

现在，Claude开始编写实现代码：

# zodiac.pyZODIAC_DATES = [
    (1, 20, "水瓶座"),
    (2, 19, "双鱼座"),
    (3, 21, "白羊座"),
    (4, 20, "金牛座"),
    (5, 21, "双子座"),
    (6, 21, "巨蟹座"),
    (7, 23, "狮子座"),
    (8, 23, "处女座"),
    (9, 23, "天秤座"),
    (10, 23, "天蝎座"),
    (11, 22, "射手座"),
    (12, 22, "摩羯座"),
]
def get_zodiac(month: int, day: int) -> str:
    """
    根据月份和日期返回对应星座名称。    Args:
        month: 月份，整数1-12
        day: 日期，整数1-31    Returns:
        str: 中文星座名称    Raises:
        ValueError: 当month或day超出有效范围时
    """
    if not (1 <= month <= 12):
        raise ValueError(f"月份必须在1-12之间，收到: {month}")
    if not (1 <= day <= 31):
        raise ValueError(f"日期必须在1-31之间，收到: {day}")    for cutoff_month, cutoff_day, zodiac_name in ZODIAC_DATES:
        if month < cutoff_month or (month == cutoff_month and day < cutoff_day):
            return zodiac_name    # 12月22日及之后都是摩羯座
    return "摩羯座"

再次运行测试：

pytest test_zodiac.py -v

test_zodiac.py::TestGetZodiac::test_aries PASSED
test_zodiac.py::TestGetZodiac::test_taurus PASSED
test_zodiac.py::TestGetZodiac::test_gemini PASSED
test_zodiac.py::TestGetZodiac::test_cancer PASSED
test_zodiac.py::TestGetZodiac::test_leo PASSED
test_zodiac.py::TestGetZodiac::test_virgo PASSED
test_zodiac.py::TestGetZodiac::test_libra PASSED
test_zodiac.py::TestGetZodiac::test_scorpio PASSED
test_zodiac.py::TestGetZodiac::test_sagittarius PASSED
test_zodiac.py::TestGetZodiac::test_capricorn PASSED
test_zodiac.py::TestGetZodiac::test_aquarius PASSED
test_zodiac.py::TestGetZodiac::test_pisces PASSED
test_zodiac.py::TestGetZodiac::test_boundary_capricorn_to_aquarius PASSED
test_zodiac.py::TestGetZodiac::test_boundary_pisces_to_aries PASSED
test_zodiac.py::TestGetZodiac::test_invalid_month_zero PASSED
test_zodiac.py::TestGetZodiac::test_invalid_month_thirteen PASSED
test_zodiac.py::TestGetZodiac::test_invalid_day_zero PASSED
test_zodiac.py::TestGetZodiac::test_invalid_day_thirty_two PASSED18 passed in 0.12s

所有测试都通过了（GREEN状态）。

第5步：Code Review

/superpowers:requesting-code-review

Claude会按照critical、warning、info三个级别对代码进行评审。典型的输出示例如下：

Critical: 无Warning:
- day验证只检查1-31，但2月没有29-31日，4/6/9/11月没有31日。
  建议：如果业务不关心这个精度，可以在docstring里注明"不验证日期是否在该月真实存在"。Info:
- ZODIAC_DATES数据结构可以改用namedtuple提高可读性
- 函数在处理12月22日之后的边界依赖"遍历完都不匹配则返回摩羯座"的逻辑，建议加注释明确这个意图

没有发现critical级别的问题，因此可以继续进行。Warning中提到的日期精度问题是一个真实的边界条件，这里根据Brainstorming阶段的约定（使用固定边界日期，不进行精确验证）选择接受，只需在docstring中加以注明即可。

整个流程走下来大约需要25到30分钟。在这个时间里，你得到的不仅仅是一个能运行的函数——而是一个有18个测试用例覆盖、带有清晰文档、并且通过了Code Review的函数，同时还有一份记录了所有设计决策的对话历史。

这就是Superpowers的工作方式。

和裸用Claude Code的真实差距

仅仅说“有用”是不够的，需要清楚地说出差在哪里，以及差距是在什么量级上。

裸Claude Code的典型问题模式：

第一次运行：90%的功能正常，测试覆盖率为40%到60%，代码风格因上下文而异。这个阶段感觉非常好。

第五次迭代：开始出现函数长度膨胀的问题，边界条件处理不一致，某些模块与其他模块之间存在隐式假设的耦合。这个阶段开始让人有些烦恼。

第十次迭代：遇到回归（regression）bug的概率显著上升。由于缺乏系统性的测试，修复一个问题可能会破坏另一个你尚未意识到的功能模块。这个阶段开始令人头疼。

使用Superpowers之后的差异：

任务的颗粒度被强制细化（每个任务2到5分钟），这意味着每次子Agent出错，其影响范围会被限制在一个原子任务内，而不会扩散到整个功能。这个设计使得第三个小时的代码质量依然接近第一小时——在裸Claude Code模式下，通常到第二小时的中段，代码质量就开始明显下滑。

测试覆盖率目标设定在85%到95%，而不仅仅是“有测试就行”。chardet v7.0.0的案例是迄今为止有记录的Superpowers最大规模实测：实现了41倍的性能提升，准确率从94.5%提升到96.8%，覆盖了2161个测试文件和99种编码。这并非统计噪音，而是系统性TDD约束带来的可信结果。

但代价也是真实存在的：对于一个简单的bug修复，走完完整的7阶段流程会比直接让Claude去修慢得多。Superpowers的设计取向是明确的——它是为“中大型功能开发”而优化的，并非为“一行代码的快速修改”而设计。评估是否值得使用，最简单的判断标准是：如果这个改动出了问题，修复成本是否会超过30分钟？如果答案是肯定的，那么走Superpowers流程就是值得的。

和GSD、gstack的定位差异

目前在Claude Code生态中，主要有三个工作流框架，值得认真比较一下它们各自的定位，以便于你进行选择——因为它们所解决的，本质上是三种不同类型的问题，而非同一个问题的三种不同解法。

Superpowers（204K stars）：侧重于约束开发流程本身。其核心假设是“AI编写的代码在没有测试约束的情况下，会随着时间的推移积累隐患”。该框架的解决方法是：将TDD、计划先行、子Agent隔离等工程实践强制编码到每一次的开发流程中，使Claude没有机会走捷径。它适用于需要测试覆盖和代码质量保证的功能开发，特别是那些“三个月后还需要维护”的代码。其弱点在于，单一的协调Agent在处理极长任务（超过一天的工作量）时，仍然会遇到上下文限制，而GSD在这方面处理得更好。

GSD（51K stars）：侧重于约束执行环境。其核心假设是“Agent的上下文会随工作时间增长而腐化，导致质量下降”。该框架的解决方法是基于阶段的编排（phase-based orchestration）——将工作拆分为原子任务，每个任务都分配一个新的Claude实例（使用全新的200K token上下文）来执行，同时协调Agent始终保持在其上下文容量的50%以内，状态通过Markdown文件进行持久化。根据Pulumi的数据，对于包含50个以上文件的大型项目，GSD能够将第三小时的代码质量维持在接近第一小时的水平。它适用于跨天的长任务、多个并行工作流，或者需要在任务中途崩溃后恢复的场景。其弱点在于，与Superpowers相比，它对TDD的约束要弱一些——它更关注“任务能够完成”，而非强制关注“测试覆盖率”。

gstack（71K stars）：侧重于约束决策视角。其核心假设是“单一Agent的视角会存在盲点，代码虽然写出来了，但方向本身可能就是错误的”。该框架的解决方法是通过23个角色（如CEO、产品经理、QA负责人、工程师、安全审计员等），让Claude以不同的身份审视同一段代码，从而防止仅仅从工程师视角出发所带来的判断盲区。这对于需要产品和技术并行思考的独立开发者来说非常具有价值——在开发面向消费者的产品时，纯粹的工程视角往往会忽略用户体验和商业逻辑的优先级。然而，“编写代码”本身并非其强项，它更像是一个决策审查工具，而非一个开发流程工具。

选择思路如下：如果你的核心问题是“AI编写的代码缺乏工程纪律，三个月后会成为技术债务”，那么请选择Superpowers。如果你的问题是“长任务（超过4小时）进行到中途时Claude开始出错，上下文发生腐化”，那么请选择GSD。如果你的问题是“代码虽然写出来了，但不确定方向是否正确，需要从产品经理和用户的视角重新审视一遍”，那么可以尝试使用gstack。这三个框架的定位基本不重叠，如果用错了框架，将无法解决对应的问题。

图：三个主流Claude Code工作流框架的核心定位对比，数据截至2026年5月

常见问题

Q：Superpowers会不会让Claude Code变得很慢？

会增加时间，但这个时间花得值不值得取决于任务的规模。对于一个需要3到5个迭代周期，并且后续还要维护的功能模块，走完整的Superpowers流程通常比直接开始编码慢20%到30%——前期的Brainstorming和Writing Plans阶段大约会多花10到20分钟，但产出的代码拥有85%以上的测试覆盖率，后续遇到需求变更时，修改成本会大幅降低。对于单行的bug修复或快速原型开发（不打算长期维护），直接使用裸Claude Code更为合适。一个实用的判断标准是：如果这个改动出了问题，修复成本是否会超过30分钟？如果会，那么走Superpowers流程就是值得的。
Q：SKILL.md文件能自定义吗？

完全可以。每一个SKILL.md文件都是普通的Markdown文件，你可以修改TDD的覆盖率要求、调整Brainstorming的问题列表，或者加入团队特有的代码规范检查（例如增加一条“所有函数都必须有type hints”）。该框架将工程文化编码成文件，而不是将其锁在平台里。在v5.1.0版本中，还加入了writing-skills这个元技能，帮助你规范地编写出新的Skill——这个设计很有意思，框架本身的扩展也需要走TDD和Code Review流程，从而保证新Skill的质量。
Q：只用Claude Code，不使用Cursor或Copilot，还有必要安装吗？

有必要的。Superpowers最核心的价值——TDD强制、子Agent任务隔离、Brainstorming前置——与你使用哪个IDE无关，它们与AI编写代码时如何防止隐式假设的积累直接相关。这是一个方法论层面的问题，而非工具兼容性问题。Superpowers同时支持Claude Code、Cursor、Gemini CLI、Codex CLI以及GitHub Copilot CLI，同一套Skill文件在这些工具中都能正常工作。
Q：子Agent跳过TDD的问题解决了吗？

截至v5.1.0版本，这仍然是一个已知问题，虽然得到部分缓解但尚未完全解决。问题的根源在于，子Agent启动时不会自动继承主会话中注入的Superpowers引导文档，导致它有时并不知道TDD约束的存在。该框架在SubagentStart hook方向上做了部分缓解，但并未完全解决。如果遇到子Agent跳过了测试而直接编写实现代码的情况，可以手动触发一次using-superpowers Skill来将其拉回正轨——这个Skill的作用就是重新激活工程约束。
Q：这个框架在Windows上能用吗？

能。Superpowers的执行层是Claude Code，平台的兼容性由Claude Code本身来保证。SKILL.md文件本身是纯文本，没有操作系统依赖性。根据社区报告，在macOS、Linux以及Windows（包括WSL和原生环境）上都有成功使用的案例。
Q：安装之后Claude的上下文消耗会增加多少？

引导注入大约需要2000 tokens，这相当于Claude每次对话会多消耗大约1%到2%的上下文。对于拥有200K token窗口的Claude来说，这个消耗几乎可以忽略不计。该框架设计的出发点之一就是极度的轻量化——刻意将引导内容控制在2000 tokens，这并非出于技术限制，而是有意为之。

参考资料

obra/superpowers - GitHub
Superpowers Plugin - Anthropic官方插件页
Superpowers, GSD, and GSTACK: Picking the Right Framework - Pulumi Blog
Superpowers: Injecting Engineering Discipline into Claude Code

归根结底，Superpowers所应对的核心挑战并非AI能否生成代码，而是其所生成的代码在数月之后是否依然具备可维护性。前者如今几乎所有工具都能够做到，但后者却很少有人认真对待过。

上一篇：数据集划分不能随意切：手把手带你切分大众点评情感数据集下一篇：从表单到 Agent：得物社区活动搭建的 AI 实践之旅