三个工具单拎都很猛，拼在一起才是完全体

摘要：Spec-Kit、Superpowers、ECC 是 Claude Code 生态里 Star 最多的三个工具，多数人只用一两个。本文拆解了它们分别对应治理、执行、工具三个层面，缺任意一层就漏------两两组合各有短板。附带新需求开发和 Bug 修复两条完整流水线、三条铁律、安装踩坑记录，以及三件套同开与单开的 token 消耗取舍分析。

GitHub 上 Claude Code 生态里 Star 最猛的三个工具，我盯了大半年。Spec-Kit 10万+，Superpowers 20万，ECC 也快20万------三个加起来快五十万 Star。但有意思的是，我翻了大量讨论帖和教程，绝大多数人只用其中一个，顶多两个。

我自己把三个都拆开研究了一遍，写了最佳实践指南之后，发现一件事：这三个工具不是竞品，压根不在一个层面上。Spec-Kit 管的是"做什么"，Superpowers 管的是"怎么做"，ECC 管的是"用什么做"。刚好三层，缺一层就漏。

这篇不讲安装教程（命令文末有），讲的是我把三个拼在一起之后，为什么觉得这才是完全体。

三个工具，三个层面

先说 Spec-Kit。

GitHub 官方出品（github/spec-kit），截至2026年6月 Star 数 109K+（来源：github.com/github/spec-kit，2026年5月官方通讯称"100,000+ stars"，6月媒体报道109K）。这个工具干的事一句话能说清：给项目立法。

核心产物是四个文件------CONSTITUTION.md（项目宪法）、spec.md（功能规格）、plan.md（技术方案）、tasks.md（任务清单）。看着像需求文档？不完全是。CONSTITUTION.md 不是给人写的，是给 AI 写的------它定义"这个项目里 AI 应该遵循什么规矩"：技术栈选型、编码规范、架构约束、禁止行为。AI 每次动手之前先读这个文件，就知道边界在哪。

我的理解是，Spec-Kit 解决的是"AI 不知道你的项目是什么"的问题。你给 Claude Code 一个需求，它默认按通用最佳实践来。但你的项目有自己的约定------不用 Lombok、Controller 层不直接返回实体、必须用 Result 包装。这些约定散在团队成员脑子里，AI 不知道。CONSTITUTION.md 就是把这些约定固化成 AI 能读的规则。

再说 Superpowers。

第三方作品（obra/superpowers），Star 数约20万（来源：github.com/obra/superpowers，2026年5月媒体报道198,582 stars）。干的事也一句话：强制流程纪律。

核心是 TDD 铁律加一套7阶段工作流：brainstorm → plan → TDD → subagent → review（两轮）→ finalize。还配了 Git Worktree 做隔离------每个任务在独立 worktree 里干，互不干扰。

我对 Superpowers 的判断是：它不让你走捷径。很多人用 AI 写代码的流程是"提需求→AI生成→看看能跑→提交"。Superpowers 把这条路堵死了------没有先写失败测试，不允许写实现代码；没有通过安全扫描，不允许提交。听着烦？确实烦。但 AI 生成的代码最大的问题不是跑不起来，而是"跑起来了但你不知道为什么"。TDD 强制你先想清楚预期行为，再用测试锚定它。

最后是 ECC。

affaan-m/ECC（原名 everything-claude-code），Star 数也约20万（来源：github.com/affaan-m/ECC，2026年6月媒体报道"近20万Star"）。注意这个仓库地址变了------之前是 affaan-m/everything-claude-code，现在改成了 affaan-m/ECC，安装方式也变了，后面说。

ECC 干的事是：提供弹药库。48个 Agent、182个 Skill、AgentShield 安全扫描（102条规则），外加一个持续学习系统。你可以理解为 Claude Code 的"应用商店"------预置了大量场景化的 Agent 和 Skill，不用自己从零写提示词。

为什么是三个，不是两个

这是我最想说的部分。

很多人觉得装两个就够了。我试过各种两两组合，结论是：缺哪个都漏。

只用 Superpowers + Spec-Kit------流程有了，规矩有了，但缺工具。需要安全扫描、需要特定场景的 Agent、需要复用别人写好的 Skill------它俩都不提供。你得自己写，或者手动找。实现效率低不说，还容易写出质量参差不齐的提示词。

只用 Superpowers + ECC------流程和工具都有了，但没有宪法。AI 知道怎么做（Superpowers 管流程），也知道用什么做（ECC 供工具），但它不知道你的项目有什么特殊约定。生成的代码可能"技术上正确但不符合项目规范"------你项目要求用 MyBatis-Plus，AI 给你用了 JPA。跑得起来，但不符合团队约定。

只用 Spec-Kit + ECC------规矩和工具都有了，但没有流程强制。AI 读了宪法，知道该用什么规范，也调用了 ECC 的工具------但它可能跳过 TDD 直接写实现，也可能不做安全扫描就提交代码。人都有偷懒的时候，何况 AI。没有流程强制，质量门禁就是摆设。

一张图说清楚：

arduino 复制代码

┌──────────────────────────────────────────────────────────┐
│                    完整开发体系                            │
│                                                          │
│  ┌────────────┐    ┌──────────────┐    ┌───────────┐     │
│  │  Spec-Kit  │    │ Superpowers  │    │    ECC    │     │
│  │  L1 治理层  │───▶│  L2 执行层    │───▶│ L3 工具层  │     │
│  │            │    │              │    │           │     │
│  │ 定规矩      │    │ 管流程        │    │ 供弹药     │     │
│  │            │    │              │    │           │     │
│  │CONSTITUTION│    │ TDD铁律       │    │ 48 Agents │     │
│  │ spec.md    │    │ 7阶段工作流    │    │ 182 Skills│     │
│  │ plan.md    │    │ Git Worktree │    │ AgentShield│    │
│  │ tasks.md   │    │ 双轮Review    │    │ 持续学习   │     │
│  └────────────┘    └──────────────┘    └───────────┘     │
│     "做什么"           "怎么做"           "用什么做"        │
└──────────────────────────────────────────────────────────┘

缺任意一层：
  缺L1 → AI 不知道项目规范，代码能跑但不合规
  缺L2 → 没有流程强制，TDD和质量门禁形同虚设
  缺L3 → 缺工具和安全扫描，什么都得自己造轮子

核心公式就一句：Spec-Kit 定规矩 → Superpowers 管流程 → ECC 供弹药。

拼在一起怎么用

不讲四个场景全写（那变成文档了），挑两个最典型的，按流水线的节奏走一遍------每一步谁上场、干什么、交接给谁，一步步说。

新需求开发：审计日志模块

产品提了个需求：给系统加操作审计日志模块，记录所有关键操作的执行人、时间、参数、结果。

拿这个需求走一遍三件套流水线。

第 1 步｜Spec-Kit 立法 + 需求澄清

Spec-Kit 先上场。它先读 CONSTITUTION.md------如果宪法里写了"所有数据访问通过 MyBatis-Plus"和"Controller 层返回 Result 包装"，这些约束会贯穿后面所有步骤，不用你反复纠正。

bash 复制代码

specify init . --ai claude
specify new "操作审计日志模块"

命令跑完，Spec-Kit 引导你走需求澄清：审计日志记哪些操作？同步写还是异步写？要不要加密存储？存多久？澄清完产出三个文件------spec.md（功能规格）、plan.md（技术方案，比如用 AOP 切面拦截还是手动调用）、tasks.md（任务清单，拆成"建表→写切面→写查询接口→写单元测试"）。

这步的核心不是文档本身，是把 AI 的默认行为对齐到项目约定。我之前在 RBAC 项目里踩过------没写宪法，AI 默认用 JPA，来回改了三遍。

第 2 步｜Superpowers 接管，brainstorm 阶段

Spec-Kit 的任务清单交给 Superpowers，它不急着写代码，先进 brainstorm。这个阶段它会追问需求边界："审计日志的查询要不要分页？""敏感参数怎么脱敏？""并发写入会不会冲突？"------这些问题 Spec-Kit 阶段可能没覆盖到，brainstorm 补这一刀。

brainstorm 的产出是一份确认过的需求边界文档，后面 plan 和 TDD 都基于它。

第 3 步｜Superpowers plan 阶段

brainstorm 确认完边界，进入 plan。Superpowers 把 tasks.md 里的任务再拆细，排执行顺序，标注哪些可以并行、哪些必须串行。比如建表和写切面可以并行，但查询接口依赖切面完成，必须排后面。

第 4 步｜Superpowers TDD------先写失败测试（红灯）

重头戏来了。Superpowers 的铁律：没有失败测试，不准写实现。先写测试：

java 复制代码

@Test
void shouldRecordAuditLogWhenUserCreatesEntity() {
    auditService.logAction(userId, "CREATE", entity);
    assertThat(auditLogRepository.count()).isEqualTo(1);
}

跑一遍，红灯------AuditService 还没实现。这一步看着多余，但它是锚点：后面所有实现代码的目标就是让这个测试变绿。没有锚点，AI 生成的代码"能跑"但"不知道对不对"。

第 5 步｜ECC 介入------调用工具辅助实现

测试红了，开始写实现。这步 ECC 上场------需要安全审计检查，ECC 预置的 AgentShield 能扫；182 个 Skill 里如果有现成的日志框架集成 Skill（比如 Logback 配置模板、AOP 切面模板），直接调用，省得从零写提示词。

ECC 在这步的角色是"弹药供应商"------Superpowers 管的是"必须先写测试再写实现"这个纪律，ECC 管的是"实现的时候用什么工具最快最好"。

第 6 步｜TDD 循环------写实现，让测试变绿

实现代码写完，跑测试。绿了进下一步，没绿继续改。Superpowers 强制你在这个循环里待着，不允许跳出去写别的功能。

第 7 步｜Superpowers review 第一轮------代码审查

测试全绿，进第一轮 review。Superpowers 自动检查代码风格、命名规范、是否符合 CONSTITUTION.md 的约束。有问题打回，回第 6 步改。

第 8 步｜ECC AgentShield 安全扫描

第一轮 review 过了，ECC 接手跑安全扫描。102 条规则覆盖 OWASP Top 10------SQL 注入、硬编码密钥、敏感信息泄露这些 AI 高发问题。发现问题打回修，没问题进下一步。

第 9 步｜Superpowers review 第二轮------最终审查

第二轮 review 是最终把关，确认代码质量、测试覆盖、安全扫描全部通过。这轮过了就可以提交了。

第 10 步｜Superpowers finalize------归档收工

提交代码，清理 worktree，归档任务。整个流水线走完，三个工具各管一段：

scss 复制代码

需求 ──→ Spec-Kit ──→ Superpowers ──→ ECC ──→ Superpowers ──→ 交付
         立法+澄清     brainstorm      工具      review×2+finalize
                      plan            供应
                      TDD(红→绿)

没有重叠，也没有空白。Spec-Kit 管"做什么"和"按什么规矩做"，Superpowers 管"怎么一步步做"，ECC 管"做的时候用什么工具"。10 步走完，从需求到交付一条线，每一步都有明确的输入和输出，每一步都有工具兜底。

Bug 修复：并发提交重复记录

线上报了个 Bug：用户并发提交，审计日志记了两条。同样走流水线，节奏一样，但步骤精简一些。

第 1 步｜Spec-Kit 记录 Bug 规格

Spec-Kit 先上场，把 Bug 写进 spec.md 的 BugDelta------复现步骤、预期行为（记一条）、实际行为（记了两条）。这步看着多余，但它逼你把 Bug 描述清楚，而不是凭感觉让 AI 去修。描述不清楚的 Bug，修了也是碰运气。

第 2 步｜Superpowers 根因分析（4 阶段）

Superpowers 接手，不急着改代码，先走 4 阶段根因分析：为什么并发会重复？是没加锁？锁的粒度不对？还是根本没有幂等性控制？分析完定位到根因------提交接口没有幂等性控制，两个请求同时进来，各写了一条。

第 3 步｜Superpowers TDD------写复现测试（红灯）

根因找到了，先写复现测试：

java 复制代码

@Test
void shouldNotDuplicateWhenConcurrentSubmit() throws Exception {
    // 两线程同时提交相同请求
    assertThat(auditLogRepository.count()).isEqualTo(1);
}

跑一遍，红灯------Bug 复现成功。这个测试的意义在于：修复之后它必须变绿，以后回归测试也不会让这个 Bug 再冒出来。

第 4 步｜写修复代码（变绿）

根据根因写修复方案------加幂等性控制。代码写完跑测试，变绿。

第 5 步｜ECC 安全扫描 + 回归测试

ECC 接手，跑安全扫描确认修复没引入新安全问题，再跑全量回归测试确认没搞坏别的功能。

第 6 步｜知识沉淀

最后一步是 ECC 独有的------把 Bug 根因和修复方案记到持续学习系统里。下次类似场景，AI 能自动规避，不用再踩一遍。

markdown 复制代码

Bug ──→ Spec-Kit ──→ Superpowers ──→ Superpowers ──→ ECC ──→ ECC
        记录规格      根因分析         TDD复现+修复    安全+回归  知识沉淀

Bug 修复的流水线比新需求短，但结构一样------Spec-Kit 先定性，Superpowers 管分析和修复的纪律，ECC 管安全和知识沉淀。区别在于 Bug 修复多了"根因分析"这一步，少了"brainstorm"和"plan"------因为需求是明确的（修 Bug），不需要澄清。

三条铁律

用了一段时间之后，我总结出三条不能破的铁律。

宪法优先。 任何代码变更前，AI 必须先读 CONSTITUTION.md。这不是形式主义------AI 的默认行为是按通用最佳实践走，但你的项目有自己的约定。不读宪法，它就不知道你的约定。Spec-Kit 的 specify 命令创建规格时会自动引用宪法，但你要确保宪法文件一直在维护，不是写完就忘了。

TDD 强制。 没有先写失败测试，不允许写任何实现代码。这条最容易被破------因为 AI 写代码太快了，你看着它生成一堆代码，觉得"能跑就行"，就懒得先写测试。但"能跑"和"正确"之间差着一个 TDD 的距离。Superpowers 的工作流强制了这一点，你要做的是别手动跳过它。

安全必扫。 任何提交前，必须通过 ECC AgentShield 安全扫描。102条规则覆盖了 OWASP Top 10 和常见的注入、越权、敏感信息泄露。AI 生成的代码里 SQL 注入和硬编码密钥是高发问题，安全扫描能兜底。

装的时候注意几个事

安装命令贴一下，顺便说几个踩过的坑：

bash 复制代码

# Spec-Kit（依赖 uv，需要 Python 环境）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init . --ai claude

# Superpowers
npx skills add obra/superpowers

# ECC（别再 git clone 了，方式变了）
npm install -g ecc-universal
# 或在 Claude Code 中用插件 slug: ecc@ecc

ECC 的安装方式变过。老教程会让你 git clone affaan-m/everything-claude-code，现在仓库改名了（affaan-m/ECC），官方推荐用 npm 包 ecc-universal 或者插件 slug 安装。照着老教程操作，会 clone 到一个不存在的地址。

Spec-Kit 依赖 uv（Python 包管理器），没装过得先装。如果你主力语言是 Java，机器上可能没有 Python 环境，得提前准备好。这个不算坑，但容易被忽略。

Superpowers 安装最省心，一条 npx 搞定。但装完之后它会在项目里创建 .claude/ 目录，放 skill 定义文件。如果 .gitignore 把这个目录排除了，记得调整------这些文件要提交，团队成员要共享。

什么时候上三件套，什么时候别折腾

说了这么多好处，也得泼盆冷水。三件套不是所有项目都值得上。

值得上的场景：团队项目，多人协作，有明确的技术规范和编码约定。新项目从零开始，或者历史项目准备做规范化改造。核心业务系统，对代码质量和安全性有要求。这些场景下，三件套的前期配置成本能被后续的效率提升和安全保障覆盖。

别折腾的场景：一个人写的脚本工具、原型验证、hackathon 项目。这些场景你花在配置三件套上的时间比写代码还多。AI 直接生成代码，能跑就行，不需要 TDD、不需要安全扫描、不需要项目宪法。杀鸡不用牛刀。

还有一种中间状态：项目不大但想试试。我的建议是先上 Spec-Kit + Superpowers，不装 ECC。规矩和流程有了，工具后面再加。ECC 的 48个 Agent 和 182个 Skill 需要时间去了解和筛选，初期全装上反而信息过载。

最后

三个工具单拎出来都很强，但它们真正的价值在于拼在一起形成的闭环：Spec-Kit 定义边界，Superpowers 守住底线，ECC 提供火力。缺了任何一层，闭环就断了。

这不是什么高深的理论，就是一个分工问题------治理、执行、工具，各管一段。只不过在 AI 辅助开发的语境下，这三层刚好被三个工具分别覆盖了。

前几篇讲了怎么给 Claude 定规则（CLAUDE.md 写法），也讲了 AI 辅助开发的工程体系（规则分层 L1/L2/L3），这篇算是落到工具层面------具体怎么用三个工具把那套体系跑起来。

有个现实问题得说一句：三个工具一起开，token 消耗是会涨的。Spec-Kit 每次创建规格要往上下文塞 CONSTITUTION.md 全文；Superpowers 的7阶段流程每一步都有前置检查和后置校验，一来一回都是上下文；ECC 那 48 个 Agent 和 182 个 Skill 的描述文件本身也占 token，哪怕你没全用。三层叠加，一个中等复杂度的功能从需求到交付，上下文膨胀是肉眼可见的------我体感比裸用 Claude Code 多出 30% 到 50% 的 token 量，具体数字取决于功能复杂度和宪法文件的大小。

那单个工具用呢？只开 Spec-Kit，token 增量最小------主要就是 CONSTITUTION.md 的体积，多则几千 token，但流程纪律和安全扫描得你自己盯着，容易漏。只开 Superpowers，token 开销集中在工作流的阶段切换上，不算夸张，但缺宪法约束和工具库，AI 容易跑偏技术选型，纠偏的来回沟通反而费 token。只开 ECC，工具描述占一些 token，但没流程强制，很多时候你调了个 Skill 就以为完事了，跳过了测试和审查，省下的 token 换来的是质量风险。

说白了这是个取舍。三件套全开，token 花得多，但规矩、流程、工具都到位，返工少；单开一个，token 省了，但总有一层漏着，后面补窟窿的成本未必比省下来的 token 少。我的实际做法是看项目------核心业务系统全开不犹豫，脚本和原型验证就裸跑 Claude Code，中间地带先上 Spec-Kit + Superpowers。

tangyuewei，从后端出发，用 AI 拓展到全栈的工程师。