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