一个典型场景是这样。
你让 Codex 修复 CI 里的 typecheck 报错。没有额外规则时，它可能会找到报错文件，改掉类型定义，然后停在"看起来已经修了"的状态。CI 再跑一次，还是红的，因为它没有在本地复现，也没有重新跑 typecheck 验证。
同一个任务，如果项目里放了一套精简过的工程规则，行为会更稳定：先用 npx tsc --noEmit 复现错误，定位第一个有意义的失败，改根因，再跑一次验证，通过后才收工。
多了一步，但少了返工。
区别不在于 Codex 突然"变聪明"了，而是它被明确提醒了一件工程里很普通、但 AI 编程助手经常漏掉的事：改完要验证。
这就是 everything-claude-code（下面简称 ECC）对 Codex 的真正价值。它不是一个应该被完整复制进项目的全家桶，而是一套可以被提炼的工程习惯：规则怎么写、任务怎么拆、什么时候验证、什么时候做安全检查。
这篇文章想讲清楚一件事：在 Codex 里用 ECC，重点不是搬运，而是翻译。
Codex 本来就能做什么
先把底座说清楚。Codex 原生已经有一套项目级能力，不需要 ECC 也能工作：
| 能力 | Codex 原生入口 | 适合承载什么 |
|---|---|---|
| 项目规则 | AGENTS.md |
项目规范、测试命令、协作方式、禁止事项 |
| 项目配置 | .codex/config.toml |
sandbox、approval、MCP、profile 等配置 |
| Skills | .agents/skills/*/SKILL.md 或已安装 skills |
可复用的任务工作流 |
| Subagents | Codex 内置或项目配置 | 并行探索、实现、审查 |
| MCP | .codex/config.toml 或全局配置 |
接入 GitHub、Playwright、文档检索等工具 |
| Hooks / Commands | Codex 原生配置或命令机制 | 做流程自动化、权限检查、命令入口 |
OpenAI 官方文档里，AGENTS.md 是 Codex 的项目级说明入口；Skills 是 Codex 可发现、可调用的任务能力；Hooks 也已经有 Codex 自己的配置方式。
所以问题不是"Codex 有没有这些能力"。真正的问题是：ECC 里的 Claude Code 配置，不能默认等价于 Codex 配置。
Codex 是引擎，ECC 更像一套驾驶习惯。把驾驶习惯移植过来有价值，但你不能把另一辆车的按钮面板直接粘到方向盘上。
为什么不能全量搬
ECC 最早的语境更偏 Claude Code。社区项目里常见的内容包括：
- agents
- skills
- rules
- hooks
- slash commands
- MCP 配置
- installer / sync 脚本
- 安全扫描或 dashboard 辅助工具
这些东西有些能直接变成 Codex 规则，有些需要改写，有些则不应该进普通项目。
直接把整个 ECC 仓库复制进 Codex 项目，通常会遇到三个问题。
第一是 上下文膨胀。规则越多，不代表 Codex 越稳定。几十个规则文件一起塞进去，很容易让真正关键的指令被噪声淹没。你想要的是"每次任务都能读到关键规则"，不是"仓库里有很多漂亮的规则"。
第二是 语义错位。Codex 有自己的 Hooks、Commands、Slash commands 和 Skills，但 Claude Code 里的 hooks 或 slash commands 不会因为文件名一样就自动变成 Codex 原生能力。能复用的是思想和流程，不是所有配置格式。
第三是 配置污染。全局 MCP、权限规则、安装脚本、安全扫描工具一旦混进项目，后面很难判断哪些是当前项目真正需要的，哪些只是跟着全家桶一起进来的。
所以不是"搬家"，是"提炼"。
先提炼四样东西
对个人项目和中小型团队来说，最值得先落地的是这四类：
arduino
your-project/
AGENTS.md
.codex/
config.toml
ecc/
rules.md
workflow.md
security.md
.agents/
skills/
search-first/
tdd-workflow/
verification-loop/
security-review/
code-review/
...（按需增加）它们分别解决四个问题：
AGENTS.md：项目入口。只放最短、最稳定、每次任务都值得看的规则。.codex/config.toml：项目配置。把 sandbox、approval、MCP 等配置和全局配置区分开。.codex/ecc/*.md：长期工程规则。比如工作流、安全边界、协作约定。.agents/skills/：可复用任务流程。比如修构建、做代码审查、写测试、更新文档。
这里的关键是分层。
AGENTS.md 不应该变成一本小册子。它更适合做入口：告诉 Codex 这个项目有什么规则，以及复杂任务需要去哪里读更详细的流程。真正的大段规则放到 .codex/ecc/，可复用任务步骤放到 skills。
这样做有一个实际好处：规则能被维护。一个 500 行的 AGENTS.md，最后往往没人敢改；三个职责清楚的规则文件，后续增删都更容易。
为什么要做中文友好版本
Codex 能理解中文，也能读英文配置。但如果你的日常指令是中文：
帮我做一个登录页
帮我修复这个构建错误
帮我审查这个 PR 有没有安全问题
帮我把 README 更新一下那么 skills 的触发描述最好也对中文友好。
我更推荐这种写法：英文 skill name 保持不变，英文关键词保留，同时补中文触发描述。
vbnet
name: build-fix
description: Use when fixing CI, build, typecheck, compile, or test failures.
当用户用中文要求修复 CI 失败、构建错误、typecheck 报错、
编译失败或测试失败时使用。这样有三个好处：
- 兼容英文生态，后续迁移和分享成本低。
- 中文任务更容易命中合适的 skill。
- 人自己打开文件维护时，不需要在英文抽象描述里来回猜。
skill 的名字可以短，描述必须准。因为 Codex 是否自动选择一个 skill，很大程度上取决于 description 是否把触发场景写清楚。
Level 2：日常开发够用的中间层
我更倾向于把这套模板做成 Clean ECC for Codex Level 2。
它不是最小版，也不是全家桶，而是一个适合真实项目长期使用的中间层：
| 层级 | 内容 | 适合谁 |
|---|---|---|
| Level 1 | AGENTS.md + 少量基础 skills |
想试试，不想改太多项目结构 |
| Level 2 | 14 个工程工作流 skills + .codex/ecc 规则 |
日常用 Codex 做真实开发 |
| Full-ish | MCP、subagents、hooks、安全扫描等更重能力 | 团队级、重度自动化用户 |
Level 2 重点不是"装得多"，而是覆盖日常开发里最容易出问题的环节：
| skill | 解决的问题 |
|---|---|
search-first |
先查项目和文档，再动手写 |
tdd-workflow |
适合有明确行为边界的功能改动 |
verification-loop |
改完跑测试、typecheck、lint 或构建 |
security-review |
权限、凭证、输入校验、危险操作检查 |
code-review |
站在 reviewer 角度找 bug 和回归 |
frontend-patterns |
前端组件、交互、响应式和可访问性 |
backend-patterns |
后端边界、错误处理、数据一致性 |
api-design |
请求响应结构、错误码、分页、幂等性 |
docker-patterns |
Dockerfile、镜像构建、端口、体积和安全 |
deployment-patterns |
部署、回滚、环境变量、日志和健康检查 |
deep-research |
需要多轮查证和材料整理的任务 |
docs-update |
代码变更后同步 README、注释或文档 |
build-fix |
CI、编译、typecheck、测试失败修复 |
refactor-clean |
小步重构，保持行为不变 |
这些 skills 的价值不是让 Codex 多背几句口号，而是把任务流程固定下来。
比如用户说：
帮我修复 CI 里的 typecheck 报错Codex 更容易匹配到：
arduino
build-fix
verification-loop于是任务流程会变成：
rust
复现失败 -> 找第一个有意义的错误 -> 修根因 -> 重新验证 -> 汇报结果再比如用户说：
帮我设计一个订单 APICodex 可以匹配：
api-design
backend-patterns
security-review这样它更可能同时考虑请求响应结构、错误码、分页、权限、幂等性和兼容性，而不是只写一个看起来能跑的 endpoint。
怎么用
最小使用方式很简单：把三样东西放到项目根目录。
AGENTS.md
.codex/
.agents/然后用 Codex 打开这个项目。
推荐的 AGENTS.md 不需要很长：
markdown
# Project Agent Instructions
本项目使用 Clean ECC for Codex Level 2 模板。
详细规则：`.codex/ecc/`
可复用工作流：`.agents/skills/`
处理非简单任务前，按需阅读：
- `.codex/ecc/workflow.md`
- `.codex/ecc/rules.md`
- `.codex/ecc/security.md`这个文件只做入口，不负责承载所有细节。长期规则放 .codex/ecc/，任务工作流放 .agents/skills/。
如果后面确实需要更强的自动化，再逐步加 MCP、subagents 或 Codex 原生 hooks。不要第一天就把所有东西打开。
什么时候用，什么时候不用
不是所有项目都需要这套东西。
不需要：改一个小脚本、写一次性 demo、生成一段 SQL。原生 Codex 足够，额外规则反而会增加负担。
可以试试 Level 1 ：项目很小，但你希望 Codex 每次都记住测试命令、代码风格和不要覆盖用户改动。一个短 AGENTS.md 加两三个 skills 就够了。
适合上 Level 2：长期维护的项目，有测试、构建、部署流程；或者项目里同时有前端、后端、API、Docker、CI/CD。这个阶段，Codex 的问题通常不是"不会写代码"，而是"收尾不稳定"。
再考虑 Full-ish：团队协作、多仓库、多工具集成、需要权限控制或审计。这个阶段再上 MCP、subagents、hooks 和安全扫描更合理。
一条建议：不要贪多
真正有效的不是规则数量，而是四件事：
- 规则是否会被读到
- skill 是否能被正确触发
- 上下文是否干净
- 验证动作是否真的发生
我更推荐这条路线：
markdown
Codex 原生能力
+ 精简 AGENTS.md
+ 项目本地 .codex/ecc 规则
+ 少量高价值 skills
+ 需要时再加 MCP / subagents / hooks先让 Codex 在日常开发中变稳定。等你真的遇到"需要接入外部工具""需要并行审查""需要强制执行命令策略"的问题，再把更重的能力加进来。
这也是 Clean ECC for Codex 的核心取舍：先可靠，再复杂。
从聪明到可靠
AI 编程工具写代码快，这是最容易让人兴奋的地方。
但真正让人愿意长期用的，是可靠：知道什么时候先查资料，什么时候该写测试，改完要验证，安全敏感改动要小心，不要覆盖已有工作，任务结束时要汇报做了什么、验证了什么、还剩什么风险。
ECC 对 Codex 的价值就在这里。
不是把 Claude Code 全家桶塞给 Codex，而是把其中最有价值的工程习惯，重新组织成 Codex 原生能理解的形式。
最终得到的不是一个更重的项目模板，而是一套更稳的工作方式：
用 Codex 的原生能力做底座，用 ECC 的工程化思想做增强。
项目地址
我整理的 Level 1、Level 2、Level 3 模板放在这里，可以直接使用：