项目卡片
- 项目:ECC[1]
- 状态:v2.2.3 / 28.1 万 Star / 4.1 万 Fork / 活跃迭代中
- 一句话判断:一套经过高强度实战打磨的 AI Agent 工程操作系统,专门治理 AI 编程中的上下文腐化、跨会话失忆与违规乱改。
在终端里高频使用 Claude Code、Cursor 或 Codex 编程时,很多开发者都会经历相似的断崖式体验:前十分钟让它写新功能,速度惊艳;可一旦代码规模扩大、交互超过十几轮,终端就会出现明显的上下文腐化。
模型开始遗忘早先立下的数据结构约定,为了修一个局部报错,顺手把两个公共模块改回旧版本。更让人头疼的是,一旦关掉终端退出会话,昨天的探索与排错经验瞬间归零,第二天同一条坑它依然会踩进同一处泥潭。
大模型本身擅长语法与算法生成,却天然缺乏软件工程里的长效记忆、权限约束与测试戒律。在 GitHub 斩获超过 28 万 Star 的开源项目 ECC(全称 Everything Claude Code),正是针对这套工程断层给出的系统级解法。它把散落的配置文件升级为由技能、子代理、会话钩子与安全门禁组成的完整工程体系。

怎么让 AI 不在盲目瞎试中烧爆上下文?
使用原生 AI 编码终端时,最直接的痛点就是 Token 消耗失控与注意力稀释。很多开发者习惯把所有能用的 MCP 服务一股脑挂进配置,结果还没输入第一个提示词,几万 Token 的协议定义就已经把上下文窗口占得满满当当。
更要命的是,面对大型代码库,主模型往往会在没有任何先验知识的情况下漫无目的地运行查找命令。在盲目翻看几十个不相关目录后,宝贵的高智力思考窗口被无关源码完全挤爆。
ECC 解决这道难题的策略是轻量技能收敛与模型分层调度。它明确主张放弃那些仅仅用来包装常规 CLI 的臃肿 MCP,改用执行成本极低的专用技能(Skills)。比如用精简的命令行交互替代重型数据库协议,直接省下大量常驻协议体积。
更进一步,ECC 组织了多层级的子智能体梯队分工。在日常开发中,代码库探索、关键字过滤、简单文件查看等繁琐杂务全部委派给轻量且廉价的模型(如 Haiku);只有当需求收敛为明确的多文件修改与架构设计时,才调用 Sonnet 或 Opus 集中决策。通过把探路过程与核心实现隔离在不同会话上下文中,开发者不再需要为主模型的盲目瞎试买单,主力会话始终保持清爽。

跨越会话的记忆怎么留存?
解决了单次会话的上下文膨胀,紧接着冒出的第二个难题就是跨会话失忆。如果只靠在全局系统提示词(如 CLAUDE.md)里硬塞规则,随着项目推进,该文件会变成又臭又长的规约清单。每次打开终端都要先做一次无差别的全量记忆灌输,既烧钱又极易导致规则打架。
ECC 把关键存盘节点放在了上下文压缩前夕与会话退出瞬间,避免了每次回车都同步带来的额外延迟。
通过配置 PreCompact 钩子,系统会在会话接近容量上限、即将触发自动压缩前,强制梳理出一份包含三项硬核事实的结构化临时存盘:哪些方案已经被测试证实有效、哪些改动已被证明失败、后续还有哪些关键待办。
这套台账被写入独立的会话记录文件,配合 SessionStart 钩子在下次启动时按需读取,使得复杂重构能够跨越几天平滑接力。同时,ECC 在架构上立下了极严苛的防线:外部召回的记忆始终属于不可信数据,仅供模型查阅上下文,绝对不允许作为最高优先级的执行指令生效,从根源掐断了恶意记忆注入的后门。

从测试红绿循环到敏感文件防线
许多开发者对 AI 编程助手心存忌惮,根源在于 AI 的破坏力不可控。如果不加约束,代码助手经常会在未跑通本地测试的情况下谎称完成,甚至在重构时误触环境配置、泄露生产密钥。
针对这种野蛮施工行为,ECC 建立了一套结合命令链与安全钩子的自动化闭环防线。
在行为规约层面,项目提供了直观的链式工作流。开发者通过 /plan 明确实现路径,随即触发 /tdd 建立测试用例;在测试红绿循环未能变绿之前,严厉禁止代码提交。任务完成后,再由 /refactor-clean 自动清理重构中残留的死代码与临时文件,将整个交付过程牢牢锁在严谨的工程轨道内。
在底线防御层面,ECC 内置的 GateGuard 门禁系统构建了严密的物理拦截。当智能体试图首次触碰 .env 文件、密钥证书、支付路由或敏感配置文件时,钩子会立即阻断操作,并要求智能体必须提供前置的检索与分析凭证。如果改动没有任何前置调研支撑,拦截器绝不放行,杜绝了 AI 在未经审查时改动核心基础设施。

普通开发者怎么用:避开全量堆砌,从最小切片起步
ECC 仓库目前包含 311 多个技能、71 个代理与数十个钩子,内容极其庞大。我实测全量安装时,光是技能列表就有三百多项,不仅终端补全眼花缭乱,还容易把本地配置搅成一锅粥。
对于日常编码的普通团队与独立开发者,最理智的打开方式是最小化切片起步。
第一步,优先使用 Claude Code 官方支持的插件机制,在终端内执行:
/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc
这套安装方式轻量透明,会自动引入最常用的核心命令与分析技能,而不会污染全局配置文件。
第二步,根据实际业务技术栈,按需按目录复制规则。如果你正在编写 TypeScript 项目,只需从仓库提取 rules/typescript 和 rules/common 放置在本地目录,切忌全盘复制无用语言的规则库。
mkdir -p ~/.claude/rules
cp -R rules/common ~/.claude/rules/
cp -R rules/typescript ~/.claude/rules/
最后,务必认清项目的边界与局限。ECC 里的高级多智能体编排(如 multi-plan)与统一记忆服务,需要额外依赖 Node 运行时与外部包支持;而即使部署了全部防御钩子,最终提交的代码依然需要人类工程师进行严格审阅。
普通开发者拿它当个按需取用的工程规约库,只拉取当前项目需要的规则与钩子,反而比盲目全量部署省心得多。若想深入理解这类 AI 工程化实践的配置思路,也可以系统查阅 技术文档,把规则来源、钩子触发时机和常见避坑点串起来看。
引用链接:
[1] ECC: https://github.com/affaan-m/ECC