快速结论
ECC（Everything Claude Code）不是一个独立代码模型，也不是传统 IDE，而是一套把 agents、skills、rules、hooks、MCP 配置和操作流程分发到多种 AI 编程环境的工具集。当前仓库以 v2 为稳定线，官方称其可用于 Claude Code、Codex、Cursor、OpenCode、Gemini、Zed、GitHub Copilot 等 harness；开源仓库采用 MIT 许可证，托管的 ECC Tools / ECC Pro 则是另一个商业服务表面，不能把“源码免费”理解为私有仓库云端审查也永久免费。
它适合已经在多个编程智能体之间切换、愿意审计配置，并希望复用安全检查、测试、研究与编排流程的开发者。它不适合只想安装几个提示词的新手：完整安装会向用户级或项目级目录写入 agents、skills、rules、commands 和 hooks，部分流程还会申请执行命令、访问仓库或连接 MCP 服务。正确用法是先预览、按模块安装、固定 commit，再逐步放开权限，而不是直接复制全量配置。
核心功能
- 跨 harness 分发：同一仓库为 Claude Code、Codex、Cursor、OpenCode、Gemini、Zed 等提供适配配置。
- Skills 与 agents：提供编程规范、测试、安全审查、研究、部署和编排等可复用工作流；数量以仓库当前 catalog 为准。
- Rules 与 hooks：规则可持续注入上下文，hooks 可在会话开始、工具调用前后或结束阶段执行检查与记录。
- v2 操作层：v2 文档描述了会话适配、MCP inventory、worktree 生命周期和 operator/control-pane 等能力。
- AgentShield：独立 npm 表面用于扫描 secrets、权限、hooks、MCP 与 agent 配置；高级模型审查可能产生额外模型费用。
- 安装生命周期：支持 install plan/apply、已安装状态、doctor、repair 与 dry-run uninstall，便于控制写入范围。
- 托管服务：ECC Tools GitHub App 面向 PR 审计等云端场景，ECC Pro 面向私有仓库席位；它们与本地 MIT 仓库分开计费和授权。
适合人群
- 同时使用 Claude Code、Codex 或 OpenCode，希望复用工作流的开发者。
- 能阅读 shell、Node.js 脚本和配置 diff，并愿意维护安装清单的平台团队。
- 需要把安全审查、测试门禁、会话记录或 worktree 编排标准化的小型工程团队。
- 不适合受严格终端权限限制、不能审计第三方 hooks，或希望零配置即用的用户。
使用场景
- 按项目装规则：只选择 common 与当前语言规则，避免全量上下文挤占模型窗口。
- 复用开发流程：把计划、代码审查、验证循环和安全扫描作为 skills 调用。
- 跨客户端迁移：在 Cursor、Codex 与 OpenCode 间保留相似的操作约定，但分别检查各 harness 的兼容性。
- 安装健康检查：用 list-installed、doctor、repair 和 uninstall dry-run 管理 ECC 写入的文件。
- PR 云端审计：需要 GitHub App 时再评估 ECC Tools 免费层或 Pro，不把云服务凭据交给本地插件。
价格与版本
| 表面 | 许可或计费 | 适合场景 |
|---|---|---|
ECC v2 开源仓库 / ecc-universal | MIT，免费 | 本地 agents、skills、rules、hooks 与 CLI |
| AgentShield CLI | 开源工具；模型调用另计 | 本地或 CI 配置扫描 |
| ECC Tools GitHub App | 官方提供免费与商业表面 | 公共或托管 PR 审计 |
| ECC Pro | 官方标示按席位订阅 | 私有仓库与托管能力 |
价格、额度和包含功能可能调整，应以 ecc.tools/pricing 与 GitHub App 页面为准。官方 README 对商业能力的描述属于项目方营销材料，诸如节省时间、安全测试规模和星标数量不等同于第三方审计或效果保证。
国内访问与使用体验
开源仓库和 npm 包是否可达取决于 GitHub、npm 及用户网络；ECC 本地运行并不代表其连接的模型、MCP 或 GitHub App 也能稳定访问。安装前先在临时目录克隆并查看 install plan，不要从第三方镜像下载同名包。企业环境还应确认代码能否发送给所选模型、GitHub App 能访问哪些仓库，以及 hooks 是否会把会话摘要写入用户目录。
建议只选一种安装路径。Claude Code 插件与完整手工安装叠加，可能产生重复 skill 和重复 hook；官方文档也明确提醒不要堆叠安装方式。对于生产仓库，使用 release tag 或完整 commit SHA 固定来源，在测试仓库验证后再升级，并保留变更清单和卸载预览。
优点
- 开源部分采用 MIT，配置和脚本可审阅、可裁剪。
- 覆盖多个 harness，适合把团队方法而不是单次提示词沉淀下来。
- 提供安装预览、状态、修复和卸载工具，比直接复制散落配置更容易治理。
- v2 把会话、MCP、worktree 与操作面板纳入同一套约定，适合复杂 agent 工作流。
- 官方文档持续强调安全扫描、验证循环和单一路径安装，风险提示相对明确。
不足
- 完整安装侵入性高，会改动多个用户级或项目级配置目录，hooks 还能自动执行脚本。
- skills、agents 与兼容层数量大，容易增加上下文、维护成本和重复行为。
- 不同 harness 的权限模型并不相同，“跨平台支持”不代表功能完全一致。
- 托管 ECC Pro、GitHub App 与本地 OSS 的边界需要自行核对，商业承诺不能由 MIT 源码担保。
- 若跟随
main或使用未固定版本的安装命令，供应链与行为漂移风险高。
替代品对比
| 工具 | 更适合谁 | 相比 ECC 的差异 |
|---|---|---|
| Claude Code | 单一终端 agent 用户 | 官方产品更集中，但不提供 ECC 的跨 harness 配置库 |
| Codex | OpenAI 编程工作流 | 原生运行环境明确，复用 ECC 组件需额外适配 |
| OpenCode | 偏好开源 agent 客户端的用户 | 是客户端本体，ECC 更像配置与工作流层 |
| Cursor | 需要图形化 AI IDE 的开发者 | 上手直接，跨客户端治理能力较少 |
| GitHub Copilot | 企业 IDE 与 GitHub 用户 | 服务和管理成熟，定制 hooks/skills 的自由度不同 |
常见问题 FAQ
ECC v2 是免费的吗？
ECC 仓库和 ecc-universal 包采用 MIT 许可证，可免费使用和修改；ECC Pro 与部分托管 GitHub App 能力是独立商业表面，模型 API、CI 和第三方 MCP 也可能收费。
ECC 会修改哪些文件？
范围取决于安装方式和 profile，可能涉及 agents、skills、rules、commands、hooks、MCP 配置及安装状态文件。执行前应查看 plan 或 dry-run，并避免把插件安装与 full profile 叠加。
为什么说安装有侵入性？
因为 rules 会改变模型上下文，hooks 可在事件发生时执行脚本，skills 和 agents 会增加可调用行为，权限配置还可能允许 shell、文件或网络操作。这些能力有价值，但都应按最小权限启用。
生产环境应该固定 npm 版本还是 commit？
npm 安装至少固定精确版本；从 GitHub 安装时固定经过审阅的 release tag，安全要求更高时记录完整 commit SHA。不要让生产环境无审查地追随 latest 或 main。
ECC 的安全和效率数据可信吗？
可以把官方 README 中的测试数、星标数和效率叙述当作项目方披露，但不应视为独立认证。团队仍需审阅 hooks、运行自身测试，并验证 AgentShield 的规则是否覆盖本地威胁模型。
总结
ECC v2 的价值不在于又多一个编码聊天框，而在于把可复用工作流铺到多个 agent harness。对于有治理能力的团队，它能减少重复配置；对于个人新手，全量安装反而可能带来重复 hooks、过宽权限和升级漂移。先选 OSS 还是托管服务，再选单一安装路径，预览文件、固定版本、最小化模块和权限，才是稳妥的采用顺序。