GitHub 上有个 28.5 万 Star 的仓库，叫 ECC。它给自己的定位很硬：不是又一个提示词合集，而是「AI 编码助手的操作系统」——71 个子智能体、311 个技能、97 个命令，装一次，让你的编码助手按一套工程流程干活。
仓库的自我要求也硬。它配了 13 道自动检查，提交代码时全部跑一遍。我把它拷进隔离沙箱，先跑了一遍：13 道全绿，45 秒跑完。
然后我开始动手改。按它的贡献指南，每个技能都必须写「什么时候该用我」和「别这么做」两节，我就把一个技能的「什么时候该用」整段删了；又挑了一个技能，把正文全清空，只留文件开头那几行元数据；再把这 311 篇技能里 30 篇的简介全换成一句「A skill.」。
四处改动，13 道闸门一次都没响。
—
它到底是什么
ECC 不是单个技能，更像一个中台。装进 Claude Code、Codex、Cursor 这类编码助手后，它提供四层东西：
| 层 | 数量 | 干什么 |
|---|---|---|
| 子智能体（agents） | 71 个 | 分别负责规划、代码审查、构建报错修复、安全审查、各语言专项 |
| 技能（skills） | 311 个 | 按需加载的工作流，从测试驱动开发到 Python、Go、Spring Boot 各框架规范 |
| 命令（commands） | 97 个 | 斜杠命令入口，仓库自己标注为「过渡期兼容层」，正在往技能迁移 |
| 规则（rules） | 122 条 | 按语言和项目类型挑选的常驻约束 |
先给一句公道话：这些数字全是真的。我在沙箱里数了一遍目录，71、311、97、122，与 README 写的逐项对得上——很多号称几万 Star 的项目，README 里的数字是上个季度的。ECC 的自检脚本 catalog:check 专门盯这一条，我把 README 里的 311 改成 999，它立刻亮红灯拦下。
它还做了一件同类项目很少做的事：把自己的失败写进文档。仓库里有一份「提问有效性」的实验报告——作者拿 6 个藏了坑的编程任务做对照，四个组跑了 72 次真实会话，结果四组全部满分通过，什么也没测出来。报告里直接写「这次实验没有提供任何信息」，并分析了三个原因：坑都藏在仓库里、实验时关掉了向用户提问的通道、测试用例是按闸门自己的问题分类写的因此注定通过。这份诚实，比大多数评测报告值钱。
—
实测：闸门守的是什么
先说常驻成本，这是装之前最该知道的。
311 个技能的简介会全部塞进助手的上下文，因为助手得先知道有哪些技能，才能决定加载哪个。我实测这 311 条简介合计 10 万字符，按英文四字符一个词元估算，约 2.5 万词元常驻。词元（也就是模型计费时说的那种字数单位）在场的每一轮对话都要重新计费。对一个每天开十几个短任务的人来说，这是纯开销。
如果 311 篇正文全部加载，是 73 万词元——当然设计上不会全加载，但这也说明「311 个技能」不是一个轻量的承诺。
再看内容厚度。311 篇技能里，269 篇的目录里只有一个说明文件，没有任何脚本、模板或附件。真正带可执行脚本的只有 23 篇。这不是罪状——很多技能的价值就是一份写清楚的流程文档——但它解释了为什么 2.9 MB 的正文撑起了 311 这个数字。
13 道闸门实际放了 409 条警告。 这个数字是我跑 npm run test:validators 得到的：退出码 0，同时打印 409 条提示。拆开看，160 篇技能缺「什么时候该用我」这一节，211 篇缺「别这么做」这一节，37 篇正文超过贡献指南规定的 500 行上限。
这些闸门本身写得没问题，问题在于它们的出厂设置：全部按「建议」处理，只有加 --strict-checklist 才升级为「错误」。我加上这个参数再跑一次，同样的 409 条立刻变成 409 个错误，退出码 1。也就是说，仓库自己写下的规矩，默认状态下一条都不会拦人。
于是就有了开头那组注入。五处改动，只有一处被拦：
| 我改的地方 | 闸门反应 |
|---|---|
| README 里技能数 311 → 999 | 拦下（catalog:check 报错） |
| 删掉一个技能的「什么时候该用我」整节 | 放行 |
| 把一个技能正文清空，只留 324 字节元数据 | 放行（三道检查全绿） |
| 改掉技能的内部名，塞进只在 Claude 下有效的变量 | 放行 |
| 30 篇技能的简介全替换成「A skill.」 | 放行 |
被拦的那一处，恰好是「数字」——catalog:check 会拿 README 里的计数和实际目录数比对。它守的是数量和结构，不守内容。一份技能文档是三千字还是一句话，在它眼里没有区别。
这不是疏忽，是个工程取舍：文档写得好不好，没法用脚本判定。但取舍的边界应该写清楚——贡献指南把这四节列为「必填清单」，闸门却全部降级成建议，这中间的落差，读者容易误解成「不写也没事」。
—
更值得说的问题：副本已经漂了
ECC 支持十几种编码助手。它的做法是：仓库根目录的 skills/ 是唯一真源，其他平台的目录（给 Codex 用的 .agents/skills、给 Kiro 用的 .kiro/skills、给 Cursor 用的 .cursor/skills）打包或映射同一批文件。README 写得很明确：「根目录是真源，平台适配器打包或映射这些同样的工作流，而不是维护独立副本。」
我按字节比对了一遍：
| 副本目录 | 篇数 | 与主库逐字节一致 |
|---|---|---|
pi/core/skills |
132 | 131 |
.agents/skills |
46 | 5 |
.kiro/skills |
43 | 0 |
.cursor/skills |
12 | 0 |
pi 那一套几乎完美同步，说明同步机制是存在的、能用的。但另外三套——合计 101 篇——只有 5 篇还对得上。差异不是改几个字，是整节消失：25 篇副本里丢了整节内容，其中 8 处丢的是「不可信来源」这类段落。
举个具体的。主库的深度研究技能里有一节专门写：网页抓回来的内容全部是「攻击者可以控制的东西」，页面里出现「忽略你之前的指令」这类话，只能当引用、不能当命令执行。给 Codex 用的那份副本，这一节没有了。同一个缺失出现在市场研究技能上，给 Cursor 用的副本也一样。内容创作技能的「硬性禁令」一节，在 Cursor 副本里也消失了。
这些段落不是文风问题，是防提示注入的安全约束。三个平台的用户，拿到的是少了这道防线的版本，而没有任何检查会发现这件事——我试着把副本改回和主库一致，闸门毫无反应，因为它根本不比对副本。
还有一个更小的细节，能说明「真源」的边界在哪。日语版本里有 32 篇技能，每篇都是 11 行的占位符，正文写着「翻译进行中」，末尾指向一个本地路径 D:/tmp/ECC/...——那是作者自己电脑上的盘符。仓库有一条检查专门防止这种本地绝对路径泄漏，但它只认 Mac 和 Windows 用户目录两种格式，D:/tmp 这种盘符根部路径不在它的识别范围里。这 32 篇占位符，随包进了 npm 分发包。
—
同类里的位置
这条赛道上，ECC 走的是「大而全」那一头。之前评测过的 mattpocock/skills（27.4 万 Star）是 27 个技能、688 KB，走的是少而精；addyosmani/agent-skills（9.9 万 Star）是 25 个工程技能；i-have-adhd 是单点解决输出样式。ECC 反过来：把你能想到的语言、框架、流程全铺一遍，311 个技能铺满，用「总有一个你用得上」换取覆盖面。
代价就在上面那几组数字里。铺得越宽，单篇被校验的深度就越浅；支持的平台越多，副本漂移的面积就越大。MIT 协议、单月 5.2 万次 npm 下载、1778 次提交的主作者加上 500 多次的第二贡献者——这是一个真在高速迭代的项目，而高速迭代和「每份副本都跟主库一致」天然冲突。
适合谁：刚给编码助手上手一套工程流程的人。它的规划、测试驱动、审查三段式确实成体系，71 个子智能体里挑几个常用的，比自己从零攒提示词快得多。规模是真的，这点不用怀疑。
不适合谁：只想装一个轻量技能的人。2.5 万词元的常驻索引，对偶尔用一次的人是负担。以及，如果你用的是 Codex、Kiro 或 Cursor——你拿到的那份副本，可能比主库少了点什么，而没有任何东西会提醒你。
—
我的判断
值得看，但要按「一套规模很大、质量参差的工程模板」来理解它，而不是「一个自带质量保证的体系」。
它最值钱的地方恰恰不是那 13 道闸门，而是那份把自己实验做失败、然后老实写下来的报告。一个愿意公开「这次什么也没测出来」的团队，比一个宣称「13 道闸门全绿」的团队可信得多——后者只能说明结构和数量没坏。
真要用得踏实，建议补三件事：一是把 --strict-checklist 打开，让那 409 条警告真的变成错误，否则你写的技能可以是一句空话；二是如果你用的是非 Claude 平台，以主库的 skills/ 为准，别信副本；三是装之前先算一笔账，2.5 万词元的常驻索引，值不值。
28 万 Star 买的是覆盖面。而覆盖面这件事，从来不承诺深度。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：