三方对抗式代码评审（Blue Team / Third Party / Adjudication）

这个 skill 要解决什么

单人或单 AI 写代码，最大的风险不是"不会写"，而是：

1. 用未验证的乐观假设说服自己推迟修复（"这个兜底应该够了吧"）；
2. 测试提供假安全感（测试全绿，但功能其实早坏了）；
3. 为了修 A 而引入 B（新写的修复代码本身没被独立审视）。

这三个问题靠"再仔细看一遍"解决不了, , 写代码的人和审代码的人是同一个，就一定会为自己辩护。只能靠结构化的对抗关系：

角色	立场	硬性约束
蓝军	敌意审查, , 假设代码会出事，去证明	每条结论必须附证据链（文件:行号 / 实测命令 / 上游源码）；🔴/🟠 必须是实测结论，仅凭推理最高 🟡；禁止空话
第三方	独立审计, , 不信任任何一方文档，直接读代码	逐条复核"声称修了的是否真修了"、专找修改引入的新缺陷、并稽核蓝军漏掉了哪些维度
中立裁定	对双方结论逐条采纳 / 驳回 / 改级	必须由与蓝军不同的 agent 担任；当事人不能当法官

关键不是"多找两个 AI 看看"，而是顺序与互不信任：第三方不信开发团队，裁定方不信蓝军和第三方。任一环节缺失，闭环就破。

配套文件（按需读取）

• references/review-dimensions.md, , 完整质量维度清单（19 项）。第 0 步按改动类型选维度时必须读，否则审查会漏掉大片区域。
• references/prompt-templates.md, , 三个角色的完整提示词模板 + 占位符约定 + 「设计要点」表（改模板前必读）。第 1/2/3 步派发子代理时直接取用，不要临时自编。
• references/quickstart.md, , 面向用户的上手说明（档位选择、什么时候不该用它）。
• examples/sample-review.md, , 一次真实评审的产出样例。

⚠️ 能力边界（必须向用户如实说明） 子代理与主代理通常是同一模型，这不是真正独立的第三方。其价值来自角色约束 + 强制证据，而非"另一个 AI 的观点"。

• ✅ 能有效抓出：代码级错误、逻辑漏洞、测试造假、自相矛盾、遗漏分支、声明与实现不符；
• ❌ 抓不出：双方共有的知识盲区（例如对某个上游行为的一致误解）。若某个结论依赖外部系统行为，必须要求实测验证，而不是两个 agent 互相点头。

向用户汇报时，不要说"经独立第三方验证无误"，要说"经同模型不同角色的对抗审查"。

🔁 降级模式（宿主无子代理能力时） 若宿主不提供 subagent，只能由同一个 agent 串行扮演三角色。此时：

• 独立性已被显著削弱，第 2、3 步的价值大幅下降；
• 必须在报告开头显式声明"本次为降级模式，角色由同一 agent 串行扮演"；
• 不得使用"独立复核""第三方验证"等措辞；
• 有条件时优先换一个有子代理能力的宿主，而不是将就。

---

执行流程

第 0 步：确定档位、范围与维度

先问用户或从上下文判断档位（默认标准档）：

档位	配置	相对成本	适用
轻档	1 个蓝军（聚焦选定维度）	~1x	小改动、时间紧
标准档（默认）	蓝军全量 → 第三方复核 → 中立裁定，共 3 轮	~3x	一般功能版本
重档	标准档 + 多路子代理并行交叉验证（按维度分组并行审）	~5-8x	发布前、重大重构、涉及上游兼容

（~Nx 为相对一轮蓝军审查的 token 经验估计，未经精确计量。）

必做四件事：