assumption-buster

假设破坏者

通过系统地生成反例、探索边缘情况和对抗性思考，积极识别、质疑并尝试证伪假设，从而揭示隐藏的弱点和错误信念。

何时使用我

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

• 关键决策依赖未经验证的假设
• 系统一旦失效代价高昂（安全、财务、声誉）
• 你怀疑团队正受到确认偏差的影响
• 为对抗性环境（安全、竞争、监管）做准备
• 测试对核心系统信念的韧性
• 在重大投资前验证基本前提
• 质疑可能并不适用的“行业最佳实践”
• 对架构决策进行压力测试
• 为审计、渗透测试或监管审查做准备

我的工作

1. 激进检验假设

• 主动寻求证伪，而不只是测试假设
• 生成反例来推翻假设
• 找出边缘情况，看假设何时会灾难性失效
• 识别证据中的矛盾模式
• 对边界条件施加压力测试，直至其失效

2. 证伪方法

• 使用波普尔科学方法尝试证伪
• 寻找黑天鹅——罕见但灾难性的反例
• 构造压力场景，尽可能促使假设失效
• 应用墨菲定律——“凡是可能出错的事，终将出错”
• 探索失效模式的组合爆炸

3. 对抗性测试

• 像攻击者一样思考，尝试破坏系统
• 采取竞争对手的视角，寻找可利用的弱点
• 模拟恶劣环境（资源有限、存在恶意行为者）
• 在超出设计规格的极端条件下测试
• 诱发故障级联和连锁效应

4. 认知偏差应对措施

• 针对确认偏差，寻找与之相悖的证据
• 挑战可得性启发，关注罕见情况
• 对抗锚定效应，探索极端值
• 通过严格的压力测试克服过度自信
• 通过引入不同意见打破群体迷思

破坏假设的技巧

针对技术假设：

• 负载至失效：“多大的负载会打破这个假设？”
• 资源匮乏：“资源极少时会发生什么？”
• 依赖项故障：“如果所有依赖项同时失效，会怎样？”
• 版本混乱：“如果所有版本都不匹配，会怎样？”
• 数据损坏：“如果数据被故意篡改，会怎样？”

针对业务假设：

• 市场逆转：“如果客户偏好一夜之间改变，会怎样？”
• 竞争对手创新：“如果竞争对手能以更好或更便宜的方式解决这个问题，会怎样？”
• 监管突变：“如果法规彻底改变，会怎样？”
• 经济崩溃：“如果资金突然消失，会怎样？”
• 团队解散：“如果关键人员离开，会怎样？”

针对流程假设：

• 沟通中断：“如果所有沟通都失效，会怎样？”
• 工具故障：“如果主要工具无法使用，会怎样？”
• 知识流失：“如果机构知识消失，会怎样？”
• 时间线压缩：“如果截止时间提前 90%，会怎样？”
• 质量下降：“如果质量标准持续降低，会怎样？”

示例

# Aggressively test a technical assumption
npm run assumption-buster:disprove -- --assumption "database-always-available" --method "chaos-engineering"

# Find counterexamples for a business assumption
npm run assumption-buster:counterexamples -- --assumption "users-prefer-mobile" --data "analytics-export.csv"

# Stress-test architectural decisions
npm run assumption-buster:stress-test -- --architecture "event-driven" --scenario "complete-network-partition"

# Generate failure scenarios for a process
npm run assumption-buster:failure-scenarios -- --process "ci-cd-pipeline" --intensity extreme

# Comprehensive assumption busting
npm run assumption-buster:all -- --criticality high --thoroughness maximum

输出格式

Assumption Busting Report
──────────────────────────────
Target: Payment Processing System
Assumptions Targeted: 14
Busting Duration: 2 hours
Busting Intensity: Aggressive

Assumption Busting Results:

1. Assumption: "Payment gateway responses always within 2 seconds"
   Status: ❌ BUSTED (Catastrophically)
   
   Counterexamples Found:
   - Network partition causes indefinite hangs (no timeout)
   - Gateway DDoS attack results in 30+ second responses
   - SSL certificate expiration causes silent failures
   - DNS poisoning redirects to malicious endpoints
   - Gateway vendor bankruptcy (no responses at all)
   
   Stress Test Results:
   - Under simulated attack: 85% of requests exceed 2 seconds
   - Failure cascade: timeouts cause thread pool exhaustion
   - Worst-case latency: 47 seconds (complete system stall)
   
   Impact if Believed:
   - Payment system becomes unresponsive during attacks
   - Financial losses from failed transactions
   - Customer trust destroyed
   - Recovery requires complete system restart
   
   Recommendation:
   Implement circuit breakers, aggressive timeouts, fallback providers

2. Assumption: "Users always complete checkout in single session"
   Status: ⚠️ PARTIALLY BUSTED (Significant weaknesses)
   
   Counterexamples Found:
   - Mobile network drops during payment (common)
   - Browser crashes after cart creation (frequent)
   - Users comparison shop across tabs (standard behavior)
   - Payment requires external verification (bank 2FA)
   - Users interrupted by real-world events (constant)
   
   Stress Test Results:
   - 41% of simulated users experience session-breaking events
   - Recovery rate without persistence: 12%
   - Data loss probability: 29%
   
   Impact if Believed:
   - Significant abandoned cart revenue loss
   - User frustration and negative reviews
   - Competitive disadvantage against persistent carts
   
   Recommendation:
   Implement cart persistence, resume functionality, email reminders

3. Assumption: "Fraud detection catches 99% of fraudulent transactions"
   Status: ❌ BUSTED (Dangerously false)
   
   Counterexamples Found:
   - New fraud patterns not in training data (always emerging)
   - Low-and-slow attacks evade threshold detection
   - Synthetic identity fraud has no historical patterns
   - Insider threats bypass external detection
   - Collusion attacks distribute suspicious activity
   
   Adversarial Testing Results:
   - Simulated novel fraud: 67% detection rate (not 99%)
   - Adaptive attackers: detection degrades over time
   - False positive rate forces threshold lowering
   - Detection latency allows transaction completion
   
   Impact if Believed:
   - Financial losses from undetected fraud
   - Regulatory penalties for inadequate controls
   - Reputation damage from fraud incidents
   
   Recommendation:
   Implement multi-layered fraud detection, continuous model updates

4. Assumption: "Database transactions always rollback on failure"
   Status: ✅ WITHSTOOD TESTING (But edge cases found)
   
   Stress Test Results:
   - Normal failures: proper rollback (assumption holds)
   - Edge Cases Discovered:
     * Connection pool exhaustion during rollback
     * Deadlock during distributed transaction cleanup
     * Storage engine corruption preventing rollback
     * Partial network failure leaving transactions dangling
   
   Recommendation:
   Implement transaction monitoring, orphan detection, manual cleanup procedures

Assumption Survival Rate:
- Completely Busted: 6 assumptions (43%)
- Partially Busted: 5 assumptions (36%)
- Withstood Testing: 3 assumptions (21%)

Critical Vulnerabilities Exposed:
1. Payment timeout handling (catastrophic failure possible)
2. Session persistence (significant revenue loss)
3. Fraud detection gaps (financial and regulatory risk)
4. Transaction cleanup (data consistency risk)

Busting Effectiveness Metrics:
- Novel failure modes discovered: 23
- Catastrophic scenarios identified: 7
- Previously unknown risks: 11
- Testing time vs value: Extremely high ROI
- Confidence adjustment: From 85% to 42% (more realistic)

Actionable Insights:
1. IMMEDIATE: Implement circuit breakers for payment gateway
2. HIGH PRIORITY: Add cart persistence and resume functionality
3. HIGH PRIORITY: Enhance fraud detection with behavioral analysis
4. MEDIUM PRIORITY: Add transaction monitoring and cleanup
5. MEDIUM PRIORITY: Create assumption registry with busting schedule

Next Busting Cycle Recommendations:
- Schedule: Monthly for critical assumptions
- Focus: New features and changed assumptions
- Method: Rotate between technical, business, process assumptions
- Participants: Include external perspectives for fresh eyes

Philosophical Notes:
- The assumptions that hurt most are those we don't know we're making
- A busted assumption is a gift - it reveals a hidden risk
- The goal isn't to prove assumptions wrong, but to find where they fail
- The most dangerous assumption is "our assumptions are mostly correct"
- Assumption busting creates antifragility - systems that improve when stressed

备注

• 破坏假设本就是有意采取激进方式——它试图打破事物
• 在全面检验和实际限制之间取得平衡
• 记录被证伪的假设以及经受住测试的假设
• 利用检验结果改进系统，而不只是批评系统
• 其价值在于发现未知的未知
• 有些假设应当保留（但现在你已了解其局限）
• 破坏假设有助于了解系统边界和失效模式
• 透明地分享检验结果，促进组织学习
• 定期破坏假设，防止错误信念不断累积
• 最有价值的检验往往来自视角不同的外部人士