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