当 AI 编码助手从实验性工具走向生产环境，团队面临一个共性问题：如何在 Claude Code、Codex、Cursor、OpenCode 等多种 agent harness 之间建立一致的性能优化层，同时让 AI 真正学习项目特有的开发约定。everything-claude-code（简称 ECC）给出了一个经过 10 个月高频实战验证的答案：它不是一套配置文件，而是一个包含 48 个 agent、182 个 skill、完整 hooks 自动化、规则引擎和 MCP 集成的性能优化系统，在 GitHub 上已积累超过 177K 星标。
五大组件的系统化协同
ECC 的架构并非功能的简单堆叠，而是一套层次分明的组件体系。agents 目录下的 48 个专业化子 agent 处理委托任务，每个 agent 用有限范围描述自身职责：planner 处理功能实现规划，architect 负责系统设计决策，security-reviewer 执行漏洞分析，tdd-guide 强制测试先行的工作流。这种委托模式将复杂任务拆解为可独立执行的单元，避免单次会话的上下文膨胀。
skills 目录则是 ECC 的主要工作流入口。相比 slash 命令的扁平调用方式，skill 以 YAML frontmatter 描述触发时机、工具依赖和约束条件。以 tdd-workflow skill 为例，它明确要求先定义接口、再写失败测试、然后实现最小代码、最后验证 80% 以上覆盖率。这种结构化描述允许 agent 在规划阶段就能判断某个 skill 是否适用于当前任务，而不是在执行过程中随机触发。
hooks 层通过事件监听实现自动化。PreToolUse 和 PostToolUse 钩子在每次工具调用前后执行，SessionStart 和 SessionEnd 管理会话生命周期的上下文持久化。例如 hooks/memory-persistence/ 下的会话保存和加载逻辑，确保 session 结束时将中间状态写入磁盘，session 开始时恢复上下文。相比 v1 版本依赖 skills 被动触发（约 50%–80% 触发率），v2 版本的 hooks 触发概率为 100%，学习行为不再遗漏。
rules 目录下的规则分为 common/（语言无关原则）和语言特定目录（typescript、python、golang、swift、php 等）。这种分层设计支持选择性安装：用户只需将 rules/common/ 和自己使用的语言目录复制到 ~/.claude/rules/ecc/，避免将所有语言的上下文规则都加载进 Claude Code 的 context window。
MCP 配置层则统一管理外部工具集成。ECC 的 mcp-configs/mcp-servers.json 包含 GitHub、Supabase、Vercel、Railway 等常用服务的连接模板，用户根据实际 API key 填充后即可使用。
Instinct-Based Learning：从观察到进化
ECC v2.1 版本引入的 instinct-based learning 系统是其最具创新的设计之一。该系统将 AI 从会话中学习到的行为拆解为原子化的 instincts，每个 instinct 携带触发条件、置信度评分、领域标签和证据记录。以一个典型的 instinct 为例：
---
id: prefer-functional-style
trigger: "when writing new functions"
confidence: 0.7
domain: "code-style"
source: "session-observation"
scope: project
project_id: "a1b2c3d4e5f6"
project_name: "my-react-app"
---
置信度评分机制是该系统的核心。0.3 表示试探性建议，0.5 表示适度适用，0.7 表示强烈推荐且可自动批准，0.9 表示近乎确定的核心行为。置信度会随时间演变：当某个模式被反复观察且用户未纠正时提升，当用户明确纠正该行为或矛盾证据出现时下降。
v2.1 新增的项目级隔离机制解决了 v2.0 的跨项目污染问题。系统通过 git remote URL 哈希生成项目 ID，确保 React 项目的模式留在 React 项目、Python 项目的约定留在 Python 项目。只有当同一个 instinct 在两个以上项目中出现且平均置信度达到 0.8 时，系统才建议将其提升为全局本能。这种设计允许团队成员在不同项目间保持隔离的学习空间，同时自动提炼跨项目通用的最佳实践。
学习管道的工作流程为：会话活动（prompt + tool use）通过 hooks 实时捕获 → observer agent（后台 Haiku 模型）读取并分析观测记录 → 模式检测生成 instinct → 项目级或全局存储 → /evolve 命令将相关 instincts 聚类为 skills、commands 或 agents → /promote 命令将跨项目 instincts 提升至全局作用域。
跨平台架构：同一套工作流，多个执行表面
ECC 的核心设计哲学是：工作流的持久化行为应放在统一仓库中，而 harness 特定的适配放在边缘层。该项目已在 Claude Code、Codex（macOS app + CLI）、Cursor、OpenCode、Gemini 上验证了功能，feature parity 矩阵显示了各平台的实际能力差异。
Claude Code 拥有最完整的实现：48 个 agents、68 个 commands、182 个 skills、8 类 hook 事件、997 项内部测试。OpenCode 在 hook 事件类型上反而更多（11 类 vs 8 类），且支持 6 个原生自定义工具。Codex 目前仍依赖指令驱动而非原生 hooks，Cursor 则通过 DRY adapter 模式复用 Claude Code 的 hook 脚本。
跨平台适配的关键是 skills/*/SKILL.md 的格式规范：一个合格的 ECC skill 应使用 YAML frontmatter（包含 name、description、origin），描述触发时机而非嵌入密钥，示例应使用仓库相对路径或通用路径，避免 harness 特定的命令假设。这意味着同一份 skill source 可以通过 Claude plugin、Codex plugin、OpenCode package 等不同路径安装到各 harness 中。
ecc2/ 目录下的 Rust 控制平面原型（ECC 2.0 alpha）进一步将控制逻辑与执行逻辑分离。它暴露了 dashboard、start、sessions、status、stop、resume、daemon 等命令，允许用户将 agent 生命周期管理从 harness 内部移到独立的 Rust 进程中。
性能优化的关键参数
Token 成本是生产环境的硬约束。ECC 建议将默认模型从 opus 切换到 sonnet，配合 MAX_THINKING_TOKENS 从 31999 降至 10000，CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 从 95 降至 50。这三个参数的组合调整预计可将日常任务的成本降低约 60%–70%，而 sonnet 模型足以处理 80% 以上的日常编码任务。只有复杂架构设计、深度调试和深度推理时才切换到 Opus。
Context window 管理同样关键。每个 MCP 工具描述都会消耗 context window 的 token，上限 200K 的 window 可能因此降至约 70K。ECC 建议将启用的 MCP 控制在 10 个以内，活跃工具控制在 80 个以内，超出这个范围的 MCP 应通过 /mcp 命令禁用。SessionStart 上下文的默认上限为 8000 字符，低 context 或本地模型场景可通过 ECC_SESSION_START_MAX_CHARS=4000 或 ECC_SESSION_START_CONTEXT=off 进一步压缩。
Hook runtime 提供三个严格级别：minimal（最少 hooks）、standard（默认值）、strict（最强约束）。用户可以通过 ECC_DISABLED_HOOKS 环境变量禁用特定 hooks，例如 ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck" 临时跳过特定检查而不修改 hook 文件本身。
安装策略与避坑指南
ECC 支持两种安装路径：plugin 安装（推荐）和手动完整安装。Plugin 路径通过 /plugin marketplace add 和 /plugin install 完成，适合大多数用户。重要限制是 Claude Code 插件系统不支持自动分发 rules/ 目录，因此使用 plugin 安装后仍需手动将 rules/ 下的目录复制到 ~/.claude/rules/ecc/。
一个常见的破坏性场景是同时使用 plugin 安装和完整安装脚本。Plugin 安装后运行 ./install.sh --profile full 会导致 skills、commands、hooks 的重复安装，造成行为混乱和调试困难。正确做法是选择一种路径并坚持下去。
另一个高频问题是 Claude Code v2.1+ 的自动 hooks 加载行为。该版本会自动从已安装插件中加载 hooks/hooks.json，因此不应在 plugin.json 中显式声明 "hooks" 字段，否则会触发 "Duplicate hooks file detected" 错误。这个行为在 v2.1 之前的版本中不存在，导致许多用户反复遇到该问题。
适用场景与工程价值
ECC 最适合以下场景：有明确技术栈和代码规范的多人团队项目（通过 rules 和 project-scoped instincts 实现统一约束）；需要 AI 长期学习项目特有约定的持续迭代项目（通过 instinct-based learning 逐步积累可验证的行为模式）；跨多个 AI 编码工具协作的多工具工作环境（通过统一的 skill source 避免维护多份配置）。
对于首次接触该项目的用户，建议从 minimal profile 开始：仅安装 core skills（search-first、tdd-workflow、verification-loop）和 rules/common/，验证基本流程后再逐步扩展。这种渐进式采纳策略避免了初期过载，也为后续深度定制保留了空间。
ECC 项目的工程价值在于它将分散在多个 AI 工具中的最佳实践收敛到单一可验证的来源。当团队需要从 Claude Code 迁移到 OpenCode 或接受新的 agent harness 时，不需要重新发明工作流，只需要为新的 harness 编写适配层，而核心的 skills、rules 和 instincts 保持不变。这种关注点分离是 ECC 最值得借鉴的架构思路。
资料来源：GitHub - affaan-m/everything-claude-code
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。