用 Claude Code 写过超过 500 行代码的人多半都遭遇过同一件事你描述一个需求Claude 给你生成了一大段看起来很合理的代码。代码能跑测试也写了几个功能对了。但两周之后你往同一个模块加功能发现之前那段代码的假设是错的——没有测试覆盖那个边界条件修起来比重写还难。不是 Claude 写得烂。是你们两个从一开始就没有共识过这段代码要对什么负责。这就是 Superpowers 要解决的问题。不是让 AI 更聪明是给 AI 一套工程纪律。截至 2026 年 5 月这个由 Jesse Vincentobra维护的框架已经积累了 204K GitHub Stars、18.2K Forks在 Anthropic 官方插件市场的安装量超过 68 万次是 Claude Code 生态里增长最快的插件。v5.1.0 在 2026 年 4 月 30 日发布仍在快速迭代。它到底是什么本质上是一个可组合的 Skill 执行器大多数人第一次听说 Superpowers以为是某种 Claude 的 fine-tune 版本或者是一个专属的 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-developmentTDD 强制执行、requesting-code-review发起代码评审、receiving-code-review处理评审意见、verification-before-completion完成前验证调试与元技能类systematic-debugging系统化调试、writing-skills编写新 Skill、using-superpowersSuperpowers 激活恢复、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-superpowersskill 可以把它拉回来。框架完全透明你可以修改任何 Skill 来适配自己团队的规范——这是刻意的设计决策把工程文化编码成文件而不是锁进平台。图Superpowers 的架构本质——14 个可组合的 Markdown Skill 文件通过 Hook 注入到 Agent 会话形成工程约束层7 阶段工作流从「能跑」到「可维护」Superpowers 把软件开发的一次完整迭代拆成 7 个强制阶段。每个阶段对应一个或多个 Skill框架要求不允许跳过。阶段 1Brainstorming需求澄清这不是闲聊是 Socratic 对话。Claude 会主动问这个功能的边界在哪里有哪些已有代码会受影响你接受什么形式的输出边界条件是什么大多数工程师觉得这一步啰嗦想直接开写。但这一步的设计目的很明确让 Claude 在写代码之前先暴露它对需求的假设。我用裸 Claude Code 踩过的坑有 60% 源头都在这一步省掉了——需求没说清楚Claude 就开始猜了而它猜的方向往往会在你不知道的地方和别的模块打架。Brainstorming 就是把这些隐式假设在写代码之前逼出来让你确认或纠正。阶段 2Git Worktree 隔离在写任何代码之前先建一个干净的 worktree 分支。这不是噱头是防止 Claude 在主分支上做试验性修改污染你的工作区。生产环境里吃过Claude 顺手改了三个文件然后功能坏了这种亏的工程师会明白这一步的价值。v5.1.0 对 worktree skill 做了重写加入了环境检测和基于同意的工作区创建逻辑比之前的版本更稳。阶段 3Writing Plans任务分解把设计分解成 2-5 分钟的原子任务每个任务有明确的文件路径、预期改动、验证步骤。这一步的输出是一份计划文档你需要 review 并确认。这里有个反直觉的建议不要让 Claude 在写完计划之后立刻开始执行。新开一个会话再执行计划防止写计划时累积的上下文污染执行阶段的判断。这是社区里很多重度用户总结出来的框架文档本身也提到了。阶段 4Subagent-Driven Development子 Agent 并行执行这是 Superpowers 架构里最关键的设计。每个原子任务派给一个全新的子 Agent子 Agent 只知道自己这一个任务的上下文执行完报告结果给协调 Agent。背后的逻辑是长时间运行的单一 Agent 上下文会腐化——随着对话轮数增加早期假设会被忘记新的错误会越来越难发现。新鲜子 Agent 的上下文是干净的判断也是干净的。这是 Superpowers 最核心的工程假设也是它和裸 Claude Code 在长周期开发上差距最大的地方。阶段 5TDD测试驱动这是整个框架最暴力的一环。规则只有一条没有失败的测试就没有实现代码。不是尽量先写测试不是写完再补测试是字面意义上的——如果发现子 Agent 在没有失败测试的情况下写了实现代码Superpowers 要求删掉那段代码回到测试先行的状态。RED → GREEN → REFACTOR循环不跳步。阶段 6Code Review代码评审任务之间穿插代码评审发现 critical 级别的问题会阻断后续任务。这里的critical有明确定义逻辑错误、安全漏洞、与 spec 不符——不是风格问题。v5.1.0 对 code review 做了整合去掉了命名 Agent 的方式改为更简洁的自包含模板减少了角色混乱的问题。阶段 7Branch Finishing分支收尾给你四个选项合并到主分支 / 创建 PR / 保留分支 / 丢弃分支。这一步强制你对这次迭代的结果做一个明确的决策而不是先放着。TDD 强制化的背后AI 写代码为什么不加测试会出问题这是很多人觉得「TDD 感觉没必要」的地方我想多说几句因为 AI 场景和人类写代码的场景有本质区别。人类工程师跳过测试写代码通常是偷懒但他脑子里还存着这段代码应该对什么负责的隐式知识。他之后补测试的时候大概率还记得那些边界条件。这是人类的记忆系统在发挥作用。AI 写代码没有这个隐式记忆。Claude 生成的代码是当前上下文的最优解。但当前上下文不等于完整需求。测试是一种合约——测试逼着你在写实现之前把这段代码要保证什么显式地写出来。这个合约用机器可以验证的方式存在于代码库里。没有这个合约Claude 在两周后面对新需求时不知道那个合约存在它可能会完全合理地违反它。我见过最典型的例子一个负责订单状态流转的模块用裸 Claude Code 写的跑了三周没问题。然后加了一个退款逻辑Claude 顺手重构了状态机把一个边界状态合并了——因为在新的上下文里那个状态看起来多余。那个状态是处理异常支付渠道的生产上有 0.3% 的概率触发。没有测试覆盖悄悄坏掉了上线之后客服系统才报警。这不是模型的 bug是系统设计层面的架构隐患。上下文无记忆的 AI 在长周期迭代中天然会侵蚀没有显式约束覆盖的代码区域。有数据支撑这一点。chardetPython 字符编码检测库的维护者用 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 superpowersclaude-plugins-official这是官方 Anthropic 插件市场的安装命令。安装完成后重启 Claude Code在新会话中输入/help能看到 Superpowers 命令列表则安装成功。如果官方市场安装不了网络问题备选方案是社区市场/plugin marketplace add obra/superpowers-marketplace /plugin install superpowerssuperpowers-marketplace第 1 步触发 Brainstorming Skill在 Claude Code 里输入/superpowers:brainstorming 我想写一个 Python 函数输入月份和日期返回对应的星座名称Claude 不会立刻给你写代码。它会先问一系列澄清问题类似这样“在开始之前我需要了解几件事输入格式是整数1-12 月1-31 日还是字符串输入非法日期比如 2 月 30 日时应该怎么处理——抛出异常还是返回 None星座边界日期比如 1 月 19 日 vs 1 月 20 日是否需要精确到哪年的实际分界点还是用固定日期返回值是中文星座名还是英文是否需要同时返回两者这个函数会用在什么场景——单独调用还是作为 API 的一部分这就是 Brainstorming 的核心价值它把你的隐式假设逼出来。对这些问题回答后“你的回答整数输入非法日期抛 ValueError用固定边界日期返回中文单独函数就行现在 Claude 有了清晰的合约。第 2 步生成计划/superpowers:writing-plansClaude 会把实现拆成原子任务任务 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-12day 1-31无效输入 raise ValueError 验证边界值测试通过重点在新会话里执行这份计划不要在同一个会话里直接让 Claude 开始执行。打开新的 Claude Code 会话把计划粘贴进去再开始。第 3 步TDD 执行——先写失败的测试/superpowers:test-driven-developmentClaude 的第一动作是写测试文件不是实现代码# test_zodiac.py import pytest from zodiac import get_zodiac class 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 -vERROR collecting test_zodiac.py ModuleNotFoundError: No module named zodiac这是正确的状态。Superpowers 框架要求看到测试失败后才允许开始写实现代码。第 4 步最小实现GREEN 状态现在 Claude 写实现代码# zodiac.py ZODIAC_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 超出有效范围时 ifnot (1 month 12): raise ValueError(f月份必须在 1-12 之间收到: {month}) ifnot (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 -vtest_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 PASSED 18 passed in 0.12s所有测试通过GREEN 状态。第 5 步Code Review/superpowers:requesting-code-reviewClaude 会按 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 fix套完整 7 阶段流程会明显比直接让 Claude 修慢。Superpowers 的设计取向是明确的——它是为中大型功能开发优化的不是为一行代码的快速修改。评估是否值得用最简单的判断标准是这个改动如果出了问题修复成本是否超过 30 分钟是的话走 Superpowers 流程值得。和 GSD、gstack 的定位差异Claude Code 生态里现在有三个主要的工作流框架值得认真比一下定位方便你选型——它们解决的根本上是三种不同的问题不是同一个问题的三种解法。Superpowers204K stars约束开发流程本身。核心假设是AI 写的代码在没有测试约束的情况下会随时间积累隐患。框架的解法是把 TDD、计划先行、子 Agent 隔离这些工程实践强制编码进每次开发流程让 Claude 没有机会走捷径。适合需要测试覆盖和代码质量保证的功能开发尤其是那些三个月后还要维护的代码。弱点是单一协调 Agent 在极长任务超过一天的工作量中仍然会遇到上下文限制这个问题 GSD 处理得更好。GSD51K stars约束执行环境。核心假设是Agent 上下文会随工作时间增长而腐化导致质量下滑。框架的解法是 phase-based orchestration——把工作拆成原子任务每个任务派一个新的 Claude 实例新鲜 200K token 上下文执行协调 Agent 始终保持在上下文容量的 50% 以内状态通过 Markdown 文件持久化。Pulumi 的数据显示GSD 在 50 文件的大型项目上可以把第三小时的代码质量维持在接近第一小时的水平。适合跨天的长任务、多个并行工作流、或者需要在中途 crash 后恢复的场景。弱点是相比 Superpowers它对 TDD 的约束要弱一些——它更关注任务能完成不强制关注测试覆盖率。gstack71K stars约束决策视角。核心假设是单一 Agent 视角会有盲点代码写出来了但可能方向本身就是错的。框架的解法是 23 个角色CEO、产品经理、QA 负责人、工程师、安全审计员……让 Claude 以不同身份审视同一段代码防止只有工程师视角的判断盲区。对需要产品和技术并行思考的独立开发者很有价值——做一个面向消费者的产品时纯工程视角往往会忽略用户体验和商业逻辑的优先级。但写代码本身不是它的强项它更像是一个决策审查工具而不是开发流程工具。选择思路如果你的核心问题是AI 写的代码缺少工程纪律三个月后会成为技术债选 Superpowers。如果你的问题是长任务超过 4 小时中途 Claude 开始犯错上下文腐化选 GSD。如果你的问题是代码写出来了但不确定方向对不对需要从 PM 和用户视角再看一遍试试 gstack。三个框架定位基本不重叠用错了框架解决不了问题。图三个主流 Claude Code 工作流框架的核心定位对比数据截至 2026 年 5 月常见问题QSuperpowers 会不会让 Claude Code 变得很慢会增加时间但这个时间花得值不值取决于任务规模。对于一个需要 3-5 个迭代周期、后续还要维护的功能模块整个 Superpowers 流程通常比直接开写慢 20-30%——前期 Brainstorming 和 Writing Plans 大约多花 10-20 分钟但产出的代码有 85% 测试覆盖后续遇到需求变更时的修改成本大幅降低。对于单行 bug fix 或 quick prototype不打算长期维护直接用裸 Claude Code 更合适。一个实用的判断标准这个改动如果出了问题修复成本超过 30 分钟吗是的话走 Superpowers 流程值得。QSKILL.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-superpowersSkill 可以把它拉回来——这个 Skill 的作用就是重新激活工程约束。Q这个框架在 Windows 上能用吗能。Superpowers 的执行层是 Claude Code平台兼容性由 Claude Code 本身保证。SKILL.md 文件本身是纯文本没有 OS 依赖。框架在 macOS、Linux、WindowsWSL 和原生上均有社区报告的成功使用案例。Q安装之后 Claude 的上下文消耗会增加多少引导注入大约 2000 tokens相当于 Claude 每次对话会多消耗约 1-2% 的上下文。对于 200K token 窗口的 Claude这个消耗可以忽略不计。框架设计的出发点之一就是极度轻量——2000 tokens 的引导是刻意控制的不是技术限制导致的。总结说白了Superpowers 解决的不是「AI 能不能写代码」的问题而是「AI 写的代码能不能在三个月后还可以维护」的问题。前者现在几乎所有工具都能做到后者没有几个人认真对待过。我用它三个月之后的判断对于超过 200 行的功能模块不加 TDD 约束的 AI 生成代码在第二个月就会开始累积隐患第三个月开始让人头疼。这不是玄学是上下文无记忆的 AI 系统在长周期迭代中的必然结果。chardet 41 倍性能提升的数字是有记录的不是营销话术。下篇打算写 Subagent 的上下文隔离设计——不只是 Superpowers而是从底层理解为什么多 Agent 架构在今天这个阶段比单个大 context 更可靠。感兴趣关注一下不然算法不一定推给你。