无论是任何方式推广你所认可的理念或教育给到孩子们，给到用户——但有一种方式，是我所比较拒绝的：通过放大焦虑胁迫。没有任何一个“组织提供的教育”是必须的，没有任何一个“组织规划的学科”是必须的——人的高贵之处在于人的自由意志和基于此的成长性。

作为教育者和家长，我们都是孩子们的环境，我们不是主宰，不是赶鞭子的人。

所以，诸如“让中国孩子不能输在少儿编程的起跑线上”这样的参与方式，是我所拒绝的。无论教育内容方式是怎样的，我们不要用这样一种心态去教育、去运营。更不要用这样一种心态去设计课程、去教学。

这是一种传统的教学方法，从中小学文化主课到高等教育中的大部分讲师，再到职业教育中的许多场景，都是如此的。

这里所有教学目标中，涉及“学会***等程序模块”的部分，都是程序设计的知识性目标，也就是编程语言的指令（而对于“发散思维”等能力，则从课程大纲上难以看出如何落地）。

这种指令和相关知识，在另外一个团队的公开教学视频中，很好的展现了知识讲授的教学方法。

老师给出屏幕上的例子：一个座标系背景下不同位置有不同的表情。老师提问：找一找座标为（2，2）的表情是哪个？然后学生们就可以回答，老师进行确认。

这就是我们最常见的一种形式，把教学目标拆解成知识目标（按照主课方式也会拆解能力目标，但许多时候是知识目标的重复，再加上一些学科特点或概念），然后通过讲解和训练的方式，去落实知识目标的教学。

另一种常见的方式是步步引导操作。这种教学方式，其实是针对的是少儿编程这种课程，其知识目标是以操作性知识为主的——至少在启蒙入门阶段，大部分的知识都是操作性知识。

所以，我们能见到的许多课程，是类似于这样的：上来先介绍编程工具的基本方面，比如舞台、角色、积木编码等等，然后会用一个很小的任务，一般选用游戏场景，来吸引孩子一步步操作，进而动手实现一个小的游戏活动。

这里的重点是一步步引导操作，用操作来学习各种编程行为，加角色、改属性、拖放代码……每若干操作会形成一个结果，一个可以执行的小游戏活动场景。通过不断的模仿操作和查看结果，来学习编程知识。

这样的操作过程，如果团队资源足够，会再嫁接一套IP形象和资源体系，用IP形象的方式来推动不同课节之间的切换，也可以用小动画来衔接。但总而言之，教学方法可以概括为步步引导操作。

第三种教学方式，是小组活动教学为核心形式的教学方式，但教学的逻辑，是以问题探究为驱动的（且必须以）。

这种教学方式当然不是常见的，且也不是成熟的。它在部分环节可能涉及到第二种和第一种教学方法的实施——但大家需要注意到关键：这两种教学方法的使用都是有前提条件和时机的。

所以这种教学方法的实施不如前两种容易操作，不如它们容易标准化。但也不是没有实施方法和脉络。

这种教学法，是以问题驱动的，是以形成性评价驱动的，是以孩子探究和教师coach驱动的复合教学方法。

从本质上而言，不同教学方法，是由教育目标追求和教学实施资源来决定的，当然，很大程度上也受限于组织的商业模型路径选择。

就教学目标而言，核心素养目前我相信还停留在文本层面，全人教育还是一个概念（不说局部资源集中的点）。

其实少儿编程在落实综合素养的教学目标而言，是有其独特优势的——但非常可惜，一些惯性更擅长知识讲授，另一些更擅长步步操作引导。少儿编程学科在教学目标上，其实还可以挖掘更加深入，课程设计和教学实施，还可以做更多。

这里不得不再次引入我之前的一个探讨：

所以，我们讲课程和教学需要由问题来驱动，知识讲授和操作性知识训练是必要的——但也是有条件和时机要求的。我们应该把问题驱动实践当做核心。

而由此延伸出来，教师和学生的角色也发生了变化。这既不是传统的教师为中心，也不是完全的学生为中心。这是以问题实践和教练为中心的，以学生和教师的深度互动为中心的。

就商业路径实施而言，当然比如会面临折中取舍的时候。我不反对折中取舍，我所反对和拒绝的，在一开始已经说明。

这种由真实问题到真实实践、由真实实践到真实问题的反复，我相信才是当今孩子们学习过程中最需要的学习范式。

它需要我们的教育目标、课程、教学法、测评，以及教师和学生角色各个层面进行升级才能完成的。

就好比，锅是一个锅，都是Scratch或乐高，但炒出的菜真的不同。我当然期望我们的工作者，以及我们的家长，都能多多关注这个方面。

我们自己亲生的孩子，我们自己的事业，无论哪个角度，我们都不应肤浅的去对待这件事，更不应胁迫她们。