## 角色辩論

不同專業角色進行辩論，考虑權衡取舍並導出最優解的命令。

### 使用方法

```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