夜雨聆风最近半年，AI 编程圈有两个项目增长异常凶猛。
一个叫 Superpowers，GitHub 上 15.9 万 Star。另一个叫 Everything Claude Code，简称 ECC，19.6 万 Star。两个项目加起来，接近 36 万星标——这个数字，放在任何技术领域都足以让人停下来看一看。
但真正有意思的，不是它们有多火。而是它们代表了两种截然不同的 AI 工程化路线。
一种路线说：AI 太会"偷懒"了，必须给它套上缰绳，逼它按规矩来。
另一种路线说：AI 的能力边界还远没有被释放，应该给它配齐装备，让它什么都能干。
你不会以为这两种路线只是"严格"和"灵活"的区别吧。它们背后，是两种完全不同的技术价值观。
今天这篇文章，我们就来拆开这两个项目，看清楚它们分别解决了什么问题，适合什么人，以及——你该怎么选。
图 1：Superpowers vs ECC 核心哲学对比 — 纪律漏斗(紫) vs 全能工具箱(绿)
一、Superpowers：把"纪律"写进代码
先看 Superpowers。
这个项目由 Jesse Vincent 创建，核心定位非常清晰：它是一套强制执行工程纪律的 Skill 系统。
什么意思？
用过 AI 写代码的人都有这种体验：你提一个需求，AI 二话不说就开始写代码。写得飞快，看起来也像模像样。但你仔细一看——没考虑边界条件，没写测试，甚至直接在你的 main 分支上改。这就是所谓的"Vibe Coding"——跟着感觉写代码。
Superpowers 要做的，就是用 14 个 Skill 告诉 AI：不许这么做。
它的架构是三层设计：
图 2：Superpowers 三层架构 — 元技能→流程控制(brainstorming→writing-plans→executing-plans)→质量保障(TDD+调试+验证)
最上层是 using-superpowers，一个"元技能"。它强制 AI 在每次对话开始时，先检查当前任务适用于哪些 Skill。这不是建议——是硬门槛。
中间层是流程控制 Skill：brainstorming 负责需求梳理，writing-plans 负责拆解任务，executing-plans 负责按计划推进。
最底层是质量保障 Skill：test-driven-development 强制先写测试，systematic-debugging 走四阶段根因分析，verification-before-completion 要求做事前先验证。
这三个环，像一个漏斗：想法从上面进来，代码从下面出去。中间每一环都有明确的质量门禁。
它的铁律，是你不舒服的原因
Superpowers 有几个让人"不舒服"的设计：
第一个：没先写失败的测试，就不准写生产代码。如果你先写了实现代码？删掉，从头来过。文档里甚至专门有一章叫"常见借口和为什么它们都是错的"。
第二个：调试必须先做根因分析。AI 遇到 bug 喜欢直接改代码碰运气，Superpowers 不允许。它要求先完成根因调查，再提出假设，验证后才允许修复。
第三个：绝不在 main 分支上直接工作。每个任务都在独立的 Git Worktree 里完成，完成后再合入主分支。
这些规则听起来像新员工的入职培训手册。但事实是：资深工程师之所以资深，不是因为他们更聪明，而是因为他们养成了这些习惯。 Superpowers 做的，就是把好工程师的习惯固化为 AI 的行为准则。
它解决的核心问题
Superpowers 本质上在解决一个悖论：AI 越强，越容易写出"看起来对但实际上有坑"的代码。因为它太能自圆其说了。
所以 Superpowers 的策略是：不追求 AI"更聪明"，而是追求 AI"更可靠"。可靠来自流程，而不是智力。
如果你管理过实习生，你会有同感：一个聪明的实习生可能会写出很酷的代码，但往往不考虑异常处理、不考虑扩展性、不考虑回归影响。你需要花很多时间给他"抠细节"。而一个不那么聪明但纪律好的实习生，虽然写代码慢一点，但出错率低，交付物可预测。
Superpowers 就是在训练 AI 成为后者。
二、ECC：把"全能"装进工具箱
再看 ECC。
这个项目由 affaan-m 创建，最初是 Anthropic 黑客松的获奖项目。经过 10 个月的高强度实战打磨，已经从一个配置集合演化为一个完整的 Agent Harness 性能优化系统。
如果 Superpowers 像一位严格的导师，那 ECC 就像一把瑞士军刀——什么都有，按需取用。
六个维度，各司其职
ECC 的架构是六层：
图 3：ECC 六层架构 — Token优化→记忆持久化→技能匹配→验证循环→AgentShield→并行编排，底部持续学习系统
第一层是 Token 优化。 简单任务用 Sonnet（成本降 60%），复杂架构设计用 Opus。系统提示精简到最少必要指令，砍掉所有"礼貌性废话"。后台进程通过 Hook 管理，避免僵尸进程和 Token 泄漏。
第二层是记忆持久化。 这是 ECC 最特别的地方——它能跨会话记住上下文。每次会话结束时，系统自动提取新模式，更新技能库。下次启动时，历史上下文自动注入。这意味着你用得越久，它越懂你。
第三层是技能匹配。 246 个技能模块，覆盖 TypeScript、Python、Go、Java、Kotlin、C++、Rust、Swift、PHP 等 12 种语言生态。从 Django 模式到 SwiftUI 设计系统，从数据库迁移到视频编辑，几乎覆盖了你能想到的所有开发场景。
第四层是验证循环。 两种模式：Checkpoint Eval 用于不可逆操作（架构决策），Continuous Eval 用于高频迭代（大规模重构）。支持 PassAtK、ExactMatch、SemanticMatch 三种评分器。
第五层是 AgentShield 安全扫描。 1282 个测试用例、102 条静态分析规则。每个 Shell 命令经过净化检查，危险命令（如 rm -rf /）直接拦截。依赖项自动对照 CVE 数据库扫描。甚至支持三个 Opus Agent 同时进行红蓝对抗审计。
第六层是并行编排。 通过 Git Worktree 级联法将大型重构拆分为多个并行工作树。子代理只接收与当前子任务最相关的上下文片段，用语义检索 Top-K 加截断压缩解决上下文稀释问题。
它最大的差异化：持续学习
ECC 有一个独一无二的能力：持续学习系统 v2。
它不是靠人工写 Skill，而是基于置信度评分自动从会话中提取有效模式。相关本能会被聚类为技能。更关键的是，学习成果可以在团队间共享——通过 /instinct-export 导出，/instinct-import 导入。
这意味着一个团队使用 ECC 六个月后，它积累的不是数据，而是集体经验。
它解决的核心问题
ECC 解决的是另一个悖论：AI 很强，但每次对话都从零开始。你昨天教会它的东西，今天它全忘了。你在这个项目里踩过的坑，换个项目又要重新踩一遍。
ECC 的策略是：把 AI 的每一次交互都变成可积累的资产。不是让它"更聪明"，而是让它"不遗忘"。
三、两条路线的根本分歧
到这里，你应该能感觉到这两个项目的本质差异了。
Superpowers 问的问题是：AI 做事太随意了，怎么让它严谨起来？
ECC 问的问题是：AI 能力太单薄了，怎么让它强大起来？
这两个问题的方向是相反的。一个向内收，一个向外扩。
一个类比帮你理解
想象你要教两个人做饭。
第一个人，你的策略是给他一本 14 页的菜谱。每道菜写得很详细：备菜 5 分钟，大火 3 分钟，小火 10 分钟。每一步都有明确的检查点。在他熟练掌握这套流程之前，不允许自由发挥。
第二个人，你的策略是给他一整个厨房。从菜刀到蒸烤箱，从脱水机到真空低温烹饪器。各种厨具一应俱全，他可以根据想做的菜自由组合使用。
第一个人做出来的菜，味道可预期，不会翻车。但菜式有限。
第二个人能做出来的花样多，但要把握火候和搭配，需要自己判断。
Superpowers 是第一个人。ECC 是第二个人。
从数据看差异
14 对 300+，这不是量变，是质变。Superpowers 追求的是"纵深"——把少数几件事做到极致。ECC 追求的是"覆盖面"——让 AI 什么都能干。
图 4：Superpowers vs ECC 七维度数据对比（技能数量 / 设计哲学 / 语言覆盖 / 安全审计）
为什么它们不能简单叠加？
你可能会想：既然一个管纪律、一个管能力，那我把两个都装上不就行了？
问题在于，它们对 AI 的行为假设是矛盾的。
Superpowers 的假设是：AI 会偷懒，所以我要强制它一步一步走。
ECC 的假设是：AI 会遗忘，所以我要帮它记住一切，给它选择自由。
当两个框架同时生效时会发生什么？Superpowers 说"你必须先设计再写代码"，ECC 说"你可以直接调用 planner Agent 快速启动"。AI 会在两个互相矛盾的指令间摇摆不定。
已经有实践者明确指出：不建议同时使用两者。 功能重叠的领域（TDD、审查、验证）只能选一个，否则会出现指令竞争和不可预测的行为。
如果你确实需要两者的能力，正确的做法是：以 Superpowers 为主（控制流程），ECC 为辅（补充语言专项审查、安全扫描、持续学习）。但必须明确分工，禁用 ECC 的 TDD、审查等流程类 Hook，避免冲突。
四、你应该怎么选？
图 5：Superpowers vs ECC 选择决策树 — "AI需要被管教吗？" → 是(Superpowers) vs 否(ECC)
没有绝对的好坏，只有合适不合适。以下是一个自测清单。
选 Superpowers，如果：
你在做严肃的生产级项目，出 bug 的代价很高 你的团队刚引入 AI 编程，需要一个规范的起点 你认同 "先测试后代码" 的 TDD 理念 你需要深度调试能力，而不是碰运气式改代码 你希望 AI 帮你做决策（什么时候该设计、什么时候该审查）
选 ECC，如果：
你的项目涉及多种语言和框架，需要专项优化 你重视成本控制，需要精细的 Token 管理和模型路由 你有一个使用 AI 编程经验丰富的团队，知道什么时候该用什么 你需要安全审计能力，项目对安全性有硬要求 你希望系统越用越懂你，积累团队集体经验
如果你是管理者，看这里：
如果你在管理一个技术团队，正考虑引入这类工具来提升 AI 编程的质量和效率，我的建议是：
对于新团队或项目质量要求高的团队，先上 Superpowers。 它的约束机制能帮团队建立正确的 AI 协作习惯，减少"AI 写的代码看着对但跑不通"这类问题。就像一个严格的导师，先帮你打好基本功。
对于已经熟练使用 AI 编程的团队，选 ECC。 这些人已经知道 AI 的边界在哪，不需要"管教"，需要的是"赋能"。ECC 的 246 个技能和持续学习系统能帮他们突破能力天花板。
如果你想两全其美： 以 Superpowers 为主框架（控制设计→开发→审查→验证→Git 全流程），用 ECC 的选择性模块（语言专项审查、AgentShield 安全扫描、持续学习）作为补充。但要花时间划清职责边界，明确哪些流程由谁主导。
一个简单的决策公式
你是否认同"AI 必须教会它纪律"？ ├── 是 → Superpowers │ └── 补充问题：团队成员是否经验丰富？ │ ├── 是 → 可搭配 ECC 安全/语言模块 │ └── 否 → 单用 Superpowers 即可 └── 否 → ECC └── 补充问题：是否需要深度调试？ ├── 是 → 搭配 Superpowers 的调试技能 └── 否 → 单用 ECC 即可写在最后
图 6：AI编程两阶段进化与路线选择 — 第一阶段(能不能写)→第二阶段(怎么写得好)→靠流程 vs 靠能力
AI 编程工具进入了一个新的阶段。
第一阶段的主题是"能不能写"——AI 能不能帮我们生成代码。这个问题的答案是：能，而且越来越强。
第二阶段的主题是"怎么写得好"——AI 生成的代码，怎么保证质量？怎么避免明显的坑？怎么让它遵循工程规范？
Superpowers 和 ECC 代表了两种回答。一个说"靠流程"，一个说"靠能力"。它们不是对错之争，而是路线选择。
我的判断是：在 AI 编程的早期，约束比自由更重要。 当 AI 还不理解什么是"好代码"的时候，给它一套清晰的行为规范，比给它一百个能力选择更有价值。这就是 Superpowers 的护城河。
但当 AI 变得越来越聪明，越来越懂得工程上下文，ECC 的"全能工具箱"路线会越来越有优势——因为到了那一天，纪律已经内化为 AI 的能力，真正拉开差距的，是它能覆盖多少场景，能记住多少经验，能在多大程度上替代人的判断。
选择哪个，取决于你现在站在哪个路口。
但不管你选哪个，都别什么都不选。裸用 Claude Code 或 Cursor，就像让一个聪明但没有受过训练的实习生直接写生产代码——他能写出来，但你会为每一次"差不多"付出代价。
