wasabeef 多角色辯論探討權衡方案
不同專業角色進行辩論，考虑權衡取舍並導出最優解的命令。
使用方法
/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
"關于微服務化的必要性"
辩論的基本原則
建設性辩論準則
- 相互尊重: 尊重其他角色的專業性和視角
- 基于事實: 基于數據·證據的辩論，而非情绪化反驳
- 解決導向: 旨在寻找更好的解決方案，而非為批判而批判
- 重視實施: 考虑可實現性的提案，而非理想論
論據的質量要求
- 官方文檔: 引用標準·指南·官方文檔
- 實證案例: 具體引用成功案例·失败案例
- 定量評估: 尽可能使用數值·指標進行比较
- 時間考慮: 評估短期·中期·長期的影響
辩論倫理
- 诚實性: 承認自身專業領域的局限
- 開放性: 對新資訊·視角保持灵活性
- 透明性: 明示判斷依據·前提條件
- 責任性: 包括提案的實施風險
辩論流程
阶段 1: 初始立場表明
各角色從專業視角独立表達意見
- 提出推薦方案
- 明示依據的標準·文檔
- 說明預期的風險·挑战
- 定義成功指標
阶段 2: 相互辩論·反驳
角色間的交叉辩論
- 對其他角色提案的建設性反驳
- 指出被忽視的視角
- 明確權衡取舍
- 提出替代方案
阶段 3: 妥協點探索
寻求可實施的解決方案
- 評估各視角的重要性
- 考虑雙赢解決方案
- 分阶段實施方法
- 考虑風險緩解策略
阶段 4: 综合結論
決定最終推薦事項
- 達成共識的解決方案
- 實施路線圖
- 成功指標·測量方法
- 未來的審查點
輸出格式示例
2 角色辩論的情况
角色辩論: 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 角色辩論的情况
角色辩論: 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 數據保護級別"
角色別辩論特性
🔒 Security 角色
辩論立場:
- 保守方法 (風險最小化)
- 重視規則遵守 (謹慎偏離標準)
- 最壞情況假設 (攻擊者視角)
- 重視長期影響 (安全作為技術債務)
典型論點:
- "安全 vs 便利性" 的權衡
- "合規要求的必達"
- "攻擊成本 vs 防御成本的比较"
- "隱私保護的彻底性"
論據來源:
- OWASP 指南
- NIST 框架
- 行業標準 (ISO 27001, SOC 2)
- 實際攻擊案例·統計
辩論優勢:
- 風險評估的精度
- 監管要求的知識
- 對攻擊手法的理解
需注意的偏見:
- 過度保守 (阻礙創新)
- 對 UX 的考虑不足
- 忽視實施成本
⚡ Performance 角色
辩論立場:
- 數據驅動決策 (基于測量)
- 重視效率 (成本效益優化)
- 用戶體驗優先 (重視體感速度)
- 持續改進 (分阶段優化)
典型論點:
- "性能 vs 安全"
- "優化成本 vs 效果的投資回報"
- "現在 vs 未來的可擴展性"
- "用戶體驗 vs 系統效率"
論據來源:
- Core Web Vitals 指標
- 基準測試結果·統計
- 對用戶行為的影響數據
- 行業性能標準
辩論優勢:
- 定量評估能力
- 瓶頸識別
- 優化手法的知識
需注意的偏見:
- 忽視安全性
- 對可維護性考虑不足
- 過早優化
🏗️ Architect 角色
辩論立場:
- 重視長期視角 (考慮系統演進)
- 追求平衡 (全局優化)
- 分阶段變更 (風險管理)
- 標準遵守 (優先經過驗證的模式)
典型論點:
- "短期效率 vs 長期可維護性"
- "技術债務 vs 開發速度"
- "微服務 vs 單體"
- "新技術採用 vs 稳定性"
論據來源:
- 架構模式集
- 設計原則 (SOLID, DDD)
- 大規模系統案例
- 技術演進趨勢
辩論優勢:
- 全局俯瞰能力
- 設計模式的知識
- 長期影響的預測
需注意的偏見:
- 過度泛化
- 對新技術的保守性
- 對實施细节的理解不足
🎨 Frontend 角色
辩論立場:
- 用戶中心設計 (UX 最優先)
- 包容性方法 (考虑多樣性)
- 重視直觀性 (最小化學習成本)
- 可訪問性標準 (WCAG 準拠)
典型論點:
- "可用性 vs 安全性"
- "設計統一 vs 平台優化"
- "功能性 vs 簡洁性"
- "性能 vs 丰富體驗"
論據來源:
- UX 研究·可用性測試結果
- 可訪問性指南
- 設計系統標準
- 用戶行為數據
辩論優勢:
- 代表用戶視角
- 設計原則的知識
- 可訪問性要求
需注意的偏見:
- 對技術約束的理解不足
- 忽視安全要求
- 低估性能影響
📱 Mobile 角色
辩論立場:
- 平台特化 (考虑 iOS/Android 差異)
- 場景適應 (移動中·單手操作)
- 資源約束 (電池·內存·通信)
- 商店準拠 (審核指南)
典型論點:
- "原生 vs 跨平台"
- "離線支持 vs 實時同步"
- "電池效率 vs 功能性"
- "平台統一 vs 優化"
論據來源:
- iOS HIG / Android Material Design
- App Store / Google Play 指南
- 移動 UX 研究
- 設備性能統計
辩論優勢:
- 理解移動特有約束
- 平台差異的知識
- 觸摸界面設計
需注意的偏見:
- 對 Web 平台的理解不足
- 忽視服務器端約束
- 對桌面環境的考虑不足
🔍 Analyzer 角色
辩論立場:
- 重視證據 (數據優先)
- 假設驗證 (科學方法)
- 結構思維 (系統思維)
- 偏差排除 (追求客觀性)
典型論點:
- "相關性 vs 因果關系"
- "對症疗法 vs 根本解決"
- "假設 vs 事實的區別"
- "短期症狀 vs 結構問題"
論據來源:
- 實測數據·日誌分析
- 統計方法·分析結果
- 系統思維理論
- 認知偏差研究
辩論優勢:
- 邏輯分析能力
- 證據評估的客觀性
- 結構問題的發現
需注意的偏見:
- 分析瘫痪 (行動力不足)
- 完美主義 (忽視實用性)
- 數據万能主義
辩論進行模板
阶段 1: 立場表明模板
【角色名】的推薦方案:
"[具體提案]"
依據:
- [官方文檔·標準的引用]
- [實證案例·數據]
- [專業領域的原則]
預期效果:
- [短期效果]
- [中長期效果]
担忧·風險:
- [實施風險]
- [運維風險]
- [對其他領域的影響]
成功指標:
- [可測量指標 1]
- [可測量指標 2]
阶段 2: 反驳模板
對 [目標角色] 的反驳:
"[對目標提案的具體反驳]"
反驳依據:
- [被忽視的視角]
- [對立的證據·案例]
- [專業領域的担忧]
替代方案:
"[改進的提案]"
可妥協點:
- [可接受的條件]
- [分阶段實施的可能性]
阶段 3: 综合解決模板
综合解決方案:
"[考虑各角色担忧的最終提案]"
對各角色的考虑:
- [Security]: [如何满足安全要求]
- [Performance]: [如何满足性能要求]
- [其他]: [如何满足其他要求]
實施路線圖:
- 阶段 1 (立即): [紧急應對事項]
- 阶段 2 (短期): [基本實施]
- 阶段 3 (中期): [完整實施]
成功指標·測量方法:
- [综合成功指標]
- [測量方法·頻率]
- [審查時機]
辩論質量檢查清單
論據質量
- 引用了官方文檔·標準
- 提供了具體案例·數據
- 明確區分了推測和事實
- 明示了資訊來源
辩論的建設性
- 準確理解了對方的提案
- 邏輯而非情绪化的反驳
- 也提出了替代方案
- 探索了雙赢的可能性
可實施性
- 考虑了技術可實現性
- 估算了實施成本·期間
- 檢讨了分阶段實施的可能性
- 提出了風險緩解策略
综合性
- 考虑了對其他領域的影響
- 追求全局優化
- 包含長期視角
- 設置了可測量的成功指標
與 Claude 的協作
# 基于設計文檔的辩論
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