# Challenge

> 红蓝对抗（Red-Blue Adversarial）结构化思维工具。对方案、架构、决策、技术选型、故障假设进行多轮攻防审查，蓝军挑战假设、红军用数据回应，迭代收敛到更优方案。当用户提到"红蓝对抗"、"challenge"、"挑战一下"、"帮我找漏洞"、"找找风险点"、"可能翻车的地方"、"Devil's advocate"、"对抗分析"、"攻防"时触发。也适用于：用户对方案不够自信想要压力测试、纠结多个方案想暴露各自弱点、怀疑某个故障根因但不确定方向是否正确。注意：简单的技术比较（"X 和 Y 哪个好"）不应触发此 skill，除非用户明确要求对抗/攻防式分析。

- Skill: `zhuqingxun/challenge` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zhuqingxun/challenge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhuqingxun/challenge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhuqingxun (https://skillmd.com/u/zhuqingxun)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhuqingxun/challenge

---


# 红蓝对抗（Red-Blue Adversarial）

对方案进行结构化的多轮攻防审查，通过蓝军（攻击方）挑战假设和红军（防御方）用数据回应的交替迭代，暴露盲点、消除过度工程、收敛到最小可行方案。

## 参数

- `/challenge` — 对当前对话上下文中的方案发起对抗
- `/challenge [方案描述或文件路径]` — 对指定方案发起对抗
- `/challenge --light` — 轻量模式，快速压力测试
- `/challenge --deep` — 深度模式，含隐性假设专项攻击和前瞻分析

## 输入

对抗目标：$ARGUMENTS

如果 $ARGUMENTS 为空，从当前对话上下文中识别最近讨论的方案/设计/决策作为对抗目标。如果上下文中也没有，使用 AskUserQuestion 询问用户要对什么进行对抗。

## 核心原则

1. **蓝军必须提"最小实验"**：每条批评必须附带一个可在 10 分钟内执行的验证动作，空谈无效
2. **红军必须"用数据回应"**：引用实际数据（grep 结果、API 响应、日志条目、配置文件内容），禁止纯理论反驳。数据有可信度层级（见证据分级），致命/严重问题的回应必须用高可信度证据
3. **对抗是双向的**：红军不是来认错的，而是用证据守住合理设计。轻易全盘投降和顽固不化一样有害——如果方案的某个决策有充分理由，红军有义务据理力争。好的对抗让方案的合理部分更坚固，不合理部分被替换
4. **对抗目标是收敛**：每轮对抗应减少方案的复杂度或不确定性，不是增加
5. **采纳有成本**：每次"采纳"意味着修改方案，修改本身引入复杂度和风险。红军在采纳时必须评估修改成本，避免"攻击什么就改什么"的条件反射

## 证据可信度分级

对抗中引用的"数据"并非同等可靠。按可信度从高到低：

| 层级 | 证据类型 | 示例 |
|------|---------|------|
| **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. 明确对抗对象：方案文档、架构设计、技术选型、故障假设等
2. 用 1-3 句话概括方案的核心主张
3. 识别方案依赖的**显性假设**（通常 3-5 个）
4. **挖掘隐性假设**：列出方案中没有明确说出但必须为真的前提条件——这些是最危险的，因为从未被质疑过。重点关注：
   - 运行环境假设（OS、网络、权限、依赖服务可用性）
   - 规模假设（数据量、并发量、增长速率）
   - 用户行为假设（使用方式、操作顺序、容错预期）
   - 时间假设（执行频率、延迟容忍、生命周期）
5. **评估对抗深度**（如果用户未通过 `--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 句话展示对方案优势的真正理解——这不是客套。如果蓝军不理解方案为什么这样设计，攻击容易打偏。钢铁人描述应包含：方案试图解决的核心问题、当前设计的合理性来源、相比显而易见的替代方案的独特优势。

**蓝军攻击技巧（按优先级）**：

1. **"没确诊就开药"**：方案是否基于未验证的假设？是否先设计了方案再找问题？
   → 要求：提出验证假设的最小实验
2. **过度工程化检测**：最简方案试过了吗？能用 3 行代码解决的问题是否用了 3 层抽象？
   → 要求：给出更简单的替代方案
3. **逻辑悖论识别**：方案是否自相矛盾？如"用规则解决忘记规则的问题"
   → 要求：指出具体的逻辑环
4. **房间里的大象**：是否忽略了已有的现成方案/工具/框架？
   → 要求：列出被忽视的已有方案
5. **成本盲区**：隐含的运维成本、token 消耗、注意力代价、技术债是否被低估？
   → 要求：给出粗略的成本估算
6. **钢铁人攻击（Steelmanning Attack）**：在理解方案优势的基础上，指出在某个特定条件下优势不成立
   → 要求：明确指出使优势失效的具体条件
7. **反转测试**：把方案的核心决策反转（如从微服务改为单体），结果会更差吗？
   → 要求：给出反转后的具体对比
8. **前瞻性失败**（深度模式）：假设方案已上线 6 个月，它最可能因为什么原因失败？
   → 要求：给出具体的失败场景和触发条件

**严重度定义**（严格校准）：

| 严重度 | 定义 | 判断标准 | 每轮上限 |
|--------|------|---------|---------|
| **致命** | 方案上线后会导致**不可逆损失**或**完全无法工作** | 数据丢失、安全漏洞、核心功能失效 | 最多 2 个 |
| **严重** | 方案能工作但会产生**显著的持续性问题** | 性能瓶颈、维护负担、成本超预期 | 不限 |
| **中等** | 方案可以工作但有改进空间 | 代码冗余、缺少监控、扩展性不足 | 不限 |

致命上限的意义：如果超过 2 个问题都符合致命定义，说明方案需要从头审视而非逐条修补——此时蓝军应直接建议用户重新评估方案可行性，而不是继续攻击细节。

**输出格式**：

```
## 蓝军攻击 Round N

**钢铁人理解**：[2-3 句话展示对方案优势的理解]

| # | 严重度 | 攻击类型 | 问题 | 最小实验（<10min） |
|---|--------|----------|------|-------------------|
| B1 | 致命 | [类型] | [问题描述] | [验证动作] |
| B2 | 严重 | [类型] | [问题描述] | [验证动作] |
| B3 | 中等 | [类型] | [问题描述] | [验证动作] |
```

蓝军攻击完成后，**立即执行**所有标记为"致命"和"严重"的最小实验，将实验结果（含证据层级标注）记录在攻击表下方。这些实验结果将作为红军回应的证据基础。

### Phase 2：红军回应

红军的使命是双重的：修正方案中真正有问题的部分，同时守住合理的设计决策。好的红军回应让方案变得更好，而不是被蓝军牵着鼻子走。

**红军的平衡约束**：

红军不应全盘接受蓝军攻击。当蓝军提出 5 个以上攻击时，如果红军全部采纳，往往说明红军没有认真评估每个攻击的真实成本。对于 5+ 个攻击，红军必须对至少 30% 做出实质性抗辩（驳回、或部分采纳中附带对不合理部分的反驳），除非每个攻击都附带了 L1-L3 级铁证且修改成本可忽略。

"实质性抗辩"不是简单说"不同意"——是提供反面证据，或证明蓝军攻击的前提不成立，或证明修改成本大于风险。

**红军回应模式**：

| 类型 | 含义 | 要求 |
|------|------|------|
| **采纳** | 攻击有效，修改方案 | 给出具体修改 **+ 修改成本**（新增复杂度、影响范围、额外工作量） |
| **部分采纳** | 攻击方向对但结论过头 | 说明接受/拒绝各部分，拒绝理由附 L1-L3 数据 |
| **驳回** | 攻击无效或修改成本不合理 | 给出驳回理由 + L1-L3 级数据支撑 |
| **降级** | 攻击有效但当前阶段不处理 | 说明何时处理、临时缓解措施、降级的风险敞口 |
| **超出范围** | 超出当前评审范围 | 说明归属范围，是否需要单独跟踪 |

**回应技巧**：

1. **认同 + 修正**：认可批评方向，但修正具体推论或解决方案
2. **降级而非放弃**：将"立即引入"降级为"Phase 2 观察"，而非完全移除
3. **用数据反转**：用 grep/curl/实验的实际结果推翻蓝军的假设
4. **区分"方向对"和"结论过头"**：承认问题存在但质疑蓝军建议的解决方案
5. **约束声明**：明确方案的适用边界，"这个方案不处理 X 场景，因为..."
6. **成本对比**：攻击指出的风险确实存在，但缓解成本 > 风险期望损失
7. **检验攻击前提**：蓝军的攻击是否基于正确的前提？前提本身是否需要验证？

**输出格式**：

```
## 红军回应 Round N

**防守立场**：[1-2 句话——哪些设计决策值得坚守，为什么]

| # | 蓝军编号 | 回应类型 | 回应内容 | 数据支撑 [证据层级] |
|---|---------|---------|---------|-------------------|
| R1 | B1 | 采纳 | [回应] **修改成本**：[评估] | [数据] [L3] |
| R2 | B2 | 驳回 | [回应] | [数据] [L2] |
| R3 | B3 | 部分采纳 | [接受部分] / [拒绝部分及理由] | [数据] [L1] |

### 方案修正 Diff

**变更 1**：[原设计] → [修正后设计]
  理由：采纳 B1，[具体原因]
  修改成本：[引入的新复杂度/工作量]

**坚守的设计决策**：
1. [决策 1]：驳回 B2，理由 [摘要]
2. [决策 2]：未被攻击，仍然合理因为 [摘要]
```

### Phase 3：蓝军第二轮攻击（收敛轮）

针对红军修正后的方案，进行第二轮审查。此轮重点关注：

1. **修正是否引入新问题**：改 A 是否破坏了 B？
2. **降级处理是否合理**：被降级的项目是否真的可以推迟？
3. **整体一致性**：修正后的方案各部分是否仍然自洽？
4. **驳回质量审查**：红军的驳回证据是否足够？如果驳回仅靠 L4-L5 证据，重新挑战

此轮只关注"致命"和"严重"问题，中等及以下问题不再提出。

### Phase 4：红军第二轮回应（终结轮）

回应蓝军第二轮攻击，产出最终方案。

## 收敛判断

满足以下**任一**条件即可结束对抗：

1. **蓝军无致命/严重问题**：第二轮蓝军攻击未发现致命或严重问题
2. **红蓝共识**：双方对所有致命/严重问题的处理达成一致
3. **最大轮次**：已完成 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 呈现双方论据让用户裁决
- **警惕全盘采纳**：如果红军对所有攻击都说"采纳"，暂停反思——是方案真的全盘有问题（则建议用户重新评估），还是红军偷懒没做防守（则重新执行红军回应）