你知道有些事情就是这样，一旦接触和了解了它们，你就会发现它们几乎无处不在！最近，我个人所经历的『问题求解顺序』（problem-solution ordering）事宜就是一个例子。它们呈现为一种此起彼伏的状态：不仅在我首次遭遇它们的游戏设计环境中，即使是一些不相关的领域，如数学和函数式编程，它们同样显而易见。
尽管如此，我从未见到问题求解顺序这一主题，在我所参与的任何在线社区有过明确的讨论。所以，我打算尝试着将这一主题定义一下；凭借我个人在这一主题上的些许经验，跟踪一下这一现象在不同领域的轨迹；当然，我也希望在此过程中，展现一下我对这一主题的初步认识。当你需要讲述和沟通新的想法或者新的知识的时候，帮助你规避掉一些常见的陷阱。
游戏设计
我就读大学的一位游戏设计老师 Richard Lemarchand 教授第一次向我介绍了问题求解顺序这一主题。自那时起，该主题的核心思想一直紧紧伴随着我。我之所以会这样，其中很大一部分原因，是由于这个主题为一类让人倍感困惑的游戏玩家行为模式提供了一个令人满意的解释。实际上，这类行为模式在我看来，早就屡见不鲜了。
这是一个对这种行为模式的描述：一位新玩家进入你的游戏，开始四处窥探你精心勾画的入门场景。在这一场景中，他得到了一把钥匙，然后他走到一扇紧紧关闭的大门前，成功地打开了门锁。接下来，沿着这条路一直走到头，他遇见了第二扇紧闭的大门... 这一次，他完全不知所措。在此之前，这位玩家已经解决过此类问题 - 但是当他再次面对同样的问题时，为什么突然变得如此艰难呢？
我们在这里所面临的正是一个问题求解顺序问题。由于游戏玩家在入门场景中得到钥匙这件事情，是在他遇见一扇上锁的大门之前发生的，他对『得到钥匙』与『打开门锁』之间这种看似松散的关系还没有完全理解。他得到了钥匙，然后，另外一件事情发生了：他走到一扇门前，用这把钥匙打开了大门。因为在这位玩家的大脑中，『获得钥匙』与『打开大门』分别存储在两处不同的地方，所以这两个事件还没有建立联系。
如果这位玩家首先面对的是一扇上锁的大门，他一定会尝试将其推开，但是无法取得成功，然后，他设法找到了一把钥匙，并且用它把门打开了。在这种情况下，这种看似松散的关系就不会出现错误。你用钥匙打开了紧闭的大门，如果没有了钥匙，大门就根本无法打开。
在你不把『钥匙』看作『钥匙』，或者，当『门』看起来也不像一扇『门』时，这个问题就会变得尤为突出。由于其中的原理非常易于理解，『钥匙与大门』这一类比已被广泛地应用于数量众多的游戏设计中。很多游戏玩家觉得，即使一款游戏在引导玩家这件事情上的做的非常糟糕，依照常识，你也应该知道使用钥匙打开一扇紧闭的大门。然而真实情况却是，如果我们把『钥匙』替换成一枚手榴弹，而那扇门是一台发电机，我认为，当游戏玩家再次见到发电机时，一定会有很多人围着它转圈圈，试图用他们的刀剑毁坏这台设备。
数学教育
我很久之前就发现了游戏设计与教育的相似之处，但是我仍然花费了不少时间才使自己意识到，由问题求解顺序引发的的问题在教室发生的次数和在游戏中一样频繁。
不知你是否还能记得，在高中数学课上，有很多很多的学习内容真的让人觉得毫无意义。（如果这类事情尚未发生在你的身上，或许你同学之中一定会有人对此有同感。）我经常把这种自觉毫无意义的感受看作是数学教育的副产品。不然的话，它们很可能是问题求解顺序不当在数学教学中造成的一个后果。
请思考一下 Dan Meyer 给数学教育者提出的一个问题：如果数学是阿司匹林，那么，你应该如何创造头痛呢？
请把你自己想象成一位兜售阿司匹林的药贩。你一定知道，你最好的顾客就是那些正在遭受疼痛折磨的人。其实不需要很多疼痛，一点点就行。
最糟糕的一种情景就是，你强迫那些没有任何症状的人服用你的阿司匹林。如果你在他们的生活中正在扮演着某种特殊权威的话，他们也许会感激你，除此之外，他们不仅会觉得服用阿司匹林毫无价值，而且对医学的尊重还将慢慢地减退。
数学不应该给人一种无关痛痒的感觉，数学其实具有很高的价值。或许在工作 Y 或者工作 Z 上，数学显得价值微薄，但是数学就其自身而言，肯定意义重大。我们发明新的数学概念，就是为了打破已有数学的局限。所有的数学教育者（包括我在内）面临的最大挑战就是，在我们给学生讲解新的功能强大的数学概念和知识之前，能否先将他们置身于那些旧有的、功能较弱的数学无法解决的，或者不易解决的问题环境中。
换言之，如果在介绍一类问题或者情景之前，你先讲解一种解决办法（如，介绍一种新的数学概念或技巧），这个解决办法就会显得随意且乏味。但是如果你首先让学生们尝试使用他们已有的数学知识解决这类问题，他们很可能就会患上一种『智力性头痛』的『疾病』 - 所以，只有采取这种方法，你才能让学生们更好地理解『阿司匹林』的目的和作用。
这将我们引向了...
函数式编程
在函数式编程中，有一个概念名叫 monad（单子）。众所周知，Monad 是出了名的抽象，很多学习函数式编程的新手，在试图理解这一概念时，经常会被它绊倒。
实际上，monad 这个概念本身并没有那么复杂，那么难以理解。在现实中，我所见过的绝大多数富有经验的函数式程序员都认为这一概念极其简单。这种情况主要发生在那些新程序员身上，当他们试图理解究竟什么是 monad 时，经常陷入非常尴尬的境地。
有很多处于中级到高级水平之间的函数式程序员肩负起编写 monad 教程的职责：他们通过博客文章等各种形式，企图向所有人揭示 monad 的秘密。但是绝大多数诸如此类的教程，似乎从来就没有发挥出它们应有的作用。专家们看过这些文章之后，依旧认为 monad 非常简单，但是那些初学者，当他们阅读完这些教程，还是倍感迷惑。为什么会是这样？这其中的根本原因究竟是什么？
我认为该问题的症结就在于问题求解顺序这个关键点上。
Monad 是解决一类特定问题的解决方法：代码重复的问题。如果你用函数式编程语言编写了足够多的代码之后，你才会慢慢注意到，你使用了大量看似雷同的代码，解决了一堆完全不同的问题。如果可以把它们整合在一起，只编写一次，然后重用这段代码岂不是更好！这样的话，既提高了开发效率，也让代码变得简单整洁。我在这里省略了很多细节，但是这就是 monad 真正想要完成的工作，也是它的意义所在。
本质上，富有经验的函数式程序员与缺乏经验的新手相比，最重要的差别在于，那些极富经验的函数式程序员已经利用函数式语言编写了大量的代码。他们已经遭遇过无数次这样的情景，并且一直在寻求解决办法。换一种说法，他们已经感受过头痛，他们知道 monad 就是消除这种症状的阿司匹林。
从另一个角度来看，初学者只编写过少量代码。他们可能还没有注意到任何重复出现的模式；即使出现过，这种重复还没来及给他们增添麻烦。就是说，头痛症状依然没有出现。
这就是为什么向初学者解释 monad 这一概念是如此困难的原因。特别是那些『罐装教程』，在没有给予充分讲解 monad 作用之前，浪费了大量时间试图解释什么是 monad。Monad 只是一种特定问题的解决方案，但是对新手而言，这些问题他们从来没有碰到过；结果就是，他们发觉这一概念乏味无趣、晦涩难懂。这和我们在高中上数学课时所遭受的境遇完全一样。
请记住：有一种最糟糕的情景就是，你强迫那些没有头痛感觉的人服用你的阿司匹林。同样的，我怀疑企图给那些还没有理解为什么需要 monad 的函数式编程新手『讲授 monad』这种行为本身，很可能适得其反，不仅弊大于利，还更进一步加剧了毫无必要的混淆和感知迷惑，让他们误以为 monad 本质上就是难以理解。
最后的思考
刻意强化解决问题顺序是真正高效的探究性解释的一个显著标志。利用初始安排的元素以及其交互特性，一个设计良好的探究活动，可以快速地将用户吸引进来，并且使他们沉浸其中，从而做到引导用户发现自身『潜在问题』。亲身经历和体验一个问题能够有效地触发用户（或读者等各类受众）的智力需求（Intellectual need）（或者，如果你愿意，也可以称之为『头痛』），而且更重要的是，为稍后解决方案的引入奠定坚实的认知基础。
简单谈谈智力需求：如果你对学习深藏在本文底层的教育理论颇感兴趣的话，我强烈建议你阅读一下这篇有关数学教室里的智力需求的研究性论文，该文不仅对『智力需求』给出了详细的定义，而且还对其在教育领域的必要性进行了广泛而深入的阐述。
最后，我的一点想法和建议：如果你期望打造令人难忘的课程或者学习之旅，你一定要在得到钥匙之前，先行介绍那扇上锁的大门；在兜售阿司匹林之前，详细讲解头痛这种症状；在你罗哩罗嗦的隐喻式概述之前，清晰表明想要解决的具体问题。
（好吧，或许在最后一点上，我也应该做到不要自食其言。）
作者：Max Kreminski，南加州大学本科生，喜欢学习研究交互式媒体与游戏。
原文：Locked doors, headaches, and intellectual need
感谢：Qingniu 帮助审阅并完成校对。