夜雨聆风一个 Claude Code 插件，
3个月狂揽20万 Star，凭什么？
参考文章：一个 Claude Code 插件，狂揽 20 万 Star！（GitHubDaily / 小 G）
刷 GitHub Trending 的时候，我愣了一下。
榜单顶上有个项目，3 个月，20 万 Star。
要知道，那些大家耳熟能详的开源神项目，混到 10 万 Star 已经是稀有动物。这个项目从零开始，3 个月飙到 20 万。
它叫 Everything Claude Code，简称 ECC。说白了，就是一个 Claude Code 的插件包。
听到"插件包"你可能不感冒。一个插件而已，能有啥稀奇？
但你看完这篇就明白了——它不只是个插件，它是一整套"AI 团队管理系统"。
故事要从一场黑客松说起
ECC 的作者叫 Affaan Mustafa，旧金山一个普通开发者。
去年 9 月，Anthropic 联合 Forum Ventures 办了一场比赛。规则有点野——用 AI Agent 在一天之内从零搭出一家公司。
啥意思？以前要花几周的活儿，你得在 24 小时内搞定：找客户、写需求、做原型、写代码、跑通流程。一气呵成。
Affaan 和他的队友夺冠了。作品叫 zenith.chat，一个 AI 客户调研平台。
最离谱的是什么？整个产品几乎没敲过一行代码。全是 Claude Code 写的。
你可能想问，Claude Code 不就是个 AI 编程助手吗？谁都能用，凭啥他赢了？
答案就是——他赢的不是 Claude Code 本身。是他用了 10 个月时间，给 Claude Code 配的那套工作流。
比赛一结束，他直接把这套工作流开源了。这就是 ECC 的来历。
61 个 Agent + 246 个 Skill，相当于一支 AI 团队
现在 ECC 经过 3 个多月的迭代，已经长成这样：
61 个 Agent，246 个 Skill，再加 76 个命令。
你装上之后，Claude Code 就不再是"一个 AI 助手"——它变成了一支分工明确的团队。
有专门做架构设计的。有专门写测试的。有专门做代码审查的。还有专门揪安全漏洞的。
打个比方。以前你跟 Claude 说"帮我写个登录功能"，它就吭哧吭哧给你写。写完是写完了，但架构合不合理？有没有漏洞？测试覆盖率够不够？全靠你自己再去查。
装了 ECC 之后呢？你提需求，架构 Agent 先帮你规划，写代码 Agent 出活儿，测试 Agent 自动补测试，代码审查 Agent 挑毛病，最后安全 Agent 扫一遍漏洞。
像不像一个迷你 dev team？
还有个细节我觉得挺香——跨会话记忆。
平时用 Claude Code 最烦的就是每开一个新会话，前面聊过的上下文就全没了。每次都要重新解释项目背景。ECC 给加了个自动存取上下文的能力，新会话也能"接着上次的聊"。
200多个技能不会撑爆上下文？秘密在"按需加载"
说实话，第一次听说 246 个 Skill 的时候，我第一反应是：这不得把上下文撑爆？
要知道，每加一个工具、一个技能，都会占用 Claude 的上下文窗口。200 多个全堆进去，别说干活了，模型先疯。
结果一研究，ECC 用的是"按需加载"机制。
平时这些技能不会全部塞进上下文。你写 TypeScript 项目，它只调 TS 相关的审查 Agent。你切到 Python 写测试，TDD 的 Agent 才上场。
就像你公司里员工 200 多个，开会的时候不会全拉进会议室。要谁来谁来。
这个设计是 ECC 能"装得下"庞大技能库的关键。也是为什么它没有被"功能过载"拖死。
AgentShield：写代码时最怕的那件事，它帮你拦住了
用 AI 写代码，最怕什么？
密钥泄露。
Claude 一不留神，把你的 API key、数据库密码这些东西，直接提交到了 GitHub 公共仓库。
我个人觉得这是 AI 写代码最大的安全黑洞。人写代码会下意识地避开敏感信息，AI 不会——它只看到字符串。
ECC 里有个工具叫 AgentShield。毫秒级扫描代码，专门拦凭证泄露。
更狠的是 --opus 模式。一开，它会同时启动三个 Agent 分身：
- 红队 Agent：专门找漏洞，模拟攻击者思维
- 蓝队 Agent：负责修复漏洞
- 审计师 Agent：最后汇总结果出报告
红蓝对抗 + 第三方审计。这套打法，是企业级安全团队的标配玩法。
一个开源插件，把这个搬到了你的本地。
怎么装？两行命令的事
作者给了两种安装方式。
第一种，插件市场（推荐）：
/plugin marketplace add https://github.com/affaan-m/ECC /plugin install ecc@ecc
两行命令，搞定。装完会自动加载技能、命令和 hooks。
第二种，手动安装。 适合你想精确控制装哪些 Agent 和 Skill 的情况。把仓库 clone 下来，自己挑需要的部分往项目配置目录里复制就行。
不过有个注意点：rules 规则文件无论哪种方式都得手动复制。插件系统不支持自动分发 rules，复制时记得整个语言目录一起拿，别只挑单个文件。
对了，ECC 也不只能给 Claude Code 用。Codex、Cursor 这些 AI 编程工具也能装。
装完之后，有个坑要避开
ECC 这么多功能，是不是全开就最爽？
不是。这是新手最容易踩的坑。
作者反复强调一件事：不要一次启用所有 MCP。
为什么？因为工具太多，上下文窗口会被"工具描述"挤爆。你以为有 200k 的上下文可以用，实际工具一开，可能就剩 70k 给你写代码。
作者的建议是：
- 配置 20-30 个 MCP
- 单个项目启用不多于 10 个
- 活跃工具控制在 80 个以内
这就像你买了把瑞士军刀，结果天天把所有刀片都打开拿在手里——既不安全，也用不顺手。
这个项目最有意思的"反共识"
ECC 火了之后，争议也不小。
最多人吐槽的，就是功能太多，很多用不上。
作者自己也大方承认：这套配置是按我个人的工作流打磨的。
他甚至明说：你应该挑适合自己的、删掉用不上的、再加自己的——构建一套专属你的工作流。
这话挺反常识的。一般开源项目都怕用户不知道怎么用，恨不得提供"开箱即用"的标准答案。ECC 反过来：给你一堆素材，让你自己拼。
我个人挺欣赏这种态度。AI 工具发展到现在，"一个配置打天下"的时代结束了。每个人写的代码不一样，习惯不一样，工作流就得不一样。
写在最后
3 个月，20 万 Star。这个数字真的吓人。
但比数字更值得琢磨的，是这件事透露出的趋势——
AI 编程工具，已经从"补全代码的助手"，进化成了"可被编排的多 Agent 系统"。
以前大家比的是模型谁更聪明。现在比的是——你怎么给模型配技能、配规则、配记忆、配安全。
模型本身的能力在收敛，但围绕模型搭建的工作流，差距却在拉大。
或许往后某一天，当模型都强到差不多的时候，真正拉开人和人差距的，反而是我们怎么去"调教"它。
ECC 给了我们一份很好的参考答案。剩下的，就看你怎么写属于自己的那一份了。
GitHub 项目地址：https://github.com/affaan-m/ECC
