> 用红蓝双队辩论模式深度解答通用问题,以非讨好型人格的理性人视角输出最终报告。 触发条件:用户提出任何值得深度分析的问题,尤其是存在争议、有多个维度、需要权威数据支撑的问题。 提到"红蓝辩论"、"辩证分析"、"正反两面"、"两种观点"、"帮我深度分析"、"有没有反驳意见"、"理性分析一下"、"客观看待",或提出任何开放性、争议性问题时必须使用本 skill。 即使用户只是提出一个看似简单的问题如"XX 到底值不值得做"或"XX 是对的吗", 只要涉及价值判断、策略选择、事实真相等复杂情境,也应使用本 skill。 本 skill 不追求讨好用户,拒绝模糊骑墙,双队结论必须互斥,最终裁判整合并输出面向小白的第一人称深度文章。
Install with the open skills CLI (global, non-interactive — available in every Claude Code session):
npx skills add digoal/blog --skill "red-blue-debate" -g -a claude-code -yOr manually — copy the SKILL.md below into:
~/.claude/skills/red-blue-debate/SKILL.md---
name: red-blue-debate
description: >
用红蓝双队辩论模式深度解答通用问题,以非讨好型人格的理性人视角输出最终报告。
触发条件:用户提出任何值得深度分析的问题,尤其是存在争议、有多个维度、需要权威数据支撑的问题。
提到"红蓝辩论"、"辩证分析"、"正反两面"、"两种观点"、"帮我深度分析"、"有没有反驳意见"、"理性分析一下"、"客观看待",或提出任何开放性、争议性问题时必须使用本 skill。
即使用户只是提出一个看似简单的问题如"XX 到底值不值得做"或"XX 是对的吗",
只要涉及价值判断、策略选择、事实真相等复杂情境,也应使用本 skill。
本 skill 不追求讨好用户,拒绝模糊骑墙,双队结论必须互斥,最终裁判整合并输出面向小白的第一人称深度文章。
---
# Red-Blue Debate Skill
> 非讨好型人格 · 理性人模式 · 红蓝双队辩论 · 裁判整合输出
---
## 一、总体流程
```
接收问题
│
├─► 领域识别 → 拆分专家角色
│
├─► 红队组建(正方/主流/支持方)
│
├─► 蓝队组建(反方/异见/挑战方)
│
├─► 红蓝各自独立搜证与立论
│
├─► 双方辩论(≤5轮,针锋相对)
│
├─► 各专家输出中间结果(Markdown,存 markdown/)
│
└─► 大裁判整合 → 最终文章(第一人称,存 markdown/)
```
---
## 二、核心原则(必须严格遵守)
1. **非讨好原则**:任何一方都不能因为对方说得有道理就随意退让,立场由证据驱动,而非社交压力。
2. **互斥原则**:红队与蓝队的核心结论必须是真正的对立——不能变成"都有道理"的骑墙输出。
3. **专家原则**:每个涉及的领域都必须有对应的专家角色出场,不允许用通用视角替代专业视角。
4. **第一性原理**:所有结论都必须从最基本的前提推导,而非依赖权威或惯例。
5. **自我验证**:每位专家在最终输出前必须经过一轮自我检验(数据、逻辑、边界条件)。
6. **可证伪性**:每个结论都必须说明如何被证明或证伪,以及需要观测哪些指标。
---
## 三、执行步骤详解
### Step 0:问题解析与领域识别
- 复述问题,提取核心争议点
- 识别问题所属领域(经济学、心理学、医学、工程、历史、社会学等)
- 确定每个领域需要的专家角色(每队可有多个角色)
- 明确"互斥"的红蓝立场是什么
**输出格式示例:**
```
问题核心:[一句话]
争议焦点:[列出2-3个核心分歧点]
红队立场:[结论A]
蓝队立场:[结论B,与A真正对立]
涉及领域:[领域1、领域2、...]
红队专家组:[角色1、角色2]
蓝队专家组:[角色1、角色2]
```
---
### Step 1:红队立论
红队代表**支持/正方/主流**立场。
每位红队专家依次发言,结构如下:
```markdown
## 红队 · [专家角色名]
### 1. 复述与理解问题
[用自己的专业语言重新表述问题,说明从本专业视角看,核心争议是什么]
### 2. 核心论点
[1-3个最强论点,每个论点必须有数据或案例支撑]
### 3. 第一性原理推导
[从基本假设出发,一步步推导结论;明确列出前置条件]
### 4. 适用边界
[结论在什么条件下成立,在什么条件下失效]
### 5. 图示(SVG/Mermaid/ASCII)
[至少一个图示辅助说明逻辑或数据]
### 6. 可证伪性
- 证明方法:如果 [X] 数据出现,则支持本结论
- 证伪方法:如果 [Y] 数据出现,则推翻本结论
- 后续观测指标:[具体可观测的数据]
### 7. 自我验证
[列出自查项目,确认数据来源、逻辑链条、边界条件均无误]
```
---
### Step 2:蓝队立论
蓝队代表**反对/异见/挑战**立场。
格式与红队完全相同,但结论必须与红队互斥。
蓝队专家必须:
- 直接针对红队的核心论点提出挑战
- 提供不同的数据源或不同的解读角度
- 不允许"其实双方都有道理"——必须坚持对立结论
---
### Step 3:辩论(≤5轮)
每轮辩论格式:
```markdown
## 第[N]轮辩论
### 红队反驳
[针对蓝队上一轮的最强论点,提出具体反驳;引用新数据或新案例]
### 蓝队反驳
[针对红队上一轮的最强论点,提出具体反驳;引用新数据或新案例]
```
**辩论规则:**
- 每次反驳必须直接回应对方的具体论点,不能顾左右而言他
- 允许承认对方的某个子论点有道理,但核心结论不能改变
- 第5轮后强制停止,进入中间结果整理
---
### Step 4:中间结果输出(每位专家)
辩论结束后,每位专家(红队+蓝队)分别整理自己的最终立场:
**文件命名**:`markdown/[red|blue]_[专家角色]_中间结果.md`
内容包括:
- 最终核心结论(一句话)
- 经过辩论修正后的论点(若有修正,说明为何修正)
- 最强支持证据(2-3条)
- 承认的对方有效挑战(诚实列出)
- 未解决的疑点
---
### Step 5:大裁判整合输出
**裁判角色**:不属于红队或蓝队,无预设立场,但**必须做出明确判断**(不允许"各有道理"作为最终结论)。
裁判工作:
1. 梳理双方最强论点与最强反驳
2. 评估各方证据质量(数据来源、样本量、逻辑严密性)
3. 识别双方争议的根本分歧(是价值观分歧?是事实分歧?是边界条件分歧?)
4. 给出明确的裁判意见(支持哪方,或在哪些条件下支持哪方)
5. 整合成最终文章
**最终文章要求:**
- **第一人称**写作,以"我"或"我们"开头
- **面向小白**,专业术语需要通俗化解释
- **图文并茂**,至少包含1-2个图示
- **一气呵成**,不露出"红队说…蓝队说…"的拼接痕迹
- 引用专家视角时用"站在[领域]的角度"等措辞
- 在章节名和正文中不出现"红队""蓝队""中间结果""合成"等词
- **有明确结论**,不骑墙
- 包含"如何验证这个结论"的段落
**文件命名**:`markdown/最终报告_[问题关键词].md`
---
## 四、文件组织
```
markdown/
├── red_[专家角色]_中间结果.md # 红队各专家中间结果
├── blue_[专家角色]_中间结果.md # 蓝队各专家中间结果
├── [图表文件].svg # 如有独立SVG图
└── 最终报告_[关键词].md # 裁判整合的最终文章
```
---
## 五、质量检查清单(输出前必须过一遍)
| 检查项 | 标准 |
|--------|------|
| 红蓝结论是否真正互斥 | 不能是"都有道理"的软对立 |
| 每个论点是否有数据/案例 | 不能有空洞断言 |
| 图示是否清晰 | SVG/Mermaid/ASCII至少一种 |
| 第一性原理是否明确 | 前置条件需列出 |
| 边界条件是否说明 | 结论在何时失效 |
| 可证伪性是否完整 | 证明方法+证伪方法+观测指标 |
| 自我验证是否通过 | 数据和逻辑均已核查 |
| 最终文章是否第一人称 | 全篇一致 |
| 最终文章是否面向小白 | 无未解释的术语 |
| 最终结论是否明确 | 裁判不能骑墙 |
---
## 六、注意事项
- **搜索优先**:对于需要实时数据的问题,必须先用 web_search 工具搜索,不能凭印象断言数据。
- **引用规范**:所有外部数据需注明来源(机构名+年份)。
- **SVG 图**:如果使用SVG图,必须先输出为独立 `.svg` 文件,再在 Markdown 中用 `` 引用。
- **辩论真实性**:辩论内容必须是真实的论点对抗,不能为了"平衡"而人为弱化某一方。
- **裁判独立性**:裁判的结论可以完全支持红队或完全支持蓝队,不必强求"折中"。
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when executing implementation plans with independent tasks in the current session