deliberation-debate-red-teaming
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDeliberation, Debate & Red Teaming
审议、辩论与红队评估
What Is It?
什么是红队评估？
Deliberation-debate-red-teaming is a structured adversarial process where you intentionally challenge plans, designs, or decisions from multiple critical perspectives to surface blind spots, hidden assumptions, and vulnerabilities before they cause real damage.
Quick example:
Proposal: "Launch new feature to all users next week"
Red team critiques:
- Security: "No penetration testing done, could expose user data"
- Operations: "No runbook for rollback, deployment on Friday risks weekend outage"
- Customer: "Feature breaks existing workflow for power users (20% of revenue)"
- Legal: "GDPR consent flow unclear, could trigger regulatory investigation"
Result: Delay launch 2 weeks, address security/legal/ops gaps, add feature flag for gradual rollout
审议-辩论-红队评估是一种结构化的对抗流程，通过从多个批判性视角刻意挑战计划、设计或决策，在问题造成实际损害前找出盲点、隐藏假设和漏洞。
快速示例：
提案： "下周向所有用户推出新功能"
红队批评意见：
- 安全层面： "未开展渗透测试，可能导致用户数据泄露"
- 运维层面： "无回滚操作手册，周五部署可能导致周末服务中断"
- 客户层面： "该功能会破坏付费用户（贡献20%营收）的现有工作流程"
- 法务层面： "GDPR授权流程不清晰，可能引发监管调查"
结果： 推迟上线2周，解决安全、法务、运维方面的问题，添加功能标志以逐步推出
Workflow
工作流程
Copy this checklist and track your progress:
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 revisionsStep 1: Define the proposal and stakes
Ask user for the plan/decision to evaluate (specific proposal, not vague idea), stakes (what happens if this fails), current confidence level (how certain are they), and deadline (when must decision be made). Understanding stakes helps calibrate critique intensity. See Scoping Questions.
Step 2: Assign adversarial roles
Identify critical perspectives that could expose blind spots. Choose 3-5 roles based on proposal type (security, legal, operations, customer, competitor, etc.). Each role has different incentives and concerns. See Adversarial Role Types and resources/template.md for role assignment guidance.
Step 3: Generate critiques and challenges
For each role, generate specific critiques: What could go wrong? What assumptions are questionable? What edge cases break this? Be adversarial but realistic (steelman, not strawman arguments). For advanced critique techniques → See resources/methodology.md for red team attack patterns.
Step 4: Synthesize findings and prioritize risks
Collect all critiques, identify themes (security gaps, operational risks, customer impact, etc.), assess severity and likelihood for each risk. Distinguish between showstoppers (must fix) and acceptable risks (monitor/mitigate). See Risk Prioritization.
Step 5: Recommend mitigations and revisions
For each critical risk, propose concrete mitigation (change the plan, add safeguards, gather more data, or accept risk with monitoring). Present revised proposal incorporating fixes. See Mitigation Patterns for common approaches.
复制以下检查清单并跟踪进度：
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：提出缓解措施与修订建议
针对每个关键风险，提出具体的缓解方案（修改计划、添加保障措施、收集更多数据，或在监控下接受风险）。提交整合修复方案后的修订版提案。常见方法详见缓解模式。
Scoping Questions
范围界定问题
To define the proposal:
- What exactly are we evaluating? (Be specific: "launch feature X to cohort Y on date Z")
- What's the goal? (Why do this?)
- Who made this proposal? (Understanding bias helps)
To understand stakes:
- What happens if this succeeds? (Upside)
- What happens if this fails? (Downside, worst case)
- Is this reversible? (Can we roll back if wrong?)
- What's the cost of delay? (Opportunity cost of waiting)
To calibrate critique:
- How confident is the team? (0-100%)
- What analysis has been done already?
- What concerns have been raised internally?
- When do we need to decide? (Time pressure affects rigor)
明确提案：
- 我们具体要评估什么？（需明确："向群体Y在日期Z推出功能X"）
- 目标是什么？（为什么要做这件事？）
- 谁提出的这个提案？（了解潜在偏差）
了解影响范围：
- 如果成功会怎样？（收益）
- 如果失败会怎样？（损失，最坏情况）
- 该决策可逆吗？（如果出错可以回滚吗？）
- 推迟的成本是什么？（等待的机会成本）
调整批评力度：
- 团队的信心有多高？（0-100%）
- 已经完成了哪些分析？
- 内部已经提出了哪些顾虑？
- 我们需要何时做出决策？（时间压力会影响严谨性）
Adversarial Role Types
对抗性角色类型
Choose 3-5 roles that are most likely to expose blind spots for this specific proposal:
选择3-5个最有可能暴露当前提案盲点的角色：
External Adversary Roles
外部对手角色
Competitor:
- "How would our competitor exploit this decision?"
- "What gives them an opening in the market?"
- Useful for: Strategy, product launches, pricing decisions
Malicious Actor (Security):
- "How would an attacker compromise this?"
- "What's the weakest link in the chain?"
- Useful for: Security architecture, data handling, access controls
Regulator/Auditor:
- "Does this violate any laws, regulations, or compliance requirements?"
- "What documentation is missing for audit trail?"
- Useful for: Privacy, financial, healthcare, legal matters
Investigative Journalist:
- "What looks bad if this becomes public?"
- "What are we hiding or not disclosing?"
- Useful for: PR-sensitive decisions, ethics, transparency
竞争对手：
- "我们的竞争对手会如何利用这个决策？"
- "这会给他们带来哪些市场机会？"
- 适用场景：战略规划、产品发布、定价决策
恶意攻击者（安全）：
- "攻击者会如何破坏这个计划？"
- "链条中最薄弱的环节是什么？"
- 适用场景：安全架构、数据处理、访问控制
监管机构/审计师：
- "这是否违反任何法律、法规或合规要求？"
- 审计追踪缺少哪些文档？"
- 适用场景：隐私、金融、医疗、法务事务
调查记者：
- "如果此事公开，哪些内容会造成负面影响？"
- "我们隐瞒或未披露的信息有哪些？"
- 适用场景：公关敏感决策、伦理、透明度
Internal Stakeholder Roles
内部利益相关者角色
Operations/SRE:
- "Will this break production? Can we maintain it?"
- "What's the runbook for when this fails at 2am?"
- Useful for: Technical changes, deployments, infrastructure
Customer/User:
- "Does this actually solve my problem or create new friction?"
- "Am I being asked to change behavior? Why should I?"
- Useful for: Product features, UX changes, pricing
Finance/Budget:
- "What are the hidden costs? TCO over 3 years?"
- "Is ROI realistic or based on optimistic assumptions?"
- Useful for: Investments, vendor selection, resource allocation
Legal/Compliance:
- "What liability does this create?"
- "Are contracts/terms clear? What disputes could arise?"
- Useful for: Partnerships, licensing, data usage
Engineering/Technical:
- "Is this technically feasible? What's the technical debt?"
- "What are we underestimating in complexity?"
- Useful for: Architecture decisions, technology choices, timelines
运维/SRE：
- "这会导致生产环境故障吗？我们能维持其运行吗？"
- "如果凌晨2点出现故障，操作手册在哪里？"
- 适用场景：技术变更、部署、基础设施
客户/用户：
- "这真的能解决我的问题，还是会带来新的麻烦？"
- "为什么要我改变行为？"
- 适用场景：产品功能、UX变更、定价
财务/预算：
- "隐藏成本有哪些？3年总拥有成本（TCO）是多少？"
- "投资回报率（ROI）是真实的，还是基于乐观假设？"
- 适用场景：投资、供应商选择、资源分配
法务/合规：
- "这会带来哪些法律责任？"
- "合同/条款是否清晰？可能引发哪些纠纷？"
- 适用场景：合作伙伴关系、授权、数据使用
工程/技术：
- "这在技术上可行吗？会产生哪些技术债务？"
- "我们低估了哪些复杂度？"
- 适用场景：架构决策、技术选型、时间规划
Devil's Advocate Roles
唱反调角色
Pessimist:
- "What's the worst-case scenario?"
- "Murphy's Law: What can go wrong will go wrong"
- Useful for: Risk assessment, contingency planning
Contrarian:
- "What if the opposite is true?"
- "Challenge every assumption: What if market research is wrong?"
- Useful for: Validating assumptions, testing consensus
Long-term Thinker:
- "What are second-order effects in 1-3 years?"
- "Are we solving today's problem and creating tomorrow's crisis?"
- Useful for: Strategic decisions, architectural choices
悲观主义者：
- "最坏的情况是什么？"
- "墨菲定律：可能出错的地方一定会出错"
- 适用场景：风险评估、应急预案规划
持异议者：
- "如果相反的情况成立会怎样？"
- "挑战所有假设：如果市场调研有误呢？"
- 适用场景：验证假设、测试共识
长期思考者：
- "1-3年内会产生哪些二阶效应？"
- "我们在解决今天问题的同时，是否会制造明天的危机？"
- 适用场景：战略决策、架构选择
Risk Prioritization
风险优先级划分
After generating critiques, prioritize by severity and likelihood:
提出批评意见后，按严重程度和发生概率划分优先级：
Severity Scale
严重程度等级
Critical (5): Catastrophic failure (data breach, regulatory fine, business shutdown)
High (4): Major damage (significant revenue loss, customer exodus, reputation hit)
Medium (3): Moderate impact (delays, budget overrun, customer complaints)
Low (2): Minor inconvenience (edge case bugs, small inefficiency)
Trivial (1): Negligible (cosmetic issues, minor UX friction)
关键（5）： 灾难性故障（数据泄露、监管罚款、业务关停）
高（4）： 重大损害（巨额营收损失、客户流失、声誉受损）
中（3）： 中等影响（延迟、预算超支、客户投诉）
低（2）： 轻微不便（边缘案例bug、小范围低效）
** Trivial（1）：** 可忽略（外观问题、轻微UX摩擦）
Likelihood Scale
发生概率等级
Very Likely (5): >80% chance if we proceed
Likely (4): 50-80% chance
Possible (3): 20-50% chance
Unlikely (2): 5-20% chance
Rare (1): <5% chance
极有可能（5）： 继续推进的话，概率>80%
有可能（4）： 概率50-80%
可能（3）： 概率20-50%
不太可能（2）： 概率5-20%
罕见（1）： 概率<5%
Risk Score = Severity × Likelihood
风险评分 = 严重程度 × 发生概率
Showstoppers (score ≥ 15): Must address before proceeding
High Priority (score 10-14): Should address, or have strong mitigation plan
Monitor (score 5-9): Accept risk but have contingency
Accept (score < 5): Acknowledge and move on
致命问题（评分≥15）： 推进前必须解决
高优先级（评分10-14）： 应解决，或制定强有力的缓解计划
监控（评分5-9）： 接受风险但需制定应急预案
接受（评分<5）： 确认后继续推进
Risk Matrix
风险矩阵
| Severity ↓ / Likelihood → | Rare (1) | Unlikely (2) | Possible (3) | Likely (4) | Very Likely (5) |
|---|---|---|---|---|---|
| Critical (5) | 5 (Monitor) | 10 (High Priority) | 15 (SHOWSTOPPER) | 20 (SHOWSTOPPER) | 25 (SHOWSTOPPER) |
| High (4) | 4 (Accept) | 8 (Monitor) | 12 (High Priority) | 16 (SHOWSTOPPER) | 20 (SHOWSTOPPER) |
| Medium (3) | 3 (Accept) | 6 (Monitor) | 9 (Monitor) | 12 (High Priority) | 15 (SHOWSTOPPER) |
| Low (2) | 2 (Accept) | 4 (Accept) | 6 (Monitor) | 8 (Monitor) | 10 (High Priority) |
| Trivial (1) | 1 (Accept) | 2 (Accept) | 3 (Accept) | 4 (Accept) | 5 (Monitor) |
| 严重程度 ↓ / 发生概率 → | 罕见（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（高优先级） |
| ** Trivial（1）** | 1（接受） | 2（接受） | 3（接受） | 4（接受） | 5（监控） |
Mitigation Patterns
缓解模式
For each identified risk, choose mitigation approach:
1. Revise the Proposal (Change Plan)
- Fix the flaw in design/approach
- Example: Security risk → Add authentication layer before launch
2. Add Safeguards (Reduce Likelihood)
- Implement controls to prevent risk
- Example: Operations risk → Add automated rollback, feature flags
3. Reduce Blast Radius (Reduce Severity)
- Limit scope or impact if failure occurs
- Example: Customer risk → Gradual rollout to 5% of users first
4. Contingency Planning (Prepare for Failure)
- Have plan B ready
- Example: Vendor risk → Identify backup supplier in advance
5. Gather More Data (Reduce Uncertainty)
- Research, prototype, or test before committing
- Example: Assumption risk → Run A/B test to validate hypothesis
6. Accept and Monitor (Informed Risk)
- Acknowledge risk, set up alerts/metrics to detect if it manifests
- Example: Low-probability edge case → Monitor error rates, have fix ready
7. Delay/Cancel (Avoid Risk Entirely)
- If risk is too high and can't be mitigated, don't proceed
- Example: Showstopper legal risk → Delay until legal review complete
针对每个已识别的风险，选择缓解方案：
1. 修订提案（修改计划）
- 修复设计/方案中的缺陷
- 示例：安全风险 → 上线前添加认证层
2. 添加保障措施（降低发生概率）
- 实施控制措施预防风险
- 示例：运维风险 → 添加自动回滚、功能标志
3. 缩小影响范围（降低严重程度）
- 限制故障发生时的范围或影响
- 示例：客户风险 → 先向5%的用户逐步推出
4. 应急预案规划（为失败做准备）
- 准备备选方案
- 示例：供应商风险 → 提前确定备用供应商
5. 收集更多数据（降低不确定性）
- 提交前进行研究、原型开发或测试
- 示例：假设风险 → 运行A/B测试验证假设
6. 接受并监控（知情风险）
- 确认风险，设置警报/指标以检测风险是否出现
- 示例：低概率边缘案例 → 监控错误率，准备修复方案
7. 推迟/取消（完全规避风险）
- 如果风险过高且无法缓解，不要推进
- 示例：致命法务风险 → 推迟至法务审查完成
When NOT to Use This Skill
何时不使用该方法
Skip red teaming if:
- Decision is trivial/low-stakes (not worth the overhead)
- Time-critical emergency (no time for deliberation, must act now)
- Already thoroughly vetted (extensive prior review, red team would be redundant)
- No reasonable alternatives (one viable path, red team can't change outcome)
- Pure research/exploration (not committing to anything, failure is cheap)
Use instead:
- Trivial decision → Just decide, move on
- Emergency → Act immediately, retrospective later
- Already vetted → Proceed with monitoring
- No alternatives → Focus on execution planning
无需红队评估的场景：
- 决策无关紧要/低风险（不值得投入精力）
- 时间紧迫的紧急情况（没时间审议，必须立即行动）
- 已充分审查（已有大量前期评估，红队评估会重复）
- 无合理替代方案（只有一条可行路径，红队评估无法改变结果）
- 纯研究/探索（无需承诺，失败成本低）
替代方案：
- 无关紧要的决策 → 直接决策，继续推进
- 紧急情况 → 立即行动，事后复盘
- 已充分审查 → 推进并监控
- 无替代方案 → 专注于执行规划
Quick Reference
快速参考
Process:
- Define proposal and stakes → Set scope
- Assign adversarial roles → Choose 3-5 critical perspectives
- Generate critiques → What could go wrong from each role?
- Prioritize risks → Severity × Likelihood matrix
- Recommend mitigations → Revise, safeguard, contingency, accept, or cancel
Common adversarial roles:
- Competitor, Malicious Actor, Regulator, Operations, Customer, Finance, Legal, Engineer, Pessimist, Contrarian, Long-term Thinker
Risk prioritization:
- Showstoppers (≥15): Must fix
- High Priority (10-14): Should address
- Monitor (5-9): Accept with contingency
- Accept (<5): Acknowledge
Resources:
- resources/template.md - Structured red team process with role templates
- resources/methodology.md - Advanced techniques (attack trees, pre-mortem, wargaming)
- resources/evaluators/rubric_deliberation_debate_red_teaming.json - Quality checklist
Deliverable: with critiques, risk assessment, and mitigation recommendations
deliberation-debate-red-teaming.md流程：
- 明确提案与影响范围 → 确定边界
- 分配对抗性角色 → 选择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