创意问题解决（Problem Solving）

一套突破困境、找到优雅解决方案的技术集合。

概述

本技能包含六个子技能，覆盖从问题分派到具体突破技术的完整工具箱：

何时使用

快速参考

常规方案不够用？              → 碰撞区思维
"这必须这样做"？              → 反转练习
同一模式出现3次以上？          → 元模式识别
在规模化时是否可行？           → 规模博弈
同一个东西实现了5种以上方式？   → 简化级联

核心哲学

"一个强大的抽象 > 十个巧妙的 hack"

这些技术帮助你找到让复杂性变得不必要的优雅方案，而不是通过蛮力来管理复杂性。

------------|-------------| | 复杂度失控 - 同一件事实现了5种以上方式，特殊情况不断增长 | 简化级联 | | 需要创新 - 常规方案不够用，找不到合适的方法 | 碰撞区思维 | | 重复出现的模式 - 同样的问题出现在不同地方，在重复发明轮子 | 元模式识别 | | 被假设束缚 - "必须这样做"，无法质疑前提 | 反转练习 | | 规模不确定 - 在生产环境中是否可行？边界情况不清楚？ | 规模博弈 | | 代码出了问题 - 行为错误、测试失败、意外输出 | 系统化调试 | | 多个独立问题 - 可以并行调查 | 并行代理分派 | | 根因未知 - 症状清楚，原因隐藏 | 根因追踪 |

流程

1. 识别卡住类型 - 哪个症状与上表匹配？
2. 加载对应技能 - 阅读具体的技术
3. 应用技术 - 按照其流程执行
4. 如果仍然卡住 - 尝试不同的技术或组合使用

组合技术

有些问题需要多种技术：

• 简化 + 元模式：找到模式，然后简化所有实例
• 碰撞 + 反转：强制隐喻，然后反转其假设
• 规模 + 简化：极端情况揭示应该消除什么

记住

• 将症状与技术匹配
• 每次只用一种技术
• 如果第一种不奏效则组合使用
• 记录你尝试过什么

附录B：子技能 - 碰撞区思维（Collision-Zone Thinking）

概述

革命性的洞察来自于强制不相关概念的碰撞。将 X 当作 Y 来对待，看看会涌现出什么。

核心原则： 刻意的隐喻混合产生新颖的解决方案。

快速参考

流程

1. 选择两个不相关的概念 - 来自不同领域
2. 强制组合："如果我们将 [A] 当作 [B] 来处理会怎样？"
3. 探索涌现属性：出现了什么新能力？
4. 测试边界：隐喻在哪里失效？
5. 提取洞察：我们学到了什么？

碰撞示例

问题： 复杂的分布式系统存在级联故障

碰撞： "如果我们将服务当作电路来处理会怎样？"

涌现属性：

• 断路器（过载时断开连接）
• 保险丝（一次性故障保护）
• 接地故障（错误隔离）
• 负载均衡（电流分配）

有效之处： 防止级联故障 失效之处： 电路没有重试逻辑 获得的洞察： 来自电气工程的故障隔离模式

你需要此技能的信号

• "我已经试过这个领域里的所有方法了"
• 方案感觉是渐进式的，而非突破性的
• 陷入了常规思维
• 需要的是创新，而非优化

记住

• 最疯狂的组合往往产生最好的洞察
• 严格测试隐喻的边界
• 记录即使失败的碰撞（它们也有教育意义）
• 最佳来源领域：物理学、生物学、经济学、心理学

附录C：子技能 - 反转练习（Inversion Exercise）

概述

翻转每一个假设，看看什么仍然成立。有时候相反的方向反而揭示了真相。

核心原则： 反转暴露隐藏的假设和替代方案。

快速参考

流程

1. 列出核心假设 - 什么"必须"是真的？
2. 系统性地反转每一个 - "如果相反的才是真的呢？"
3. 探索影响 - 我们会做什么不同的事？
4. 找到有效的反转 - 哪些在某些场景下确实有效？

示例

问题： 用户抱怨应用程序太慢

正常方法： 让一切更快（缓存、优化、CDN）

反转： 在某些地方故意变慢

• 搜索防抖（增加延迟 → 实现更好的结果）
• 请求限流（增加摩擦 → 防止滥用）
• 延迟加载内容（延迟 → 减少初始加载量）

洞察： 策略性的"慢"可以改善用户体验（UX）

你需要此技能的信号

• "只有一种方法可以做到这个"
• 被迫使用一个感觉不对的方案
• 无法说清为什么某个方法是必要的
• "这就是一直以来的做法"

记住

• 不是所有反转都有效（测试边界）
• 有效的反转揭示了上下文依赖性
• 有时候相反的方向才是答案
• 质疑"必须"类的陈述

附录D：子技能 - 元模式识别（Meta-Pattern Recognition）

概述

当同一个模式在3个以上的领域中出现时，它可能是一个值得提取的通用原则。

核心原则： 在模式的涌现方式中寻找模式。

快速参考

流程

1. 发现重复 - 在3个以上的地方看到同样的形态
2. 提取抽象形式 - 用与任何领域无关的方式描述
3. 识别变体 - 它在每个领域如何适配？
4. 检查适用性 - 它还能在哪里发挥作用？

示例

发现的模式： 速率限制出现在 API 节流、流量整形、断路器、准入控制中

抽象形式： 限制资源消耗以防止耗尽

变化点： 什么资源、什么限制、超限时怎么处理

新应用： LLM Token 预算（同样的模式 - 防止上下文窗口耗尽）

你正在遗漏元模式的信号

• "这个问题是独特的"（很可能不是）
• 多个团队独立地以相同方式解决"不同的"问题
• 跨领域重复发明轮子
• "我们以前是不是做过类似的事？"（是的，找到它）

记住

• 3个以上领域 = 很可能是通用的
• 抽象形式揭示新的应用场景
• 变体显示适配点
• 通用模式是经过实战检验的

附录E：子技能 - 规模博弈（Scale Game）

概述

在极端规模下测试你的方法，找出什么会崩溃、什么会出人意料地存活。

核心原则： 极端规模揭示正常规模下隐藏的基本事实。

快速参考

流程

1. 选择维度 - 什么可能发生极端变化？
2. 测试最小值 - 如果缩小 1000 倍/更快/更少会怎样？
3. 测试最大值 - 如果放大 1000 倍/更慢/更多会怎样？
4. 记录什么会崩溃 - 极限出现在哪里？
5. 记录什么能存活 - 什么是根本上健全的？

示例

示例1：错误处理

正常规模： "错误发生时处理"运行良好 10亿规模下： 错误量淹没了日志系统，系统崩溃 揭示： 需要使错误不可能发生（类型系统）或预期错误（混沌工程）

示例2：同步 API

正常规模： 直接函数调用可以运行 全球规模下： 网络延迟使同步调用不可用 揭示： 异步/消息传递变成了生存需求，而非优化选项

示例3：内存状态

正常持续时间： 运行数小时/数天没问题 数年后： 内存无限增长，最终崩溃 揭示： 需要持久化或定期清理，不能依赖内存

你需要此技能的信号

• "在开发环境中能运行"（但在生产环境中呢？）
• 不知道极限在哪里
• "应该能够扩展"（但没有测试过）
• 被生产环境的行为所惊讶

记住

• 极端揭示基本面
• 在一个规模下有效的方法在另一个规模下可能失败
• 向两个方向测试（更大和更小）
• 利用洞察尽早验证架构

附录F：子技能 - 简化级联（Simplification Cascades）

概述

有时候一个洞察可以消除10个东西。寻找使多个组件变得不必要的统一原则。

核心原则： "一切都是...的特殊情况"可以戏剧性地折叠复杂性。

快速参考

模式

寻找：

• 相似概念的多个实现
• 到处都是的特殊情况处理
• "我们需要对 A、B、C、D 做不同的处理..."
• 复杂规则伴随大量例外

问自己： "如果它们在底层都是同一个东西呢？"

示例

级联1：流抽象（Stream Abstraction）

之前： 批处理/实时/文件/网络数据各有独立的处理器 洞察： "所有输入都是流 - 只是来源不同" 之后： 一个流处理器，多个流来源 消除了： 4 个独立实现

级联2：资源治理（Resource Governance）

之前： 会话跟踪、速率限制、文件验证、连接池化（全部独立） 洞察： "都是针对每个实体的资源限制" 之后： 一个 ResourceGovernor 管理 4 种资源类型 消除了： 4 个自定义的执行系统

级联3：不可变性（Immutability）

之前： 防御性拷贝、锁机制、缓存失效、时序耦合 洞察： "将一切视为不可变数据 + 变换" 之后： 函数式编程（FP）模式 消除了： 整个类别的同步问题

流程

1. 列出变体 - 什么以多种方式实现了？
2. 找到本质 - 底层什么是相同的？
3. 提取抽象 - 与领域无关的模式是什么？
4. 测试它 - 所有情况都能干净地适配吗？
5. 衡量级联效果 - 有多少东西变得不必要了？

你正在遗漏级联的信号

• "我们只需要再加一个情况..."（永远在重复）
• "这些都类似但不同"（也许它们是一样的？）
• 重构感觉像打地鼠（修一个，坏另一个）
• 配置文件不断膨胀
• "别碰那个，很复杂"（复杂性隐藏了模式）

记住

• 简化级联 = 10倍的收益，而非10%的改进
• 一个强大的抽象 > 十个巧妙的 hack
• 模式通常已经存在，只需要被识别
• 用"我们能删除多少东西？"来衡量