devils-advocate

唱反调者

通过扮演唱反调者，系统地质疑想法、假设、设计和决策，在确定行动方案前找出弱点、盲点和其他视角。

何时使用我

在以下情况下使用此技能：

• 团队似乎正在达成一致，却没有展开辩论
• 重要决策依据的是共识而非证据
• 需要在实施前对想法进行压力测试
• 识别潜在的故障模式和风险
• 防止群体迷思和确认偏误
• 在选择前评估多个备选方案
• 为应对利益相关方的质疑或反对意见做准备
• 增强应对批评和失败的韧性

我能做什么

1. 论证拆解

• 识别提案、设计或决策中的核心主张和假设
• 分析支撑证据的强度、相关性和可靠性
• 梳理前提与结论之间的逻辑联系
• 发现推理中的修辞谬误和认知偏差
• 揭示未明确陈述的隐含信念

2. 生成反驳论点

• 针对相同证据提出其他解释
• 提出也可能成立的竞争性假设
• 找出矛盾数据或对立观点
• 提出对事实和发现的不同解读
• 构建当前想法可能有误的“假设情境”

3. 识别弱点

• 找出论证和推理中的逻辑漏洞
• 识别未经审视的风险和潜在故障模式
• 发现预测或估算中的过度自信
• 发现对复杂问题的过度简化
• 识别缺失的视角或利益相关方观点

4. 探索其他视角

• 采纳不同利益相关方的视角（用户、客户、监管机构、竞争对手）
• 考虑争议问题上的对立立场
• 探索边缘情况和边界条件
• 应用不同的思维模型或框架
• 质疑基本前提，而不只是结论

唱反调者技巧

对于技术决策：

• 质疑技术选型：“如果这个框架不再维护了怎么办？”
• 质疑架构决策：“如果负载达到预期的 10 倍，这套架构如何应对？”
• 探查安全假设：“有哪些攻击途径是我们没有考虑到的？”
• 检验可扩展性方面的说法：“在压力下最先出问题的会是什么？”
• 审视依赖风险：“如果这项第三方服务发生变化，会有什么后果？”

对于产品/功能决策：

• 质疑对用户的假设：“如果用户的行为与我们的预期不同呢？”
• 质疑市场契合度：“有哪些证据与我们的市场假设相矛盾？”
• 探查价值主张：“客户为什么会选择其他方案？”
• 检验商业模式：“哪些假设会导致这种收入模式失败？”
• 审视竞争威胁：“竞争对手如何轻易地削弱我们的优势？”

对于流程/运营决策：

• 质疑工作流效率：“是什么让这个流程变得脆弱？”
• 质疑衡量指标的有效性：“我们衡量的是正确的内容吗？”
• 探查团队动态：“哪些人际问题可能会让计划脱轨？”
• 检验沟通计划：“哪些地方可能会产生误解？”
• 审视激励机制的一致性：“这会造成哪些有害的激励？”

示例

# Challenge a technical design decision
npm run devils-advocate:challenge -- --decision "use-microservices" --context "ecommerce-platform"

# Test a product assumption  
npm run devils-advocate:test -- --assumption "users-want-mobile-app" --data "user-research.json"

# Identify weaknesses in a proposal
npm run devils-advocate:weaknesses -- --proposal "architecture-redesign.pdf" --perspective "security"

# Generate counterarguments for a business case
npm run devils-advocate:counterarguments -- --business-case "expand-to-europe.md" --stakeholder "competitor"

# Comprehensive devil's advocate review
npm run devils-advocate:review -- --document "project-plan.md" --thoroughness high

输出格式

Devil's Advocate Analysis
──────────────────────────────
Subject: Microservices Architecture Proposal
Date: 2026-02-26
Analysis Duration: 45 minutes

Core Claims Identified:
1. "Microservices will improve development velocity by 40%"
2. "Team autonomy will increase with bounded contexts"
3. "System will be more resilient to failures"
4. "Scaling will be more efficient and cost-effective"
5. "Technology diversity will enable better tool selection"

Argument Analysis:

1. Claim: "Microservices improve development velocity by 40%"
   Supporting Evidence: Case studies from other companies
   
   Devil's Advocate Challenges:
   - Case studies may not apply to our context (different scale, team structure)
   - 40% improvement assumes optimal implementation and mature DevOps
   - Velocity gains may be offset by coordination overhead
   - Microservices introduce new failure modes (network, versioning, data consistency)
   - Learning curve could reduce velocity initially
   
   Alternative Explanation: 
   The perceived velocity improvement may come from better practices 
   (CI/CD, testing) that could be applied to monoliths too.

2. Claim: "Team autonomy increases with bounded contexts"
   Supporting Evidence: Conway's Law, team structure diagrams
   
   Devil's Advocate Challenges:
   - Bounded contexts require clear domain boundaries (do we have them?)
   - Teams need new skills (distributed systems, SRE practices)
   - Increased autonomy may lead to inconsistent standards
   - Cross-team coordination becomes more formal and slower
   - Some domains naturally span multiple services
   
   Alternative Perspective:
   Monolith with modular architecture might provide similar autonomy benefits 
   without operational complexity.

3. Claim: "System more resilient to failures"
   Supporting Evidence: Failure isolation diagrams, redundancy claims
   
   Devil's Advocate Challenges:
   - Distributed systems have MORE failure modes (network partitions, service discovery)
   - Resilience requires sophisticated infrastructure (circuit breakers, retries, fallbacks)
   - Debugging failures across services is harder
   - Data consistency becomes a major challenge
   - Cascading failures possible if dependencies not managed
   
   Contradictory Evidence:
   Many companies report increased operational complexity and failure rates 
   after microservices adoption without proper preparation.

Risk Assessment:
- High Risk: Data consistency across services
- Medium Risk: Operational complexity overwhelming team
- Medium Risk: Cross-team coordination overhead
- Low Risk: Technology choice limitations

Alternative Approaches Worth Considering:
1. Modular monolith with clear internal boundaries
2. Start with coarse-grained services, refine later
3. Hybrid approach: monolith for core domain, services for edge functions
4. Focus on DevOps maturity first, then evaluate service boundaries

Critical Questions Unanswered:
1. What specific metrics will measure "improved velocity"?
2. How will we handle distributed transactions?
3. What is the rollback plan if microservices don't deliver value?
4. How will team structure change to support service ownership?
5. What monitoring and observability investments are needed?

Recommendations:
1. Pilot with one non-critical service first
2. Define clear success metrics before proceeding
3. Invest in foundational capabilities (monitoring, deployment, testing)
4. Consider evolutionary architecture rather than big-bang rewrite
5. Document assumptions and revisit after 3 months

Analysis Value:
- Weaknesses identified: 8 significant, 3 critical
- Alternative perspectives generated: 5 viable alternatives
- Assumptions challenged: 12 core assumptions
- Risk areas highlighted: 3 high-risk areas needing mitigation
- Decision quality improvement: High (prevents potential costly mistake)

注意事项

• 唱反调是一种角色，而非个性——它是临时且有明确目的的
• 目标是做出更好的决策，而不是赢得争论或阻碍进展
• 在保持质疑的同时，提供建设性的替代方案
• 记录质疑及其回应，以供日后参考
• 仅在重要决策中选择性地唱反调，而非在每次讨论中都这样做
• 最有价值的质疑，往往是最难回答的
• 将唱反调与其他视角结合起来，以进行平衡分析
• 为唱反调分析设定时间限制，避免陷入分析瘫痪
• 注重实质，而非表达方式——质疑想法，而非针对个人
• 最好的唱反调式提问，能让所有人换个角度思考