adversarial-reviewer

对抗式代码审查员

描述

对抗式代码审查 Skill，通过三个敌对的审查者角色（破坏者、新人、安全审计员）强制实现真正的视角转换。每个角色都必须至少找到一个问题，不允许出现"LGTM"式的放行。问题会按严重程度分类，并在被多个角色同时发现时进行交叉提升。

功能特性

• 三个对抗式角色：破坏者（生产环境故障）、新人（可维护性）、安全审计员（基于 OWASP）
• 强制发现问题：每个角色至少需要提出一个问题，杜绝走过场式的审查
• 严重程度提升：被 2 个及以上角色发现的问题，严重程度提升一级
• 自审陷阱破解：提供具体技巧，克服共享心智模型带来的盲点
• 结构化结论：BLOCK / CONCERNS / CLEAN，并附带清晰的合并建议

用法

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

示例

示例：合并前审查 PR

/adversarial-review --diff main...HEAD

会生成一份结构化报告，汇总三个角色的发现，去重并按严重程度排序，最后给出 BLOCK / CONCERNS / CLEAN 的结论。

解决的问题

当 Claude 审查自己编写的代码（或刚读过的代码）时，它与作者共享相同的心智模型、假设和盲点。这会导致它对一个新来的人类审查者会立即指出问题的代码给出"看起来没问题"的审查结论。用户普遍将此视为 AI 辅助开发中最令人沮丧的问题之一。

本 Skill 通过要求你采用对抗式角色来强制实现真正的视角转换。每个角色都有不同的优先级、不同的担忧，以及对"糟糕代码"的不同定义。

目录

1. 快速开始
2. 审查流程
3. 三个角色
4. 严重程度分类
5. 输出格式
6. 反模式
7. 适用场景

快速开始

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

审查流程

第 1 步：收集变更

根据调用方式确定审查范围：

• **无参数：**运行 git diff（未暂存）+ git diff --cached（已暂存）。如果两者都为空，则运行 git diff HEAD~1（上一次提交）。
• **--diff <ref>：**运行 git diff <ref>。
• **--file <path>：**读取整个文件。审查重点应放在完整文件上，而不仅仅是变更部分。

如果未发现任何变更，则停止并报告："Nothing to review."

第 2 步：阅读完整上下文

对于 diff 中的每个文件：

1. 阅读完整文件（而不仅仅是变更的行）——缺陷往往隐藏在新代码与现有代码的交互之中。
2. 明确变更的目的：缺陷修复、新功能、重构、配置变更或测试。
3. 记录来自 CLAUDE.md、.editorconfig、lint 配置或现有模式的任何项目约定。

第 3 步：依次运行三个角色

依次执行每个角色。每个角色都必须至少产出一个发现。如果某个角色没有发现任何问题，说明它还没有足够认真地审视——请返回重新检查。

**重要：**不要淡化发现，不要含糊其辞。不要说"这可能没问题，但……"——问题要么存在，要么不存在。请直截了当。

第 4 步：去重与综合

三个角色都报告完毕后：

1. 合并重复发现（同一问题被多个角色发现）。
2. 将被 2 个及以上角色发现的问题提升到下一严重程度。
3. 生成最终的结构化输出。

三个角色

角色 1：破坏者

心态：“我要在生产环境中把这段代码搞崩。”

关注重点：

• 从未经过验证的输入
• 可能变得不一致的状态
• 没有同步的并发访问
• 吞掉异常或返回误导性结果的错误路径
• 对数据格式、大小或可用性的假设，这些假设可能被打破
• 差一错误、整数溢出、null/undefined 解引用
• 资源泄漏（文件句柄、连接、订阅、监听器）

审查流程：

1. 对每个被修改的函数/方法，问自己：“我能发送的最坏输入是什么？”
2. 对每个外部调用，问自己：“如果它失败、超时或返回垃圾数据怎么办？”
3. 对每次状态变更，问自己：“如果它运行两次？并发运行？从不运行？”
4. 对每个条件分支，问自己：“如果两个分支都不正确怎么办？”

你必须找出至少一个问题。如果代码确实无懈可击，请指出它所依赖的最脆弱的假设。

---

角色 2：新入职者

心态：“我刚加入这个团队。我需要在 6 个月后，在完全不了解原作者背景的情况下，理解并修改这段代码。”

关注重点：

• 无法表达意图的命名（data 是什么意思？process() 做了什么？）
• 需要阅读 3 个以上其他文件才能理解的逻辑
• 魔法数字、魔法字符串、没有解释的常量
• 一个函数做了多件事（名字说的是 X，但它还做了 Y 和 Z）
• 缺少类型信息，迫使读者沿着调用链逐层追踪
• 与周围代码风格或项目约定不一致
• 测试的是实现细节而非行为
• 注释描述的是做什么（冗余），而不是为什么（有用）

审查流程：

1. 像从未见过这个代码库一样阅读每个被修改的函数。仅凭名称、参数和函数体，你能理解它做什么吗？
2. 端到端地追踪一条代码路径。你需要打开多少个文件？
3. 检查：新贡献者是否知道在哪里添加类似功能？
4. 寻找“作者知道而读者不知道”的情况——即嵌入代码中的隐性知识。

你必须找出至少一个问题。如果代码非常清晰，请指出新人最可能感到困惑的地方。

---

角色 3：安全审计员

心态：“这段代码将会遭受攻击。我的工作是在攻击者之前发现漏洞。”

基于 OWASP 的检查清单：

类别	需要关注什么
注入	SQL、NoSQL、操作系统命令、LDAP——任何用户输入未经参数化就进入查询或命令的地方
认证失效	硬编码凭据、新端点缺少认证检查、会话令牌出现在 URL 或日志中
数据暴露	错误消息、日志或 API 响应中包含敏感数据；静态或传输中缺少加密
不安全的默认配置	调试模式未关闭、过于宽松的 CORS、通配符权限、默认密码
访问控制缺失	IDOR（用户 A 能否访问用户 B 的数据？）、缺少角色检查、权限提升路径
依赖风险	含已知 CVE 的新依赖、锁定到存在漏洞的版本、不必要的传递依赖
密钥	代码、配置或注释中的 API 密钥、令牌、密码——即使是“临时”的

审查流程：

1. 找出代码跨越的每一个信任边界（用户输入、API 调用、数据库、文件系统、环境变量）。
2. 对每个边界：输入是否经过验证？输出是否经过清理？是否遵循最小权限原则？
3. 检查：经过身份验证的用户能否通过此次变更提升权限？
4. 检查：此次变更是否暴露了任何新的攻击面？

你必须找出至少一个问题。如果代码不涉及任何安全面，请指出与安全相关的、最接近的一个假设。

严重程度分类

严重程度	定义	所需操作
CRITICAL	会导致数据丢失、安全漏洞或生产环境中断。合并前必须修复。	阻止合并。
WARNING	可能在边缘情况下引发 bug、降低性能，或让未来的维护者困惑。合并前应当修复。	修复，或在说明理由后明确接受风险。
NOTE	风格问题、细微的改进机会或文档缺失。最好修复。	由作者自行决定。

升级规则： 被 2 个及以上角色标记的问题，升高一个级别（NOTE 升为 WARNING，WARNING 升为 CRITICAL）。

输出格式

按以下结构编写你的审查：

## Adversarial Review: [brief description of what was reviewed]

**Scope:** [files reviewed, lines changed, type of change]
**Verdict:** BLOCK / CONCERNS / CLEAN

### Critical Findings
[If any — these block the merge]

### Warnings
[Should-fix items]

### Notes
[Nice-to-fix items]

### Summary
[2-3 sentences: what's the overall risk profile? What's the single most important thing to fix?]

结论定义：

• BLOCK — 存在 1 个及以上 CRITICAL 问题。在问题解决前不要合并。
• CONCERNS — 没有 CRITICAL 问题，但有 2 个及以上 WARNING。合并风险自负。
• CLEAN — 仅有 NOTE。可以安全合并。

反模式

本 Skill 不是什么

反模式	为什么是错的
"LGTM，未发现问题"	如果你什么都没发现，说明你还不够仔细。每项改动至少都有一个风险、假设或改进机会。
只提风格类问题	只报告空白字符或格式问题，却漏掉空指针解引用，比完全不做审查更糟。先看实质，再看风格。
含糊其辞	"这可能是个小问题……" 不可取。要直接。例如："当 user 为 undefined 时，这里会抛出 NullPointerException。"
复述差异	"这个函数是为了处理身份验证而添加的" 不算发现。真正的问题是：它处理身份验证的方式哪里有错？
忽视测试缺口	新代码没有测试就是一个问题，始终如此。测试不是可选项。
只审查修改过的行	Bug 往往藏在新代码与既有代码的交互之中。要通读完整文件。

自我审查陷阱

你很可能正在审查刚刚编写或刚刚阅读过的代码。你的思维（权重）形成了产生这段代码的同一套心智模型，因此你会自然地认为它是正确的，因为它符合你的预期。

打破这种模式的方法：

1. 从底部开始阅读代码（从最后一个函数开始，逆向推进）。
2. 对每个函数，在阅读函数体之前先说明其契约。函数体是否与之相符？
3. 在被证明之前，假设每个变量都可能为 null/undefined。
4. 假设每一次外部调用都可能失败。
5. 自问："如果把这项改动完全删除，会出什么问题？" 如果答案是"什么都不会"，那么这项改动可能是不必要的。

何时使用

• 合并任何 PR 之前，尤其是没有人工审阅者的自行提交的 PR
• 经过长时间编码之后，疲劳会产生盲区，本 Skill 可以弥补
• 当 Claude 说"看起来不错"时，如果你获得了轻松的批准，请运行本审查以获取第二意见
• 涉及安全敏感的代码时，如身份验证、支付、数据访问、API 端点
• 当某处"感觉不对"时，相信这种直觉，并运行一次对抗式审查

交叉引用

• 相关：engineering-team/senior-security，深入的安全分析
• 相关：engineering-team/code-reviewer，通用代码质量审查
• 互补：ra-qm-team/，质量管理工作流