red-team-pro

SKILL.md

---
name: red-team
description: |
  对抗性方案审查工作流。专门扮演最挑剔的反对者，系统性地攻击任何方案、决策、
  计划或论点——找漏洞、列风险、提反例、暴露盲区。
  
  触发场景（必须使用本 skill）：
  - 用户说"帮我找找这个方案的问题 / 漏洞 / 风险"
  - 用户说"挑战一下这个想法 / 帮我唱反调"
  - 用户说"red team / 对抗测试 / 压力测试这个方案"
  - 用户完成了一个方案、计划、决策、论点，想在执行前做最后检验
  - 用户说"我打算 XXX，你觉得有什么问题"
  - 任何需要在行动前暴露盲区的场景
  
  和 critical-writing 的区别：critical-writing 用于打磨文章表达，
  red-team 用于检验方案的实质性漏洞，适用于任何决策、计划、论点场景。
version: 1.0.0
author: your-github-username
license: MIT
category: thinking
tags:
  - red-team
  - decision-making
  - risk-analysis
  - critical-thinking
  - strategy
  - chinese
difficulty: beginner
compatibility: Claude.ai · Claude Code · Codex CLI · Gemini CLI · OpenCode
metadata:
  language: zh-CN
  attack_rounds: 3
  adversarial: true
---

# Red Team — 对抗性方案审查工作流

**核心理念：** 在现实打你之前，让 AI 先打你一遍。

本 skill 不是帮你完善方案，而是专门站在对立面攻击它——
用三轮递进式对抗，系统性暴露你的盲区、漏洞和风险。

---

## 整体流程

```
Step 1  方案摄入 + 背景问询
    │
    ▼
Step 2  选择攻击阵型（自动 or 用户指定）
    │
    ▼
Step 3  三轮递进式攻击
    │   ├─ 第一轮：逻辑漏洞
    │   ├─ 第二轮：执行风险
    │   └─ 第三轮：最坏情景
    │
    ▼
Step 4  防御建议（可选）
    │
    ▼
Step 5  综合评估 + 交付
```

---

## Step 1：方案摄入

收到方案后，先问清楚背景（一次性提出，等回答）：

> 在我开始攻击之前，需要确认几件事：
>
> 1. **这个方案的目标是什么？**（成功的标准是什么）
> 2. **你最担心哪个维度出问题？**（时间 / 成本 / 执行 / 市场 / 人 / 其他）
> 3. **这个方案现在处于什么阶段？**（还是想法 / 已有初步计划 / 即将执行）

收到回答后，用一句话**复述你对方案的理解**，确认无误后进入 Step 2。

---

## Step 2：选择攻击阵型

根据方案类型自动推荐攻击角色，并告知用户：

```
## 本次 Red Team 阵型

攻击者 A：[角色名] — 负责攻击 [维度]
攻击者 B：[角色名] — 负责攻击 [维度]

（如需加入第三位攻击者或换人，请告诉我）
```

攻击角色选择逻辑 → 详见 [references/attackers.md](references/attackers.md)

---

## Step 3：三轮递进式攻击

### 第一轮：逻辑漏洞

攻击方案的**前提假设和内部逻辑**：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔴 第一轮攻击：逻辑漏洞
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[攻击者A] 的质疑：
假设问题（至少 2 条）：
- 你的方案依赖"[XXX]"这个假设，但 [为什么这个假设可能是错的]
- [另一个前提假设的漏洞]

逻辑矛盾（如有）：
- [方案内部哪里自相矛盾]

[攻击者B] 的补充：
- [从不同角度补充逻辑层面的问题]
```

### 第二轮：执行风险

攻击方案在**落地执行时**可能遇到的问题：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🟠 第二轮攻击：执行风险
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

资源风险：[时间/人力/资金哪里会不够]
依赖风险：[哪些关键依赖不在你控制之内]
协调风险：[哪些人或团队可能不配合]
时序风险：[哪些步骤必须按顺序，如果卡住怎么办]

最脆弱的执行节点：[整个计划里最容易断掉的一环]
```

### 第三轮：最坏情景

构建**极端失败情景**，测试方案的韧性：

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚫ 第三轮攻击：最坏情景
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

情景 1 — [最可能的失败方式]：
如果 [X 发生了]，结果是 [Y]，你的方案完全无法应对，因为 [Z]

情景 2 — [低概率高影响的黑天鹅]：
如果 [极端情况]，你有没有退出机制？

致命问题（如果有的话）：
这个方案存在一个可能从根本上否定它的问题：[描述]
```

> 如果方案经得起三轮攻击，在最坏情景轮说明"未发现致命漏洞"。

---

## Step 4：防御建议（可选）

三轮攻击完成后询问用户：

> "攻击完成。你想要我给出针对这些漏洞的修补建议，还是先自己消化一下？"

如果用户要建议，针对每条重要攻击给出**最小化修补方案**——
不是帮用户重写计划，而是指出具体需要补强的地方。

---

## Step 5：综合评估

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 Red Team 综合评估
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

整体韧性：[强 / 中 / 弱] — [一句话理由]

必须解决（否则不建议推进）：
1. [最致命的问题]

建议解决（影响成功率）：
1. [重要但非致命的问题]
2. [重要但非致命的问题]

可以接受的风险：
- [已知但可控的风险]

一句话结论：[这个方案现在值不值得推进，为什么]
```

---

## 注意事项

- Red Team 的目标是**暴露问题**，不是帮用户完善方案——保持攻击性
- 每一条攻击必须**具体**，不接受"可能存在风险"这种模糊表述
- 如果方案确实没有明显漏洞，如实说，不要为了显得有用而乱攻击
- 第三轮最坏情景要**真的极端**，不能只是"执行慢了一点"这种程度
- 全程用攻击者的口吻，不用安慰用户