Codex Rules：把常用约束写成可复用规则

适用场景

这篇手册适合已经有一套稳定 Codex 使用规范的团队。比如“修改前端必须检查移动端”“写文章不能用意向图”“提交前必须说明验证命令”，这些要求经常重复出现，就可以考虑沉淀为 Rules。

OpenAI 官方文档把 Rules 放在 Codex 自定义能力里，用于让 Codex 在任务中遵守更稳定的行为约束。

步骤 1：先整理哪些规则真的稳定

适合写成 Rules 的内容：

• 长期有效的团队约定。
• 多个项目都会使用的安全边界。
• 输出格式要求。
• 审查或验证清单。
• 常见错误的禁止项。

不适合写成 Rules 的内容：

• 只针对一次任务的要求。
• 仍在讨论中的临时偏好。
• 过于宽泛的抽象描述。
• 会频繁变化的版本号或临时链接。

规则越稳定，越适合抽出来复用。

步骤 2：把规则写成可执行语言

不要写：

保持高质量。

应该写：

修改代码后，说明运行过的验证命令。如果没有运行测试，必须说明原因。

Codex 更容易执行明确动作，而不是抽象价值判断。

步骤 3：避免和 AGENTS.md 冲突

如果项目里已经有 AGENTS.md，Rules 应该补充它，而不是制造冲突。

推荐分工：

• AGENTS.md：仓库内规则，例如目录、命令、内容字段。
• Rules：跨项目通用偏好，例如回答格式、安全边界、审查习惯。

如果两边都写了同一规则，要保持表述一致。

步骤 4：从少量高价值规则开始

不要一次写几十条 Rules。先从 3 到 5 条最重要的开始。

示例：

不要生成概念图或意向图来冒充产品截图。

修改内容站文章时，必须检查 frontmatter 是否包含 title、description、date、updated、category、tags、source、status。

完成代码修改后，优先运行项目已有 lint 或 build 命令，并在最终回复中说明结果。

这些规则都足够具体，Codex 可以实际遵守。

步骤 5：定期清理过期规则

Rules 是长期约束，但不是永久不变。项目流程、工具和团队习惯变了，旧规则也要删掉。

建议每隔一段时间检查：

• 是否有重复规则。
• 是否有和项目实际不符的规则。
• 是否有过时命令。
• 是否有太宽泛、执行不了的规则。

常见错误

不要把 Rules 写成愿景文案。它应该像操作清单，而不是团队宣言。

不要让 Rules 和当前任务互相打架。如果确实要临时覆盖规则，在提示词中明确说明原因。

不要把敏感信息写进 Rules。Rules 应该只包含通用约定。

小结

Rules 适合管理长期、稳定、跨任务的 Codex 行为约束。写规则时要具体、可执行、可验证，并和 AGENTS.md 做好分工。