everything-claude-code 在 Codex 怎么应用？该做聪明增强层还是照搬全家桶？
一个典型场景是这样。
你让 Codex 修复 CI 里的 typecheck 报错。没有额外规则时，它可能会找到报错文件，改掉类型定义，然后停在“看起来已经修了”的状态。CI 再跑一次，还是红的，因为它没有在本地复现，也没有重新跑 typecheck 验证。
同一个任务，如果项目里放了一套精简过的工程规则，行为会更稳定：先用 npx tsc --noEmit 复现错误，定位第一个有意义的失败，改根因，再跑一次验证，通过后才收工。
多了一步，但少了返工。
区别不在于 Codex 突然“变聪明”了，而是它被明确提醒了一件工程里很普通、但 AI 编程助手经常漏掉的事：改完要验证。
这就是 everything-claude-code（下面简称 ECC）对 Codex 的真正价值。它不是一个应该被完整复制进项目的全家桶，而是一套可以被提炼的工程习惯：规则怎么写、任务怎么拆、什么时候验证、什么时候做安全检查。
这篇文章想讲清楚一件事：在 Codex 里用 ECC，重点不是搬运，而是提纯。
我将 ECC 提炼出了 level1、2、3 三个等级，放在码云上，项目地址在本文末尾
Codex 本来就能做什么
先把底座说清楚。Codex 原生已经有一套项目级能力，不需要 ECC 也能工作：
| 能力 | Codex 原生入口 | 适合承载什么 |
|---|---|---|
| 项目规则 | AGENTS.md |
项目规范、测试命令、协作方式、禁止事项 |
| 项目配置 | .codex/config.toml |
sandbox、approval、MCP、profile 等配置 |
| Skills | .agents/skills/*/SKILL.md |
可复用的任务工作流 |
| Subagents | Codex 内置或项目配置 | 并行探索、实现、审查 |
| MCP | .codex/config.toml 或全局配置 |
接入 GitHub、Playwright、文档检索等工具 |
| Hooks | Codex 原生配置或命令机制 | 做流程自动化、权限检查、命令入口 |
OpenAI 官方文档里，AGENTS.md 是 Codex 的项目级说明入口；Skills 是 Codex 可发现、可调用的任务能力；Hooks 也已经支持流程控制。
为什么不建议直接照搬全家桶
很多人在拿到 ECC 之后的第一反应是：直接复制所有规则、所有技能、所有 hooks 进去。
结果往往是：
- 上下文被迅速塞满，模型注意力分散
- 很多规则与 Codex 的执行方式不兼容，反而制造冲突
- 维护成本暴增，后面改一个规则要同步好几处
真正高效的做法是只抽取核心工程习惯，然后用 Codex 自己的机制重新表达。
提纯后的三层增强方案
我把 ECC 提炼成了三个递进的等级，供不同阶段的项目选用：
Level 1：最小验证闭环
只保留“改完必须验证”这一条核心原则。把最常用的测试和类型检查命令写进 AGENTS.md，同时配置 Codex 的 approval 策略，让它在修改后自动执行一次验证。
Level 2：任务拆解与安全检查
在 Level 1 基础上增加任务拆解模板和安全检查点。比如要求 Codex 先列出修改影响范围、必须检查的敏感文件，再执行修改。把这些流程做成可复用的 Skills。
Level 3：完整工程节奏
加入并行子代理、MCP 工具集成、CI 联动等更深层的自动化能力。只有当团队已经习惯前两层，并且需要更高频的工程协作时，才考虑引入。
实际落地建议
- 先从 Level 1 开始，只放 3-5 条最关键的规则。
- 用 Codex 自己的
.codex/config.toml管理 sandbox 和审批策略，而不是完全依赖 ECC 的 hooks。 - 把验证命令做成可复用的 Skills，而不是每次都写在提示词里。
- 定期 review 规则，删除不再适用的内容。
这样既保留了 ECC 里最有价值的工程思维，又避免了把 Codex 变成一个臃肿的规则容器。
把 ECC 当成灵感来源，而不是直接拷贝对象，才是目前在 Codex 里使用它的最优方式。