Adversarial review

对抗评审

一句话：同一份内容，Claude(Opus) 和 GPT(5.5) 各出一份独立评审，再由 Opus 当裁判逐条裁决。

主线程负责打证据包、并行发起两份评审、最后跑裁判轮并写报告。流程只有一条，没有模式分支。

---

0. 核心哲学

为什么要两份独立评审，而不是一份？

1. 视角正交：Claude 和 GPT 是两套不同的模型，关注点、盲区、偏好都不同。同一份方案，两边会挑出不同的问题。合起来覆盖面远大于任何单一评审者。
2. 生成与评审是不同语境：即使被评审的方案出自某个模型，换到「评审」语境（哪怕同型号模型）也能发现设计时忽视的盲区——设计时的目标是"让方案自洽完整"，评审时的目标是"找漏洞、找边界、找过度设计"，认知工具不同。
3. 裁判收口：两份评审难免有噪声、有互相矛盾。Opus 裁判逐条裁决"哪条成立、哪条驳回"，把两份评审收敛成一份经得起挑战的结论。

不必隐瞒方案出处。 只要明确告诉模型"你现在是评审者"或"你现在是裁判"，Claude 和 GPT 都能公正工作——它们足够聪明，知道评审角色该干什么。是否知道方案是谁设计的，不影响评审质量。所以本 skill 不做任何"身份隐瞒"，只做清晰的角色设定。

---

1. 角色与模型

角色	调用方式	默认模型	降级（用户要"快/省"时）
评审者 A	Agent 工具	opus	sonnet
评审者 B	codex exec	gpt-5.5（reasoning xhigh）	gpt-5.5（reasoning medium）
裁判	Agent 工具	opus	sonnet

Claude 侧默认 Opus（评审和裁判都用 Opus）。GPT 侧固定 gpt-5.5 超强思考模式，与 Opus 的高规格默认对齐。

同源亲和风险：裁判与评审者 A 同为 Opus，Claude 占两席、GPT 一席，裁判可能仅因「表述顺眼/同源」而系统性偏向 A 侧批判。为此裁判 prompt 内置抵消指令（§5.1）：对 A 侧批判额外加压审视、如实标注采纳来源分布。

降级：用户说"用 sonnet 快速过一遍 / 省点跑"时，评审者 A 与裁判降 sonnet，评审者 B 加 -c 'model_reasoning_effort="medium"'。codex 是 GPT 的唯一调用路径。

成本提示：默认（Opus + gpt-5.5 xhigh）质量最高、也最贵、最慢（评审轮常 60–180s，复杂方案更久）。设计早期快速迭代可用降级档，定稿前的核心审查用默认档。

---

2. 总体流程

主线程
  │
  ├─ ① 打证据包（§3）—— 评审对象 + 约束 + 判断标准
  │
  ├─ ② 并行发起两份评审（§4，同一份评审对象）
  │     评审者A：Agent(opus) 批判      ┐  run_in_background
  │     评审者B：codex(gpt) 批判        ┘  并行、互不等待
  │
  ├─ ③ 两边都完成 → 收齐 C_claude + C_gpt
  │     （codex 输出经文件中转：其后台进程退出后，需再起一次 Bash 粘 $SCRATCH 字面值 cat gpt-out.txt 取 C_gpt）
  │
  ├─ ④ 裁判（§5）：Agent(opus) 读 评审对象 + C_claude + C_gpt
  │      → 逐条裁决采纳/驳回 → 写报告到指定路径
  │
  └─ ⑤ 验收（§11）→ 报告用户：报告在 [路径]，采纳 N 条 / 驳回 M 条

唯一需要向用户确认的是输出文件路径（§3 未给到就开口问）。其余无需路由、无需选模式。

---

3. 证据包

证据包的方法论直接复用 ask-sonnet/references/dispatch.md（或 ask-opus/references/dispatch.md，两份一致）的 RAM 框架：R（谁读）/ A（干什么）/ M（最小充分集），三种交付方式（内嵌 / 引用 / 混合），约束区内嵌原文，输出要求必须声明，附带最小必读清单。复杂场景回去读 dispatch；这里只补对抗评审专属的两条规则。

3.1 对抗评审专属规则

① 评审对象逐字内嵌、不压缩。 dispatch 的通则是"先浓缩、禁贴原始代码"——那是因为代码在普通问答里只是背景。但在对抗评审里，被评审的设计文档 / 代码本身就是评审对象（A 的宾语），压缩了就没法评。所以：

• 评审对象：原样内嵌，不压缩、不改写。设计文档贴全文；代码贴相关文件/方法的真实内容。
• 它周围的约束 / 判断标准 / 背景：仍按 dispatch 的最小化压缩。
• 体量逃生口：评审对象会被发送三次（评审者 A、评审者 B、裁判各一份）。若对象超大、贴全文会撑爆任一侧 prompt 上下文，则不内嵌，改用 §3.1② 的「同一份最小必读清单」把对象钉死（两侧与裁判读同一清单），并在证据包注明「对象过大，以引用方式钉定」。默认仍是内嵌；只有撑爆风险时才走此口。

② 钉对象、不钉视野。 两个评审者必须评的是同一份对象——评审对象要么内嵌（天然一致），要么作为同一份最小必读清单给到两边。但佐证上下文各自自由补读：不要求两份评审"读了完全相同的东西"。Claude 多读一段、发现 GPT 没发现的真问题，正是我们要的独立性，不是 bug。（这与 dispatch 松绑后的"最小必读 + 可自行补读"一致。）

3.2 打包清单

□ 评审对象（必填）
  - 原样内嵌（设计文档全文 / 代码真实内容），不压缩
  - 注明类型：设计文档 / 代码 / 其他方案

□ 输出文件路径（必填）
  - 用户指定 → 直接用
  - 用户未指定 → 问用户："评审报告写到哪个文件？"
  - 不允许 Claude/GPT 自己决定路径
  - **拿到路径后第一步：派生本轮 scratch 目录，并记住下方 echo 出的两个字面值**（见「scratch 隔离」）

□ scratch 隔离（并发安全，必做）
  - 多 worktree / 多 agent 并发跑对抗评审时，临时文件若用全局固定名会互相覆盖 ——
    A 的子线程会读到 B 的 prompt / 评审结果，导致「评审串台」。
  - **派生一次（不是每次重算）**：本轮开始时跑下面这段一次。它把"输出路径哈希"当可追踪前缀、
    再用 `mktemp -d` 原子加唯一后缀（run-id），生成本轮专属目录。**记住 echo 出的 `ABS_REPORT` 与 `SCRATCH` 两个字面值**，
    后续每个 Bash 调用（写 prompt、读 gpt-out、§11 验收）**直接粘这两个字面值，不要重跑 mktemp**（重跑会建新空目录）：

    ```bash
    REPORT='<用户指定的输出报告路径>'        # 路径含单引号等特殊字符时需转义，或改 here-doc 传入
    case "$REPORT" in /*) ABS_REPORT="$REPORT" ;; *) ABS_REPORT="$PWD/$REPORT" ;; esac
    PHASH=$(printf '%s' "$ABS_REPORT" | shasum -a256 | cut -c1-12)   # 仅作可追踪前缀，非隔离保证
    SCRATCH=$(mktemp -d "/tmp/adv-review-${PHASH}-XXXXXX")           # mktemp 原子保证唯一，这才是隔离保证
    echo "ABS_REPORT=$ABS_REPORT"; echo "SCRATCH=$SCRATCH"           # ← 记住这两行字面值，后续直接复用
    ```

  - **为何隔离靠 `mktemp` 而非路径哈希**：路径哈希只防"路径不同"的任务，**挡不住两个并发 agent 写到同一报告路径**
    （同 worktree 重跑、或固定输出文件名习惯）—— 那种情况哈希相同会串台。`mktemp -d` 的唯一后缀按"运行实例"隔离，
    任意并发（含同路径）都落不同目录。代价：**放弃"同路径重跑复用同一 scratch"**——重跑本就该重算，每轮全新目录反而免去残留污染。
  - **为何 `mkdir`/哈希都不再"每次重算"**：`mktemp` 是随机的、不可重算，所以隔离目录只能"生成一次 + 字面值携带"，
    不能像旧版那样靠确定性公式在每个 Bash 调用里重算（这也顺带消除了 `$PWD` 在调用间漂移导致自串的风险）。
  - **为何不用 `realpath -m` 绝对化**：BSD/macOS 的 `realpath` 不认 `-m`（GNU 专有），会报错。纯 shell `case + $PWD`
    跨 macOS/Linux 可移植、不依赖文件已存在。（`shasum` 在 macOS 默认可用；纯 Linux 若无 `shasum` 换 `sha256sum`，
    二者哈希均在行首，`cut -c1-12` 取值正确。）
  - 残留目录 `/tmp/adv-review-*` 不会自动清理，靠系统 `/tmp` 回收；如需即时清理，本轮收尾可 `rm -rf "$SCRATCH"`（非阻塞）。

□ 约束（如有）
  - 从 CLAUDE.md 摘出适用条款，内嵌原文（不写"参考 CLAUDE.md"）
  - 用户本轮明确说的限制
  - 没有就写"无"

□ 判断标准（如有）
  - 用户说了"好方案应满足 X" / "重点看 Y" → 记录
  - 没有就写"无"

□ 非范围（如有）
  - 哪些内容不要评、不要动
  - 没有就写"无"

发包前两条快速校验：(1) 有没有与评审无关的内容（聊天记录、历史上下文）→ 删除；(2) 有没有漏掉用户这轮明确说的要求 → 补上。

---

4. 阶段一·并行双评审

主线程把 §3 的同一份评审对象，配上同一套批判者角色设定，分别发给评审者 A（Agent/Opus）和评审者 B（codex/GPT）。两轮并行（§8），互不等待。

4.1 批判者 prompt 模板（A、B 共用）

你是一个尖锐、不留情面的设计/代码评审者。你现在的角色是评审者——你的唯一任务是从下面这份方案中找出漏洞、盲区、未覆盖的边界情况、隐藏假设和过度设计。

规则：
1. 每个批判点必须具体——指出方案中哪个部分有问题，而不是笼统地说"这里不好"
2. 每个批判点必须说明为什么它是问题——会导致什么后果
3. 每个批判点应给出修正方向——不是完整替代方案，而是"朝哪个方向改"
4. 批判点数量不限，但每个都必须是实质性问题，不要凑数
5. 不要客气，不要先夸再批，直接挑刺
6. 如果方案整体方向有根本性问题，直接说出来

输出格式：
## 批判报告
### 核心问题
[如果方案有根本性方向问题，列在这里；没有则写"无"]
### 具体批判
#### 批判 #1：[一句话标题]
- 位置：[方案中哪一部分]
- 问题：[具体什么问题]
- 后果：[会导致什么后果]
- 修正方向：[朝哪个方向改]
#### 批判 #2：...

---

【约束】[§3 摘出的原文，没有则"无"]
【判断标准】[§3，没有则"无"]
【最小必读】[评审对象已在下方内嵌；如需要可自行阅读仓库其他文件辅助判断]

以下是待评审的对象（类型：设计文档 / 代码）：

[评审对象，原样内嵌]

4.2 收集产出

• 评审者 A 的输出 → 保存为 C_claude
• 评审者 B 的输出 → 保存为 C_gpt
• 各自的成功判定见 §10；任一失败按 §9 降级。

---

5. 阶段二·Opus 裁判

两份评审都收齐后，主线程把"评审对象 + C_claude + C_gpt"打包给裁判（Agent/Opus），让它逐条裁决并写报告。

5.1 裁判 prompt 模板

你是这次对抗评审的最终裁判。你现在的角色是裁判——不是设计者，也不是评审者。你的任务是裁决两份评审意见，而不是重新设计。

你会收到：
- 原始评审对象 D
- 评审者 A（Claude）的批判报告 C_A
- 评审者 B（GPT）的批判报告 C_B

你要做的：
1. 把两份报告的批判点合并、去重，逐条审查
2. 判断每条批判是否成立，给出明确裁决：✅采纳 / ❌驳回（部分成立则采纳成立部分、说明驳回部分）
3. **对每条初判驳回的意见做自我反驳复核**：先写出"该批判若要成立，需要哪些前提成立"；**只有当这些前提有具体文本证据或高可信上下文支撑时，才翻转为 ✅采纳 / 降级为"部分采纳"**。仅"理论上可能但无证据"→ 维持驳回。无论翻转与否，都留下这层"成立所需前提 + 该前提是否有证据"的复核痕迹（留痕是程序要求，与是否翻转脱钩——别因为要留痕就倾向翻转）。
4. 每条裁决给出清晰理由；驳回必须写清"评审者哪里理解错了 / 逻辑有什么漏洞"，不能只说"我觉得不对"
5. 标注每条意见的来源：Claude / GPT / 两者都提（两者都提 = 高置信信号）
6. 汇总所有采纳项，给出修正后的最终结论
7. 单独汇总驳回项及原因

关键原则：
- 你的角色是裁判，专长是判断"这条批判有没有道理"，不是为评审对象辩护，也不是无脑接受批判
- 批判成立就大方采纳；不成立就明确驳回并说清理由
- 评审者可能批得很尖刻，但尖刻 ≠ 正确
- 两位评审者意见冲突时，明确判定谁对谁错并给理由
- **抵消同源亲和 + 与复核统一证据标准**：你与评审者 A（Claude）同为 Opus，"加压审视 A 侧"具体落为——**对 A 侧批判不接受"无证据采纳"**（仅表述顺眼、无实质论证的，不予采纳）。这与第 3 条自我反驳复核"有证据才翻转"是同一把证据尺：复核普遍要求"有证据才翻转"，加压额外要求"A 侧更不容许无证据"。两条不冲突、无需额外优先级排序；对 GPT 侧用同等证据强度，不偏不向
- 如实标注每条意见来源（§6 已有来源字段），并在报告第 5 节给出"采纳来源分布"，便于事后核对是否偏向某侧
- 你的产出是「对采纳项的整合收口」——整合 ≠ 重新设计：综合采纳项给出内聚结论即可，不要另起炉灶推翻方案

输出：严格按 §6 的报告模板，写入文件 [输出路径]。只写这一个文件，不要创建或修改其他文件。

---

【约束】[§3 原文，没有则"无"]
【判断标准】[§3，没有则"无"]
【阶段质量告警】[主线程填：评审者 A / B 是否产出 < 2 个实质批判点（§9/§10）。某方不足则在此标明，裁判须在报告中点明"某方评审不足"；都达标则写"无"]

=== 原始评审对象 D ===
[评审对象，原样内嵌]

=== 评审者 A（Claude）批判 C_A ===
[C_claude]

=== 评审者 B（GPT）批判 C_B ===
[C_gpt]

---

6. 最终报告格式

裁判严格按以下模板输出（写入 §3 指定的文件）：

# 评审报告：[主题]

> 评审日期：[日期]
> 评审对象：[设计文档 / 代码]
> 评审模型：[Claude 模型] + [GPT 模型]   （如 Opus + GPT 5.5）

---

## 1. 评审对象概述
[3-5 句话总结被评审的内容]

## 2. 意见逐条裁决

### 意见 #1：[标题]
- 来源：Claude / GPT / 两者都提
- 意见：[评审者说了什么，原文或摘要]
- 裁决：✅ 采纳 / ⚠️ 部分采纳 / ❌ 驳回
- 理由：[为什么。驳回必须写清评审者哪里错了]
- 驳回复核：[仅驳回 / 部分采纳填：成立所需前提 + 该前提是否有证据支撑（呼应 §5.1 第 3 条）；纯采纳写"—"]
- 修正：[采纳则给出对原方案的具体修正；驳回则写"无需修正"]

### 意见 #2：...
[重复]

## 3. 修正后的最终结论
[把所有采纳项整合成内聚的、可直接使用的最终结论。是"对采纳项的整合收口"而非"原方案 + 补丁"罗列；整合 ≠ 推翻重设计。]

## 4. 驳回意见汇总

| # | 来源 | 意见 | 驳回原因（须体现"成立所需前提为何不成立"，而非仅凭直觉） |
|---|------|------|----------|
| 1 | GPT | [标题] | [一句话] |

（全部采纳则写"无驳回"。）

## 5. 双方共识与分歧
- **共识（两位评审者都提的点）**：[列出 —— 这些是高置信问题]
- **分歧（互相矛盾的点）**：[列出，并指明裁判最终判了哪边]
- **采纳来源分布**：[Claude 独有采纳 N / GPT 独有采纳 M / 两者都提采纳 K —— 供核对是否偏向某侧]
- （没有则写"无"）

---

7. 调用命令

7.1 评审者 A / 裁判（Claude）——用 Agent 工具

Agent(
  description: "对抗评审·评审者A（批判）",   # 裁判轮："对抗评审·裁判"
  model: "opus",          # 降级时 "sonnet"
  run_in_background: true, # 评审轮并行用；裁判轮可前台
  prompt: [§4.1 或 §5.1 制好的 prompt]
)

• 评审轮：只读分析、不写文件（prompt 已声明）。
• 裁判轮：让 Agent 直接把报告写入指定路径（prompt 已声明路径与"只写这一个文件"）。

7.2 评审者 B（GPT）——用 codex exec

# $SCRATCH 用本轮 §3.2 已派生并记住的字面值（如 /tmp/adv-review-867b2124314e-Ab3Xy9）——
# 直接粘字面值，不要重跑 mktemp（mktemp 是随机的，重跑会建新空目录、丢掉已写的 prompt）。
SCRATCH='<§3.2 记住的本轮 SCRATCH 字面值>'

# -C 目标：按下方"工作目录选择"判别后赋值（项目内→worktree 根，无关内容→/tmp）。
# git 解析失败（非 git 目录）回退 /tmp，避免 -C 拿到空串。
CODEX_CWD="$(git rev-parse --show-toplevel 2>/dev/null || echo /tmp)"   # 无关内容评审时直接写 CODEX_CWD=/tmp

# 把 §4.1 的批判 prompt（含评审对象）写入本轮 scratch（绝不用全局固定名，否则并发串台）
cat > "$SCRATCH/gpt-prompt.txt" << 'PROMPT_EOF'
[§4.1 制好的 prompt，含内嵌评审对象]
PROMPT_EOF

# 后台调用，-o 写纯文本输出；< /dev/null 必须加，否则 codex 检测到 stdin 是管道会永久阻塞
codex exec \
  -m gpt-5.5 \
  -c 'approval_policy="never"' \
  -s read-only \
  -C "$CODEX_CWD" \
  --skip-git-repo-check \
  --ephemeral \
  -o "$SCRATCH/gpt-out.txt" \
  "$(cat "$SCRATCH/gpt-prompt.txt")" \
  < /dev/null \
  > "$SCRATCH/gpt-log.txt" 2>&1

-C(=CODEX_CWD) 与 scratch 是两件正交的事：-C 管 codex 去读哪个项目（按 worktree 区分阅读上下文），$SCRATCH 管临时文件落在哪（按运行实例隔离，防并发覆盖）。-s read-only 保证 codex 写不了被评审工作区；它自身在 $TMPDIR 的运行时临时文件不在 $SCRATCH 内、也不计入越界（见 §11）。

• codex 没有 system/user 分离，角色设定合并进 prompt 首部即可。
• 沙箱与审批：-s read-only（只读沙箱，可读文件辅助评审但物理上写不了任何东西）+ -c 'approval_policy="never"'（非交互必须，否则可能阻塞等审批）。注意 exec 子命令没有 -a flag（照顶层 help 写会直接报错），approval 只能走 -c 覆盖。禁止用 --dangerously-bypass-approvals-and-sandbox——评审是只读任务，无理由全开权限。
• 工作目录选择（-C）：
  • 评审代码 / 项目内设计文档 → -C 指向被评审项目的根目录（主仓或对应 worktree）。codex 自动注入的只有 AGENTS.md 本体（其原生约定，不认 CLAUDE.md）；若 AGENTS.md 是指向 CLAUDE.md 的指针（常见于工程项目），模型通常会自行跟进阅读，但这是模型自觉而非机制保证——所以适用红线必须照 §3 内嵌进证据包，项目上下文只是补充视野。进项目的价值：评审者可自由补读周边代码与工程规约，与评审者 A 的视野对称（§3.1② 钉对象、不钉视野）。
  • 评审与任何项目无关的独立内容 → -C /tmp 隔离，避免无关项目上下文混入。
  • 判别标准：项目根的 CLAUDE.md/AGENTS.md 是工程规约（红线、架构约束）→ 进项目；是人格/身份设定（个人外脑类项目）→ 隔离到 /tmp。
• 默认 gpt-5.5 reasoning xhigh（config 默认即是）；降级加 -c 'model_reasoning_effort="medium"'（合法档位：none/minimal/low/medium/high/xhigh）。codex 是 GPT 的唯一调用路径，失败按 §9。
• 配合 §8 用 run_in_background 发起。codex 后台进程退出后，再起一次 Bash（粘本轮记住的 $SCRATCH 字面值）cat "$SCRATCH/gpt-out.txt" 读取 C_gpt，日志在 $SCRATCH/gpt-log.txt。注意：codex 的 stdout 已重定向到 log，C_gpt 只能从 gpt-out.txt 文件取，不在退出通知里。

---

8. 超时与响应

• 上限 30 分钟（1800s）。子线程 / codex exec 一旦完成就立刻进入下一步，不空等。
• 两份评审并行发起：评审者 A 的 Agent 调用与评审者 B 的 codex exec 调用都用 run_in_background: true，互不阻塞；两者完成会各自通知，主线程收到通知即响应。
• Bash 单次 timeout 上限只有 10 分钟，所以 codex exec 必须走 run_in_background（后台进程不受 10 分钟限制）才能容纳 30 分钟的评审。不要用前台 Bash + 长 timeout 跑 GPT 评审。（此处 run_in_background 指 Bash 工具自带的后台参数——它让命令 detached、跨 turn 运行、不受前台 10 分钟约束；不是 shell 的 &，命令块里也无需加 &/nohup。）
• 裁判轮可前台 Agent 调用，完成即返回。
• 30 分钟仍未完成 → 按 §9 当超时处理。

---

9. 失败降级策略

失败场景	降级策略
评审者 A（Claude）超时（>30min）/ 调用失败	重试一次。仍失败 → 用评审者 B 单份评审继续裁决，报告里标注"仅 GPT 评审"
评审者 B（GPT）超时 / 调用失败	重试一次。仍失败 → 用评审者 A 单份评审继续裁决，报告里标注"仅 Claude 评审"
两份评审都失败	报告用户，终止流程（无可裁决的素材）
某份评审产出 < 2 个实质批判点	按 §10（"≥2"的单一真值源）当质量告警、非失败：当作有效输出继续裁判，并把"哪方不足"填进 §5.1 裁判 prompt 的【阶段质量告警】区，要求裁判在报告中点明"某方评审不足"
裁判超时（>30min）/ 失败	重试一次。仍失败 → 主线程用已绝对化的输出路径（同 §3.2 的 ABS_REPORT 字面值）把 D + C_claude + C_gpt 拼接写入，标注"裁判未完成，以下为两份原始评审"
裁判产出格式不符模板	不重试，直接交付并说明格式有偏差
用户未指定输出路径	不执行，先问用户拿到路径
任一轮返回空响应	检查 prompt 是否有歧义或信息缺口，修正后重试；仍空按对应行处理

核心原则：不因一份失败就丢弃已完成的产出。两份评审只剩一份 → 用一份裁决并标注；裁判失败 → 至少交付两份原始评审拼接。

---

10. 各阶段成功判定

本表是"≥2 批判点"判定的单一真值源；§9 只引用本表、不另行定义。

阶段	成功 / 质量判定
评审者 A / B	质量目标（非放行闸、非中止条件）：各产出 ≥ 2 个具体批判点（不是笼统的"可以更好"），每个指向评审对象的具体位置。取 2 是因为"单点批判可能是噪声、≥2 才显出评审者真在挑刺"；未达标不算失败，按 §9 当质量告警续跑
裁判（硬通过标准）	每条意见都有 ✅采纳 / ⚠️部分采纳 / ❌驳回 标签 + 理由 + 来源；每条驳回 / 部分采纳项留有"成立所需前提 + 是否有证据"的自我反驳复核痕迹；修正后结论包含全部采纳项；报告第 5 节（共识/分歧 + 采纳来源分布）已填

---

11. 主线程验收清单

裁判完成后，主线程执行。$ABS_REPORT 与 $SCRATCH 不跨 Bash 调用持久——验收这次 Bash 调用里必须先把它们带回来：ABS_REPORT 按 §3.2 的 REPORT/case 两行重算（确定性，可重算），SCRATCH 用本轮记住的字面值（mktemp 随机、不可重算）。

□ 先带回变量：REPORT=...; case ... ABS_REPORT；SCRATCH='<本轮记住的字面值>'
□ 输出文件 "$ABS_REPORT" 存在且非空（mtime 在本轮之后）
□ 报告含"意见逐条裁决"+"修正后的最终结论"两节
□ 每条意见都有 ✅/⚠️/❌ 标签 + 来源标注；驳回 / 部分采纳项留有自我反驳复核痕迹
□ 没有评审意见被悄悄忽略（每条都有裁决）
□ 无越界写入【有界声明，只在以下范围内可验证】：
   - 报告确实写到 "$ABS_REPORT"；scratch 产物都在 "$SCRATCH/" 内归本轮
   - repo 内无意外改动（`git status --porcelain`，报告/ scratch 在 repo 外时此项只覆盖 repo 内）
   - 不承诺"repo 外全局无越界"（无文件系统快照不可证）；codex 自身在 `$TMPDIR` 的临时文件不计入越界
□ 向用户报告：评审完成 + 文件路径 + 采纳 N 条 / 驳回 M 条

不通过 → 告知用户具体哪项不达标，由用户决定接受还是重试。

---

12. 与 ask-sonnet / ask-opus 的关系

• 对抗评审是 ask-sonnet / ask-opus 的上层编排，不是替代品。
• 证据包方法论与这两个 skill 共用 references/dispatch.md 的 RAM 框架；§3 的对抗专属规则是在它之上的补充。
• 评审者 A 和裁判的 Claude 调用，与 ask-sonnet / ask-opus 用的是相同的 Agent 工具机制。
• 日常单方问答 / 派活 → /ask-sonnet 或 /ask-opus；需要 Claude + GPT 对抗性双评审 → 本 skill。