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