adversarial-review

1# 三方对抗式代码评审（Blue Team / Third Party / Adjudication）
2 
3## 这个 skill 要解决什么
4 
5单人或单 AI 写代码，最大的风险不是"不会写"，而是：
6 
71. **用未验证的乐观假设说服自己推迟修复**（"这个兜底应该够了吧"）；
82. **测试提供假安全感**（测试全绿，但功能其实早坏了）；
93. **为了修 A 而引入 B**（新写的修复代码本身没被独立审视）。
10 
11这三个问题**靠"再仔细看一遍"解决不了**——写代码的人和审代码的人是同一个，就一定会为自己辩护。只能靠**结构化的对抗关系**：
12 
13| 角色 | 立场 | 硬性约束 |
14|---|---|---|
15| **蓝军** | 敌意审查——假设代码会出事，去**证明** | 每条结论必须附证据链（`文件:行号` / 实测命令 / 上游源码）；🔴/🟠 必须是**实测**结论，仅凭推理最高 🟡；禁止空话 |
16| **第三方** | 独立审计——**不信任任何一方文档**，直接读代码 | 逐条复核"声称修了的是否真修了"、**专找修改引入的新缺陷**、并稽核蓝军**漏掉了哪些维度** |
17| **中立裁定** | 对双方结论**逐条采纳 / 驳回 / 改级** | 必须由**与蓝军不同的 agent** 担任；当事人不能当法官 |
18 
19**关键不是"多找两个 AI 看看"，而是顺序与互不信任**：第三方不信开发团队，裁定方不信蓝军和第三方。任一环节缺失，闭环就破。
20 
21### 配套文件（按需读取）
22 
23- **`references/review-dimensions.md`** —— **完整质量维度清单（19 项）**。第 0 步按改动类型选维度时必须读，否则审查会漏掉大片区域。
24- **`references/prompt-templates.md`** —— **三个角色的完整提示词模板 + 占位符约定 + 「设计要点」表（改模板前必读）**。第 1/2/3 步派发子代理时直接取用，不要临时自编。
25- **`references/quickstart.md`** —— 面向用户的上手说明（档位选择、什么时候不该用它）。
26- **`examples/sample-review.md`** —— 一次真实评审的产出样例。
27 
28> ⚠️ **能力边界（必须向用户如实说明）**
29> 子代理与主代理通常是**同一模型**，这不是真正独立的第三方。其价值来自**角色约束 + 强制证据**，而非"另一个 AI 的观点"。
30> - ✅ 能有效抓出：代码级错误、逻辑漏洞、测试造假、自相矛盾、遗漏分支、声明与实现不符；
31> - ❌ 抓不出：**双方共有的知识盲区**（例如对某个上游行为的一致误解）。若某个结论依赖外部系统行为，必须要求**实测验证**，而不是两个 agent 互相点头。
32>
33> 向用户汇报时，不要说"经独立第三方验证无误"，要说"经同模型不同角色的对抗审查"。
34 
35> 🔁 **降级模式（宿主无子代理能力时）**
36> 若宿主不提供 `subagent`，只能由**同一个 agent 串行扮演三角色**。此时：
37> - 独立性**已被显著削弱**，第 2、3 步的价值大幅下降；
38> - 必须在报告开头显式声明"本次为降级模式，角色由同一 agent 串行扮演"；
39> - 不得使用"独立复核""第三方验证"等措辞；
40> - 有条件时优先换一个有子代理能力的宿主，而不是将就。
41 
42---
43 
44## 执行流程
45 
46### 第 0 步：确定档位、范围与维度
47…