572 lines
12 KiB
Markdown
572 lines
12 KiB
Markdown
## 角色辩论
|
|
|
|
不同专业角色进行辩论，考虑权衡取舍并导出最优解的命令。
|
|
|
|
### 使用方法
|
|
|
|
```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
|