Everything Claude Code (ECC) 完整调研报告

项目地址: https://github.com/affaan-m/everything-claude-code
调研日期: 2026-03-25
项目版本: v1.9.0+
Stars: 105,000+ | Forks: 13,700+ | 支持语言: 12种

一、项目概述

Everything Claude Code（简称 ECC）是一个面向 AI Agent 开发工具链的性能优化系统，最初诞生于 Anthropic 黑客松，经过 10+ 个月的密集开发，已演变为一套生产级的 Claude Code Plugin。它不是简单的配置文件集合，而是一个完整的系统，包含 28 个专用 Agent、125+ Skills、60+ Commands、8 大通用 Rule、完整的 Hook 生命周期管理以及记忆持久化与持续学习机制。

ECC 兼容多个主流 AI 编程助手平台：Claude Code、Codex、Cursor、OpenCode。

核心定位: 将个人级的 AI 编程助手体验，提升为团队级的、可积累的、可治理的 AI 开发基础设施。

二、系统架构总览

2.1 分层架构图

2.2 模块依赖关系图

关键依赖关系说明:

• Commands → Agents: 每个斜杠命令映射到一个或多个 Agent。例如 /tdd 调用 tdd-guide，/orchestrate 按序调用 planner → tdd-guide → code-reviewer → security-reviewer
• Agents → Skills: Agent 在执行时按需加载对应 Skill 作为参考知识（如 code-reviewer 加载编码风格 Skill）
• Agents → Rules: Rules 作为 Agent 的强制约束在系统层自动注入（通过 .claude/rules/*.md 自动加载）
• Hooks → Scripts: 每个 Hook 配置项指向一个具体的 JS/Shell 脚本执行
• Hooks ↔ Agents: Hook 在 Agent 工具调用前后自动触发（如 PreToolUse 在 Bash 执行前运行安全检查）

三、安装部署与上手

3.1 安装方式对比与选择

ECC 支持三种安装方式，各有利弊。其中插件安装最快（<2分钟），但需要特别注意的是，插件安装后 Rules 仍需手动安装。这是因为 Claude Code 插件系统目前尚不支持自动分发规则文件到 .claude/rules/ 目录，必须通过脚本完成。

关键要点: 无论选择哪种安装方式，都要确保 Rules 系统完整安装。Rules 是 ECC 的约束层，Agent 执行时会自动加载 .claude/rules/ 下的规则文件（通过 extends 和 override 机制），缺失 Rules 会导致 Agent 行为偏离预期。

3.2 安装后验证与 Hook Profile 配置

安装完成后，需要进行两步验证和配置：第一步是验证 ECC 核心命令是否正常响应；第二步是根据开发需求选择合适的 Hook Profile 严格度（minimal/standard/strict）。这个选择很重要，因为它影响代码审查、安全扫描、质量门禁等自动化检查的行为。

关键要点:

• minimal 模式适合快速原型和探索性开发，开销最小，但缺少安全和质量检查。
• standard 模式是推荐的日常开发选择，平衡了安全、质量和性能。
• strict 模式适合生产环境和安全关键代码，会启用所有检查和自动修复。

四、28个Agent深度解析

4.1 Agent 总览表

4.2 核心 Agent 详解

4.2.1 Planner Agent — 实施规划专家

设计哲学: “先计划，后编码”。在写任何代码之前，通过系统化的规划降低返工风险。

5步工作流程:

计划输出模板:

## Overview
[一句话描述]

## Requirements
- 功能需求列表
- 成功标准

## Architecture Changes
- 受影响的组件
- 新增/修改的接口

## Implementation Steps
### Phase 1: [名称]
- Step 1.1: [精确到文件路径和函数名]
  - File: `src/services/auth.ts`
  - Action: 添加 `validateToken()` 方法
  - Complexity: Medium
  - Risk: 可能影响现有Session管理

### Phase 2: [名称]
...

## Testing Strategy
## Risks & Mitigations
## Success Criteria

红旗检测清单: 函数超过50行、嵌套超过4层、缺少错误处理、硬编码值、缺少测试、计划中没有测试策略、步骤缺少文件路径。

4.2.2 Code Reviewer Agent — 代码审查专家

4级严重度分类系统:

审批标准:

• Approve: 无 CRITICAL 或 HIGH 问题
• Warning: 仅有 HIGH 问题
• Block: 存在 CRITICAL 问题 → 阻止提交

审查流程（5步）:

v1.8 增强 — AI生成代码附录: 当审查 AI 生成的变更时，优先检查行为回归、安全假设、隐藏耦合、不必要的复杂性。标记无理由升级到高成本模型的工作流。

4.2.3 Security Reviewer Agent — 安全审查专家

三阶段审查方法:

触发时机: 新增 API 端点、认证变更、用户输入处理、数据库查询修改、文件上传、支付代码、外部 API 集成、依赖更新。

安全审查自动触发场景:

4.2.4 TDD Guide Agent — 测试驱动开发专家

强制性 Red-Green-Refactor 循环:

8类必测边界场景:

覆盖率要求:

• 普通代码: ≥80%
• 关键代码 (金融计算/认证/安全): 100%

v1.8 增强 — Eval 驱动集成: 在实现前定义 eval，捕获基线失败，实现后报告 pass@1 和 pass@3 指标。

4.2.5 E2E Runner Agent — 端到端测试专家

双工具策略:

Flaky 测试处理: 使用 test.fixme() 隔离不稳定测试，通过 --repeat-each=10 识别 flaky 测试，常见原因包括竞态条件（用 auto-wait locator 解决）、网络时序（用 waitForResponse 解决）、动画时序（用 networkidle 解决）。

成功指标: 关键流程 100% 通过、总体通过率 >95%、Flaky 率 <5%、执行时间 <10分钟。

4.2.6 Chief of Staff Agent — 通信管理总管

4层消息分类系统:

发送后自动跟进（7步）: 创建日历事件 → 更新关系记录 → 更新 Todo → 设置跟进截止 → 归档已处理消息 → 更新分拣文件 → Git commit & push 所有知识文件变更。

4.2.7 其他关键 Agent

Refactor Cleaner — 死代码清理专家:

• 使用 npx knip（未使用文件/导出）、npx depcheck（未使用依赖）、npx ts-prune（未使用TS导出）
• 3级风险分类: SAFE（安全删除）→ CAREFUL（需验证）→ RISKY（可能有副作用）
• 原则: 活跃开发期间避免大规模删除，每次提交聚焦单一清理

Doc Updater (Haiku 模型) — 文档同步专家:

• 核心原则: “不匹配现实的文档比没有文档更糟糕”
• 通过 AST 分析 TypeScript 编译器 API，自动提取导出/导入关系
• 输出 docs/CODEMAPS/ 下的结构化文档

Harness Optimizer — 工具链优化专家:

• 使命: “通过改进工具链配置提升 Agent 完成质量，而不是重写产品代码”
• 5步流程: 执行审计 → 定位3个最高杠杆点 → 建议最小可逆调整 → 验证 → 记录前后对比

Loop Operator — 自主循环控制专家:

• 升级触发: 连续两个检查点无进展 / 重复相同堆栈错误 / 成本超预算 / 合并冲突阻塞
• 安全检查: 质量门禁活跃 + Eval基线存在 + 回滚路径存在 + 分支/Worktree隔离

4.3 语言特定 Agent 矩阵

五、Hooks 钩子系统 — 完整生命周期引擎

5.1 完整 Hook 配置详解

Hooks 是 ECC 的神经系统——在每个工具调用的前后自动触发，无需用户干预。

5.2 Hook 关键配置代码

// hooks.json 核心结构示例
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{"type": "command", "command": "npx block-no-verify@1.1.2"}],
        "description": "阻止 git --no-verify 绕过预提交钩子"
      },
      {
        "matcher": "Edit|Write",
        "hooks": [{"type": "command",
          "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js\" \"pre:edit-write:suggest-compact\" \"scripts/hooks/suggest-compact.js\" \"standard,strict\""}],
        "description": "在逻辑间隔建议手动压缩上下文"
      },
      {
        "matcher": "Bash|Write|Edit|MultiEdit",
        "hooks": [{"type": "command",
          "command": "node \"...run-with-flags.js\" \"pre:insaits-security\" \"scripts/hooks/insaits-security-wrapper.js\" \"standard,strict\"",
          "timeout": 15}],
        "description": "可选 InsAIts AI 安全监控 (ECC_ENABLE_INSAITS=1)"
      },
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [{"type": "command",
          "command": "node \"...run-with-flags.js\" \"pre:config-protection\" \"scripts/hooks/config-protection.js\" \"standard,strict\"",
          "timeout": 5}],
        "description": "阻止修改 linter/formatter 配置文件"
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "hooks": [{"type": "command",
          "command": "node \"...run-with-flags.js\" \"stop:cost-tracker\" \"scripts/hooks/cost-tracker.js\" \"minimal,standard,strict\"",
          "async": true, "timeout": 10}],
        "description": "追踪每个会话的 Token 和成本指标"
      }
    ]
  }
}

5.3 Hook Profile 三级配置

run-with-flags.js 机制: 每个 Hook 通过此脚本包装，根据当前 ECC_HOOK_PROFILE 环境变量决定是否执行。脚本签名: run-with-flags.js <hookId> <scriptPath> <allowedProfiles>。

5.4 Hook 使用与调整流程

调整 Hook 行为可以通过三种方式实现，从临时的环境变量到持久的项目级配置。这为不同使用场景提供了灵活性。

5.5 三级 Profile 适用场景

六、Rules 规则系统 — 8大通用规则详解

6.1 规则分层架构

6.2 各规则详细内容

coding-style.md — 编码风格

git-workflow.md — Git 工作流

# Commit 格式
<type>: <description>

# 允许的 type:
feat | fix | refactor | docs | test | chore | perf | ci

PR 流程5步: 审查完整提交历史 → git diff [base]...HEAD 检查全量变更 → 创建详细摘要 → 规划测试 → 使用 -u 推送新分支。

testing.md — 测试标准

• 强制 TDD: 写测试 (RED) → 确认失败 → 写代码 (GREEN) → 确认通过 → 重构 → 覆盖率 ≥80%
• 三层必测: Unit (始终) + Integration (始终) + E2E (关键路径)
• 测试失败处理: 调用 tdd-guide Agent → 验证测试隔离 → 检查 Mock → 修改实现而非测试

performance.md — 性能与 Token 优化

模型选择策略:

上下文窗口管理: 大规模重构/跨文件功能/复杂调试时避免使用最后20%的上下文窗口。扩展思考模式可保留最多 31,999 tokens 用于内部推理。

security.md — 安全准则

提交前8项必检:

1. 无硬编码密钥 (API key, password, token)
2. 所有用户输入已验证
3. SQL 注入防护 (参数化查询)
4. XSS 防护 (HTML 清理)
5. CSRF 保护启用
6. 认证/授权已验证
7. 所有端点有速率限制
8. 错误消息不泄露敏感数据

发现漏洞时: STOP → 使用 security-reviewer Agent → 修复 CRITICAL → 轮换泄露密钥 → 审查全代码库类似问题。

patterns.md — 设计模式

Repository 模式: 标准操作接口 (findAll, findById, create, update, delete)，隐藏存储实现。

API 响应格式: 统一信封结构 → { success, data, error, pagination: { total, page, limit } }。

agents.md — Agent 委派规则

4个自动触发场景:

1. 复杂功能请求 → 自动调用 planner
2. 代码刚修改 → 自动调用 code-reviewer
3. Bug 修复/新功能 → 自动调用 tdd-guide
4. 架构问题 → 自动调用 architect

关键原则: “ALWAYS use parallel Task execution for independent operations.” — 独立操作必须并行执行多个 Agent。