用途
codex-review 用于在 Claude 托管的会话中进行代码审查，直接调用 codex 二进制实现跨模型验证：Claude 写代码，Codex 审代码。其核心洞察是单模型自我审查存在系统性偏差，而跨模型审查能发现不同类别的缺陷，因为审查者与作者具有根本不同的盲点。
需要诚实界定独立性的范围：不同模型打破的是自审偏差——仅此而已。它无法发现共享训练带来的过时问题（版本、SOTA、生态主张无论多少模型同意，都需要实时一手来源），也无法避免从任务简述中继承的意图误读（应把用户的原始请求原文带入提示词，并要求审查者挑战该解读）。
主要能力
两种调用方式：
- codex review：结构化 diff 审查，按优先级给出发现项，适用于 pre-PR 审查、提交审查、WIP 检查。
- codex exec：自由形式的非交互深度调查，完全控制提示词，适用于安全审计、架构、聚焦调查、规范文档。
范围标志（仅 codex review）：--base <BRANCH> 与基线分支比较；--commit <SHA> 审查特定提交；--uncommitted 审查工作区改动。当审查对象根本不是 diff（规范文档、未纳入版本控制的单文件、自由调查）时，应使用 codex exec "PROMPT"，绝不使用裸 codex review。
沙箱与易用性标志（两种模式通用）：--sandbox read-only（审查工作的默认，不写入）、--sandbox workspace-write（审查并应用建议修复）、--full-auto、--dangerously-bypass-approvals-and-sandbox（最后手段，仅在用户明确要求时）、-C/--cd <DIR>、--skip-git-repo-check、--add-dir <DIR>、--ephemeral、--json / --output-last-message <FILE>、-c model_reasoning_effort="xhigh"。
使用方式
前提条件：必须安装并认证 codex CLI，用 codex --version 验证。用户默认配置位于 ~/.codex/config.toml，应予以尊重。方向为 Claude → Codex 单向；若需双向技能（也处理 Codex → Claude），应使用 /hyperskills:cross-model-review。在 Pi 上安装 pi-nova xreview 扩展时优先使用 /xreview。
两条不可协商规则：
规则一：始终为 codex review 传入范围标志。裸 codex review（无范围）是失败的头号原因：它会挂起或产生 100KB 以上的大块输出。始终精确指定一个范围标志。已限定范围的 codex review 还接受结尾的 [PROMPT] 参数作为自定义指令。
规则二：将输出捕获到文件，不要管道传给 tail。切勿把审查输出管道给 | tail -N，原因有三：管道会缓冲到 EOF，tail 先读完整条流才输出，审查结束或超时前得不到任何输出；审查结论通常靠近顶部而非底部，发现项按严重度排序（BLOCKER 在前），tail -300 恰好切掉你想要的部分；文件可让人实时观察进度，在另一终端 tail -f /tmp/review.txt 可实时流式查看。正确做法是用 mktemp 选择不冲突的文件名，重定向后再读回。另外，在 --sandbox read-only 下，Codex 无法按提示词要求写出报告文件，应通过重定向或 --output-last-message 捕获，绝不要写“把报告写到 X”。
输出超过约 100KB 时说明 diff 对单次审查过大，应按提交拆分，或用 codex exec 配合更窄的提示词。在脏分支或多工作流分支上，应给出明确的文件列表或把精确 diff 管道传入 codex exec，避免审查者扩散到无关 diff。审查运行期间不要编辑被审查的代码；结论产生后再编辑即作废，需针对该增量重新审查。
审查模式
模式一：Pre-PR 完整审查（默认）。第一步结构化审查 codex review --base main；第二步安全深挖（若代码涉及认证、输入处理或 API）；第三步修复发现项后携带台账重新审查。同一形态可用于按提交或开发中的工作区。
模式二：聚焦调查。针对特定关注点（错误处理、并发、数据流）进行外科式深挖，使用 codex exec。
模式三：规范 / RFC 审查。在写代码之前审查散文（markdown 设计文档），配合 model_reasoning_effort="xhigh"。
模式四：单文件 / 聚焦路径审查。只审查一个文件或目录，而非完整 diff。
模式五：Ralph 循环（实现 → 审查 → 修复）。第一轮宽泛且严苛；后续每一轮携带台账：逐条列出上一轮的发现及声称的修复，要求审查者（a）用证据验证每个修复，（b）寻找修复引入的新缺陷，（c）不再重提已定论的权衡。范围逐轮衰减：宽泛 → 仅阻断项 → 用一行契约做收敛检查。预算的目标是收敛而非轮数：只要每轮产生新的确认发现或验证了修复就继续，轮次震荡或反复重提时停止。默认预期三轮，但不是硬墙。
多轮策略：正确性（codex review）、安全（codex exec 安全提示词）、架构（codex exec 架构提示词）、性能（codex exec 性能提示词）。当 diff 在审查中变化时，应按顺序运行各轮，并在轮次之间修复关键发现；在冻结的产物上，可并行运行各锁定视角的审查。行数是粗略指引，应按风险与规模而非算术来安排：小于 50 行的单一关注点用单次 codex review；50–300 行的功能工作用 codex review 加安全轮；300 行以上或架构变更用完整四轮；安全敏感（认证、支付、加密）始终包含安全轮。
消费审查结论
审查者输出是输入而非命令。任何编辑前，应针对代码、git 历史、实时数据等事实基准复核每一条发现。三种处置始终要报告：立即修复 / 有意保留并说明理由 / 无法验证并标记给人工。“已验证，无需改代码”是合法结果。用证据反驳错误发现，绝不静默丢弃。两个独立简报的审查者如果都指向同一缺陷，则该缺陷升级为已确认。
提示词工程要点与反模式
有效提升审查信号质量的杠杆：明确说明跳过什么（“跳过格式化、命名风格、次要文档缺口”）；要求置信度分数并只处理 ≥ 0.7 的发现；每轮只聚焦一个领域；要求给出结论。
常见反模式包括：裸 codex review（无范围标志）会挂起或产生大块输出，应精确指定一个范围标志；把输出管道给 tail -N 会缓冲到 EOF 并切掉结论，应重定向到文件；timeout 30 codex review 时间过短（审查合理耗时 30 秒到 5 分钟），应不加超时或至少 timeout 300；把 transcript 大小当作失败信号（1MB 以上的 codex exec transcript 可能是成功的深挖），应按增长与是否收敛到结论判断；“审查这段代码”（无具体信息）过于含糊，应用带角色设定的具体领域提示词；单一轮次审查一切会导致上下文稀释，应多轮、每轮一个关注点；自审（Claude 审查 Claude 的代码）存在系统性偏差，应跨模型；无置信度阈值会噪声淹没信号，应只处理 ≥ 0.7；审查中的风格评论会滑向细枝末节，应声明跳过；跨轮重提已定论发现会超预算；无项目上下文的审查产出脱离代码库的通用建议，应从仓库根运行；对 codex 做 MCP 封装是不必要的间接层，应通过 Bash 直接调用 codex；硬编码 --model/-m/-c model= 会覆盖用户配置并使用过时模型名，应尊重 ~/.codex/config.toml；对常规代码审查做 effort 覆盖会浪费 token 并忽视用户默认值。
适用场景与限制
适用场景：pre-PR 与提交审查、WIP 检查、安全审计、架构与性能专项调查、设计文档 / RFC 的事前评审、单文件审查，以及迭代式实现—审查—修复循环。
限制与已知风险：评审可能挂起——输出文件是存活性指标，应按增长与进程状态判断，绝不按流逝时间；输出文件在增长就继续等待；文件为空但进程树存活时再等一个窗口，然后隔离变量（截至 2026 年 7 月，卡住的 MCP 服务器与启动钩子是常见元凶）；文件为空且进程卡死时只杀该进程树，用更少自由度重试一次；重试仍卡住则预先声明放弃并如实记录失败审查。切勿在有审查者运行时再生成一个副本。Codex 特有的易漏点需优先检查：时间范围（它审查的是发现所声称的提交状态吗）、近似名称混淆（引用的产物确实是变更过的那个吗）、虚构的标志/API（建议的标志或函数是否存在，用 --help 验证）、修复时已过时（抱怨在审查时成立但现已解决）。
缺失信息：资料未提供该技能的收费、价格、支持平台清单或效果保证，暂未提供。