constructive-dissent

建设性异议

通过结构化的异议流程，系统地质疑提案，揭示弱点、检验假设并提出更优方案。

何时使用此技能

• 在敲定重大决策或架构选择之前
• 检验提案中隐藏的弱点和盲点
• 生成尚未考虑过的替代方案
• 审查假设（显式、隐式和结构性假设）
• 从利益相关方的角度评估相互竞争的解决方案
• 避免将其用于常规代码审查——改用 requesting-code-review

工作流

步骤 1：选择异议强度

根据决策的重要程度选择合适的质疑级别：

级别	目的	使用时机
温和	在不质疑核心方案的前提下改进	影响较小的改进、早期草稿
系统性	在尊重意图的同时质疑方法	影响中等的决策、方法论审查
严格	抨击根本前提	影响重大的架构、重大转向
范式性	质疑世界观，提出激进的替代方案	战略方向、追求创新

步骤 2：开展假设审查

针对待审查的提案，系统地识别：

1. 显式假设 — 哪些内容被视为已知事实？
2. 隐式假设 — 哪些未明说的假设正在发挥作用？
3. 结构性假设 — 存在哪些框架偏见？
4. 时间假设 — 哪些时间限制是人为设定的？

| Assumption | Type | Validity | Risk if Wrong |
|------------|------|----------|---------------|
| Users prefer speed over accuracy | Implicit | Medium | Product misalignment |
| API rate limits won't change | Temporal | Low | System failure at scale |

步骤 3：生成边界案例

从多个维度对提案进行压力测试：

• 规模极值：当量达到 10 倍和 0.1 倍时会发生什么？
• 性能限制：方案会在何处失效？
• 用户行为极端情况：最佳和最差使用模式
• 资源限制：如果预算、时间或团队规模减半，会怎样？

步骤 4：应用质疑方法

替代方案生成框架：

1. 目标抽象 — 从具体实现中提取核心目标
2. 放宽约束 — 暂时移除限制，看看有哪些可能
3. 方法反转 — 考虑相反的方案
4. 跨领域借鉴 — 应用其他领域的解决方案

利益相关方代言 — 从以下各方的角度提出论据：

• 终端用户、维护者、安全、无障碍性、未来利益相关方

步骤 5：综合并提出建议

生成结构化分析：

## Constructive Dissent Analysis: [Proposal Title]

### Intensity Level: [Selected Level]

### Executive Summary
[2-3 sentence summary of key challenges and recommendations]

### Challenges Raised
#### Challenge 1: [Title]
**Type**: Methodology / Premise / Evidence / Stakeholder
**Core Argument**: [What's being challenged and why]
**Evidence**: [Data or reasoning supporting the challenge]
**Alternative Approach**: [What to do instead]

### Generated Alternatives
#### Alternative 1: [Title]
**Approach**: [High-level description]
**Advantages**: [Why this might be better]
**Trade-offs**: [What you give up]

### Synthesis
- Strengthen current proposal: [specific improvements]
- Consider alternative if: [conditions that favor switching]
- Unresolved questions: [items needing more information]

最佳实践

• 让强度与影响相匹配 — 对 CSS 微调进行范式性异议，只会浪费大家的时间
• 保持建设性的表达方式 — 质疑观点，而非针对个人
• 始终提出替代方案 — 只批评而不提出替代方案，那就只是批评
• 明确记录假设 — 隐藏的假设是风险最高的事项
• 代言利益相关方 — 真诚地论证各方观点，而不是树立稻草人