Initial commit

commands/role-debate.md

@@ -0,0 +1,571 @@
+## 角色辩論
+
+不同專業角色進行辩論，考虑權衡取舍並導出最優解的命令。
+
+### 使用方法
+
+```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