一天新增 1,905 星，ECC 为什么把 Codex 安装做成了选择题

北京时间 9 月 8 日清晨，affaan-m/ECC 在 GitHub Trending Today 显示新增 1,905 stars。同一时点，GitHub API 给出的累计数是 252,691★、37,909 forks。前者是榜单当前窗口里的增长信号，后者才是仓库累计数，不能把 25 万颗 star 写成“今天涨了 25 万”。

这个项目最近重新进入视野，并不只是因为它收集了很多提示词。ECC 试图把计划、测试、实现、复查、验证、记忆和反思放进一条长期的工程流程。它的最新稳定版 v2.2.0 在 8 月 28 日发布，更新中加入了引导式设置，并把 Codex 放进正式支持范围。我会借这轮热度把它实际装进 Codex 时最容易混淆的边界讲清楚。期望对大家有所帮助。

不是一包 Skill，而是一套运行时约束

ECC 的 README 把主流程写成：

plan -> test -> implement -> review -> verify -> remember -> improve

这条顺序并不新鲜。真正的差别在于，它不把这些环节只留在一段 system prompt 里，而是拆成 Skill、Agent、规则、hook、会话记录和安全扫描的不同载体。项目 README 当前称整个目录包含 68 个 Agent、286 个 Skill 和 94 个旧命令兼容入口；原生 Codex 插件说明则写 281 个 Skill。两个数对应的打包范围不同，安装前不该把它们当成一个精确的承诺。

例如，Skill 可以给 Agent 一个明确工作流，规则负责持续生效的编码约束，hook 则会在工具事件附近运行。ECC 还把 AgentShield 放在同一套生态里，用来检查 Agent 配置、MCP 配置、权限、hook 和潜在密钥暴露。它的 安全政策 同时明确了官方发行面：affaan-m/ECC、ecc-universal、ecc@ecc 与 ECC Tools GitHub App，其他同名或近似 npm 包不该仅凭名称安装。

这解释了为什么它看起来比普通 Skill 包更重：它不是只教模型“下一步怎么做”，还会尝试影响安装后的执行环境。优点是工作流可以被反复使用；代价是每一层都需要你知道它何时写入文件、何时执行命令、何时读取会话状态。

Codex 的两条路径不能叠加

对于 Codex，ECC 文档区分得很明确。一条是当前推荐的原生 marketplace 插件路径：

codex plugin marketplace add affaan-m/ECC
codex plugin add ecc@ecc
codex plugin list --json

它把 manifest、Skill、MCP 配置、脚本和资产作为一个插件缓存到 Codex 的环境中。安装一次以上是幂等的，但这不表示可以把所有安装方式叠在一起。

另一条是旧的 scripts/sync-ecc-to-codex.sh，它会向 ~/.codex 复制和合并配置。项目把它定义为兼容方案，而不是新用户的默认方案。原生插件已经装好时，再跑同步脚本，会同时留下原生插件状态和复制的配置层，后续到底由哪一层提供 Skill、MCP 或说明文件就变得不清楚。Codex 插件说明 的建议很朴素：新安装走原生插件；只有确实需要旧的复制配置时才选同步路径。

这不是“命令多一点”的小问题。Agent 工具的可靠性很大程度来自可追溯的来源：你应当能回答一个 Skill 来自哪个仓库、一个 MCP 配置何时被加入、一个规则是否仍由你维护。先选一种分发方式，比先追求安装目录里的数量更重要。

插件启用不等于允许 hook 执行

另一个容易被忽略的边界是 hook。ECC 的原生插件说明写得很直接：插件安装后，Codex 仍要求用户在 /hooks 中审查并显式信任 hook 定义；信任记录还会与定义的 hash 关联，变更后需要重新审查。

这和“装了一个扩展就自动接管工具调用”不是一回事。ECC 的 Codex 支持矩阵也没有宣称与 Claude Code 完全一致：它将 Codex 标为支持 native plugin，但把能力定位为部分对齐，并指出 native hooks 是经过审查的子集。

所以第一次尝试时，比较稳妥的顺序是：

• 在 仓库 中确认来源与版本，再添加 marketplace
• 安装 ecc@ecc 后，用 codex plugin list --json 确认注册状态
• 打开 /hooks，逐项阅读会运行什么命令、触发条件是什么，再决定是否信任
• 不把原生插件与旧同步脚本叠加，也不把第三方重打包的同名包当成官方渠道

如果只想借用某一个测试、审查或文档 Skill，也可以先看其 SKILL.md，不必因为“286 个 Skill”就一次把整套运行时约束都接进工作目录。热榜给的是集中注意力，不是对每个 hook、每个 MCP 配置和每个默认行为的担保。ECC 的价值恰好也在这里：它把工程步骤放在台面上，剩下的选择仍应该由安装者做。

---

• 仓库：github.com/affaan-m/ECC
• v2.2.0：发布说明