Everything Codex 

1. 它是什么

everything-codex 是当前这台机器上对 ECC 思路做的 Codex 化入口名。

它不是一条 shell 命令，也不是一个后台常驻进程。 它更像是一套可显式调用的工作流约束，用来让 Codex 在真实工程里按更严格的方式做事：

• 先读代码和文档

• 再给计划

• 再实现

• 再验证

• 最后交代风险和未验证项

2. 它会不会主动执行

分两层理解：

自动生效的部分

这些是被动常驻的，不需要你每次都说：

• 全局 C:\Users\Administrator\.codex\AGENTS.md

• 全局 C:\Users\Administrator\.codex\config.toml

• 已安装的全局 skill / agent 能力

它们负责提供全局默认行为和能力底座。

需要你显式触发的部分

everything-codex 这类 skill，最稳妥的用法是你在提示词里明确点名。

也就是说，实际使用时建议你直接写：

使用 everything-codex。

不要指望它像后台守护程序一样自动替你决定所有流程。

3. 在 Codex 里怎么调用

重点：这里大多数不是 shell 命令，而是你给 Codex 的提示词模板。

最常用固定句式

3.1 严格工程流程

使用 everything-codex。
先阅读工程相关代码和文档，再给计划，再实现，再验证。

3.2 整理项目资料为 Markdown

使用 technical-writer。
阅读 docs/_sources 下的芯片手册、原理图说明、SDK 文档和笔记，
整理成一份项目总览.md，不确定的地方标注待确认。

3.3 梳理模块边界 / 状态机

使用 architecture-patterns。
先梳理当前模块边界、状态机和数据流，再给出设计建议。

3.4 改完后强制验证

使用 verification-loop。
改完后运行能做的本地验证，并明确说明哪些验证无法在当前环境完成。

3.5 做风险审查

使用 security-review。
按高风险优先审查保护逻辑、边界条件、异常恢复和协议兼容性。

3.6 按本地嵌入式风格写代码

ex_entry
按当前工程已有风格修改代码。
先读目标文件，再参考同风格状态机和 *_opt 模式。

4. BMS 项目里最常用的调用模板

4.1 新建或整理项目知识

使用 technical-writer + everything-codex。
阅读这个 BMS 工程的芯片资料、模块 PDF、原理图说明、SDK 和源码目录，
整理出 docs/00_source-index.md、docs/03_mcu-sdk-summary.md、docs/04_power-tree-and-io-map.md。

4.2 实现一个真实模块

使用 everything-codex + architecture-patterns + verification-loop。
在现有 BMS 工程中实现 pack_voltage_filter 模块。
先确认模块边界、输入输出、执行周期和参数来源，再实现并验证。

4.3 审查保护逻辑

使用 everything-codex + security-review。
审查过压、欠压、过流、过温、MOS 关闭时序、锁存与恢复条件。
先输出高风险问题，再给修改建议。

4.4 改协议模块

使用 everything-codex + verification-loop。
修改 CAN 接收解析模块。
先确认兼容性风险、报文字段、校验和长度，再动代码。

5. 这些“常用命令”到底是什么

对 Codex 来说，最常用的不是 ECC 原来那种 slash command，而是你在提示词里显式写 skill 名。

可以把下面这些当成你日常最常用的“命令口令”：

• 使用 everything-codex

• 使用 technical-writer

• 使用 architecture-patterns

• 使用 verification-loop

• 使用 security-review

• ex_entry

如果你想要最稳定的效果，优先用这种写法，而不是省略 skill 名。

6. 模块 M 案例演示

这里用一个 BMS 场景里的模块 M 做例子：

M = cell_ovp_detect 职责：检测单体过压、给出告警/保护触发依据。

6.1 无 EC / 无 everything-codex 的情况下

你可能会这样问：

帮我写一个 cell_ovp_detect 模块。

典型结果：

• Codex 可能直接开始写代码

• 容易自己发明接口和命名

• 不一定先读现有采样链路和故障状态机

• 可能忽略滞回、恢复条件、延时判定

• 可能不说明参数来源和验证方式

这类输出在“写出一段代码”上可能很快，但工程风险较高。

6.2 有 EC / 使用 everything-codex 的情况下

建议你这样问：

使用 everything-codex + architecture-patterns + verification-loop。
在这个 BMS 工程里实现 cell_ovp_detect 模块。
先阅读现有 ADC 采样、参数表、故障状态机和保护上报逻辑。
先确认模块边界：它只负责检测，还是同时负责锁存、恢复和上报。
实现后做你能做的本地验证，并说明硬件侧还需要验证什么。

典型处理流程会变成：

1. 先读已有工程中的采样入口、参数结构、故障处理链路

2. 确认 cell_ovp_detect 的职责边界

3. 列出风险点：

   • 阈值来源

   • 延时判定

   • 滞回恢复

   • 与全局故障锁存的关系

4. 再实现代码

5. 最后交代：

   • 运行了哪些本地验证

   • 哪些需要上板验证

   • 还剩哪些残余风险

6.3 结果差异

无 EC：

• 更像“一次性生成代码”

• 速度快，但更容易漏工程上下文

有 EC：

• 更像“按工程流程实现模块”

• 速度略慢，但边界、验证、风险控制更完整

7. 对 BMS 项目的实际建议

如果你在做 MCU / BMS 固件，最推荐的固定组合是：

• 平时实现模块：everything-codex + verification-loop

• 牵涉状态机或模块边界：everything-codex + architecture-patterns

• 牵涉保护逻辑：everything-codex + security-review

• 整理芯片文档、原理图和 SDK：technical-writer

• 需要贴近你现有嵌入式 C 风格：ex_entry

8. 一句话总结

everything-codex 不会替你自动完成项目，也不是后台自动运行程序。

它的真正价值是：当你显式调用它时，Codex 会更像一个按工程流程做事的开发者，而不是一个只会即时生成代码的助手。