蓝图与拼图，是类比于分析和解决问题的两种过程模式。联系到前面的文章¹，可以说也是“驱动”的两种模式。

蓝图模式，指的是从整体出发，逐级分解问题，直至定义出足够具体的子问题，进而解决问题的模式。拼图模式，指的是不从整体分解，而从一个个显而易见的局部问题点出发，各个击破，每个先解决掉，进而自然解决整个问题的模式。

用程序员熟悉的语言，可以大致地对应一下。蓝图模式，类似一种广度优先的过程；而拼图模式，类似于一种深度优先的过程。

可以看到，在蓝图模式下，子问题之间的关系是很明确的，他们组合起来是不是问题的整体，解决以后可不可以解决问题的整体，这些是可以预见的。而在拼图模式下，子问题之间的关系是不明确的，即使解决掉所有识别到的子问题，仍然不能认为，问题的整体被解决了。

蓝图模式可以说是一种理想的模式。高屋建瓴，步步为营，可控性强。

但蓝图模式在实际使用中局限性很明显，很难被真正应用。

1. 蓝图模式依赖于对问题整体的深刻认识。很多时候这是做不到、来不及或者负担不起的。
2. 蓝图模式依赖于对问题的正确分解。并不是所有问题，都能容易地做到正确分解。特别是，这种分解的技能可能非常依赖于个人经验，难以工程化。

实际工作中，我们常常综合应用两种模式。比如一种常见的过程是拼图-蓝图模式。当我们对问题整体认识不足，或者认为认识成本过高，我们就寻找局部的突破点，以拼图的模式来找到一个个的局部问题。找到局部问题以后，我们就可以借助蓝图模式 -

• 一方面，局部问题的规模和复杂度相对较小，整体容易认识，这时候我们就可以画出“这块拼图的蓝图”，进而可控地完成这块拼图。
• 另一方面，随着对各个拼图块的研究，可以帮助我们对整体问题的结构有进一步的认识。就好比说，我们在拼图之前是不知道整体画面的内容的，但拼出几块图之后 ，我们对整体画面就有了一些认识。这既可以帮助我们完成接下来的拼图，也可以帮助我们验证拼图是否已经最终完成。