name: deliberation-debate-red-teaming description: 当测试计划或决策的盲点时使用，需要在启动前进行对抗性审查，验证策略对抗最坏情况，通过结构化辩论建立共识，识别攻击向量或漏洞，用户提到“扮演魔鬼代言人”、“可能出什么错”、“挑战我们的假设”、“压力测试这个”、“红队”，或当群体思维或确认偏差可能隐藏风险时。
审议、辩论与红队测试
这是什么？
审议-辩论-红队测试是一种结构化对抗性过程，有意从多个关键角度挑战计划、设计或决策，以在造成真实损害前揭示盲点、隐藏假设和漏洞。
快速示例：
提案： “下周向所有用户发布新功能”
红队批判：
- 安全： “未进行渗透测试，可能暴露用户数据”
- 操作： “无回滚手册，周五部署有周末中断风险”
- 客户： “功能破坏高级用户现有工作流程（占收入20%）”
- 法律： “GDPR同意流程不清晰，可能触发监管调查”
结果： 延迟发布2周，解决安全/法律/操作差距，添加功能标志进行渐进式推出
工作流程
复制此清单并跟踪进度：
审议与红队测试进度：
- [ ] 步骤1：定义提案和利害关系
- [ ] 步骤2：分配对抗性角色
- [ ] 步骤3：生成批判和挑战
- [ ] 步骤4：综合发现并优先排序风险
- [ ] 步骤5：推荐缓解措施和修订
步骤1：定义提案和利害关系
向用户询问要评估的计划/决策（具体提案，非模糊想法）、利害关系（如果失败会发生什么）、当前置信水平（他们有多确定）和截止日期（何时必须做出决策）。理解利害关系有助于校准批判强度。参见范围界定问题。
步骤2：分配对抗性角色
识别可能暴露盲点的关键视角。根据提案类型（安全、法律、操作、客户、竞争对手等）选择3-5个角色。每个角色有不同的动机和关注点。参见对抗性角色类型和resources/template.md获取角色分配指导。
步骤3：生成批判和挑战
对于每个角色，生成具体批判：可能出什么错？哪些假设有问题？哪些边缘情况会破坏这个？保持对抗性但现实（强人论证，非稻草人论证）。对于高级批判技术 → 参见resources/methodology.md获取红队攻击模式。
步骤4：综合发现并优先排序风险
收集所有批判，识别主题（安全差距、操作风险、客户影响等），评估每个风险的严重性和可能性。区分必须修复的阻碍者（showstoppers）和可接受风险（监控/缓解）。参见风险优先排序。
步骤5：推荐缓解措施和修订
对于每个关键风险，提出具体缓解措施（改变计划、添加保障措施、收集更多数据，或通过监控接受风险）。呈现包含修复的修订提案。参见缓解模式获取常见方法。
范围界定问题
定义提案：
- 我们具体评估什么？（具体化：“在日期Z向队列Y发布功能X”）
- 目标是什么？（为什么这样做？）
- 谁提出了这个提案？（理解偏差有助于）
理解利害关系：
- 如果成功会发生什么？（上行空间）
- 如果失败会发生什么？（下行空间，最坏情况）
- 这是可逆的吗？（如果出错能否回滚？）
- 延迟的成本是什么？（等待的机会成本）
校准批判：
- 团队有多自信？（0-100%）
- 已经做了哪些分析？
- 内部提出了哪些担忧？
- 我们需要何时决定？（时间压力影响严谨性）
对抗性角色类型
选择3-5个最可能为此特定提案暴露盲点的角色：
外部敌对角色
竞争对手：
- “我们的竞争对手会如何利用这个决策？”
- “这给了他们在市场上的什么机会？”
- 适用于：战略、产品发布、定价决策
恶意行为者（安全）：
- “攻击者会如何破坏这个？”
- “链中最弱的环节是什么？”
- 适用于：安全架构、数据处理、访问控制
监管者/审计师：
- “这违反任何法律、法规或合规要求吗？”
- “审计跟踪缺少什么文档？”
- 适用于：隐私、金融、医疗、法律事务
调查记者：
- “如果公开，什么看起来糟糕？”
- “我们隐藏或未披露什么？”
- 适用于：公关敏感决策、道德、透明度
内部利益相关者角色
操作/SRE：
- “这会破坏生产吗？我们能维护它吗？”
- “当这在凌晨2点失败时，手册是什么？”
- 适用于：技术变更、部署、基础设施
客户/用户：
- “这实际解决了我的问题还是创造了新摩擦？”
- “我被要求改变行为吗？为什么我应该？”
- 适用于：产品功能、UX变更、定价
财务/预算：
- “隐藏成本是什么？3年总拥有成本？”
- “投资回报率现实还是基于乐观假设？”
- 适用于：投资、供应商选择、资源分配
法律/合规：
- “这创造了什么责任？”
- “合同/条款清晰吗？可能产生什么争议？”
- 适用于：合作伙伴关系、许可、数据使用
工程/技术：
- “这在技术上可行吗？技术债务是什么？”
- “我们在复杂性上低估了什么？”
- 适用于：架构决策、技术选择、时间线
魔鬼代言人角色
悲观主义者：
- “最坏情况是什么？”
- “墨菲定律：可能出错的就会出错”
- 适用于：风险评估、应急计划
反对者：
- “如果相反是真的呢？”
- “挑战每个假设：如果市场研究错了呢？”
- 适用于：验证假设、测试共识
长期思考者：
- “1-3年内的二阶效应是什么？”
- “我们是在解决今天的问题并创造明天的危机吗？”
- 适用于：战略决策、架构选择
风险优先排序
生成批判后，按严重性和可能性优先排序：
严重性量表
关键（5）： 灾难性失败（数据泄露、监管罚款、业务关闭） 高（4）： 重大损害（显著收入损失、客户流失、声誉打击） 中等（3）： 中等影响（延迟、预算超支、客户投诉） 低（2）： 轻微不便（边缘情况错误、小效率问题） 琐碎（1）： 可忽略（外观问题、轻微UX摩擦）
可能性量表
很可能（5）： >80% 概率如果进行 可能（4）： 50-80% 概率 可能发生（3）： 20-50% 概率 不太可能（2）： 5-20% 概率 罕见（1）： <5% 概率
风险得分 = 严重性 × 可能性
阻碍者（得分 ≥ 15）： 必须解决后才能进行 高优先级（得分 10-14）： 应解决，或有强缓解计划 监控（得分 5-9）： 接受风险但有计划 接受（得分 < 5）： 承认并继续
风险矩阵
| 严重性 ↓ / 可能性 → | 罕见 (1) | 不太可能 (2) | 可能发生 (3) | 可能 (4) | 很可能 (5) |
|---|---|---|---|---|---|
| 关键 (5) | 5 (监控) | 10 (高优先级) | 15 (阻碍者) | 20 (阻碍者) | 25 (阻碍者) |
| 高 (4) | 4 (接受) | 8 (监控) | 12 (高优先级) | 16 (阻碍者) | 20 (阻碍者) |
| 中等 (3) | 3 (接受) | 6 (监控) | 9 (监控) | 12 (高优先级) | 15 (阻碍者) |
| 低 (2) | 2 (接受) | 4 (接受) | 6 (监控) | 8 (监控) | 10 (高优先级) |
| 琐碎 (1) | 1 (接受) | 2 (接受) | 3 (接受) | 4 (接受) | 5 (监控) |
缓解模式
对于每个识别出的风险，选择缓解方法：
1. 修订提案（改变计划）
- 修复设计/方法中的缺陷
- 示例：安全风险 → 在发布前添加认证层
2. 添加保障措施（降低可能性）
- 实施控制以防止风险
- 示例：操作风险 → 添加自动回滚、功能标志
3. 减少影响范围（降低严重性）
- 限制范围或失败发生时的冲击
- 示例：客户风险 → 首先向5%用户渐进式推出
4. 应急计划（准备失败）
- 准备备选方案B
- 示例：供应商风险 → 提前识别备用供应商
5. 收集更多数据（减少不确定性）
- 在承诺前研究、原型或测试
- 示例：假设风险 → 运行A/B测试验证假设
6. 接受并监控（知情风险）
- 承认风险，设置警报/指标检测是否显现
- 示例：低概率边缘情况 → 监控错误率，准备修复
7. 延迟/取消（完全避免风险）
- 如果风险太高且无法缓解，不进行
- 示例：阻碍者法律风险 → 延迟直到法律审查完成
何时不使用此技能
跳过红队测试如果：
- 决策琐碎/低利害关系（不值得开销）
- 时间关键紧急情况（无时间审议，必须立即行动）
- 已经彻底审查（广泛先前审查，红队会是冗余）
- 无合理替代方案（一条可行路径，红队不能改变结果）
- 纯研究/探索（未承诺任何事，失败成本低）
改为使用：
- 琐碎决策 → 直接决定，继续
- 紧急情况 → 立即行动，事后回顾
- 已审查 → 进行并监控
- 无替代方案 → 专注于执行计划
快速参考
流程：
- 定义提案和利害关系 → 设置范围
- 分配对抗性角色 → 选择3-5个关键视角
- 生成批判 → 从每个角色可能出什么错？
- 优先排序风险 → 严重性 × 可能性矩阵
- 推荐缓解措施 → 修订、保障、应急、接受或取消
常见对抗性角色：
- 竞争对手、恶意行为者、监管者、操作、客户、财务、法律、工程师、悲观主义者、反对者、长期思考者
风险优先排序：
- 阻碍者（≥15）：必须修复
- 高优先级（10-14）：应解决
- 监控（5-9）：接受有计划
- 接受（<5）：承认
资源：
- resources/template.md - 结构化红队流程与角色模板
- resources/methodology.md - 高级技术（攻击树、预死亡分析、战争游戏）
- resources/evaluators/rubric_deliberation_debate_red_teaming.json - 质量清单
交付物： deliberation-debate-red-teaming.md 包含批判、风险评估和缓解建议