在程序世界里，为什么人要写“脚本”（Linux下bash），又为什么要在解决复杂事物之前先抽象出模型？
现实世界总是如此丰富，很多时候不得不只关注于局部的细节，通常的情况很可能是经过一个星期、一个
月甚至更长的时间的摸爬滚打，我们对这一领域的知识，或是一个系统的某个部分非常熟悉，可以称得上
是这一部分的专家，我们有自信在整体构架上提出创新，信心满满的对源代码进行修改，权威的提出针对
各种边界情况的行为预测，此时的自己是一个令自己满意的自我，此时写下的一个运行脚本是“专家级”的
脚本，仅仅敲一个命令就可以专业级（包括各种各样边界情况，有时候甚至及其晦涩）地完成任务。
然而现实世界中，特别是复杂事物，你不得不从一个熟悉的环境转移到另一个新的领域，如果运气好，
可以再次产生一个专业级的脚本，此时的自己再回过头去看看前一个专家，很可能会发出感叹：“哇，这个
脚本是当时的我写的吗？”真是时过境迁啊！
既然现实世界如此，那么我就想了，如果有意无意多创造几个这样的“脚本”，在同一时间内让这几个脚
本并行运行起来，那岂不是相当于有多个自己在各个领域并行行动了？并且每一个都是专家级的自己！
其实我想说明的是，连自己都不能保证前一个专家的自己，在后来继续保持专家的水平，更何况是别人
“脚本”或是“代码”？既然遗忘是不可避免的，生疏程度只不过是时间长短的问题，我们唯一能做的只有期待
前一个“脚本”尽可能的简明易懂，以方便自己随时在需要的时候，在不必付出太大的努力的情况下，就能
接手，不要求对每个细节完全了解，也不用深究某些极其晦涩的理由，但要保证的是容易添加新的功能，
并且新功能不会对原有功能产生重大影响。听上去有点勉为其难，那么只好期望原来的脚本重点突出了，
虽然这次不能做到整个脚本的专家，但至少也是这些重点部分的熟悉者。
实际上，前面最后推出的重点部分，我想把它称为“模型”。
“模型”，应当能够被用来处理复杂问题，我们对领域的所有的思考过程被汇总到这个模型中，它还必须
超越我们的头脑，对于我们头脑遗漏掉的边界情况，如果这个模型也能处理，那么可以说它具有相当的
健壮性，也达到了提出这个模型的目的。
前面的整个过程，是我在看《模型驱动设计（精简版）》中提到的关于“模型”的一段话时所产生的联
想。以前对模型的理解是在写大型程序、或是复杂系统之前所画的几个圆饼图，以及几条代表这些圆饼
之间关系的连线。实际上模型不是这么简单，一个模型就是一个专家，它是在众多纷繁芜杂的细节中理出
的关键点，能够起到“纲举目张”的效果，从这个角度讲，模型是在完成了复杂设计之后所总结出的一套
简洁、易被理解和修改的东东，如果足够健壮，它应当对其它不曾考虑到的情况具有预测效果。
书中有一句话讲得好，“我们需要用模型来交流”。那么对于自己这个专家，并且是各个不同阶段的
专家，让我们尽量把每个脚本都变成“模型”，这样，在“一个自己”的并行行动中，我们除了可以保持高效，
还可以确保方便的修改，以保证可持续的并行行动！
注：脚本——泛指一种类似Linux下shell脚本的机制，一条命令，触发的是一堆流程，并且还具有专家级水平。