2026 年 3 到 5 月，AI 编程圈有一个项目涨得非常快：Everything Claude Code，简称 ECC。
它最早的传播口径是“Claude Code 的全能增强包”，现在看这个说法并不夸张。ECC 不是单独的 prompt 集合，也不是几个 slash command 的拼盘，而是一套围绕 AI 编程 Agent 的工程化增强层：agents、skills、commands、hooks、rules、MCP 配置、安全扫描、记忆机制、评测方法、跨工具适配都放在了一起。
需要先说明一个数据口径：很多文章里还写着 ECC 是 150k+ Star。我查 GitHub 页面时，它已经显示约 190k+ Star，README 不同语言页里的数字也有滞后。所以更稳妥的说法是：ECC 已经是 2026 年上半年 AI 编程工具生态里增长最快、关注度最高的一类项目，150k+ Star 是一个保守口径。
一、ECC 是什么
ECC 的官方定位是：
The agent harness performance optimization system.
翻成人话就是：它不是替代 Claude Code，而是增强 Claude Code 这类 Agent Harness 的执行系统。
这里的 Harness，可以理解为“承载 Agent 工作的外壳”：Claude Code、Cursor、Codex、OpenCode、Gemini CLI、Zed、GitHub Copilot Chat 都属于类似场景。模型负责推理，Harness 负责把模型接到文件、终端、Git、工具、MCP、规则和上下文。
ECC 做的事情，是把这层 Harness 变得更像一个成熟工程团队：
| 组件 | 作用 |
|---|---|
| Agents | 专门角色，例如架构师、代码审查、构建错误修复、安全审查 |
| Skills | 可复用工作流，例如 TDD、文档查找、前端规范、成本控制 |
| Commands | 旧式 slash command 入口，逐步迁移到 skills |
| Hooks | 在工具调用前后做检查、记录、约束或自动化 |
| Rules | 长期规则，例如代码风格、安全要求、语言规范 |
| MCP Configs | 接入 GitHub、Context7、Playwright、Memory 等外部工具 |
| AgentShield | 扫描 Claude Code 配置里的安全风险 |
| Installer | 面向 Claude Code、Cursor、Codex、OpenCode 等不同工具的安装适配 |
官方 README 当前提到的公开表面已经很大：61 agents、246 skills、76 legacy command shims。这也是它为什么会火：它命中的不是“写一个更聪明的模型”，而是“让模型在工程现场更稳地工作”。
二、为什么它会火
Claude Code 这类 CLI Agent 很强，但裸用时会遇到几个问题。
第一，行为不稳定。今天它认真写测试，明天它直接改实现；今天它先读文档，明天它开始猜 API。模型能力很强，但工作习惯需要被约束。
第二，复杂任务缺少分工。一个需求里可能同时有架构设计、后端实现、前端状态、数据库迁移、测试补充、安全检查。裸 Agent 很容易把所有事情挤在一个上下文里，最后越做越散。
第三，规则和经验不能沉淀。团队花了很多时间告诉 Agent：“先跑测试”“不要乱改无关文件”“查官方文档”“提交前做安全检查”。这些经验如果只存在对话里，就会反复丢失。
第四，安全边界不清晰。MCP、hooks、shell、自动写文件都很强，但强工具也意味着更大的误操作和注入风险。
ECC 的价值就在这里：它把这些“使用经验”做成了可安装、可组合、可审查的组件。
三、ECC 的整体架构
你可以把 ECC 看成 5 层。
第一层是规则层。它解决“Agent 做事应该遵守什么习惯”的问题，例如安全优先、测试优先、不要无关重构、先查文档再写代码。
第二层是技能层。它解决“某类任务应该按什么流程做”的问题，例如写计划、做 TDD、查 API、优化前端、处理构建失败。
第三层是角色层。它解决“复杂任务该交给谁看”的问题，例如让 security-reviewer 看安全，让 build-error-resolver 修构建，让 architect 看架构。
第四层是 hooks 层。它解决“工具调用前后怎么自动加约束”的问题，例如 shell 执行前提醒风险、文件编辑后跑类型检查、会话开始时加载上下文。
第五层是工具层。它通过 MCP 和外部配置，让 Agent 能连接 GitHub、文档检索、浏览器测试、记忆系统等能力。
四、它不只是 Claude Code 插件
虽然 ECC 最初是围绕 Claude Code 火起来的，但它已经明显在做跨 Harness。
官方 README 里能看到这些适配：
| 工具 | ECC 支持重点 |
|---|---|
| Claude Code | 插件、skills、agents、commands、hooks、rules |
| Cursor | 项目布局适配、agents、rules、MCP、hooks |
| Codex | AGENTS.md、.codex/config.toml、profiles、MCP servers |
| OpenCode | agents、commands、skills、instructions、plugin hooks |
| GitHub Copilot | .github/copilot-instructions.md 和 prompt files |
| Zed / Gemini / 其他 | 按目录和配置方式做兼容扩展 |
这意味着 ECC 真正想做的不是“Claude Code 皮肤包”，而是一套 AI 编程 Agent 的配置和工作流标准库。
这点很关键。未来团队可能同时用 Claude Code、Cursor、Codex、OpenCode，不同人喜欢不同工具。如果规则、技能、审查方法能跨工具复用，就比每个工具单独维护一套 prompt 更可靠。
五、上手方式：推荐只选一条安装路径
注意：下面是可复现的操作说明，不在本文环境里真实启动。
ECC 官方反复强调一个原则：
不要叠加安装方式。
最常见的坏配置是：先用 Claude Code 插件安装了一遍，又跑 install.sh --profile full 或 npx ecc-install --profile full。这样会导致 skills、hooks、rules 重复加载，最后 Agent 行为变得很怪。
方式一：Claude Code 插件安装，推荐默认路径
在 Claude Code 里执行：
/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc
安装后可以试一个命令：
/ecc:plan "添加用户认证"
查看插件内容：
/plugin list ecc@ecc
这个路径最适合普通 Claude Code 用户，因为插件会自动加载 ECC 的核心 skills、commands 和 hooks。
方式二：只复制你需要的 rules
Claude Code 插件目前不能自动分发 rules，所以如果你需要规则，需要手动复制。
Linux / macOS：
git clone https://github.com/affaan-m/ECC.git
cd ECC
npm install
mkdir -p ~/.claude/rules/ecc
cp -R rules/common ~/.claude/rules/ecc/
cp -R rules/typescript ~/.claude/rules/ecc/
Windows PowerShell：
git clone https://github.com/affaan-m/ECC.git
cd ECC
npm install
New-Item -ItemType Directory -Force -Path "$HOME/.claude/rules/ecc" | Out-Null
Copy-Item -Recurse rules/common "$HOME/.claude/rules/ecc/"
Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/ecc/"
这里不要把所有规则一股脑复制进去。你做 TypeScript 项目，就先复制 common 和 typescript。你做 Go，再换成 golang。上下文不是越多越好，规则越多，模型越容易被无关约束干扰。
方式三：完全手动安装，适合高级用户
如果你不想用插件路径，才考虑完整安装器。
./install.sh --profile full
Windows：
.\install.ps1 --profile full
或者：
npx ecc-install --profile full
如果你只想要轻量安装：
./install.sh --profile minimal --target claude
Windows：
.\install.ps1 --profile minimal --target claude
最稳的建议是：新手用插件路径，高级用户用手动路径，但不要混用。
六、一个真实工作流：从需求到审查
ECC 的最佳使用方式，不是“装完就让 Claude 自由发挥”，而是把它当成一套工作流。
一个比较舒服的使用节奏是：
/ecc:plan "给后台管理系统增加基于角色的权限控制"
让它先出计划。你确认范围后，再让它分阶段执行：
按刚才的计划，只做第一阶段：补充权限模型和数据库迁移，不改 UI。
完成后运行相关测试，并说明影响范围。
做完后再让它审：
请用 code-reviewer 和 security-reviewer 的角度审查这次改动。
重点看权限绕过、默认角色、接口边界和测试缺口。
这就是 ECC 的价值：把“随便叫 Agent 写代码”变成“规划、实现、构建、审查、安全检查”的流程。
七、AgentShield：必须认真看的安全模块
ECC 里最值得单独讲的是 AgentShield。
AI 编程工具越来越强以后，配置本身就成了攻击面。CLAUDE.md、settings.json、MCP 配置、hooks、skills、agent 定义里都可能藏着风险：
- 泄露 API Key 或 Token；
- 过宽的 shell 权限；
- MCP Server 指向不可信地址；
- hook 注入危险命令；
- agent prompt 被植入恶意指令；
- 自动执行链路缺少确认。
AgentShield 的作用就是扫描这些配置风险。
快速扫描：
npx ecc-agentshield scan
自动修复安全问题：
npx ecc-agentshield scan --fix
生成安全配置：
npx ecc-agentshield init
在团队环境里，我会建议把它放到两个地方。
第一，个人本地初始化后跑一次，先看看 Claude Code 配置是否过宽。
第二，团队公共配置变更时，在 PR 里跑一次，尤其是改 hooks、MCP、rules、skills 的时候。
一个简单的检查流程：
八、实践里最该注意什么
1. 不要把 ECC 当成魔法包
ECC 能提升 Agent 的工作习惯，但不能保证模型永远正确。它提供的是规则、流程、角色和工具链，不是业务理解本身。
你仍然要明确任务边界：
只修改认证模块，不改订单和支付。
先给出计划，不要直接写代码。
实现后运行用户服务相关测试。
最后列出风险和未覆盖场景。
这种提示比“帮我优化一下项目”可靠得多。
2. 规则不是越多越好
很多人装 ECC 的第一反应是开满。全量 agents、全量 skills、全量 rules、全量 hooks，看起来很强，但实际会增加上下文噪声。
更好的方式是按项目选择：
| 项目类型 | 建议启用 |
|---|---|
| TypeScript 前端 | common、typescript、frontend、playwright/e2e |
| Java 后端 | common、java、security、build resolver |
| Python 数据项目 | common、python、docs lookup、test workflow |
| 多语言大仓库 | common + 每个子项目对应语言规则 |
| 高安全项目 | security reviewer、AgentShield、严格 hooks |
先小范围启用，再逐步加。
3. Hooks 要分环境
Hooks 很有用，但也可能打扰开发。
比如编辑后自动跑类型检查，在小项目里很舒服；在大项目里可能每次改文件都卡住。建议按环境区分：
export ECC_HOOK_PROFILE=standard
如果某些 hook 太吵，可以临时禁用：
export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
团队里最好约定三档：
| Profile | 用途 |
|---|---|
| minimal | 个人试用、低干扰 |
| standard | 日常开发 |
| strict | 合并前、发布前、安全敏感项目 |
4. Multi 命令不是基础安装自带
ECC README 明确提醒：/multi-plan、/multi-execute、/multi-backend、/multi-frontend、/multi-workflow 这类 multi 命令需要额外的 ccg-workflow 运行时。
初始化方式：
npx ccg-workflow
如果没装这个运行时，multi 命令无法正常工作。这里很容易踩坑，因为很多文章只写了“装 ECC”，没写 multi 命令还有额外依赖。
5. 团队使用要版本化
个人用 ECC 可以随装随试，团队用就不能这么随意。
建议把这些内容纳入版本管理：
团队启用的 rules 列表
允许使用的 agents
允许连接的 MCP servers
hook profile
安装方式
回滚方式
AgentShield 扫描结果
否则每个人机器上的 Agent 行为都不一样，最后排查问题会很痛苦。
九、我建议的落地方案
如果一个团队想试 ECC，我建议分三步，不要一口吃成胖子。
第一步，单人试用。
选一个不太危险的项目，只用插件安装，加 common 和当前语言 rules。目标不是追求全自动，而是观察它对计划、测试、审查有没有帮助。
第二步，场景验证。
挑 3 类任务做对比：
- 修一个真实 bug；
- 增加一个小功能；
- 做一次代码审查。
记录几个指标：
| 指标 | 观察点 |
|---|---|
| 计划质量 | 是否能拆出合理阶段 |
| 文件范围 | 是否少改无关文件 |
| 测试意识 | 是否主动补测试和跑测试 |
| 错误恢复 | 构建失败后能否定位 |
| 安全意识 | 是否指出权限、注入、密钥风险 |
第三步，团队固化。
把有价值的 rules、skills、agents 固化成团队模板，写进项目 README 或内部工程规范。公共配置变更必须过 review 和 AgentShield。
这个流程图可以作为“团队落地路线图”配图：
十、适合谁，不适合谁
适合 ECC 的团队：
- 已经高频使用 Claude Code、Cursor、Codex 或 OpenCode；
- 项目规模中等以上，任务经常跨多个文件；
- 团队重视测试、审查、安全和文档；
- 希望把 Agent 使用经验沉淀成可复用配置；
- 愿意花时间调一套稳定工作流。
不适合 ECC 的情况：
- 只是偶尔让 AI 写几段脚本；
- 项目很小，直接裸用 Claude Code 就够；
- 团队不愿意维护配置和规则；
- 希望装完就完全自动开发；
- 对 hooks、MCP、自动化权限没有基本安全意识。
ECC 越强，越需要治理。它不是“越多越好”的增强包，而是一套需要选择、裁剪和审查的工程系统。
总结
Everything Claude Code 火起来，不是因为它给 Claude Code 加了几个炫酷命令，而是因为它抓住了 AI 编程进入工程深水区后的真问题：
模型能力已经很强，但工程流程、角色分工、规则沉淀、安全边界和工具接入还不够成熟。
ECC 把这些东西打包到一个开源仓库里。你可以把它当成 Claude Code 的增强包，也可以把它看成 AI Agent 工程化的一次大型配置实验。
我的建议是：不要盲目全量安装，不要叠加多种安装路径，也不要一开始就开满 hooks。先用插件路径跑通，再复制少量 rules，最后根据真实任务慢慢引入 agents、skills、AgentShield 和团队模板。
真正的收益不在“装了多少组件”，而在于它能不能让 Agent 更稳定地做三件事：
先理解，再计划；
先验证，再修改；
先审查，再交付。
如果 ECC 能把这三件事变成团队的默认工作流，它就不只是 Claude Code 的增强包，而是 AI 编程时代的工程规约层。
