---
title: "对抗性评审"
description: 防止懒惰"看起来不错"评审的强制推理技术
sidebar:
  order: 5
---

通过要求发现问题来强制进行更深入的分析。

## 什么是对抗性评审？

一种评审技术，评审者*必须*发现问题。不允许"看起来不错"。评审者采取怀疑态度——假设问题存在并找到它们。

这不是为了消极。而是为了强制进行真正的分析，而不是对提交的内容进行草率浏览并盖章批准。

**核心规则：**你必须发现问题。零发现会触发停止——重新分析或解释原因。

## 为什么有效

普通评审容易受到确认偏差的影响。你浏览工作，没有发现突出的问题，就批准了它。"发现问题"的指令打破了这种模式：

- **强制彻底性**——在你足够努力地查看以发现问题之前，不能批准
- **捕捉遗漏**——"这里缺少什么？"成为一个自然的问题
- **提高信号质量**——发现是具体且可操作的，而不是模糊的担忧
- **信息不对称**——在新的上下文中运行评审（无法访问原始推理），以便你评估的是工件，而不是意图

## 在哪里使用

对抗性评审出现在 BMad 工作流程的各个地方——代码评审、实施就绪检查、规范验证等。有时它是必需步骤，有时是可选的（如高级启发或派对模式）。该模式适应任何需要审查的工件。

## 需要人工过滤

因为 AI 被*指示*要发现问题，它就会发现问题——即使问题不存在。预期会有误报：伪装成问题的吹毛求疵、对意图的误解，或完全幻觉化的担忧。

**你决定什么是真实的。**审查每个发现，忽略噪音，修复重要的内容。

## 示例

而不是：

> "身份验证实现看起来合理。已批准。"

对抗性评审产生：

> 1. **高** - `login.ts:47` - 失败尝试没有速率限制
> 2. **高** - 会话令牌存储在 localStorage 中（易受 XSS 攻击）
> 3. **中** - 密码验证仅在客户端进行
> 4. **中** - 失败登录尝试没有审计日志
> 5. **低** - 魔法数字 `3600` 应该是 `SESSION_TIMEOUT_SECONDS`

第一个评审可能会遗漏安全漏洞。第二个发现了四个。

## 迭代和收益递减

在处理发现后，考虑再次运行。第二轮通常会捕获更多。第三轮也不总是无用的。但每一轮都需要时间，最终你会遇到收益递减——只是吹毛求疵和虚假发现。

:::tip[更好的评审]
假设问题存在。寻找缺失的内容，而不仅仅是错误的内容。
:::

---
## 术语说明

- **adversarial review**：对抗性评审。一种强制评审者必须发现问题的评审技术，旨在防止草率批准。
- **confirmation bias**：确认偏差。倾向于寻找、解释和记忆符合自己已有信念的信息的心理倾向。
- **information asymmetry**：信息不对称。交易或评审中一方拥有比另一方更多或更好信息的情况。
- **false positives**：误报。错误地将不存在的问题识别为存在的问题。
- **diminishing returns**：收益递减。在投入持续增加的情况下，产出增长逐渐减少的现象。
- **XSS**：跨站脚本攻击（Cross-Site Scripting）。一种安全漏洞，攻击者可在网页中注入恶意脚本。
- **localStorage**：本地存储。浏览器提供的 Web Storage API，用于在客户端存储键值对数据。
- **magic number**：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。