给 Codex 和 Claude Code 写仓库规则，怎么验收
把每次都要提醒的规则放进仓库；用一次干净会话，看看它到底有没有读到。
“记得用 pnpm”“先跑单测”“生成目录不能手改”。同样的话在不同任务里说过三次，就有理由写进仓库了。反过来，一句只适用于本周迁移的话，留在任务里比放进长期规则省事。
给 AI 的上下文与边界
用仓库里真实存在的包管理器、测试入口和生成目录做一份三条规则。分别从根目录和子目录启动干净会话，请两个工具先列出准备运行的命令，再做同一类小修改。
第一版只写能照做的指令
假设有一个用 pnpm 的前端仓库，根目录里的说明可以很短：
## 开发约定
- 安装依赖使用 pnpm；提交时保留同一份锁文件。
- 改组件后运行 pnpm test；改构建配置后另跑 pnpm build。
- src/generated/ 由 pnpm generate 产出；修改输入后重新生成。把示例里的目录和命令换成仓库里实际存在的内容。写「遵循最佳实践」省字，但无法判断有没有做到；写清生成目录从哪里来，才知道应该改哪个文件。
两个工具，两套入口
Codex 的官方说明描述了 AGENTS.md 的发现顺序，也支持在更深的目录放范围更窄的规则。Claude Code 的官方文档把 CLAUDE.md 和项目规则作为入口。两份文件承担的作用相近，但加载顺序和范围不能混用。
同时使用两个工具时，把反复变化的详细说明放在普通文档里；入口保留几条关键命令，以及在哪种任务里应该去读详细说明。否则安装命令改一次，三份重复文本漏掉一份，助手反而更容易走错。
用两次新会话检查作用范围
在根目录开一次新会话，再从需要特殊规则的子目录开一次。给两个会话同一张小改动单，让它先说明改动后要跑什么、有哪些目录不能直接改，再看实际执行是否符合预期。复述对了、运行错了，也是一个有用的结果：可能是这条规则不够明确，也可能是工作目录本身不对。
修一条规则前，先确认客户端、启动目录和实际读到的文件。这样不用靠不断加粗同一句话来猜问题出在哪里。
可以直接照着做的演练
准备一个根任务「改首页按钮」和一个子目录任务「改生成器输入」。两次会话都从同一提交开始，并保存实际运行命令。验证记录只列工具版本、启动目录、应执行命令、实际命令。只有子目录任务有理由运行生成脚本。
检查生成结果
- 根任务使用仓库既有包管理器。
- 特殊子目录运行局部检查。
- 工具能说清生成文件应该改输入、随后重新生成。
复查时追问一层
工具口头复述规则只证明看到了某段内容，还要核对执行日志。若两次结果不同，记录客户端、启动路径和文件位置，再查各工具的加载说明。保留能用检查结果验证的规则，删掉每次都要靠人解释的口号。
如果团队同时用两个客户端，让助手先找规则共有部分与客户端专用入口。包管理器和测试命令只保留一份权威说明，再让入口按使用场景引用。改完其中一个命令后，分别用两种工具跑实际验证，防止旧规则仍从另一文件生效。
