thinking-inversion

反向思维

重定向： 对于大多数风险预判工作，优先使用 thinking-pre-mortem——它会进行叙事式前瞻回顾，找出比通用清单更丰富、更具体的失败原因。仅在范围明确的功能或设计上快速枚举失败模式时使用反向思维；对于完整计划、发布或战略决策，事前验尸法是更有力的工具。

触发卡片

在规划范围明确的功能或设计，且乐观情绪可能掩盖风险时：

1. 清楚地陈述目标。
2. 询问：“怎样才能确保它失败？”——列出 10 条以上具体的失败路径。
3. 将最重要的 3-5 条转化为明确的规避要求。（例如：“不得使用明文密码” → “使用工作因子 ≥ 12 的 bcrypt”）
4. 确认计划已逐一应对这些问题。

如果任务规模小、可逆，或现有检查已充分覆盖失败模式，则跳过。对于完整计划或发布，改用 thinking-pre-mortem。

概述

由 Charlie Munger 倡导、根植于数学家 Carl Jacobi“反过来想，始终反过来想”这一原则的反向思维，通过思考问题的反面来处理问题。不要问“我怎样才能成功？”，而要问“怎样才能确保失败？”，然后避开这些路径。

核心原则：“我只想知道自己会在哪里死去，这样我就永远不会去那里。”——Charlie Munger

适用场景

• 规划新项目、功能或计划
• 在做出承诺前评估决策
• 找出乐观思维掩盖的风险
• 不知道如何实现积极结果
• 需要质疑计划中的假设
• 编写需求或验收标准

决策流程：

Have a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST
                                                      ↘ no → Definitely invert
           ↘ no → Define goal, then invert

不适用场景

• 你正在规划完整的发布、项目或战略决策。 请改用 thinking-pre-mortem——它会进行叙事式前瞻回顾，找出比清单式枚举更丰富、更具体的失败原因。反向思维更轻量、更快捷；事前验尸法则更深入。
• 任务规模小、可逆，而且失败代价低——直接去做，之后再修正。
• 你只能列出“没有测试”“命名糟糕”等泛泛而谈的失败模式，而这些并不适用于当前情况；如果想不出具体问题，就跳过。
• 现有检查（CI、lint、类型系统）已充分覆盖这些失败模式；不要重复列举已有机制强制执行的事项。

流程

步骤 1：清楚地定义目标

说明成功是什么样的：

Goal: "Ship a reliable authentication system by Q2"
Goal: "Build a high-performing engineering team"
Goal: "Launch product with strong user retention"

步骤 2：反向思考——询问“怎样才能失败？”

列出所有能确保失败、毁掉目标或导致结果与目标相反的方法：

Goal: Ship reliable auth system
Inversions (How to guarantee failure):
- Skip security review and pen testing
- No rate limiting or brute force protection  
- Store passwords in plaintext
- No monitoring or alerting
- Skip edge cases in testing
- No documentation for on-call
- Single point of failure, no redundancy
- Ignore compliance requirements
- No rollback plan
- Deploy on Friday before vacation

步骤 3：对失败模式分类

按类型和严重程度分组：

类别	失败模式	严重程度
安全	明文密码	严重
安全	没有速率限制	高
运维	没有监控	高
运维	没有回滚计划	高
流程	跳过安全审查	严重
流程	没有文档	中
可靠性	单点故障	高

步骤 4：转化为规避检查清单

将每种失败模式转化为一项要求：

Anti-goal: Store passwords in plaintext
→ Requirement: Use bcrypt/argon2 with appropriate work factor

Anti-goal: No rate limiting
→ Requirement: Implement rate limiting with exponential backoff

Anti-goal: Deploy Friday before vacation
→ Requirement: No deploys within 48h of team unavailability

步骤 5：按影响优先排序

重点规避以下失败：

• 一旦发生，破坏性最大
• 如果没有明确防范措施，最可能发生
• 最难恢复

应用模式

技术设计

Goal: Build scalable API
Invert: How to make it fail under load?
- No caching → Add caching layer
- Synchronous everything → Add async where appropriate  
- No connection pooling → Implement pooling
- N+1 queries → Eager loading, query optimization
- No circuit breakers → Add circuit breakers

代码审查

Goal: Merge high-quality code
Invert: What would make this PR problematic?
- Introduces security vulnerability
- Breaks existing functionality
- No tests for new behavior
- Unclear intent/poor naming
- Performance regression
- Missing error handling

职业发展／团队建设

Goal: Build successful engineering career
Invert (Munger's list of what to avoid):
- Be unreliable
- Learn only from your own mistakes (ignore others')
- Give up after first failure
- Be resentful and envious
- Stay within comfort zone
- Avoid difficult conversations
- Don't learn continuously

项目规划

Goal: Successful product launch
Invert: How to guarantee launch failure?
- No user research → Validate with users
- No load testing → Load test before launch
- No rollback capability → Build rollback
- No success metrics defined → Define metrics upfront
- Team burnout → Sustainable pace
- No communication plan → Prepare stakeholder comms

与事前验尸法结合

反向思维 + 事前验尸法可以有效识别风险：

1. 反向思维：列出项目可能失败的方式（理论层面）
2. 事前验尸法：设想项目确实失败了，并以叙事方式解释原因
3. 综合分析：合并两份清单，确定优先级并采取缓解措施

软件领域中的常见逆向思考

领域	目标	应避免的关键反向做法
安全	安全的系统	信任用户输入、身份验证薄弱、机密信息暴露
性能	快速的系统	不使用缓存、调用阻塞、没有索引
可靠性	稳定的系统	没有监控、没有冗余、无法平稳降级
可维护性	简洁的代码	没有测试、名称晦涩、耦合紧密
团队	高绩效	沟通不畅、缺乏心理安全感、目标不明确

验证清单

• 明确定义目标
• 列出至少 10 种导致失败／实现相反结果的方式
• 按类型和严重程度对失败进行分类
• 将最重要的失败因素转化为明确的要求
• 确认计划解决了最关键的反向因素
• 针对实际设计重新检查最重要的反向因素，找出盲点

关键问题

• “什么会确保这里失败？”
• “其他人通常会犯哪些错误？”
• “我最可能忽略什么？”
• “如果这次失败得一塌糊涂，事后复盘会怎么说？”
• “我会告诉别人避免什么？”
• “具体来说，成功的反面会是什么样？”

Munger 的警示

“我们这样的人通过努力始终不犯蠢，而不是努力表现得极其聪明，获得了多少长期优势，实在令人惊叹。”

逆向思考的力量在于避免那些会被乐观心态蒙蔽的明显错误。简单地规避错误，往往胜过巧妙地优化。