| name | challenge |
| description | 红蓝对抗（Red-Blue Adversarial）结构化思维工具。对方案、架构、决策、技术选型、故障假设进行多轮攻防审查，蓝军挑战假设、红军用数据回应，迭代收敛到更优方案。当用户提到"红蓝对抗"、"challenge"、"挑战一下"、"帮我找漏洞"、"找找风险点"、"可能翻车的地方"、"Devil's advocate"、"对抗分析"、"攻防"时触发。也适用于：用户对方案不够自信想要压力测试、纠结多个方案想暴露各自弱点、怀疑某个故障根因但不确定方向是否正确。注意：简单的技术比较（"X 和 Y 哪个好"）不应触发此 skill，除非用户明确要求对抗/攻防式分析。 |
| argument-hint | [要挑战的方案或主题] |
红蓝对抗（Red-Blue Adversarial）
对方案进行结构化的多轮攻防审查，通过蓝军（攻击方）挑战假设和红军（防御方）用数据回应的交替迭代，暴露盲点、消除过度工程、收敛到最小可行方案。
参数
/challenge — 对当前对话上下文中的方案发起对抗/challenge [方案描述或文件路径] — 对指定方案发起对抗/challenge --light — 轻量模式，快速压力测试/challenge --deep — 深度模式，含隐性假设专项攻击和前瞻分析
输入
对抗目标：$ARGUMENTS
如果 $ARGUMENTS 为空，从当前对话上下文中识别最近讨论的方案/设计/决策作为对抗目标。如果上下文中也没有，使用 AskUserQuestion 询问用户要对什么进行对抗。
核心原则
- 蓝军必须提"最小实验"：每条批评必须附带一个可在 10 分钟内执行的验证动作，空谈无效
- 红军必须"用数据回应"：引用实际数据（grep 结果、API 响应、日志条目、配置文件内容），禁止纯理论反驳。数据有可信度层级（见证据分级），致命/严重问题的回应必须用高可信度证据
- 对抗是双向的：红军不是来认错的，而是用证据守住合理设计。轻易全盘投降和顽固不化一样有害——如果方案的某个决策有充分理由，红军有义务据理力争。好的对抗让方案的合理部分更坚固，不合理部分被替换
- 对抗目标是收敛：每轮对抗应减少方案的复杂度或不确定性，不是增加
- 采纳有成本：每次"采纳"意味着修改方案，修改本身引入复杂度和风险。红军在采纳时必须评估修改成本，避免"攻击什么就改什么"的条件反射
证据可信度分级
对抗中引用的"数据"并非同等可靠。按可信度从高到低：
| 层级 | 证据类型 | 示例 |
|---|
| L1 实验 | 实际运行的实验结果 | 写脚本测量延迟、部署测试环境验证 |
| L2 探测 | API/curl/命令行实时测试 | curl -I https://...、netstat -ano |
| L3 检索 | 读取当前代码/配置/日志 | grep、cat、读文件内容 |
| L4 引用 | 文档、记忆、历史记录 | MEMORY.md 记录、官方文档 |
| L5 推理 | 逻辑推断（无直接证据） | "根据 X 原理，Y 应该成立" |
硬性要求：
- 蓝军标记为"致命"的攻击，最小实验执行后必须产出 L1-L3 级证据
- 红军驳回"致命/严重"攻击时，数据支撑必须达到 L1-L3 级
- L5 推理不能单独作为驳回依据，必须搭配更高层级证据
对抗流程
Phase 0：锚定对抗目标
- 明确对抗对象：方案文档、架构设计、技术选型、故障假设等
- 用 1-3 句话概括方案的核心主张
- 识别方案依赖的显性假设（通常 3-5 个）
- 挖掘隐性假设：列出方案中没有明确说出但必须为真的前提条件——这些是最危险的，因为从未被质疑过。重点关注：
- 运行环境假设（OS、网络、权限、依赖服务可用性）
- 规模假设（数据量、并发量、增长速率）
- 用户行为假设（使用方式、操作顺序、容错预期）
- 时间假设（执行频率、延迟容忍、生命周期）
- 评估对抗深度（如果用户未通过
--light / --deep 指定）：
| 模式 | 适用场景 | 流程 | 预期规模 |
|---|
| 轻量 | 局部决策、2-3 个假设、影响范围小 | Phase 0 → 单轮精简攻防 → 结论 | 3-4 个攻击点 |
| 标准 | 功能设计、技术选型、中等复杂度 | 完整 Phase 0-4 | 5-7 个攻击点 |
| 深度 | 架构设计、高风险决策、生产环境变更 | 完整流程 + 隐性假设专项攻击 + 前瞻分析 | 7+ 个攻击点 |
不确定时默认标准模式。
输出格式：
## 对抗目标
**方案**：[方案名称/概述]
**核心主张**：[1-3 句话]
**显性假设**：
1. [假设 1]
2. [假设 2]
3. [假设 3]
**隐性假设**（未被明确说出但必须成立）：
- [隐性假设 1]：风险等级 [高/中/低]
- [隐性假设 2]：风险等级 [高/中/低]
**对抗模式**：[轻量/标准/深度]，理由：[为什么选这个级别]
Phase 1：蓝军攻击
蓝军的目标不是"找茬"，而是帮方案找到自己看不见的风险。好的蓝军攻击让方案制定者感到"幸好在实施前发现了这个"。
必做：先钢铁人（Steelman）再攻击
每轮攻击开始前，蓝军必须用 2-3 句话展示对方案优势的真正理解——这不是客套。如果蓝军不理解方案为什么这样设计，攻击容易打偏。钢铁人描述应包含：方案试图解决的核心问题、当前设计的合理性来源、相比显而易见的替代方案的独特优势。
蓝军攻击技巧（按优先级）：
- "没确诊就开药"：方案是否基于未验证的假设？是否先设计了方案再找问题？
→ 要求：提出验证假设的最小实验
- 过度工程化检测：最简方案试过了吗？能用 3 行代码解决的问题是否用了 3 层抽象？
→ 要求：给出更简单的替代方案
- 逻辑悖论识别：方案是否自相矛盾？如"用规则解决忘记规则的问题"
→ 要求：指出具体的逻辑环
- 房间里的大象：是否忽略了已有的现成方案/工具/框架？
→ 要求：列出被忽视的已有方案
- 成本盲区：隐含的运维成本、token 消耗、注意力代价、技术债是否被低估？
→ 要求：给出粗略的成本估算
- 钢铁人攻击（Steelmanning Attack）：在理解方案优势的基础上，指出在某个特定条件下优势不成立
→ 要求：明确指出使优势失效的具体条件
- 反转测试：把方案的核心决策反转（如从微服务改为单体），结果会更差吗？
→ 要求：给出反转后的具体对比
- 前瞻性失败（深度模式）：假设方案已上线 6 个月，它最可能因为什么原因失败？
→ 要求：给出具体的失败场景和触发条件
严重度定义（严格校准）：
| 严重度 | 定义 | 判断标准 | 每轮上限 |
|---|
| 致命 | 方案上线后会导致不可逆损失或完全无法工作 | 数据丢失、安全漏洞、核心功能失效 | 最多 2 个 |
| 严重 | 方案能工作但会产生显著的持续性问题 | 性能瓶颈、维护负担、成本超预期 | 不限 |
| 中等 | 方案可以工作但有改进空间 | 代码冗余、缺少监控、扩展性不足 | 不限 |
致命上限的意义：如果超过 2 个问题都符合致命定义，说明方案需要从头审视而非逐条修补——此时蓝军应直接建议用户重新评估方案可行性，而不是继续攻击细节。
输出格式：
## 蓝军攻击 Round N
**钢铁人理解**：[2-3 句话展示对方案优势的理解]
| # | 严重度 | 攻击类型 | 问题 | 最小实验（<10min） |
|---|--------|----------|------|-------------------|
| B1 | 致命 | [类型] | [问题描述] | [验证动作] |
| B2 | 严重 | [类型] | [问题描述] | [验证动作] |
| B3 | 中等 | [类型] | [问题描述] | [验证动作] |
蓝军攻击完成后，立即执行所有标记为"致命"和"严重"的最小实验，将实验结果（含证据层级标注）记录在攻击表下方。这些实验结果将作为红军回应的证据基础。
Phase 2：红军回应
红军的使命是双重的：修正方案中真正有问题的部分，同时守住合理的设计决策。好的红军回应让方案变得更好，而不是被蓝军牵着鼻子走。
红军的平衡约束：
红军不应全盘接受蓝军攻击。当蓝军提出 5 个以上攻击时，如果红军全部采纳，往往说明红军没有认真评估每个攻击的真实成本。对于 5+ 个攻击，红军必须对至少 30% 做出实质性抗辩（驳回、或部分采纳中附带对不合理部分的反驳），除非每个攻击都附带了 L1-L3 级铁证且修改成本可忽略。
"实质性抗辩"不是简单说"不同意"——是提供反面证据，或证明蓝军攻击的前提不成立，或证明修改成本大于风险。
红军回应模式：
| 类型 | 含义 | 要求 |
|---|
| 采纳 | 攻击有效，修改方案 | 给出具体修改 + 修改成本（新增复杂度、影响范围、额外工作量） |
| 部分采纳 | 攻击方向对但结论过头 | 说明接受/拒绝各部分，拒绝理由附 L1-L3 数据 |
| 驳回 | 攻击无效或修改成本不合理 | 给出驳回理由 + L1-L3 级数据支撑 |
| 降级 | 攻击有效但当前阶段不处理 | 说明何时处理、临时缓解措施、降级的风险敞口 |
| 超出范围 | 超出当前评审范围 | 说明归属范围，是否需要单独跟踪 |
回应技巧：
- 认同 + 修正：认可批评方向，但修正具体推论或解决方案
- 降级而非放弃：将"立即引入"降级为"Phase 2 观察"，而非完全移除
- 用数据反转：用 grep/curl/实验的实际结果推翻蓝军的假设
- 区分"方向对"和"结论过头"：承认问题存在但质疑蓝军建议的解决方案
- 约束声明：明确方案的适用边界，"这个方案不处理 X 场景，因为..."
- 成本对比：攻击指出的风险确实存在，但缓解成本 > 风险期望损失
- 检验攻击前提：蓝军的攻击是否基于正确的前提？前提本身是否需要验证？
输出格式：
## 红军回应 Round N
**防守立场**：[1-2 句话——哪些设计决策值得坚守，为什么]
| # | 蓝军编号 | 回应类型 | 回应内容 | 数据支撑 [证据层级] |
|---|---------|---------|---------|-------------------|
| R1 | B1 | 采纳 | [回应] **修改成本**：[评估] | [数据] [L3] |
| R2 | B2 | 驳回 | [回应] | [数据] [L2] |
| R3 | B3 | 部分采纳 | [接受部分] / [拒绝部分及理由] | [数据] [L1] |
### 方案修正 Diff
**变更 1**：[原设计] → [修正后设计]
理由：采纳 B1，[具体原因]
修改成本：[引入的新复杂度/工作量]
**坚守的设计决策**：
1. [决策 1]：驳回 B2，理由 [摘要]
2. [决策 2]：未被攻击，仍然合理因为 [摘要]
Phase 3：蓝军第二轮攻击（收敛轮）
针对红军修正后的方案，进行第二轮审查。此轮重点关注：
- 修正是否引入新问题：改 A 是否破坏了 B？
- 降级处理是否合理：被降级的项目是否真的可以推迟？
- 整体一致性：修正后的方案各部分是否仍然自洽？
- 驳回质量审查：红军的驳回证据是否足够？如果驳回仅靠 L4-L5 证据，重新挑战
此轮只关注"致命"和"严重"问题，中等及以下问题不再提出。
Phase 4：红军第二轮回应（终结轮）
回应蓝军第二轮攻击，产出最终方案。
收敛判断
满足以下任一条件即可结束对抗：
- 蓝军无致命/严重问题：第二轮蓝军攻击未发现致命或严重问题
- 红蓝共识：双方对所有致命/严重问题的处理达成一致
- 最大轮次：已完成 3 轮完整对抗（极少需要第 3 轮）
如果 2 轮后仍有致命问题未解决，使用 AskUserQuestion 询问用户：
- 继续第 3 轮对抗
- 将未解决问题标记为已知风险，接受当前方案
- 暂停对抗，先执行实验收集更多数据
最终输出
对抗收敛后，输出结构化的攻防报告：
## 红蓝对抗报告
### 对抗目标
[方案名称/概述]
### 对抗强度
[轻量/标准/深度] | [N] 轮 | 蓝军 [M] 个攻击 | 红军驳回率 [X%]
### 攻防摘要
- **蓝军提出问题**：[M] 个（致命 X / 严重 Y / 中等 Z）
- **采纳**：[A] 个 | **部分采纳**：[B] 个 | **驳回**：[C] 个 | **降级**：[D] 个
- **方案修改总成本**：[总体评估——修改引入的复杂度是否可控]
### 关键变更
1. [变更 1]：[原方案] → [修正方案]（来源：B[n]）
2. [变更 2]：[原方案] → [修正方案]（来源：B[n]）
### 坚守的设计决策
1. [决策 1]：经受了 B[n] 攻击，驳回理由 [摘要]
2. [决策 2]：经受了 B[n] 攻击，驳回理由 [摘要]
### 已知风险与降级项
1. [风险 1]：降级计划 / 风险敞口 / 触发条件
2. [风险 2]：驳回理由 / 残余风险
### 隐性假设状态
- 已验证：[列表]
- 未验证但风险可接受：[列表]
- 需要持续监控：[列表及监控方式]
### 收敛后方案
[最终方案的完整描述，已整合所有采纳的变更]
### 下一步行动
1. **立即执行**：[最高优先级的具体动作，精确到命令或操作步骤]
2. **本周完成**：[短期跟进项]
3. **持续监控**：[降级项的观察指标和触发阈值]
轻量模式输出格式
轻量模式跳过多轮迭代，用更紧凑的格式快速产出：
## 快速对抗：[方案名称]
**钢铁人理解**：[方案的核心优势]
**隐性假设**：[1-2 个最高风险的未验证前提]
### 压力测试
| # | 风险点 | 验证结果 | 建议 |
|---|--------|---------|------|
| 1 | [问题] | [实验结果 + 证据层级] | [采纳/驳回 + 理由] |
| 2 | [问题] | [实验结果 + 证据层级] | [采纳/驳回 + 理由] |
### 结论
[方案是否可行] + [最大的单点风险] + [建议的下一步]
使用场景适配
架构设计评审
- 蓝军重点：过度工程化、未验证假设、忽略已有方案
- 红军重点：用代码实验和 grep 结果回应
- 默认深度模式
方案选型决策
- 蓝军重点：对每个候选方案分别攻击，暴露各自弱点
- 红军重点：用对比数据（benchmark、成本、复杂度）回应
- 特殊规则：不偏袒任何方案，最终推荐基于攻防后的综合评分
- 默认标准模式
故障根因分析
- 蓝军重点：挑战"确认偏误"——当前假设的根因是否有其他解释？
- 红军重点：用日志、监控数据、复现实验回应
- 特殊规则：蓝军必须提出至少 2 个替代假设
- 默认标准模式
快速决策压力测试
- 蓝军重点：最大的单点风险是什么？
- 红军重点：用已有数据快速验证
- 默认轻量模式
注意事项
- 对抗是工具，不是目标：如果方案本身足够简单且经过验证，不需要强行对抗。快速判断后告知用户"此方案无需对抗"也是有效输出
- 避免对抗膨胀：蓝军每轮最多提 7 个问题，超出时按严重度裁剪
- 实验优于辩论：能用 10 分钟实验解决的分歧，不用 3 轮辩论
- 用户是最终裁判：当红蓝双方僵持时，使用 AskUserQuestion 呈现双方论据让用户裁决
- 警惕全盘采纳：如果红军对所有攻击都说"采纳"，暂停反思——是方案真的全盘有问题（则建议用户重新评估），还是红军偷懒没做防守（则重新执行红军回应）
