给 Codex 写了评审规则，怎样用正反例检验规则是否会误报

评审规则写进 AGENTS.md 后，先验它能否被人一致判读，再测 Codex 是否遵守。比如“不要泄漏客户信息”很难验收：脱敏邮箱算不算，测试夹具算不算，前端展示算不算，都没有答案。一条能用的规则应同时说明要保护的事实、适用目录、触发行为和允许的安全做法。

用一条日志规则收窄争议

本文合同是：生产目录 src/ 中新增日志不得输出原始客户邮箱；已经经过 mask_email 的值可记录；tests/fixtures/ 中的合成文本不适用。这是演示规则，不是 Codex 内置的隐私检测器。官方评审规则资料说明可以在 AGENTS.md 中放置有范围的评审指导，但不会替项目决定哪些字段属于客户数据。

把规则标成 LOG-EMAIL-01，三个样本分别是生产日志直接拼接 customer.email、生产日志调用脱敏函数、夹具里出现虚构地址。人工预期依次为应报、豁免、不适用。三者都带路径、差异、判断理由及规则编号；只写一段“这次不应该报”的说明，后续无法确认它对应哪条规则。

先检查矩阵，再看模型表现

附件检查器只检查同一规则是否具有三类样本，以及每项是否具备可定位的差异和理由。完整集合通过；删掉豁免项后必须失败。这能发现测试集只奖励“多报一点”的偏差，却不能证明模型已经理解脱敏函数。检查器没有调用 Codex，因此这里没有识别率、误报率或真实拉取请求评审结果。

真正评测时应固定仓库快照、规则文本与输入差异，把实际发现单独记录。违规项未指出目标日志是漏报；豁免项仍要求删除日志是误报；不适用项被规则干扰则要检查范围。不要把检查器通过的结果复制到“模型评审通过”一栏。模型多说一条笼统建议，也不自动等于正确命中。

反例暴露的是规则边界

假如脱敏函数仅遮住用户名，但项目要求域名也不能进入日志，那么第二个样本的人工预期本身就错了。修复顺序是先更新合同和人工标签，再重新运行同一批评审，保留旧版本结果。不要为了让当前输出好看，临时把误报样本从集合删掉。

规则增加后还应保留原有普通缺陷用例，避免评审只围着规则打转。每条新规则不必追求大量样本，先把必报、明确安全路径、无关变化这三个判断做扎实。人工标签有争议时标为待裁定，不能把争议混入准确率分母。已有的 AGENTS.md 放置与配置方法可继续沿用；本文新增的是规则的可判定性验收，而非重复配置说明。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a001.json，离线检查器 a001.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a001.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。