deliberation-debate-red-teaming

审议、辩论与红队演练

工作流

复制此清单并跟踪进度：

Deliberation & Red Teaming Progress:
- [ ] Step 1: Define the proposal and stakes
- [ ] Step 2: Assign adversarial roles
- [ ] Step 3: Generate critiques and challenges
- [ ] Step 4: Synthesize findings and prioritize risks
- [ ] Step 5: Recommend mitigations and revisions

步骤 1：明确提案和利害关系

询问用户要评估的计划／决策（具体提案，而非模糊想法）、利害关系（如果失败会发生什么）、当前信心水平（他们有多确定）以及截止时间（必须何时做出决策）。了解利害关系有助于调整批评力度。参见范围界定问题。

步骤 2：分配对抗性角色

确定可能揭示盲点的关键视角。根据提案类型选择 3-5 个角色（安全、法律、运营、客户、竞争对手等）。每个角色都有不同的利益和顾虑。角色分配指南请参见对抗性角色类型和resources/template.md。

步骤 3：生成批评意见和质疑

针对每个角色生成具体批评意见：可能会出什么问题？哪些假设值得质疑？哪些边缘情况会导致失败？保持对抗性，但也要符合实际（提出最有力的论据，而非稻草人论证）。如需使用高级批评技巧 → 参见resources/methodology.md，了解红队攻击模式。

步骤 4：综合发现并确定风险优先级

汇总所有批评意见，找出主题（安全漏洞、运营风险、客户影响等），评估每项风险的严重性和可能性。区分必须解决的重大障碍和可接受的风险（监控／缓解）。参见风险优先级排序。

步骤 5：建议缓解措施并修订提案

针对每项重大风险，提出具体的缓解措施（修改计划、增加保障措施、收集更多数据，或接受风险并进行监控）。提交纳入修正措施后的修订版提案。常见方法请参见缓解模式。

范围界定问题

明确提案：

• 我们究竟在评估什么？（请具体说明：“在 Z 日期向 Y 群体推出功能 X”）
• 目标是什么？（为什么要这么做？）
• 这个提案是谁提出的？（了解偏见会有所帮助）

了解利害关系：

• 如果成功会发生什么？（收益）
• 如果失败会发生什么？（损失，最坏情况）
• 这项决策可以撤销吗？（如果错了，我们能否回滚？）
• 延迟的代价是什么？（等待的机会成本）

校准批评力度：

• 团队有多大把握？（0-100%）
• 已经做过哪些分析？
• 内部提出过哪些顾虑？
• 我们必须何时做出决策？（时间压力会影响严谨程度）

对抗性角色类型

选择最可能揭示这一具体提案盲点的 3-5 个角色：

外部对抗者角色

竞争对手：

• “我们的竞争对手会如何利用这项决策？”
• “这会给他们带来什么市场机会？”
• 适用于：战略、产品发布、定价决策

恶意行为者（安全）：

• “攻击者会如何攻破它？”
• “整个链条中最薄弱的一环是什么？”
• 适用于：安全架构、数据处理、访问控制

监管机构／审计员：

• “这是否违反任何法律、法规或合规要求？”
• “审计跟踪缺少哪些文档？”
• 适用于：隐私、金融、医疗、法律事务

调查记者：

• “如果此事公开，哪些方面会显得不妥？”
• “我们在隐瞒什么，或没有披露什么？”
• 适用于：对公关敏感的决策、伦理、透明度

内部利益相关者角色

运营/SRE：

• “这会导致生产环境故障吗？我们能维护它吗？”
• “凌晨 2 点出现故障时，有什么操作手册？”
• 适用于：技术变更、部署、基础设施

客户/用户：

• “这真的能解决我的问题，还是会带来新的阻碍？”
• “这是在要求我改变行为吗？我为什么要这么做？”
• 适用于：产品功能、用户体验变更、定价

财务/预算：

• “有哪些隐性成本？3 年的总拥有成本是多少？”
• “投资回报率是否现实，还是基于过于乐观的假设？”
• 适用于：投资、供应商选择、资源分配

法律/合规：

• “这会带来哪些责任？”
• “合同/条款是否清晰？可能会产生哪些争议？”
• 适用于：合作关系、许可、数据使用

工程/技术：

• “这在技术上可行吗？技术债务是什么？”
• “我们低估了哪些复杂性？”
• 适用于：架构决策、技术选择、时间安排

唱反调者角色

悲观主义者：

• “最坏的情况是什么？”
• “墨菲定律：凡是可能出错的事，终将出错”
• 适用于：风险评估、应急规划

反向思考者：

• “如果事实恰恰相反呢？”
• “质疑每个假设：如果市场调研是错的呢？”
• 适用于：验证假设、检验共识

长期思考者：

• “未来 1-3 年会产生哪些二阶影响？”
• “我们是在解决今天的问题，却制造明天的危机吗？”
• 适用于：战略决策、架构选择

风险优先级排序

生成批评意见后，按严重程度和发生可能性进行排序：

严重程度等级

严重（5）： 灾难性故障（数据泄露、监管罚款、业务停摆） 高（4）： 重大损害（收入大幅损失、客户流失、声誉受损） 中（3）： 中等影响（延误、预算超支、客户投诉） 低（2）： 轻微不便（边缘情况错误、小幅低效） 微不足道（1）： 可忽略不计（外观问题、轻微的用户体验阻碍）

发生可能性等级

极有可能（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. 应急规划（为故障做好准备）

• 准备好备用方案
• 示例：供应商风险 → 提前确定备用供应商

5. 收集更多数据（降低不确定性）

• 在做出承诺前进行研究、原型设计或测试
• 示例：假设风险 → 运行 A/B 测试以验证假设

6. 接受并监控（知情承担风险）

• 承认风险，并设置警报/指标，以便在风险显现时及时发现
• 示例：低概率边缘情况 → 监控错误率，并准备好修复方案

7. 延后/取消（完全规避风险）

• 如果风险过高且无法缓解，就不要继续
• 示例：阻碍性法律风险 → 延后，直到完成法律审查

不应使用此技能的情况

以下情况跳过红队测试：

• 决策无关紧要/风险较低（不值得投入额外精力）
• 时间紧迫的紧急情况（没有时间审议，必须立即行动）
• 已经过全面审查（此前已进行广泛审查，红队测试会重复）
• 没有合理的替代方案（只有一条可行路径，红队测试无法改变结果）
• 纯粹的研究/探索（不做任何承诺，失败代价很低）

可改为：

• 无关紧要的决策 → 直接决策，继续推进
• 紧急情况 → 立即行动，之后再复盘
• 已经过审查 → 继续推进并进行监控
• 没有替代方案 → 专注于执行规划

快速参考

流程：

1. 定义提案和风险 → 确定范围
2. 分配对抗性角色 → 选择 3–5 个关键视角
3. 提出批评意见 → 从每个角色的角度看，可能出现哪些问题？
4. 确定风险优先级 → 严重程度 × 发生概率矩阵
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，包含批评意见、风险评估和缓解建议