项目规则：把重复纠正固化
项目规则文件是给 agent 看的项目 README。Codex 读 AGENTS.md，Claude Code 读 CLAUDE.md。它们都不是安全边界，而是长期上下文：越具体、越短、越贴近真实项目，越有用。
本章目标
- 知道哪些内容适合写进规则文件，哪些不适合。
- 会把重复提醒改成可执行、可验证的规则。
- 知道如何在 Codex 和 Claude Code 之间保持单一事实源。
规则文件应该写什么
- 项目结构：核心目录、内容位置、共享组件、生成入口。
- 常用命令：dev、lint、test、build，以及什么时候跑哪个。
- 工程约定：代码风格、组件边界、服务端/客户端限制、PR 要求。
- 验证标准：不同类型改动的最低检查项。
- 高频坑点：agent 或新人反复踩过、代码本身看不出来的项目事实。
好规则要能触发、能执行、能验证
“注意质量”“代码要优雅”不是好规则。好规则应该让 agent 知道什么时候触发、具体怎么做、做到什么程度算完成。
CASE
把空泛规则改成可执行规则
场景
你想让它修前端时别再漏移动端，但“注意响应式”太泛。
可以这样说
请把这条模糊规则改写成 AGENTS.md 中的可执行规则：修改前端布局时必须用浏览器检查 390px 和 1440px；如果涉及图片、代码块或 SVG，还要确认没有横向溢出。保持简洁，写明触发场景和验证方式。验收点
- 有触发场景。
- 有具体动作。
- 有验收方式。
- 没有空泛形容词。
CASE
让它对模糊任务先问再做
场景
它经常拿到需求直接开干，遇到没完全想清的任务就做偏。
可以这样说
请在规则文件里补一条：开始任何非 trivial 任务前，先用 2-3 个问题确认范围和验收标准，得到回答后再动手；任务已经明确时可以跳过。说明触发场景，保持简洁。验收点
- 只在非 trivial 任务触发。
- 要求确认范围和验收。
- 表达简洁可执行。
- 不改无关章节。
哪些不要写进去
- 一次性的当前任务要求，放在 prompt 里。
- 个人临时偏好，除非后续每次都要遵守。
- 标准语言常识或代码里能直接看出来的事实。
- 详细 API 文档，给链接或放到 Skill / docs 里。
- 过长背景故事；文件越长，关键规则越容易被淹没。
保持单一事实源
如果仓库里同时有 AGENTS.md 和 CLAUDE.md，最大的风险是两份规则各自演化。长期规则应该维护一份主版本，另一份引用或同步，不要在两处写出不同版本。
- Codex：以 AGENTS.md 作为项目级规则。
- Claude Code：CLAUDE.md 可以导入 AGENTS.md，再补 Claude 专属内容。
- 更新规则时：说明新增规则来自哪次复盘、触发场景是什么、如何验证。
- 规则也要 review：冲突、过期、太长都会降低遵从度。
规则不是安全边界
规则文件是上下文，不是硬约束。它能提高遵守项目习惯的概率，但不能保证 agent 永远不碰某个路径、不运行某条命令、不泄露某段内容。绝不能发生的动作，要用权限、沙箱、deny 规则或 Hook 挡住。
- 适合规则文件：构建命令、代码风格、项目结构、验收习惯、PR 约定。
- 适合硬约束：禁止读取 secrets、禁止改生产迁移、禁止联网外发、阻止危险命令。
- 规则反复失效：先检查是否太长、太泛、太隐晦，再考虑用 Hook 或权限强制。
照着做
请根据最近三次我纠正你的地方，整理出最值得写进规则文件的 3 条规则。每条都要说明触发场景、具体做法和验证方式；一次性偏好不要写进去。