在HN上，Superpowers 6的帖子拿了196点，评论区吵翻了。一半人说"v6真香，速度快了一半"，另一半说"我卸了，token烧太快"。
我盯着屏幕看了半小时，决定自己也来趟一趟。5个场景实测下来，结论是：不是它不好，而是「好用」这事，真的看场景。
这篇给你一个能直接对号入座的决策框架。
一、Superpowers 做了什么
obra/superpowers 在 GitHub 上已经拿了 256K 星，不是没道理的。它的核心思路是用一套 Spec-Driven + Subagent-Driven Development + 强制 TDD + 自动 Review 的流程，把 LLM 写代码这件事从「甩一个 prompt 等结果」变成可控的工程流水线。
你让它写个功能，它不会直接动代码，而是先写一份 spec 请你确认，然后派 subagent 去实现，实现完了还有自动 review——既检查代码是否匹配 spec，又检查质量标准。每一步都像团队里有个严格的技术负责人盯着。
但代价也明显：token 烧得飞快、构建节奏慢、仪式感太重。v6 的改进就是冲着这些痛点来的——合并 review 管线、压缩 bootstrap 指令、降低每次 session 的 token 消耗。
二、v6 宣称的「速度+50%，成本-60%」验证
v6.0.0 发布于 2026-06-16，随后两周内紧急出了 v6.0.2、v6.0.3、v6.1.0、v6.1.1，修复了 Codex Hook、Evals 分离、SDD scratch 文件搬迁等问题。从 GitHub 代码频率看，最近两周（7/05–7/18）开发活动已经归零，说明 v6.1.1 基本稳定了。
官方宣称的主要优化集中在两个地方：
1. Review 管线合并
以前每个 task 要跑两个 reviewer：spec-reviewer 和 code-quality-reviewer。v6 合并成一个，减少了约 50% 的 token 消耗。实测下来，简单任务的 token 确实减少明显，但复杂任务（跨文件重构）因为 reviewer 要回溯更多上下文，节省幅度会收缩到 30% 左右。
2. Bootstrap 压缩
每次 session 都会注入 using-superpowers 指令。v6.1.0 移除了 Graphviz 技能流程图（改为纯文本描述），折叠了独立的 Instruction-Priority 章节，删除了各平台的「如何访问技能」介绍。结果就是每次启动的 token 消耗从原来的 ~8K 降到了 ~4K。
但注意，这个节省是一次性的，如果你只是短暂修改一两个文件，bootstrap 节省的 token 并不多。只有在大 session（连续工作 30+ 轮对话）中才会有可观累积。
我的实测感受：
确实更快了。原来一个中等复杂度功能（5-6 个文件）从 spec 到 review 完成要 4-5 分钟，v6 压缩到 2.5-3 分钟。但「快」的代价是，合并后的 review 有时会遗漏 spec 校验的某条规则——比如我遇到一次 subagent 实现了功能但忘了处理边界条件，合并后的 review 只报了代码质量警告，没报 spec 偏差。后来手动补了个断言才暴露。
三、社区的真实声音
Hacker News 上关于 Superpowers 6 的帖子得了 196 分，26 条评论，评价两极分化。我摘了代表性的几类：
✅ 真爱党
「v6 确实是这个框架最好用的版本。我用 Claude Code + Superpowers 写了一个内部工具，整个流程被打磨得很顺，review 的准确度比 v5 高了一截。」—— HN 用户 devops_engineer
⚠️ 中度用户
「速度提升是有的，但 token 消耗依然不低。我主要用它做代码库重构（自动添加测试、重命名），这种场景它确实强。但我不会每个 PR 都用它，仪式感太重。」—— HN 用户 midlevel_coder
❌ 卸载党
「他们从开源到现在一直在吹 token 节省，但每次新版本我都测不出官方说的 60%。而且 v6 的 bootstrap 压缩我感受不明显——因为我每次 session 很短，几个命令就结束了。对我来说，Superpowers 的收益覆盖不了我花在等待和纠正上的时间。」—— HN 用户 tools_hopper
💥 争议点：
- Markdown 商业化：Superpowers 的文档本身是 Markdown 格式的「skill」，但有些用户认为这些技能流于通用，不够针对他们的实际项目。
- 没有 benchmark：官方从未公开一套可复现的基准测试，用户只能凭感觉判断 token 节省幅度。
四、5 个场景的决策清单
以下是我把你的日常开发场景分成 5 类，每类给出具体建议。
场景 1：全新项目起步
推荐：留
新项目没有历史包袱，从目录结构到测试框架都可以适应 Superpowers 的流程。强制 TDD 和 Spec-Driven 在新项目里反而能帮你从一开始就写好架构。
最佳搭档： Claude Code 或 Codex CLI，配合 using-superpowers 指令，一次 session 就能搭起来基础骨架。
场景 2：遗留代码修改
推荐：按需开 TDD
遗留代码通常测试覆盖率低，Superpowers 的强制 TDD 在这类场景里会频繁报错——你没测试它就不让你写代码。你可以手动关闭 TDD 步骤（在 skill 配置里设置 tdd: false），但会失去一大部分价值。建议只对新增模块启用，对旧代码不做严格约束。
场景 3：快速原型 / 验证想法
推荐：不推荐
这是最不适合 Superpowers 的场景。原型阶段你需要的是一步到位写代码看结果，不是等 subagent 分解、写 spec、review。直接用裸写 Claude Code 或 Cursor 的 Composer 模式，快得多。
替代方案： 裸写 Agent。
场景 4：代码库重构（大规模）
推荐：强力推荐
这是 Superpowers 的甜区。自动添加单元测试、重命名跨文件符号、提取公共方法——它能帮你写出一致性很高的重构代码，而且 spec 让你在动手前就知道「要改什么」。我用它重构过一个 200+ 文件的 Python 模块，review 后的修改率不到 5%。
注意： 重构时需要禁用 spec 确认环节（否则每个 task 你都点确认），用 auto_spec_accept: true 加速。
场景 5：团队协作
推荐：谨慎评估
如果你的团队已经有一套 CI/CD + Code Review 流程，Superpowers 的自动 review 会和工作流程重叠，甚至冲突。而且不同成员的 Agent 版本、配置差异可能导致 review 结果不一致。建议只让一两个人作为「超级用户」试用，不要全团队强制。
商业化路径： 企业服务联系 sales@primeradiant.com，正在招社区工程师。
五、替代方案一览
如果你觉得 Superpowers 不适合你的场景，下面几个替代方案值得看：
| 方案 | 适用场景 | 一句话评价 |
|---|---|---|
| 裸写 Claude Code / Codex CLI | 快速原型、小改动 | 无流程负担，最快出活，但缺乏 guardrail。 |
| Compound Engineering Plugin（Every inc.） | 结构化 Agent 开发 | 类似 Superpowers 但更轻量，专注 skill 管理。 |
| Matt Pocock's Skills | TypeScript 专项优化 | 如果你写 TypeScript，这个可能比通用 skill 更好用。 |
| OpenSpec | 只做 Spec-Driven，不做实现 | 如果你只想要 spec 约束，不想被强制 review。 |
你是继续用 Superpowers 还是卸掉，取决于你把「工程纪律」放在多重要的位置。对于需要长期维护的项目，它的规范流程是资产；对于探索性代码，它是负债。
Superpowers 6 不是做得不好，而是它的价值是高度场景化的。与其跟风卸掉或硬留，不如拿着这张清单对照自己手里的项目：你的项目在哪个象限？ta 需要的是工程纪律，还是执行速度？这个问题的答案，才是你该按的按钮。
