## 角色辩论

不同专业角色进行辩论，考虑权衡取舍并导出最优解的命令。

### 使用方法

```bash
/role-debate <角色 1>,<角色 2> [议题]
/role-debate <角色 1>,<角色 2>,<角色 3> [议题]
```

### 基本示例

```bash
# 安全性 vs 性能的权衡
/role-debate security,performance
"关于 JWT 令牌的有效期设置"

# 可用性 vs 安全性的平衡
/role-debate frontend,security
"关于双因素认证的 UX 优化"

# 技术选型的辩论
/role-debate architect,mobile
"关于 React Native vs Flutter 的选择"

# 三方辩论
/role-debate architect,security,performance
"关于微服务化的必要性"
```

### 辩论的基本原则

#### 建设性辩论准则

- **相互尊重**: 尊重其他角色的专业性和视角
- **基于事实**: 基于数据·证据的辩论，而非情绪化反驳
- **解决导向**: 旨在寻找更好的解决方案，而非为批判而批判
- **重视实施**: 考虑可实现性的提案，而非理想论

#### 论据的质量要求

- **官方文档**: 引用标准·指南·官方文档
- **实证案例**: 具体引用成功案例·失败案例
- **定量评估**: 尽可能使用数值·指标进行比较
- **时间考虑**: 评估短期·中期·长期的影响

#### 辩论伦理

- **诚实性**: 承认自身专业领域的局限
- **开放性**: 对新信息·视角保持灵活性
- **透明性**: 明示判断依据·前提条件
- **责任性**: 包括提案的实施风险

### 辩论流程

### 阶段 1: 初始立场表明

各角色从专业视角独立表达意见

- 提出推荐方案
- 明示依据的标准·文档
- 说明预期的风险·挑战
- 定义成功指标

### 阶段 2: 相互辩论·反驳

角色间的交叉辩论

- 对其他角色提案的建设性反驳
- 指出被忽视的视角
- 明确权衡取舍
- 提出替代方案

### 阶段 3: 妥协点探索

寻求可实施的解决方案

- 评估各视角的重要性
- 考虑双赢解决方案
- 分阶段实施方法
- 考虑风险缓解策略

### 阶段 4: 综合结论

决定最终推荐事项

- 达成共识的解决方案
- 实施路线图
- 成功指标·测量方法
- 未来的审查点

### 输出格式示例

### 2 角色辩论的情况

```text
角色辩论: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

议题: JWT 令牌的有效期设置

Security 角色的主张:
"推荐 15 分钟的短期有效期"

依据:
- 符合 OWASP JWT Security Cheat Sheet
- 最小化令牌泄露时的损害时间窗口
- 限制攻击者的可用时间

担忧事项:
- 长期有效期使攻击风险呈指数级增长
- 合规要求 (金融系统) 必须使用短期

成功指标:
- 安全事件发生率 < 0.1%
- 平均攻击检测时间 < 5 分钟

Performance 角色的反驳:
"推荐 2 小时的有效期"

依据:
- 参考 Google OAuth 2.0 Best Practices
- 避免频繁重新认证导致的服务器负载增加
- 最小化用户体验 (工作中断)

担忧事项:
- 15 分钟间隔的重新认证使 API 负载增加 8 倍
- 移动环境下连接中断频发

成功指标:
- 保持 API 响应时间 < 200ms
- 服务器 CPU 使用率 < 60%

相互辩论:
Security → Performance:
"安全漏洞的业务损失远大于服务器负载。
例: Equifax 事件造成 7 亿美元损失"

Performance → Security:
"通过刷新令牌机制可以两全其美。
后台更新可确保安全而不损害 UX"

Security → Performance:
"刷新令牌也是攻击目标。需要正确实施"

Performance → Security:
"建议分阶段方法。普通操作 30 分钟，敏感操作 15 分钟"

妥协点探索:
共同理解:
- 需要兼顾用户体验和安全性
- 根据风险级别灵活应对
- 现实考虑实施·运维成本

双赢要素:
- 利用刷新令牌机制
- 逐步引入基于风险的认证
- 通过自动登出功能补充

综合结论:
"30 分钟有效期 + 刷新令牌 + 基于风险的认证"

实施详情:
1. 访问令牌: 30 分钟有效期
2. 刷新令牌: 7 天有效期
3. 高风险操作: 15 分钟强制重新认证
4. 无操作 30 分钟自动登出

分阶段实施:
第 1-2 周: 基本的 30 分钟令牌实施
第 3-4 周: 添加刷新令牌机制
第 2 月: 引入基于风险的认证

成功指标:
- 安全: 事件发生率 < 0.1%
- 性能: API 负载增加率 < 20%
- UX: 用户满意度 > 85%

未来审查:
- 3 个月后: 评估实际攻击模式·负载情况
- 6 个月后: 考虑迁移到更精细的基于风险的认证
```

### 3 角色辩论的情况

```text
角色辩论: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

议题: 微服务化的必要性

Architect 角色的主张:
"推荐分阶段微服务化"
依据: 明确领域边界、独立部署、技术选择自由度

Security 角色的担忧:
"服务间通信的安全性复杂化"
依据: API Gateway、mTLS、分布式认证的管理成本

Performance 角色的担忧:
"网络通信导致延迟增加"
依据: 内部 API 调用导致的 N+1 问题、分布式事务

3 方辩论:
Architect → Security: "通过 API Gateway 集中管理可以控制"
Security → Architect: "成为单点故障的风险"
Performance → Architect: "服务拆分的粒度很重要"
...(辩论继续)

综合结论:
"领域驱动设计的分阶段拆分 + 安全优先设计"
```

### 有效的辩论模式

### 技术选型

```bash
/role-debate architect,performance
"数据库选择: PostgreSQL vs MongoDB"

/role-debate frontend,mobile
"UI 框架: React vs Vue"

/role-debate security,architect
"认证方式: JWT vs Session Cookie"
```

### 设计决策

```bash
/role-debate security,frontend
"用户认证的 UX 设计"

/role-debate performance,mobile
"数据同步策略的优化"

/role-debate architect,qa
"测试策略与架构设计"
```

### 权衡问题

```bash
/role-debate security,performance
"加密级别 vs 处理速度"

/role-debate frontend,performance
"丰富 UI vs 页面加载速度"

/role-debate mobile,security
"便利性 vs 数据保护级别"
```

### 角色别辩论特性

#### 🔒 Security 角色

```yaml
辩论立场:
  - 保守方法 (风险最小化)
  - 重视规则遵守 (谨慎偏离标准)
  - 最坏情况假设 (攻击者视角)
  - 重视长期影响 (安全作为技术债务)

典型论点:
  - "安全 vs 便利性" 的权衡
  - "合规要求的必达"
  - "攻击成本 vs 防御成本的比较"
  - "隐私保护的彻底性"

论据来源:
  - OWASP 指南
  - NIST 框架
  - 行业标准 (ISO 27001, SOC 2)
  - 实际攻击案例·统计

辩论优势:
  - 风险评估的精度
  - 监管要求的知识
  - 对攻击手法的理解

需注意的偏见:
  - 过度保守 (阻碍创新)
  - 对 UX 的考虑不足
  - 忽视实施成本
```

#### ⚡ Performance 角色

```yaml
辩论立场:
  - 数据驱动决策 (基于测量)
  - 重视效率 (成本效益优化)
  - 用户体验优先 (重视体感速度)
  - 持续改进 (分阶段优化)

典型论点:
  - "性能 vs 安全"
  - "优化成本 vs 效果的投资回报"
  - "现在 vs 未来的可扩展性"
  - "用户体验 vs 系统效率"

论据来源:
  - Core Web Vitals 指标
  - 基准测试结果·统计
  - 对用户行为的影响数据
  - 行业性能标准

辩论优势:
  - 定量评估能力
  - 瓶颈识别
  - 优化手法的知识

需注意的偏见:
  - 忽视安全性
  - 对可维护性考虑不足
  - 过早优化
```

#### 🏗️ Architect 角色

```yaml
辩论立场:
  - 重视长期视角 (考虑系统演进)
  - 追求平衡 (全局优化)
  - 分阶段变更 (风险管理)
  - 标准遵守 (优先经过验证的模式)

典型论点:
  - "短期效率 vs 长期可维护性"
  - "技术债务 vs 开发速度"
  - "微服务 vs 单体"
  - "新技术采用 vs 稳定性"

论据来源:
  - 架构模式集
  - 设计原则 (SOLID, DDD)
  - 大规模系统案例
  - 技术演进趋势

辩论优势:
  - 全局俯瞰能力
  - 设计模式的知识
  - 长期影响的预测

需注意的偏见:
  - 过度泛化
  - 对新技术的保守性
  - 对实施细节的理解不足
```

#### 🎨 Frontend 角色

```yaml
辩论立场:
  - 用户中心设计 (UX 最优先)
  - 包容性方法 (考虑多样性)
  - 重视直观性 (最小化学习成本)
  - 可访问性标准 (WCAG 准拠)

典型论点:
  - "可用性 vs 安全性"
  - "设计统一 vs 平台优化"
  - "功能性 vs 简洁性"
  - "性能 vs 丰富体验"

论据来源:
  - UX 研究·可用性测试结果
  - 可访问性指南
  - 设计系统标准
  - 用户行为数据

辩论优势:
  - 代表用户视角
  - 设计原则的知识
  - 可访问性要求

需注意的偏见:
  - 对技术约束的理解不足
  - 忽视安全要求
  - 低估性能影响
```

#### 📱 Mobile 角色

```yaml
辩论立场:
  - 平台特化 (考虑 iOS/Android 差异)
  - 场景适应 (移动中·单手操作)
  - 资源约束 (电池·内存·通信)
  - 商店准拠 (审核指南)

典型论点:
  - "原生 vs 跨平台"
  - "离线支持 vs 实时同步"
  - "电池效率 vs 功能性"
  - "平台统一 vs 优化"

论据来源:
  - iOS HIG / Android Material Design
  - App Store / Google Play 指南
  - 移动 UX 研究
  - 设备性能统计

辩论优势:
  - 理解移动特有约束
  - 平台差异的知识
  - 触摸界面设计

需注意的偏见:
  - 对 Web 平台的理解不足
  - 忽视服务器端约束
  - 对桌面环境的考虑不足
```

#### 🔍 Analyzer 角色

```yaml
辩论立场:
  - 重视证据 (数据优先)
  - 假设验证 (科学方法)
  - 结构思维 (系统思维)
  - 偏差排除 (追求客观性)

典型论点:
  - "相关性 vs 因果关系"
  - "对症疗法 vs 根本解决"
  - "假设 vs 事实的区别"
  - "短期症状 vs 结构问题"

论据来源:
  - 实测数据·日志分析
  - 统计方法·分析结果
  - 系统思维理论
  - 认知偏差研究

辩论优势:
  - 逻辑分析能力
  - 证据评估的客观性
  - 结构问题的发现

需注意的偏见:
  - 分析瘫痪 (行动力不足)
  - 完美主义 (忽视实用性)
  - 数据万能主义
```

### 辩论进行模板

#### 阶段 1: 立场表明模板

```text
【角色名】的推荐方案:
"[具体提案]"

依据:
- [官方文档·标准的引用]
- [实证案例·数据]
- [专业领域的原则]

预期效果:
- [短期效果]
- [中长期效果]

担忧·风险:
- [实施风险]
- [运维风险]
- [对其他领域的影响]

成功指标:
- [可测量指标 1]
- [可测量指标 2]
```

#### 阶段 2: 反驳模板

```text
对 [目标角色] 的反驳:
"[对目标提案的具体反驳]"

反驳依据:
- [被忽视的视角]
- [对立的证据·案例]
- [专业领域的担忧]

替代方案:
"[改进的提案]"

可妥协点:
- [可接受的条件]
- [分阶段实施的可能性]
```

#### 阶段 3: 综合解决模板

```text
综合解决方案:
"[考虑各角色担忧的最终提案]"

对各角色的考虑:
- [Security]: [如何满足安全要求]
- [Performance]: [如何满足性能要求]
- [其他]: [如何满足其他要求]

实施路线图:
- 阶段 1 (立即): [紧急应对事项]
- 阶段 2 (短期): [基本实施]
- 阶段 3 (中期): [完整实施]

成功指标·测量方法:
- [综合成功指标]
- [测量方法·频率]
- [审查时机]
```

### 辩论质量检查清单

#### 论据质量

- [ ] 引用了官方文档·标准
- [ ] 提供了具体案例·数据
- [ ] 明确区分了推测和事实
- [ ] 明示了信息来源

#### 辩论的建设性

- [ ] 准确理解了对方的提案
- [ ] 逻辑而非情绪化的反驳
- [ ] 也提出了替代方案
- [ ] 探索了双赢的可能性

#### 可实施性

- [ ] 考虑了技术可实现性
- [ ] 估算了实施成本·期间
- [ ] 检讨了分阶段实施的可能性
- [ ] 提出了风险缓解策略

#### 综合性

- [ ] 考虑了对其他领域的影响
- [ ] 追求全局优化
- [ ] 包含长期视角
- [ ] 设置了可测量的成功指标

### 与 Claude 的协作

```bash
# 基于设计文档的辩论
cat system-design.md
/role-debate architect,security
"辩论这个设计在安全方面的挑战"

# 基于问题的解决方案辩论
cat performance-issues.md
/role-debate performance,architect
"辩论性能问题的根本解决方案"

# 基于需求的技术选型辩论
/role-debate mobile,frontend
"辩论 iOS·Android·Web 的统一 UI 策略"
```

### 注意事项

- 辩论可能需要时间 (复杂议题需要更长时间)
- 3 个以上角色可能导致辩论发散
- 最终决策请用户参考辩论结果做出
- 紧急性高的问题请先考虑 single role 或 multi-role