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
|