不同專業角色進行辩論,考虑權衡取舍並導出最優解的命令。
Facilitates multi-role debates to explore trade-offs and derive optimal solutions for technical decisions.
/plugin marketplace add wasabeef/claude-code-cookbook/plugin install cook-zh-tw@claude-code-cookbook不同專業角色進行辩論,考虑權衡取舍並導出最優解的命令。
/role-debate <角色 1>,<角色 2> [議題]
/role-debate <角色 1>,<角色 2>,<角色 3> [議題]
# 安全性 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
"關于微服務化的必要性"
各角色從專業視角独立表達意見
角色間的交叉辩論
寻求可實施的解決方案
決定最終推薦事項
角色辩論: 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 個月後: 考虑遷移到更精细的基于風險的認證
角色辩論: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
議題: 微服務化的必要性
Architect 角色的主张:
"推薦分阶段微服務化"
依據: 明確領域邊界、独立部署、技術選擇自由度
Security 角色的担忧:
"服務間通信的安全性復杂化"
依據: API Gateway、mTLS、分布式認證的管理成本
Performance 角色的担忧:
"網絡通信導致延遲增加"
依據: 內部 API 調用導致的 N+1 問題、分布式事務
3 方辩論:
Architect → Security: "通過 API Gateway 集中管理可以控制"
Security → Architect: "成為單點故障的風險"
Performance → Architect: "服務拆分的粒度很重要"
...(辩論繼續)
综合結論:
"領域驅動設計的分阶段拆分 + 安全優先設計"
/role-debate architect,performance
"數據庫選擇: PostgreSQL vs MongoDB"
/role-debate frontend,mobile
"UI 框架: React vs Vue"
/role-debate security,architect
"認證方式: JWT vs Session Cookie"
/role-debate security,frontend
"用戶認證的 UX 設計"
/role-debate performance,mobile
"數據同步策略的優化"
/role-debate architect,qa
"測試策略與架構設計"
/role-debate security,performance
"加密級別 vs 處理速度"
/role-debate frontend,performance
"丰富 UI vs 页面加載速度"
/role-debate mobile,security
"便利性 vs 數據保護級別"
辩論立場:
- 保守方法 (風險最小化)
- 重視規則遵守 (謹慎偏離標準)
- 最壞情況假設 (攻擊者視角)
- 重視長期影響 (安全作為技術債務)
典型論點:
- "安全 vs 便利性" 的權衡
- "合規要求的必達"
- "攻擊成本 vs 防御成本的比较"
- "隱私保護的彻底性"
論據來源:
- OWASP 指南
- NIST 框架
- 行業標準 (ISO 27001, SOC 2)
- 實際攻擊案例·統計
辩論優勢:
- 風險評估的精度
- 監管要求的知識
- 對攻擊手法的理解
需注意的偏見:
- 過度保守 (阻礙創新)
- 對 UX 的考虑不足
- 忽視實施成本
辩論立場:
- 數據驅動決策 (基于測量)
- 重視效率 (成本效益優化)
- 用戶體驗優先 (重視體感速度)
- 持續改進 (分阶段優化)
典型論點:
- "性能 vs 安全"
- "優化成本 vs 效果的投資回報"
- "現在 vs 未來的可擴展性"
- "用戶體驗 vs 系統效率"
論據來源:
- Core Web Vitals 指標
- 基準測試結果·統計
- 對用戶行為的影響數據
- 行業性能標準
辩論優勢:
- 定量評估能力
- 瓶頸識別
- 優化手法的知識
需注意的偏見:
- 忽視安全性
- 對可維護性考虑不足
- 過早優化
辩論立場:
- 重視長期視角 (考慮系統演進)
- 追求平衡 (全局優化)
- 分阶段變更 (風險管理)
- 標準遵守 (優先經過驗證的模式)
典型論點:
- "短期效率 vs 長期可維護性"
- "技術债務 vs 開發速度"
- "微服務 vs 單體"
- "新技術採用 vs 稳定性"
論據來源:
- 架構模式集
- 設計原則 (SOLID, DDD)
- 大規模系統案例
- 技術演進趨勢
辩論優勢:
- 全局俯瞰能力
- 設計模式的知識
- 長期影響的預測
需注意的偏見:
- 過度泛化
- 對新技術的保守性
- 對實施细节的理解不足
辩論立場:
- 用戶中心設計 (UX 最優先)
- 包容性方法 (考虑多樣性)
- 重視直觀性 (最小化學習成本)
- 可訪問性標準 (WCAG 準拠)
典型論點:
- "可用性 vs 安全性"
- "設計統一 vs 平台優化"
- "功能性 vs 簡洁性"
- "性能 vs 丰富體驗"
論據來源:
- UX 研究·可用性測試結果
- 可訪問性指南
- 設計系統標準
- 用戶行為數據
辩論優勢:
- 代表用戶視角
- 設計原則的知識
- 可訪問性要求
需注意的偏見:
- 對技術約束的理解不足
- 忽視安全要求
- 低估性能影響
辩論立場:
- 平台特化 (考虑 iOS/Android 差異)
- 場景適應 (移動中·單手操作)
- 資源約束 (電池·內存·通信)
- 商店準拠 (審核指南)
典型論點:
- "原生 vs 跨平台"
- "離線支持 vs 實時同步"
- "電池效率 vs 功能性"
- "平台統一 vs 優化"
論據來源:
- iOS HIG / Android Material Design
- App Store / Google Play 指南
- 移動 UX 研究
- 設備性能統計
辩論優勢:
- 理解移動特有約束
- 平台差異的知識
- 觸摸界面設計
需注意的偏見:
- 對 Web 平台的理解不足
- 忽視服務器端約束
- 對桌面環境的考虑不足
辩論立場:
- 重視證據 (數據優先)
- 假設驗證 (科學方法)
- 結構思維 (系統思維)
- 偏差排除 (追求客觀性)
典型論點:
- "相關性 vs 因果關系"
- "對症疗法 vs 根本解決"
- "假設 vs 事實的區別"
- "短期症狀 vs 結構問題"
論據來源:
- 實測數據·日誌分析
- 統計方法·分析結果
- 系統思維理論
- 認知偏差研究
辩論優勢:
- 邏輯分析能力
- 證據評估的客觀性
- 結構問題的發現
需注意的偏見:
- 分析瘫痪 (行動力不足)
- 完美主義 (忽視實用性)
- 數據万能主義
【角色名】的推薦方案:
"[具體提案]"
依據:
- [官方文檔·標準的引用]
- [實證案例·數據]
- [專業領域的原則]
預期效果:
- [短期效果]
- [中長期效果]
担忧·風險:
- [實施風險]
- [運維風險]
- [對其他領域的影響]
成功指標:
- [可測量指標 1]
- [可測量指標 2]
對 [目標角色] 的反驳:
"[對目標提案的具體反驳]"
反驳依據:
- [被忽視的視角]
- [對立的證據·案例]
- [專業領域的担忧]
替代方案:
"[改進的提案]"
可妥協點:
- [可接受的條件]
- [分阶段實施的可能性]
综合解決方案:
"[考虑各角色担忧的最終提案]"
對各角色的考虑:
- [Security]: [如何满足安全要求]
- [Performance]: [如何满足性能要求]
- [其他]: [如何满足其他要求]
實施路線圖:
- 阶段 1 (立即): [紧急應對事項]
- 阶段 2 (短期): [基本實施]
- 阶段 3 (中期): [完整實施]
成功指標·測量方法:
- [综合成功指標]
- [測量方法·頻率]
- [審查時機]
# 基于設計文檔的辩論
cat system-design.md
/role-debate architect,security
"辩論這個設計在安全方面的挑战"
# 基于問題的解決方案辩論
cat performance-issues.md
/role-debate performance,architect
"辩論性能問題的根本解決方案"
# 基于需求的技術選型辩論
/role-debate mobile,frontend
"辩論 iOS·Android·Web 的統一 UI 策略"
/role-debateComando onde diferentes papéis especializados debatem, consideram trade-offs e derivam soluções ótimas.
/role-debateA command that allows roles with different expertise to discuss and examine trade-offs to derive optimal solutions.