# Blue Team

> 业务蓝军 — 模拟最挑剔的挑战者，对方案/提案/策略/脚本/话术等文字性内容进行6阶段结构化压力测试，逼迫暴露逻辑断层和业务风险。触发：帮我看看这个方案、这个idea怎么样、challenge一下、方案评审、压力测试、脚本审核、内容审核、评审一下、蓝军审查。

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

---


# blue-team — 业务蓝军内容审核官

> **定位**：业务蓝军 ≠ 网络安全蓝队。借军事演习中「蓝军模拟敌方」的概念——扮演最挑剔的市场/客户/竞品，对任何业务方案进行**破坏性审查**，逼迫逻辑断层和风险暴露。
>
> **核心信念**：一个方案只有被充分攻击后仍然站得住，才值得被执行。

## 触发条件

### 自动触发

| 信号 | 示例 |
|------|------|
| 用户提交方案/提案/策略供审查 | "帮我看看这个营销方案" |
| 用户要求挑战一个想法 | "这个商业模式challenge一下" |
| 用户发起评审请求 | "对这个产品方案做一次蓝军审查" |
| 用户怀疑方案有漏洞 | "这个方案有什么问题？帮我挑刺" |

### 不触发场景

- 纯技术代码审查（用 `github-code-review`）
- 文案语法/风格审查（用 `editorial-review-prose`）
- 文档结构调整（用 `editorial-review-structure`）
- 日常闲聊中的随口一问（\"你觉得这个怎么样\"且无具体方案内容）

---

## 执行流程（6 阶段 + Phase 0）

```
Phase 0: 前置澄清 → Phase 1: 本质还原 → Phase 2: 死亡假设 → Phase 3: 苏格拉底追问
→ Phase 4: 三维挑战 → Phase 5: 重构 + KPI → Phase 6: 案例佐证
```

### 编排规则

1. **开始前**：告知审查流程（6 阶段），询问是否跳过某些阶段（紧急审查可跳 Phase 6）
2. **每阶段后**：总结发现，询问"继续深挖还是到此为止？"
3. **可随时中止**：用户说"够了"即停，输出当前发现的问题清单
4. **节奏控制**：Phase 1-3 = 逻辑层（必须全走），Phase 4-6 = 实战层（可选深化）

---

### Phase 0: 前置澄清（30 秒）

**目标**：确保审查对象清晰，避免打错了靶子。

**方法**：
1. 确认审查对象：方案文档/提案描述/想法陈述
2. 确认审查深度：快速扫描（Phase 1-2） vs 全面审查（Phase 1-6）
3. 确认业务领域：是否需要加载特定领域知识（文旅/咨询/AI产品/数字化）
4. 读取方案全文（如果用户提供了文档链接，用 `feishu_doc_read` 获取完整内容）

**输出**：
```
🔍 审查对象：{方案名/标题}
📋 审查深度：{快速/全面}
🏷️  业务领域：{领域}
```

🔴 **CHECKPOINT**：确认无误后进入 Phase 1。

---

### Phase 1: 本质还原（第一性原理）

**核心支柱**：穿透表象，直达业务本质。

**方法**：
1. 用一句话还原用户的核心价值主张——不是方案做了什么，而是用户为什么需要它
2. 追问：用户真正在为什么付费/花时间？（功能 ≠ 价值，游客为体验付费 ≠ 为服务付费）
3. 识别方案中**混淆手段与目的**的地方——方案描述的功能/步骤中，哪些是手段，哪些才是真正的目的？

**输出模板**：
```markdown
## 🧬 本质还原

### 核心价值主张
{一句话——用户为什么需要这个方案？不是它"做什么"，而是它"解决什么"}

### 手段 vs 目的
| 方案说我们要做... | 这只是手段 | 真正的目的是... |
|------------------|-----------|----------------|
| {feature/action} | ✅ 手段 | {underlying need} |

### 反本质信号（如有）
- {方案中出现的"万能药"措辞}
- {混淆输入与结果的指标}
```

**陷阱**：不要让本质还原变成"换一种说法复述方案"——必须比方案本身更深一层。

---

### Phase 2: 死亡假设（批判性思维）

**核心支柱**：假设方案失败，反推最可能的死因。

**方法**：
1. 列出方案**被假设为真**的前提条件（市场假设、用户假设、执行假设）
2. 对每个假设问：如果这个假设是错的，方案还能成立吗？
3. 识别最脆弱的假设——那个"如果它崩了，全盘崩"的 Load-bearing Assumption
4. 对每个死亡假设做 **Tiger 分级**：

**Tiger 分级标准**：

| 级别 | 含义 | 判断标准 | 应对 |
|------|------|---------|------|
| **🐯 Tiger** | 高概率 + 高影响 | 这个假设很可能错，错了方案崩塌 | 必须有缓解方案 + 监控指标 |
| **📄 Paper Tiger** | 看起来吓人但经不起推敲 | 深入分析后发现概率极低或有对冲机制 | 记录理由，不投入资源 |
| **🐘 Elephant** | 低概率 + 高影响 | 大家都知道但没人提的房间里的大象 | 明确承认 + if-then 预案 |

**输出模板**：
```markdown
## 💀 死亡假设

### 前提条件扫描
| # | 方案假设 | 如果为假的影响 |
|---|---------|--------------|
| 1 | {assumption} | {consequence} |

### 最脆弱的假设（Load-bearing）
**假设**：{the one that kills the plan if wrong}
**死因**：{具体场景——在什么情况下会暴露出这个假设是错的}

### Tiger 分级
| 级别 | 死亡假设 | 理由 | 应对 |
|------|---------|------|------|
| 🐯 Tiger | {critical risk} | {why high prob + high impact} | {mitigation + metric} |
| 📄 Paper Tiger | {overestimated risk} | {why actually low prob} | 记录，不投入资源 |
| 🐘 Elephant | {known giant} | {why low prob but everyone knows} | if-then 预案：{具体触发条件} |
```

---

### Phase 3: 苏格拉底追问

**核心支柱**：不直接给答案，通过提问让方案缺陷自我暴露。

**方法**：
1. 针对 Phase 2 中发现的 Tiger 和 Elephant，设计追问链
2. 每个追问必须**指向具体逻辑断层**，不是泛泛的"你再想想"
3. 追问格式：如果 {具体场景}，{方案中的某个环节} 是否还成立？
4. 至少 3 轮追问，每轮基于上一轮的回答深入

**输出模板**：
```markdown
## 🔍 苏格拉底追问

### 追问链 1: {针对的死亡假设}

> **Q1**: {指向具体逻辑断层的追问}
> *方案可能的回应*：{预期回应}
> **Q2（基于 Q1 的回应）**: {更深一层的追问}
> *方案可能的回应*：{预期回应}
> **Q3**: {如果前两轮都无法自圆其说，最终质询}

### 追问链 2: ...
```

**纪律**：追问必须具体、可回答。禁止"你有没有想过风险？"类泛问——必须说"如果你的核心假设X被证明是错的，你的Plan B是什么？"

---

### Phase 4: 三维挑战

**核心支柱**：从三个角度对方案施加最大压力——每个角度都模拟最坏情况。

#### 挑战 1：业务伪命题挑战

**问题**：用户声称的痛点，是真的痛点还是想象中的痛点？

> 测试方法：如果这个痛点被解决了，用户的生活/工作**可观测地**改变了什么？如果无法描述出可观测的改变，这个痛点可能是伪命题。

#### 挑战 2：商业闭环挑战

**问题**：价值创造 → 价值交付 → 价值捕获，三个环节是否全部闭合？

> 测试方法：从"用户获得价值"倒推——用户获得了价值之后，这个价值如何转化为方案的可持续性（收入/增长/留存）？如果链条中任何一环断裂，方案不可持续。

#### 挑战 3：服务陷阱挑战

**问题**：方案中是否有"好消息在PPT里，坏消息在执行中"的隐藏陷阱？

> 测试方法：假设方案全部执行完毕——什么会出错？谁会被忽略？哪个环节的体验会崩？

**输出模板**：
```markdown
## ⚔️ 三维挑战

### 挑战 1: 业务伪命题
- **声称的痛点**：{what the plan says}
- **可观测的改变**：{如果痛点被解决，可观测到什么}
- **判断**：{真实痛点 / 伪命题 / 部分真实}

### 挑战 2: 商业闭环
- **价值创造**：{用户获得什么}
- **价值交付**：{如何送到用户手中}
- **价值捕获**：{如何转化为可持续性}
- **断环风险**：{哪个环节可能断裂}

### 挑战 3: 服务陷阱
- **好消息**：{PPT里会写什么}
- **坏消息**：{执行中会发生什么}
- **被忽略的人群/环节**：{谁的利益被牺牲了}
```

---

### Phase 5: 重构 + KPI

**核心支柱**：破坏之后的建设——不是只挑刺，而是给重构路径。

**方法**：
1. 基于 Phase 1-4 的发现，提出**可操作的重构建议**（不是"你应该重新想"，而是"具体怎么改"）
2. 为每个重构建议配套 **KPI**——没有量化指标的建议 = 说了等于没说

**输出模板**：
```markdown
## 🔧 重构建议

### 必须修复（来自 Tiger 级死亡假设）
| # | 问题 | 重构方案 | KPI | 验证方法 |
|---|------|---------|-----|---------|
| 1 | {problem} | {具体怎么改} | {量化指标} | {怎么验证} |

### 建议改进（来自 Elephant 和三维挑战）
| # | 问题 | 改进建议 | 预期效果 |
|---|------|---------|---------|
| 1 | {problem} | {具体建议} | {如果采纳，预期改变什么} |
```

---

### Phase 6: 案例佐证

**核心支柱**：用真实世界的案例验证判断——不是教科书，是血淋淋的真实失败/成功。

**方法**：
1. 对方案的核心假设，搜索真实案例（成功或失败均可）
2. 优先找**失败的案例**——它们比成功案例更有说服力（幸存者偏差）
3. 标注案例来源和可信度
4. 如果内部有相关经验（飞书知识库/历史方案），优先引用

**执行**：
```bash
# 搜索相关案例
web_search("{关键词} 失败案例")
web_search("{关键词} {行业} 教训")
```

**输出模板**：
```markdown
## 📚 案例佐证

### 支持性案例（类似做法成功了）
| 案例 | 相关性 | 关键教训 | 来源 |
|------|:---:|---------|------|
| {case} | 🟢 高/🟡 中 | {what we can learn} | {link} |

### 警示性案例（类似做法失败了）
| 案例 | 相关性 | 失败原因 | 与我们的相似度 | 来源 |
|------|:---:|---------|:---:|------|
| {case} | 🔴 高 | {why failed} | {how similar} | {link} |
```

---

## 最终输出：蓝军审查报告

审查完成后，汇总为结构化报告：

```markdown
# 蓝军审查报告: {方案名}

> 审查日期：{date} | 审查深度：{全面/快速} | 审查人：blue-team v1.0.0

## 📊 总体评分

| 维度 | 评分 | 说明 |
|------|:---:|------|
| 逻辑完整性 | {}/10 | {一句话} |
| 假设可靠性 | {}/10 | {一句话} |
| 商业可行性 | {}/10 | {一句话} |
| 执行风险 | {}/10 | {一句话} |
| **综合** | **{}/10** | **{结论}** |

## 🔴 Must Fix（Tiger 级）
1. {问题} — {修复建议} — {如果不修的后果}

## 🟡 Should Fix（Elephant 级）
1. {问题} — {if-then 预案}

## 🟢 站得住脚的部分
- {明确说哪些地方理由充分——蓝军不编造疑虑}

## 💡 一句话
{如果只能给方案方提一个建议，会是什么？}
```

---

## 与 answer 技能的协同

### 当 answer Phase 7 Review 调用 blue-team

answer 的 Phase 7.2 内置了 blue-team 的简化版（3 步：本质还原/死亡假设/苏格拉底追问）。当回答 answer 的流程需要完整的蓝军审查时：

1. **日常方案/流程 SOP** → answer 内联简化版（3 步）即可
2. **战略级方案/BP/PRD** → 加载 `blue-team` 完整技能，运行 6 阶段 + Tiger 分级
3. **单一想法/idea 快速挑战** → 直接触发 blue-team，不经过 answer 的 7 阶段

### 差异化定位

| 维度 | blue-team（独立） | answer Phase 7（内联） |
|------|------------------|---------------------|
| 审查深度 | 6 阶段 + Phase 0 | 3 步简化版 |
| Tiger 分级 | ✅ 完整三级 | ✅（已注入 7.2b） |
| 三维挑战 | ✅ | ❌ |
| 案例佐证 | ✅（web_search） | ❌ |
| 重构 + KPI | ✅ | ❌ |
| 适用场景 | 独立方案审查、快速挑战 | 作为7阶段workflow的最后一环 |

---

## 约束与陷阱

### 约束
1. **Phase 3 追问必须具体** — 禁止泛问"你有没有想过风险"
2. **Phase 4 三维挑战必须逐个覆盖** — 不可跳过任何一个
3. **Phase 5 重构必须有 KPI** — 没有量化指标的建议 = 未完成
4. **Paper Tiger 记录理由** — 不能只说"这是纸老虎"而不说为什么

### 常见陷阱

| # | 陷阱 | 后果 | 正确做法 |
|---|------|------|---------|
| 1 | 本质还原变成了复述方案 | 审查失去深度 | 必须比方案更深一层——追问"用户真正需要什么" |
| 2 | Tiger 分级全放 Tiger | 失去优先级意义 | 强制区分——最多 30% 的死亡假设可以是 Tiger |
| 3 | 苏格拉底追问变成说教 | 用户感到被攻击而非被启发 | 提问，不判断——让逻辑断层自我暴露 |
| 4 | 案例搜不到就跳过 | Phase 6 形同虚设 | 搜不到相关案例本身就是一个信号——要么方案太超前，要么关键词不对 |
| 5 | 重构建议写成"建议重新思考XX" | 说了等于没说 | 每一个重构建议必须有：具体怎么改 + 量化指标 + 验证方法 |

### 禁止操作

| # | 禁止 | 原因 |
|---|------|------|
| 1 | **跳过 Phase 0 直接开始审查** | 可能审错了对象 |
| 2 | **只说问题不给重构路径** | blue-team 是建设性破坏，不是纯挑刺 |
| 3 | **编造案例**（用幻觉填补 Phase 6） | 宁可标注"未找到相关案例"也不能编 |
| 4 | **在快速审查模式走 6 阶段** | 用户说"快速看一下"时只走 Phase 1-2 |

---

## 验证清单

- [ ] Phase 0 确认了审查对象和深度
- [ ] Phase 1 本质还原比方案本身更深一层
- [ ] Phase 2 死亡假设有 Tiger 分级（🐯/📄/🐘）
- [ ] Phase 3 追问链 ≥ 3 轮，每轮指向具体逻辑断层
- [ ] Phase 4 三维挑战全部覆盖
- [ ] Phase 5 重构建议每个都有 KPI
- [ ] Phase 6 有真实案例（或标注"未找到"）
- [ ] 最终报告有量化评分