BMAD-METHOD/docs/zh-cn/explanation/adversarial-review.md

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：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。