2.3 KiB
2.3 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 对抗性评审 | 防止懒惰“看起来不错”评审的强制推理技术 |
|
对抗性评审（adversarial review）是一种“强制找问题”的评审方法：不允许直接“Looks good”，必须给出可验证发现，或者明确解释为什么没有发现。
它是什么
常规评审容易落入确认偏差：快速扫一遍，没有明显报错，就批准。
对抗性评审反过来要求评审者先假设“问题存在”，再去定位证据。
核心规则：
- 必须产出问题发现或明确的无发现理由
- 发现要具体、可追溯、可操作
- 评审对象是工件本身，而不是作者意图
为什么有效
- 强制深入阅读，减少“浏览式批准”
- 更容易发现“缺了什么”，不只看“写错了什么”
- 发现通常更结构化，便于后续分诊与修复
- 在新上下文评审时，能降低“先入为主”偏差
在哪里使用
它不是某个单一 workflow 独占，而是一种可复用评审模式，常见于：
- 代码评审
- 规范/方案评审
- 实施就绪检查
- 高风险改动复核
你需要知道的限制
因为系统被要求“必须找问题”，它会提高召回率，也会提高误报率。
你会看到：
- 吹毛求疵型发现
- 语义误解型发现
- 偶发幻觉型发现
所以它本质上是高召回、需人工分诊的策略，而不是“自动真理机”。
:::caution[关键心法] 把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在“发现数量”，而在分诊质量。 :::
与 Quick Dev 的关系
bmad-quick-dev 关注执行效率与边界控制；对抗性评审关注问题发现质量。
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
示例（对比）
普通评审可能是：
“实现基本没问题，先过。”
对抗性评审更像：
- HIGH：
login.ts缺失失败重试限流- HIGH：会话令牌存储在
localStorage，存在 XSS 风险- MEDIUM：失败登录缺少审计日志
- LOW：魔法数字
3600建议替换为命名常量
重点不是“更凶”，而是“更可执行”。