三个 Claude Code 技能框架的验尸报告：superpowers、gstack、ECC，到底该装哪个

先约定一件事：这篇文章不替你做决定

过去半年，GitHub 上每隔几周就会冒出一个“让 Claude Code 脱胎换骨”的技能框架。它们的 README 长得都差不多：几万到二十万 star，一句 /plugin marketplace add，然后是“100x 生产力”“god mode”“像一支完整的工程团队”。

在往下读之前，请先把这些词全部划掉。

因为它们没有一个能回答真正重要的问题：装上它之后，你的 agent 会做出什么不同的动作？把它删掉，动作会变回去吗？ 如果答案是“不会改变”，那这个技能就是一件装饰品——它进了上下文窗口，吃掉了 token，却没有改变任何结果。

这篇文章会解剖三个最热门的框架：Jesse Vincent（GitHub 用户名 obra）的 superpowers、Y Combinator CEO Garry Tan 的 gstack、affaan-m 的 Everything Claude Code（简称 ECC）。但它不会给出一个无条件的“最佳答案”。原因是验尸官的一条核心戒律：没有绝对的好技能，只有契合或不契合某种工作流的技能。 给单人学习者的好技能，可能毁掉团队协作；反之亦然。

所以在动刀之前，请先认领你自己属于哪一种工作流——后面所有的判决，都会按这四种分别给出：

• 单人快速迭代：你自己写、自己改，速度优先，容忍混乱。
• 团队协作交付：多人协作，一致性和可审查性优先。
• 遗留系统重构：在别人留下的烂摊子上动刀，安全网优先。
• 新手学习：你在学，要的是被纠正、被拦住走捷径。

记住你是哪一种。读到判决那一节，你只需要看属于自己的那一行。

一个必须先讲清楚的技术前提：技能不是免费的

在评判任何技能之前，得先理解一件事——技能会一直待在上下文里。

根据 Anthropic 官方的 Claude Code 文档，当你或 Claude 调用一个技能时，SKILL.md 渲染后的全文会作为一条消息进入对话，并且在整个会话期间一直留着。Claude Code 不会在后续轮次重新读取这个文件；它就那么占着位置。文档里有一句话说得很直白：技能一旦加载，它的内容会跨轮次留在上下文里，所以每一行都是一笔反复发生的 token 成本。

这意味着技能框架有两层成本。第一层是启动成本：所有已安装技能的 frontmatter 描述（那段决定“这个技能何时该出现”的元数据）在会话一开始就全部加载，好让 Claude 知道有哪些技能可用。第二层是触发成本：某个技能真正被调用时，它的完整正文涌入上下文。

请记住这个框架，因为它会直接决定下面三个仓库的命运。一个有 14 个技能的框架和一个有 180 个技能的框架，在你还没开始干活之前，占用的上下文就已经差了一个数量级。这不是细节，这是生死线。

解剖一：superpowers —— 唯一一个真的在说“不要”的框架

它的形状

superpowers 的设计哲学，可以用它自己一个技能里的话来概括——它要求 Claude 遵循“1% 规则”：哪怕只有 1% 的可能性某个技能适用，也要去调用它。 这是一种偏执，但是一种有方向的偏执。

它的工作流是一条链：头脑风暴（brainstorming）→ 建 git worktree → 写计划（writing-plans）→ 派子 agent 做 TDD → 请求代码审查 → 完成前验证 → 收尾分支。整条链一共大约 14 个技能，由一个很小的启动钩子（据报告约 2000 token）引导，技能正文按需加载。

它的禁令——这是关键

这里要引入一个判断技能强弱的核心标准。弱技能只会罗列“最佳实践”；强技能会拦截近路。两者的区别不是语气，而是：违规时，它会不会真的拦住你？

superpowers 的强，强在它把约束写成了可执行的硬门槛，而不是口号。从 SKILL.md 原文里摘三条最有代表性的：

第一条，来自 test-driven-development 技能，它称之为“铁律”：没有失败的测试，就没有生产代码；在测试之前写了代码，就删掉、重新开始。请注意这句话的形状——它不是“建议你先写测试”，它是“删掉重来”。更重要的是，这条规则附带一个验证动作：你必须亲眼看着测试失败，因为如果你没看着它失败，你就不知道它测的是不是对的东西。这是一条连非 AI 的脚本也能在 CI 里检查的规则：那个实现的提交之前，有没有一个失败的测试提交？

第二条，来自 verification-before-completion 技能：没有新鲜的验证证据，就不能宣称完成；如果你在这条消息里没有运行过验证命令，你就不能说它通过了。它把“声称完成”这件事拆成了一个五步函数：识别命令、运行、读输出、核对、带着证据陈述。这拦截的是大语言模型最常见的失败模式之一——嘴上说“已修复、测试通过”，其实根本没跑。

第三条，来自 brainstorming 技能：在你提出设计、并且用户批准之前，不要写任何代码、不要搭任何脚手架；这适用于每一个项目，无论它看起来多简单。

这三条有一个共同点：它们都在拦一条具体的近路，而且拦截点可以被客观验证。这就是强技能和弱技能的分界线，后面评判另外两个框架时，我们会反复用到这把尺子。

它诚实吗

非常诚实——诚实到值得单独加分。

Jesse Vincent 在自己的博客上公开记录过一次失败。superpowers 早期版本的头脑风暴技能，用的是“描述性”语言，大意是“请用 200 到 300 字一段来呈现设计”。结果呢？Claude 调用了这个技能，然后把它无视了——直接跑去调用前端设计工具、直接 npm create vite。只有当作者把这些描述性语句改写成带“硬门槛”标记的强制清单之后，Claude 才真的开始照着做。

这件事值得停下来想一想，因为它揭示了一个反直觉的真相：对一个大语言模型来说，礼貌的措辞约等于没有约束。 它会把“建议”合理化掉。只有当你把规则写成它无法绕过的门，门才有用。这也是为什么 superpowers 的作者敢公开这次失败——它本身就是框架“硬门槛”哲学最好的证据。

仓库里也能看到真实的 bug：issue #565 记录过头脑风暴技能跳过用户审查门的回归，issue #1077 记录过技能把一个 Skill 错当成 Agent 类型来派发。作者没有藏这些。

真实开发者怎么说

独立用户的评价整体正面。Simon Willison 称 Vincent 是“我认识的对编码 agent 最有创造力的使用者之一”，并特别点出它的 token 效率——一个完整项目据报告只用了约 10 万 token。多位开发者在 Hacker News 上确认，TDD 技能真的会用字面意义上的“删掉，重新开始”拒绝预先写好的代码。

但批评也存在，而且很对：Hacker News 上有人一针见血地说，看起来挺可爱，但没有基准测试，最终价值有限。这句话适用于本文的全部三个框架，文末会再回到它。

解剖二：gstack —— 一套角色扮演，不是一套门禁

它的形状

gstack 是 Garry Tan 把自己的 Claude Code 配置原样开源出来的产物——大约 23 个核心斜杠命令技能，外加约 12 个“power tools”。它的卖点是把 Claude 变成一个虚拟公司：CEO、设计师、工程经理、发布经理、文档工程师、QA。

这里要立刻做一个区分，它是理解 gstack 的钥匙。superpowers 的技能是门禁，gstack 的技能大多是人格提示词加检查清单。/plan-ceo-review（CEO 视角的战略挑战）、/plan-eng-review（工程评审）、/office-hours（YC 式产品拷问）——这些技能很会问尖锐的问题，逼你想清楚，但它们设的可执行硬门槛非常少。

公平地说，gstack 不是完全没有门。/investigate 技能有一条铁律，大意是“修症状会制造打地鼠式的调试”，并且有一个和 superpowers 同款的“三振出局”规则。/plan-ceo-review 要求“绝不静默地默认选择某个选项”。但整体而言，gstack 的约束力来自“它会逼你回答 20 到 45 个问题”，而不是“它会在你违规时拦住你”。用上一节那把尺子量：gstack 的禁令大多是口号式的，不是可验证的。

几个对协作来说危险的设计

gstack 里有些技能会自动改代码、自动提交。这个特性的好坏，完全取决于读者的工作流——这正是“没有绝对的好技能”那条戒律的活例子。

/review 技能（staff 工程师模式）会自动修复“机械性问题”——死代码、过时注释、N+1 查询——并打上“已自动修复”的标记。/qa 技能会在源码里直接应用修复、做原子提交、自动生成回归测试。对一个单人开发者，这是省事；但设想一下多人场景：一位同事在共享分支上跑了 /qa，Claude 自动提交了一批“修复”，绕过了团队的代码审查流程。同一个功能，在一种工作流里是便利，在另一种里是隐患。

更值得警惕的是几个静默失败。GitHub issue #1196 记录，/codex（调用 Codex CLI 做第二意见审查）会同时传入互斥的参数，导致 Codex CLI 报错——而 Claude 看到一个非零退出码、没有模型输出，就默默跳过了审查那一环继续往下走。issue #1248 更刺眼：有用户报告，跑了大约 5 次图像生成（约 0.5 美元的 API 调用）之后才发现，费用被记到了项目目录 .env 里的那个 OpenAI 账户，而不是他给 gstack 配的账户。静默失败的危险在于：没有人会知道那一步根本没发生。

它诚实吗

gstack 的问题不在隐瞒 bug，而在它的营销姿态。Tan 在 README 里写，他 2026 年的代码产出速度是 2013 年的约 810 倍。这个数字引发了相当尖锐的公开批评。开发者 Mo Bitar 做了一期视频《AI 正在让 CEO 们变得妄想》，据 TechCrunch 报道 48 小时内 80 万播放，他的判断是 gstack 本质上就是一堆放在文本文件里的提示词。一位创始人对那条“god mode” CTO 背书的反应是：如果那是真的，那个 CTO 应该立刻被开除。一篇深度复盘的标题直接是《每天一万行代码是危险信号，不是功能》。

引用这些不是为了嘲笑 gstack——它的工程并不差。引用是因为验尸官的另一条戒律：star 数是社交现象，契合度是工程现象，永远分开记。 gstack 的传播力，有相当一部分来自作者是 YC 的 CEO，而不是来自技能本身的约束力。Product Hunt 上有一条评论说得很坦白：Garry，实话实说，如果你不是 YC 的 CEO，这东西不会出现在 Product Hunt 上。

解剖三：Everything Claude Code —— 一个目录，不是一套方法论

它的形状

ECC 最难评判，因为它不是一个有明确工作流的框架，而是一个目录——一个不断膨胀的技能合集。不同来源引用的数字不一样：有的说 119 个技能，有的说 182 个，较新的说 231 个。无论取哪个数，这都是一个比 superpowers 大十倍以上的集合。

它最致命的问题：上下文税

现在回到本文开头那个技术前提。ECC 大约有 180 个技能，每个技能的 frontmatter 描述就算只占 100 到 200 token，光是这些元数据，在你还没调用任何一个技能之前，就已经吃掉 18000 到 36000 token。

这不是推断出来的指控——ECC 自己的 README 在 FAQ 里就承认了。它写道：太多的 MCP 服务器会吃掉你的上下文，每个工具描述都从你的 20 万窗口里扣 token，可能把它压缩到约 7 万。ECC 因此专门做了一堆“灭活开关”，比如 --profile minimal、ECC_DISABLED_HOOKS、ECC_SESSION_START_CONTEXT=off。一个框架需要给自己配这么多关闭开关，本身就说明默认安装太重了。

它的安装是个陷阱

这里有一个对多人协作尤其要命的问题。Claude Code 的插件系统无法分发 rules（规则文件）——这是一个上游限制。ECC 的 README 自己警告：不要叠加安装方式；最常见的损坏配置就是先 /plugin install 再跑 install.sh --profile full，这会产生重复技能和重复钩子执行。

把这个翻译成多人语言：如果一个团队通过插件安装 ECC，每个人拿到的规则集可能是不一样的。一个成员的机器行为和 CI 不一致——这正是协作交付最怕的事。ECC 的 README 坦率承认它经历过反复的“修了又退、退了又修”的钩子回归循环，并点名了 issue #29、#52、#103。

它最诚实、也最伤的一句话

ECC 里有一个叫 continuous-learning 的技能，它的 v1 版本在 SKILL.md 里这样自我批评：v1 依赖技能去做观察，而技能是概率性的——它们大约 50% 到 80% 的时间会触发；所以 v2 改用钩子来做观察，因为钩子是 100% 可靠的。

这是整个 ECC 仓库里最诚实、也最重要的一句话。它等于承认：技能不是确定性的控制流，它是一个概率性的提示。 这个事实对不同工作流的含义完全不同——对一个追求交付一致性的团队，“这个约束有 20% 到 50% 的概率不生效”是灾难；但对一个单人探索者，这或许只是偶尔需要手动重来一次的小麻烦。同一个事实，不同的判决。

它也有亮点

不要把 ECC 一棍子打死。它里面有两个技能，单独拎出来是真的好。

tdd-workflow 在严格度上不输 superpowers 的 TDD，而且多了一条很聪明的规则——它要求验证“检查点”的提交必须从当前分支的 HEAD 可达，不能把其他分支、或无关的历史提交当成有效的检查点证据。这条规则在 CI 里很有用。

eval-harness 则是三个框架里独一份的东西——它做的是“评估驱动开发”：在写代码之前先定义 evals，用 pass@k 这样的指标来定义成功，比如能力评估要 pass@3 超过 90%，回归评估要 pass^3 等于 100%。如果你在做 AI 相关的功能，这个技能没有替代品。

七维评分：把三具尸体并排放

下面这张表，是用七个维度给三个框架打的分（0 到 5 分）。需要特别说明的是，这张表是按“团队协作交付”这一种工作流加权的——这是验尸官最初接到的委托场景，所以拿它当样板。如果你属于另外三种工作流，分数的相对高低会变化；具体怎么变，看紧接其后的判决一节。

几句话解释这些数字。superpowers 在“行为增量”上拿 4 分，是因为它的作者真的做过技能开关的受控对比；其他两家只有自我报告的总量指标，没有对照实验。gstack 在“禁令密度”上只有 2 分，因为它的技能大多是逼问式的清单，而非可执行的门。ECC 在“上下文税”上只有 1 分，因为它自己承认了那个“压缩到 7 万”的问题。

判决：四种工作流，四个不同的答案

验尸官的规矩是：判决必须是条件句，不能是无条件的“好/不好”。所以这里不给“冠军”，只给四张对号入座的处方。请只读属于你自己的那一段。

如果你是团队协作交付，以 superpowers 为骨架，从另外两个里挑零件。它的硬门槛可以在 CI 里被验证（实现提交之前有没有失败的测试？最新这条消息里有没有跑验证命令？），它的产物——计划文件、设计文档、worktree——是会留下来、可被审查的。可以从 ECC 里单独挑 tdd-workflow 和 eval-harness，但不要整包安装 ECC，它的上下文税与共享预算冲突；从 gstack 里最多挑 /codex 和 /retro，并且避开共享分支上带自动修复的 /review 和 /qa。

如果你是单人快速迭代，判决会翻转。superpowers 那条“1% 规则”和强制头脑风暴门，会变成拖慢你的脚镣；gstack 那种“角色扮演式快速推进、自动修复、自动提交”的形状反而最顺手——因为没有同事会被你的自动提交波及，自动化的便利这时是纯收益。gstack 是为这种工作流量身设计的。

如果你在做遗留系统重构，优先考虑 superpowers 的 systematic-debugging（四阶段根因分析加三振出局）和 verification-before-completion——重构最怕的是“以为修好了其实没有”，而这两个技能正是安全网。可以补上 ECC 的 tdd-workflow，它那条“检查点提交必须可达”的规则，在历史混乱的老仓库里特别值钱。要远离 gstack 的自动修复类技能：在一个你还不完全理解的代码库上让 agent 自动改、自动提交，是在制造新的考古层。

如果你是新手学习，superpowers 反而可能是最好的——但理由和团队场景不同。它的价值在于，那些硬门槛会反复拦住你走捷径，而被拦住正是学习发生的地方。它逼你先写失败的测试、先出设计再写代码、跑了验证命令才能说“完成”。ECC 作为一本“技能参考书”也有用，你可以一个个翻看 SKILL.md 学别人怎么写技能，但别整包安装它来日常使用。gstack 对新手的风险是：它的自动化会替你把活干了，你看到结果，却学不到过程。

最后，有一条规矩对所有工作流都成立，值得单独记住：任何你打算装进共享环境的技能，它的核心禁令必须能被一个非 AI 的脚本验证（退出码、文件内容、git log 检查）；只靠口号的技能，在 CI 里根本无法被强制执行。

一段可以脱离全文独立转发的总结

如果你只想记住一段话，记这段：

这三个框架卖的不是同一种东西。superpowers 卖的是纪律——它用可执行的硬门槛拦住 agent 走捷径，代价是 token 开销和偶尔的过度触发。gstack 卖的是速度感——它把 Claude 装扮成一支虚拟公司，逼你回答尖锐的产品问题，它的形状是为单人创始人优化的。ECC 卖的是全——一个 180 多个技能的目录，里面有真正的好东西，但整包安装会在你开工之前就吃掉三分之一的上下文。哪个“最好”，取决于你是单人迭代、团队交付、遗留重构，还是在学习——这四种工作流要的东西互相冲突，没有通用答案。

而贯穿这三者、最值得带走的一课是：对一个大语言模型来说，礼貌的“建议”约等于没有约束。 Jesse Vincent 那次公开的失败实验证明了——技能里写“请用 200 到 300 字呈现设计”，Claude 会礼貌地把它合理化掉；只有写成它无法绕过的硬门槛，门才真的是门。所以下次评判任何一个技能时，别读它的形容词，读它的禁令：它有没有拦住一条具体的近路？那道拦截能不能被一个脚本验证？如果两个答案都是否，那它就是一件装饰品，无论它有多少个 star。

几句必要的免责声明

这三个框架没有一个有受控基准测试。所有量化说法——10 万 token 一个项目、每天上万行代码、“3 到 4 倍加速”“85% 到 95% 覆盖率”——都是从业者的自我报告，不是测量出来的对照试验。Hacker News 上“没有基准测试就价值有限”的批评，对三家都成立。

这些仓库变化非常快。star 数、issue 编号、SKILL.md 的行数都会漂移；如果你的流程依赖某个具体行为，请锁定一个 commit 再验证。

技能这个抽象本身也很新。Anthropic 的技能标准 2025 年 10 月才推出，“技能正文一直留在上下文”这个行为在不同 Claude Code 版本之间至少变过一次。所以请把这篇文章当成一份思考方法，而不是一份永久结论——它教你的是怎么解剖一个技能（读禁令、量上下文税、分清传播力和契合度），而不是替你记住三个仓库今天的状态。方法不会过期，结论会。