先选审查入口，再决定要不要安装 Skill
“代码审查”可能指本地差异、GitHub 拉取请求、仓库约束，或一套可复用的分析流程。这些需求适合放在不同位置。先明确要审查什么，再选择覆盖它的最小机制。
| 需求 | 先用什么 | 适用原因 |
|---|---|---|
| 未提交、暂存、分支或提交中的改动 | Codex /review | 针对选定的本地改动集给出审查结果，不修改工作区 |
| GitHub 拉取请求 | Code Review 应用 / 已连接的 GitHub 审查 | 把 PR 差异、评论、检查结果和审查上下文放在一起 |
| 这个仓库长期有效的专属规则 | AGENTS.md | 让简洁的项目规则靠近它所约束的代码 |
| 格式、类型或可重复验证的约束 | 测试、Linter 与 CI | 确定性检查可以阻止合并，而不只是提出建议 |
| 反复执行的专门审查步骤 | 聚焦的自定义 Skill | 可以封装有边界的流程、输出约定和禁止写入要求 |
Codex 内置审查已经能做什么？
对于 Git 仓库中的本地改动，Codex 提供 /review 流程，可以选择审查未提交改动或与基准分支比较。它会返回带优先级的发现，但不会修改工作区。这是产品功能，不是需要额外安装的 Skill。
对于拉取请求，Codex Code Review 应用可展示 PR 描述、改动文件、评论和检查结果。仓库触发或自动审查取决于是否连接了正确的来源账号、仓库权限和审查设置。如果只是想让 Agent 再看一遍差异，先确认现有入口是否已经满足需求，再考虑额外安装。
- 目标是本地 Git 改动，还是托管平台上的拉取请求？
- 审查能否看到准确的差异和预期行为？
- 当前流程是否只给出发现，而不会直接应用修改？
把仓库专属规则放进 AGENTS.md
如果审查者总要提醒某些长期约束，可以用 AGENTS.md 记录：例如兼容性承诺、数据边界或跨服务不变量。Codex Code Review 可以采用相关仓库规则，并在发现中引用规则，让重要背景跟着代码走，而不是只留在资深审查者的记忆里。
每条规则都要具体：说清风险、触发审查的条件和安全的替代方案。“保留这个公开 API 字段，或新增向后兼容的替代字段”比“检查兼容性”更可执行。服务专属规则放在相应目录附近；机械的格式与样式检查交给 CI，不要让文字规则和确定性工具争抢注意力。
- 从两三条影响重大的规则开始，不要堆一份无所不包的政策清单。
- 根据规则适用的目录或改动类型控制范围。
- 写出有效且安全的替代路径，让审查能区分违规和有意的例外。
什么情况下独立的 Codex 代码审查 Skill 才值得用？
当自定义 Skill 增加了 /review 和仓库规则尚未表达的可复用步骤时，它才真正有用。例如一套只读、缺陷优先的审查约定：完整查看目标差异，检查相关测试和调用位置，只输出有证据的可操作发现。
OpenAI 的 Codex 仓库包含一个 review-agent Skill 示例，展示了这种明确约定。它是供人检查的例子，不代表每个仓库都应该安装。该示例禁止编辑文件、提交、推送、发布审查评论和继续委派；价值在于审查纪律与输出边界，而不是承诺更准确的审查结果。
- Skill 负责独立的审查任务，而不是重复触发内置审查。
- 文件读取、写入、命令、网络和凭据权限与任务匹配；“只读”边界还要同时符合指令和附带脚本。
- 发现应指向具体的改动路径和证据，而不是猜测或风格偏好。
先用小型测试检验审查质量
SKILL.md 写得很完整，不等于审查真的有用。选三组小而可控的差异，用同一套指令检查：一组包含规则应抓出的重要缺陷；一组是有效的安全反例，不应报错；最后一组与规则无关，不应引来无关发现。将实际结果与预期逐项比较。
- 已知缺陷会产生具体、可操作且对应改动代码的发现。
- 安全例外和无关差异不会产生噪声或编造的发现。
- 审查会检查完整目标差异，而不是发现第一个问题后就停止。
- 结果说明测试缺口和剩余风险；“没有发现”不等于证明改动正确。
Skill 是额外审查者，不是合并门禁
Codex 审查可能漏掉缺陷，也可能提出需要结合上下文判断的发现。应针对当前差异、预期行为和测试逐项核实。真正决定是否合并的控制仍应包括必要测试、分支保护和人工批准。
结论：不要只因为搜索词里出现了“Skill”，就安装一个 Codex 代码审查 Skill。先分别用 /review 审查本地差异、用 Code Review 处理已连接的 PR、用 AGENTS.md 维护长期规则、用 CI 执行确定性检查。只有受控测试证明独立 Skill 带来额外价值，且没有扩大权限或制造噪声时，再考虑加入。