从“学会编程”到“用编程解决问题”：少儿编程教育正在走向项目式学习与智能评价｜行业动态

近日，教育部印发《义务教育阶段科学教育“做中学”领航行动指南》，提出聚焦真实问题，开展项目式、探究式、场景式学习，引导学生在实践过程中提出问题、设计方案、搜集证据、验证结果，并不断反思和改进。对于少儿编程教育而言，这份文件值得关注的并不只是其中出现了“人工智能”这一主题。更重要的变化是： 学生学习的重点，正在从“掌握了多少知识”，进一步走向“能不能运用知识解决真实问题”。 而编程，恰恰是最适合“做中学”的学习方式之一。

一、为什么说编程天然适合“做中学”？

传统的编程课堂通常从知识点开始。今天学习循环，明天学习条件判断，再学习变量、函数、数组…… 这种教学方式当然有必要，但如果学习一直停留在“知识点—例题—练习题”，学生很容易知道某个语法“怎么写”，却不知道什么时候应该使用它。项目式编程学习则恰恰相反。例如，老师并不首先告诉学生今天要学习“循环”和“随机数”，而是给出一个任务： 设计一个小游戏，让障碍物不断从随机位置出现，玩家控制角色躲避障碍，并记录坚持的时间。 为了把这个作品真正做出来，学生会自然遇到一系列问题：

障碍物怎样不断出现？
怎样让每次出现的位置不同？
怎样判断角色和障碍物发生了碰撞？
怎样记录分数？
游戏结束后如何重新开始？
随着时间增加，难度怎样逐渐提高？

为了回答这些问题，学生会主动用到循环、随机数、条件判断、变量、坐标、碰撞检测等编程知识。此时，知识不再是学习的终点，而成为了解决问题的工具。这正是“做中学”的价值： 不是为了学习某个知识点而完成一个任务，而是在完成真实任务的过程中产生学习知识的需要。

二、少儿编程教育正在从“写代码”走向“解决问题”

很多家长第一次接触少儿编程时，会问： “孩子学 Scratch 到底有什么用？” “以后是不是一定要做程序员？” 实际上，少儿编程教育真正重要的价值，并不是提前学习某一种编程语言。语言和工具都会不断变化。今天可能是 Scratch、Python、C++，未来还会出现新的开发方式和人工智能工具。真正能够长期留下来的，是一套解决问题的方法： 发现问题 → 拆解问题 → 提出方案 → 编程实现 → 测试验证 → 发现错误 → 修改方案 → 再次验证。 例如一个学生要设计“智能红绿灯”，就可能同时涉及：数学中的时间和比例；科学中的传感器与环境信息；程序中的条件判断和状态控制；工程设计中的异常情况处理；甚至还要思考行人、车辆与安全之间的关系。这时候，编程不再是一门孤立的技术课程。它成为连接数学、科学、工程、人工智能甚至艺术设计的一种工具。教育部此次“做中学”领航行动提出了生命健康、生态环境、地球奥秘、航空航天、新兴产业、人工智能等主题，这些领域实际上都非常适合与编程学习结合。例如：在“生态环境”主题中，学生可以采集温度、湿度或植物生长数据，通过 Python 进行数据统计和可视化；在“航空航天”主题中，可以通过程序模拟行星运动、计算飞行时间或者制作火箭发射模拟；在“人工智能”主题中，则不仅可以让学生体验图像识别和生成式 AI，更可以进一步研究模型为什么会出错、数据变化为什么会影响结果，以及怎样验证 AI 给出的答案是否可靠。 编程真正有价值的地方，不只是让计算机执行命令，而是让学生把自己的思考变成一个可以运行、可以验证、可以不断修改的模型。

三、“允许失败”，可能是编程教育最重要的价值之一

在传统学习中，学生通常希望尽快得到正确答案。但在真正的科学研究、工程设计和程序开发中，第一次尝试失败反而是常态。程序运行错误；结果和预想不同；角色没有按照设计移动；算法可以运行，但速度太慢；测试 10 次都没有问题，第 11 次却出现异常。这些都不是学习的失败。真正有价值的问题是： 为什么会失败？ 学生需要找到原因，提出新的假设，修改程序，然后再次测试。这就是程序开发中最重要的过程之一——Debug，也就是调试。一个学生能够独立找到 Bug 并修复它，很多时候比第一次就写出正确答案更有学习价值。因为在这个过程中，他真正经历了： 观察 → 判断 → 假设 → 验证 → 修正。 这与科学探究的基本过程高度一致。因此，一个好的少儿编程教学平台，也不应该只告诉学生一道题是： Accepted（正确） 或者： Wrong Answer（错误）。 更有价值的是帮助学生理解： 哪里出现了问题、为什么会出现问题，以及下一步应该怎样继续尝试。

四、这也意味着：传统 OJ 在线评测需要进一步升级

在线评测系统，也就是 Online Judge（OJ），已经广泛应用于 C++、Python 等程序设计和信息学教学。它解决了一个非常现实的问题： 程序作业怎样自动批改？ 学生提交代码后，OJ 可以自动编译和运行程序，通过多组测试数据判断：

程序输出是否正确；
是否运行超时；
是否超过内存限制；
是否发生运行错误；
是否能够处理边界情况。

这套机制非常适合传统算法题。例如要求学生输入两个整数并计算结果，系统很容易判断程序是否正确。但当编程教育进一步进入项目式学习之后，评价问题就变得复杂了。例如，一个 Scratch 作业要求学生：

制作一个海底小游戏。点击绿旗后鱼开始游动，碰到河豚时生命值减少，吃到食物增加分数，分数达到一定条件后切换场景并播放声音。

这样的作品应该怎样自动评分？仅仅检查最后的“答案”已经没有意义。系统可能需要判断：

是否存在指定角色；
是否正确使用变量；
是否设置了绿旗事件；
是否真正实现碰撞检测；
碰撞之后生命值是否发生变化；
是否正确切换造型或背景；
是否按照要求播放声音；
游戏运行过程中是否出现异常行为。

这已经不再是传统意义上的“输入一个答案、判断对错”。它实际上是在判断： 学生设计的程序是否真正实现了任务要求。

五、Scratch 自动判题，是项目式编程规模化教学的重要一步

Scratch 是少儿编程教学中非常重要的工具，但长期以来也存在一个明显的问题： 作品容易做，批改很难规模化。 一名学生制作一个 Scratch 项目，老师打开作品运行几分钟并不困难。但如果一个班有 30 名学生，一个老师同时负责多个班级，再加上每个项目需要检查多个要求，人工评价的成本会迅速增加。这也是为什么传统 OJ 很容易实现自动评分，而 Scratch、游戏、动画等项目式作品长期依赖教师人工查看。随着 Scratch 项目结构分析、虚拟机运行、自动化测试和 AI 技术的发展，这一问题正在发生变化。例如，一个 Scratch 自动判题系统可以同时从两个层面进行评价。

第一层：检查程序“怎么写”

系统可以分析 Scratch 项目的程序结构：是否使用了变量；是否存在循环；是否创建了自定义积木；事件之间是否建立了正确关系；是否使用了克隆；角色和背景是否符合任务要求。这属于静态分析。

第二层：检查程序“实际做了什么”

仅仅看积木结构还不够。两个看起来完全不同的程序，有可能实现相同的效果；一个积木结构看起来正确的项目，真正运行以后也可能出现错误。因此还需要实际运行作品。例如系统可以自动模拟：点击绿旗；等待若干秒；移动角色；触发键盘事件；制造碰撞；观察变量；检测造型变化；监听声音播放；记录角色位置。然后判断： 程序运行过程中是否真正出现了任务要求的行为。 这属于运行时行为检测。对于项目式编程教学而言，这种评价方式比简单判断“有没有某块积木”更加接近真实学习成果。

六、AI 的价值，不应该是替学生写程序，而是帮助老师看懂学习过程

人工智能进入编程教育以后，很容易让人首先想到： “让 AI 帮孩子写代码。” 但在教学场景中，这可能并不是 AI 最有价值的应用。对于教师而言，更现实的需求是： 怎样快速看懂几十个学生分别做了什么？ 如果自动评测系统已经能够得到大量客观数据，例如：这个项目通过了哪些测试；哪些要求没有实现；在哪个运行步骤出现异常；学生进行了多少次提交；程序从第一次到最后一次发生了哪些变化；那么 AI 可以进一步帮助教师整理这些信息。例如：

该作品主体功能已经完成，角色移动和得分逻辑正确，但碰撞后的生命值变化存在异常。学生已经连续修改了三次碰撞相关程序，建议重点检查广播事件与变量更新顺序。

这与简单输出一个“75分”相比，对教学显然更有价值。 AI 不一定要成为替学生完成作业的人，它完全可以成为帮助教师理解学生学习过程的助手。

七、未来的少儿编程教学平台，应该记录“过程”，而不仅是“结果”

教育部此次“做中学”领航行动特别强调过程性评价，关注学生在探究实践过程中的真实表现和发展变化。这对于编程教学平台提出了新的要求。过去，一个 OJ 平台最重要的数据可能只有：学生提交了一道题；是否通过；用了多少时间；占用了多少内存。但未来，一个完整的编程学习平台还可以记录更多过程信息：学生第一次尝试了什么方案；在哪些测试点反复失败；修改程序之后解决了什么问题；一个 Scratch 项目经过了多少次迭代；哪些知识点已经能够熟练应用；哪些能力仍然需要教师介入。于是，评价不再只是一个最终分数。而可以形成一个完整的学习轨迹： 任务 → 尝试 → 测试 → 反馈 → 修改 → 再测试 → 完成。 对于老师而言，这些信息能够帮助他们真正看到每个学生的学习过程。对于学生而言，系统给出的也不再只是“对”和“错”，而是帮助他们进入下一轮思考。

八、从 OJ 到智能评价：编程教学平台的角色正在改变

我们在建设少儿编程教学平台和 OJ 在线评测系统的过程中，也越来越明显地感受到这种变化。传统代码自动评测依然非常重要。但如果编程教育真正走向项目式、探究式学习，那么平台最终需要解决的问题一定不只是： “这段代码对不对？” 还包括： “这个程序是否解决了问题？” “学生用了什么方法解决问题？” “他在哪里遇到了困难？” “经过修改以后发生了什么变化？” 因此，我们也在尝试把传统 OJ 的自动测试能力进一步延伸到 Scratch 等少儿编程项目中，通过项目结构分析、运行时行为检测、自动化测试和 AI 辅助评价，让更多项目式编程作品也能够获得及时、客观而有价值的反馈。这并不是为了用机器替代教师。恰恰相反。 自动化应该解决重复检查的问题，把教师的时间重新还给教学。 机器适合检查程序有没有运行、变量有没有变化、碰撞有没有发生。教师真正应该做的，是观察学生为什么这样设计、引导学生发现更好的方案，并帮助他们建立解决问题的能力。

九、少儿编程最终要培养的，不只是“会写代码的孩子”

教育部此次提出，4—9年级学生每学期要完成不少于1个探究实践任务，并通过项目式、探究式等方式开展学习。从更长远的角度来看，这代表的不只是教学形式发生变化。它背后是一种学习目标的改变： 从学习一个答案，走向学会解决一个未知的问题。 而编程恰恰非常适合承担这样的角色。一个想法，可以通过代码变成程序；一个假设，可以通过程序进行验证；一个模型，可以通过运行观察结果；一个失败的方案，可以不断修改并重新尝试。因此，我们希望未来的编程课堂上，孩子提出的问题不再只是： “老师，这段代码应该怎么写？” 而是越来越多地问： “这个问题，我能不能用程序来解决？” 当这种变化真正发生时，少儿编程教育培养的就不只是掌握 Scratch、Python 或 C++ 的学生。而是一群能够发现问题、分析问题、设计方案、动手验证，并愿意持续改进的问题解决者。这或许才是“做中学”给少儿编程教育带来的最大启示。