1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | adversarial-reviewer-alirezarezvani-claude-skills |
| 作者/维护者 | ekreloff（原始贡献者，SKILL.md 内 author 字段署名）；仓库维护团队 Alireza Rezvani（GitHub: alirezarezvani） |
| 来源链接 | https://github.com/alirezarezvani/claude-skills/tree/main/engineering-team/skills/adversarial-reviewer |
| 许可证 | MIT（数据来源：SKILL.md 内声明 + GitHub API 交叉核实） |
| GitHub Stars | 23,872（所属 claude-skills 合集仓库整体星数，非本技能独立星数；数据来源：GitHub API） |
| Forks | 3,349（同上，合集仓库层面；数据来源：GitHub API） |
| 最新版本 | v2.9.0（SKILL.md 内自述版本号；数据来源：SKILL.md） |
| 安装方式 | 复制子目录到本地 skills 目录，或经仓库自带 marketplace 配置以插件方式安装 |
2. 功能介绍与亮点
adversarial-reviewer 是一个纯提示词型的代码评审技能，核心机制是强制三个立场互斥的“敌对评审人格”依次审查同一段变更：
- Saboteur（破坏者）：假设自己在故意让代码在生产环境中崩溃——关注未校验输入、状态不一致、并发竞争、吞掉异常的错误路径
- New Hire（新人）：假设自己 6 个月后要在零上下文的情况下理解并修改这段代码——关注命名是否达意、魔法数字、隐性知识、注释是否只讲“是什么”而不讲“为什么”
- Security Auditor（安全审计员）：对照 OWASP 风险清单（注入、认证缺陷、数据暴露、访问控制缺失、依赖风险、硬编码密钥等）逐项排查
主要亮点：
- 强制发现机制：每个人格必须至少给出一条发现，“没发现问题”本身被定义为“没看仔细”，杜绝空洞的“LGTM”式认可
- 严重度升级规则：同一问题被 2 个以上人格独立指出时自动升一级（NOTE→WARNING→CRITICAL），把“多方共识”转化为量化的优先级信号
- 结构化输出与合并裁决：最终产出 BLOCK / CONCERNS / CLEAN 三态裁决，并给出去重后的关键问题摘要，而非松散的评论列表
- 反模式清单：文档内明确列出“只挑格式问题不挑空指针”“只评审改动行不读全文”等 6 种常见的敷衍评审模式并逐条说明为何错误
- 零外部依赖（“dependencies: None”），纯 Markdown 指令驱动
git diff等标准命令，无需安装任何工具或申请任何密钥
3. 适用场景
固定分类：工程效率与代码质量
面向使用 Claude Code 自行编写代码、且缺少人工复核环节的开发者与小团队：当自己既是作者又是唯一评审人时，模型（或人）很容易对自己刚写出的代码产生“看着顺眼”的确认偏误。该技能适合在合并 PR 前、长时间编码后精力下降时、或怀疑 Claude 对代码质量“太好说话”时触发，尤其适合认证、支付、数据访问等安全敏感改动的合并前把关。
4. 跨 Agent 兼容性
- Claude Code：原生支持——SKILL.md 遵循 Agent Skills 规范，
/adversarial-review斜杠命令与git diff系列操作均为 Claude Code 原生可执行 - Codex：未验证——指令本体是通用 Markdown 提示词，理论上可被支持 SKILL.md 规范的 agent 加载，但未抓取到 Codex 专属适配材料
- OpenClaw：未验证——同上，未见 OpenClaw 专属说明
- Hermes Agent：未验证——未抓取到相关材料
5. 推荐理由
这个技能瞄准的是 AI 辅助编程里一个有据可查、却很少被认真解决的失效模式：当 Claude 评审自己刚写的代码时，评审者与作者共享同一套心智模型，很容易产出一份“看起来没问题”却经不起推敲的复核。它不是简单地要求模型“更挑剔一点”，而是用三个视角互斥、且都被要求必须交出至少一条发现的对抗性人格，配合严重度升级规则和明确的合并裁决，把“要不要再改改再合并”变成一个结构清晰、零配置成本的判断过程。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 6 | 未沿用合集 23,872 星（子技能层面无法计入合集 stars）；虽有真实外部贡献者原创（ekreloff 提交 PR #439 新增本技能）且已被至少 3 个独立第三方技能目录站点收录，但未找到有机的用户讨论或量化采用数据 |
| 可用性 | 9 | 单文件 SKILL.md、零外部依赖、复制即用；文档含完整评审流程、三个具体调用示例、人格分工表与反模式清单；该子技能最近一次内容更新为 2026 年 5 月，所属仓库整体持续活跃维护 |
| 安全性 | 9 | 见下方安全检查清单 |
安全检查清单：
| 检查项 | 结果 |
|---|---|
| ① Shell 命令及权限范围 | 仅指导执行标准只读 git 命令（git diff、git diff --cached、git diff HEAD~n）读取变更内容，不执行任意 shell 操作 |
| ② 运行时联网外发 | 无任何网络请求代码，纯提示词驱动的本地评审流程 |
| ③ API Key/凭据 | 不需要任何凭据或密钥 |
| ④ 可疑指令 | 未发现提示词注入或混淆内容；文档本身即在教育使用者识别“敷衍式评审”反模式 |
| ⑤ 作者/组织信誉 | 个人开发者 ekreloff 原创贡献（PR #439 有明确记录），经维护团队整合入库，未见刷星或自我造假迹象 |
| ⑥ License | MIT，明确 |
| ⑦ 最近维护 | 该子技能最近一次改动为 2026 年 5 月（对应 v2.9.0），所属仓库近日仍有提交推送 |
7. 跟同类 Skills 相比的优势
| 竞品 | 定位 | 与本技能的差异 |
|---|---|---|
| named-persona-adversarial-review（同仓库姊妹技能） | 用 Linus Torvalds、Ken Thompson、John Carmack 等真实工程师有据可查的公开理念做评审视角，每条发现须标注置信度并明令禁止编造引语 | 单轮耗时更长（自述约 8–12 分钟），且要求先在参考文件或联网检索中核实每位人物的真实理念来源；本技能的三个抽象角色无需额外溯源步骤，开箱即用，更适合日常快速复核 |
| ecfm/adversarial-review（独立仓库） | 面向学术论文手稿的红队/蓝队并行 AI 评审 | 应用领域是学术写作而非代码，评审维度（论证漏洞、引用缺失）与本技能的代码安全/可维护性视角完全不同 |
| pedronauck/skills/adversarial-review（独立仓库） | 另一位独立开发者实现的同名评审理念 | 具体评审流程与人格设定与本技能不同，属于同一评审理念下的另一套独立实现 |
本技能的差异化在于：三个人格分工明确对应“生产故障、可维护性、安全漏洞”三条最常被自我复核忽略的主线，且强制每个人格都要交出发现，避免了“随便挑个视角走个过场”的空转。
8. 用户评价
该技能已被 mcpmarket.com、Claude Directory、RemoteOpenClaw 等至少三个独立的第三方 Claude Code 技能目录站点收录，但截至目前未发现来源可查的具名用户书面评价。
9. 其他补充
SKILL.md 内明确标注了与同目录相邻技能的分工边界：深度安全分析请转 senior-security，通用代码质量评审请转 code-reviewer，二者定位互补而非重叠。同仓库内还有一个更晚加入的姊妹技能 named-persona-adversarial-review，在本技能的三个抽象人格基础上换成有据可查的真实工程师视角，供需要更强溯源依据时使用（见第 7 章对比）。
10. 安装使用方式
渠道一：手动复制
git clone https://github.com/alirezarezvani/claude-skills
cp -r claude-skills/engineering-team/skills/adversarial-reviewer ~/.claude/skills/adversarial-reviewer渠道二：仓库自带的插件市场
仓库根目录提供 marketplace.json 配置，可按仓库 README 中的插件安装说明接入。
安装后注意事项：无需重启客户端；在对话中提及“对抗性评审”“合并前复核”“帮我挑毛病”等场景，或直接输入 /adversarial-review（可选 --diff <ref> 或 --file <path> 参数）即可触发。默认评审的是当前未暂存/已暂存的改动，无改动时自动回退到最近一次提交。
11. 注意事项
- 已知限制：强制每个人格至少交出一条发现的规则，对已经非常干净的小改动可能会产出价值较低的边缘发现（SKILL.md 自身也提示此时应改为记录“最脆弱的假设”而非强行挑刺）。
- 兼容性问题：除 Claude Code 外的其他 agent 平台适配情况均未验证。
- 潜在风险：本质是提示词驱动的结构化复核辅助，不具备真正的静态分析或编译期验证能力，发现仍需人工判断是否成立；对认证、支付等高风险改动，不应替代真人评审，只作为合并前的一道额外关卡。