---
name: adversarial-review
description: 质疑一个结论 / 计划 / 既有评审 / 设计方案是否站得住脚——默认怀疑、逼出证据，把发现分成「真问题 / 误报 / 待澄清」。注意：若用户只是想给代码找冗余 / 反模式 / 做常规质量改进，用 /simplify 而非本 skill。
triggers: 对抗审查、反向提问、红队、挑战这个结论、验证某结论或方案是否站得住脚、哪些是误报哪些是真问题、审稿、复核这个判断
---

# /adversarial-review —— 对抗式审查（反向提问，默认怀疑）

## 目的

验证一个**结论 / 计划 / 既有评审 / 设计方案 / 一段代码**是否站得住脚时，别让模型（或你自己）
轻易点头。人和 LLM 面对「这个对吗？」都有**迎合反射**——倾向于附和、补论据、越夸越顺。
本 skill 的目的：用「反向提问」把这种迎合反射**翻转成怀疑反射**，再用举证纪律把怀疑落到实处，
最终把发现诚实地分成 🔴 真问题 / ⚪ 误报 / 🟡 待澄清。

## 方法一：把问题转成「表面反向的提问」（扳机）

**永远不要问「X 对不对 / X 是否正确」，要问「X 是不是错的 / X 哪里站不住脚」。**

为什么仅仅换个问法就有用？因为**举证责任被翻转**了：

- 问「X 对吗？」→ 回答者可以**零成本附和**（"对的、挺好"），不费力就能交差，迎合反射全开。
- 问「X 错在哪？」→ 回答者**必须先假设它有错**，然后去枚举失败场景、找反例、回现场核对才能回答；
  哪怕最后发现 X 其实成立，那也是**认真攻击过之后**的结论，而不是反射性点头。

类比面试：问「你会不会用 X？」对方反射答「会」；但问「你是不是其实不会 X？」对方被迫拿出
真凭实据来反驳你——被逼着深度思考、自证清白。对抗审查就是把**每一次判断**都塞进后一种问法里。

> ⚠️ 「换问法」只是扳机，不是终点。光把问法反过来，模型同样可能编出**看似合理却牵强**的
> 假问题来"完成证伪任务"，那是在制造新的误报。所以扳机必须接上「方法二：举证纪律」。

## 方法二：举证纪律（引擎）

反向提问扣动扳机后，每条判断都要过这三关，否则不算数：

1. **拆成原子主张**：把审查对象切成一条条**能被单独证伪**的主张。整段"感觉对"没意义，可攻击的最小单元才有。
2. **举证责任在主张方**：每条主张默认**未被证实**，靠具体反例 / 现场核对 / 可查依据来支撑或推翻。判定一律附证据，不附证据的判定本身就是错的。
3. **去现场，不凭记忆**：涉及代码 / 事实的主张，一律 Read / Grep 核对原文。用脑内印象当证据是制造误报的头号来源。

**误报和漏报一样有害。** 把成立的主张硬说成问题，和放过真问题一样是审查失败——这与「默认怀疑」同等重要。

## 反向提问转换示例（按情况直接套用）

把用户原本（或心里）的「迎合式问法」翻成「反向式问法」，再走方法二的纪律：

| 你想确认的事（迎合式 ❌） | 反向提问的问法（✅ 套这个） |
|---|---|
| 这个方案对吗？ | 这个方案**是不是错的**？它在什么输入 / 场景 / 规模下会崩？哪一步的假设最可能不成立？ |
| 这份代码评审准吗？ | 这份评审里**哪些是误报、哪些是真问题**？逐条去现场核对它说的代码是否真这样。 |
| 我刚写的这段代码没问题吧？ | 这段代码**哪里有 bug**？给我一个能让它出错的具体输入 / 边界 / 并发时序。 |
| X 这个事实成立吗？ | X **在什么情况下是假的**？反例是什么？它的依据经得起核对吗？ |
| 该选方案 A 吗？ | 选 A **会在什么场景下变成错误决定**？A 比 B 差在哪？A 的隐藏代价是什么？ |
| 这个回答 / 总结完整吗？ | 这个回答**漏了什么**？哪个边界 / 失败路径 / 反例没覆盖？ |
| 这个重构安全吗？ | 这个重构**会悄悄破坏什么**？哪些调用方 / 测试 / 契约依赖了被改掉的行为？ |
| 文档 / 注释和代码一致吗？ | 文档**哪一句和代码对不上**？逐句拿去和实现核对，找出已经过时（stale）的描述。 |

**worked example（评审复核——最常见场景）**

输入：「上一阶段的改动，代码评审说有以下 N 个问题，是不是误报？」

- ❌ 迎合式追问「这些问题对吗？」→ 模型容易逐条附和"是的这是问题"，等于没审。
- ✅ 反向式追问：「这 N 条里**哪些是误报、哪些是真问题，为什么**？每条都 Read 对应文件去现场核对它
  描述的代码是否属实；拿得出反例/实证的才标 🔴 真问题，只是'觉得没充分说明'但推不倒的标 🟡 待澄清，
  确认其实成立的标 ⚪ 误报并给出它为何成立。」
- 效果：模型被迫**为每条结论举证**（无论判真还是判误报），迎合空间被挤掉——这正是本 skill 要的。

## Quick Reference

| 步骤 | 操作 |
|------|------|
| 1 | 用 Read 读取被审查对象（结论/计划/评审/设计/代码）；必要时 Grep/Glob 取证，去现场核对而非凭记忆 |
| 2 | 把对象拆成一条条**独立、可被单独证伪**的原子主张 |
| 3 | 对每条问「哪里站不住脚」（见下方拷问清单），强迫找反例与证据 |
| 4 | 给每条分类：🔴 真问题 / ⚪ 误报 / 🟡 待澄清 |
| 5 | 每条都附**证据**与**为什么**（凭什么这么判，证据指向哪里）；没证据就别下 🔴 结论 |

## 第 3 步：对每条主张的拷问清单

逐条追问，任意一条命中就标记下来：

- **证据不足？** —— 它的依据是什么？依据本身可靠吗，还是空口断言？
- **把假设当事实？** —— 哪些是已验证的事实，哪些只是"应该是这样"的假设被当成了前提？
- **想当然 / 跳步？** —— 推导链有没有缺环？"因为 A 所以 C"中间的 B 被默认了吗？
- **有反例？** —— 能不能举出一个让它崩掉的具体场景、输入、边界条件？
- **被现有代码/事实推翻？** —— 去 Grep/Read 核对，它描述的代码真长这样吗？实现真按它说的走吗？

### 证明不了 ≠ 错

一段文本里很多成立的主张本就不会附带完整证据——**省略不等于错误**。所以：

- 你能拿出反例 / 找到被现有代码推翻的实证 → 标 **🔴 真问题**。
- 你只是觉得它"没充分举证"、但也举不出反例 → 标 **🟡 待澄清**，并写明「缺哪个证据才能判定」，**不要**直接判 🔴。

把「主张错误」与「主张未充分举证」混为一谈，是这类审查最常见的误报来源。

## 输出格式

三类同等呈现，不预设哪类一定有内容（真问题为 0 条是合法且常见的结论）：

```
## 对抗审查结果

### 🔴 真问题（拿得出反例/实证的）
1. [主张/位置] 这条为什么站不住脚 → 证据（文件:行 / 反例 / 事实）→ 影响
2. ...
（若无：「真问题：0 条——下方列出已尝试的攻击角度」）

### ⚪ 误报（曾被怀疑、但其实成立）
1. [主张/位置] 原审查/结论怀疑的点 → 为什么它其实成立 → 证据
2. ...

### 🟡 待澄清（未充分举证、但也推不倒）
1. [主张/位置] 缺什么证据才能判定 → 需要用户/作者补充什么
2. ...

### 结论
一句话定调：整体站得住脚 / 有 N 个真问题需修 / 关键前提待澄清。
```

## 注意事项

- **误报和漏报一样有害**（已在核心段强调，这里重申落地）。不要为了"显得严格"就把成立的结论硬说成问题——驳回一条主张同样要给证据，凭感觉拍砖等于制造新的误报。
- **找不到真问题就如实说**。如果对象本身扎实、你认真攻击后确实推不倒它，就直说"未发现真问题"，并**列出你尝试过的反驳角度**（找过哪些反例、核对过哪些代码、质疑过哪些假设），证明你是真的攻击过、而非偷懒放水。
- **去现场，别凭记忆**。涉及代码/事实的主张，一律 Read/Grep 核对原文，不要用脑内印象当证据。
- **边界**：本 skill 用于质疑「结论 / 计划 / 既有评审 / 设计是否站得住脚」。若用户只是想给代码找冗余 / 反模式 / 做常规质量改进，那是 /simplify 的活，不要套用这里的「默认有罪」框架。
