adversarial-reviewlisted

# 三方对抗式代码评审（Blue Team / Third Party / Adjudication） ## 这个 skill 要解决什么 单人或单 AI 写代码，最大的风险不是"不会写"，而是： 1. **用未验证的乐观假设说服自己推迟修复**（"这个兜底应该够了吧"）； 2. **测试提供假安全感**（测试全绿，但功能其实早坏了）； 3. **为了修 A 而引入 B**（新写的修复代码本身没被独立审视）。 这三个问题**靠"再仔细看一遍"解决不了**，只能靠**结构化的对抗关系**： | 角色 | 立场 | 硬性约束 | |---|---|---| | **蓝军** | 敌意审查——假设代码会出事，去**证明** | 每条结论必须附证据链（`文件:行号` / 实测命令 / 宿主源码）；禁止"建议加强鲁棒性"这类空话 | | **第三方** | 独立审计——**不信任任何一方文档**，直接读代码 | 必须逐条复核"声称修了的是否真修了"，并**专门寻找修改过程引入的新缺陷** | | **中立裁定** | 对第三方意见**逐条采纳 / 驳回 / 改级** | 必须由**与蓝军不同的 agent** 担任；防止第三方定级偏高或推理错误，也防止蓝军为自己的结论辩护 | **关键不是"多找两个 AI 看看"，而是顺序与互不信任**：第三方不信开发团队，裁定方不信蓝军和第三方。任一环节缺失，闭环就破。 > ⚠️ **能力边界（必须向用户如实说明）** > 子代理与主代理通常是**同一模型**，这不是真正独立的第三方。其价值来自**角色约束 + 强制证据**，而非"另一个 AI 的观点"。 > - ✅ 能有效抓出：代码级错误、逻辑漏洞、测试造假、自相矛盾、遗漏分支、声明与实现不符； > - ❌ 抓不出：**双方共有的知识盲区**（例如对某个上游行为的一致误解）。若某个结论依赖外部系统行为，必须要求**实测验证**，而不是两个 agent 互相点头。 > > 向用户汇报时，不要说"经独立第三方验证无误"，要说"经同模型不同角色的对抗审查"。 > 🔁 **降级模式（宿主无子代理能力时）** > 若宿主不提供 `subagent`，只能由**同一个 agent 串行扮演三角色**。此时： > - 独立性**已被显著削弱**，第 2、3 步的价值大幅下降； > - 必须在报告开头显式声明"本次为降级模式，角色由同一 agent 串行扮演"； > - 不得使用"独立复核""第三方验证"等措辞。 > - 有条件时优先换一个有子代理能力的宿主，而不是将就。 --- ## 执行流程 ### 第 0 步：确定档位与范围 先问用户或从上下文判断档位（默认**标准档**）： | 档位 | 配置 | 适用 | |---|---|---| | **轻档** | 1 个蓝军（聚焦关键项：正确性 / 兼容性 / 测试有效性）| 小改动、时间紧 | | **标准档**（默认）| 蓝军全量 → 第三方复核 → 中立裁定，共 3 轮 | 一般功能版本 | | **重档** | 标准档 + 多路子代理并行交叉验证（兼容性 / 功能安全 / 生态共存 分开审）| 发布前、重大重构、涉及上游兼容 | **同时确认**： - 审查基线 = 哪个 commit / 工作区？（用 `git rev-parse --short HEAD` 与 `git status` 记录，写进报告表头） - 报告落盘位置（默认 `docs/review/`，见"报告归档"一节） **动