带过几轮等级考试集训之后我越来越确认一件事Scratch入门阶段的“封神题”不是那些花哨的动画作品而是陶陶摘苹果。这道题几乎把顺序、分支、循环、列表四类核心知识点全揉在了一起题目本身却简单到一句话就能说清特别适合用来检验学员到底是真的理解了编程逻辑还是只是会拖积木。青少年等级考试图形化编程一级、二级的真题里隔三差五就能见到它的身影。很多孩子第一次拿到这道题第一反应是兴奋地开始画苹果树、设计陶陶的角色造型。但真正动手之后才发现难的不是画角色而是怎么把“陶陶最终能摘到几个苹果”这件事准确算出来。这篇文章我会从最朴素的顺序结构版本讲起逐步升级到“列表循环”的标准解法再聊到带交互反馈的动画版最后把学员最容易踩的坑和考试里常见的变体一起梳理一遍。无论你是正在备考的学员还是带学生的老师都可以照着完整做一遍。1. 先看懂题目陶陶摘苹果到底在考什么1.1 题目描述与数学建模陶陶摘苹果的原始题面很简洁大意是陶陶家的院子里有一棵苹果树每年秋天树上会结出10个苹果。陶陶有一个30厘米高的板凳身高是150厘米。当苹果离地高度不超过“身高板凳高度”时陶陶就能摘到。现在给出10个苹果离地的高度要求统计陶陶能摘到几个苹果。我特意把题面重新组织了一遍因为它正好对应编程里的“输入-处理-输出”三步。题目给定的10个苹果高度就是输入判断规则就是处理过程最终要输出的则是摘到的苹果数量。把这件事抽象成数学表达式会更清晰设陶陶身高为h板凳高度为b某个苹果离地高度为a那么能摘到的条件是 h b a。成立一次计数就加1。下面这个表格把输入、变量和规则拆开了方便初学的孩子对照项目含义示例值h陶陶的身高150 cmb板凳的高度30 cmhb陶陶伸手能达到的最大高度180 cma单个苹果离地高度100~200 cm判断规则苹果高度 a 是否 hb例如 170 180能摘到教学时我强调得最多的一个关键点是不要把“板凳”“身高”当成两个独立变量反复去比较而是先算出陶陶伸手能达到的最大高度也就是 hb然后让每个苹果的高度去和这个最大值比大小。这个简化几乎直接决定了后面积木搭建的简洁程度。如果每个苹果都单独去算身高加板凳再比较代码会冗余也更容易出错。1.2 三个审题陷阱哪怕学员说“我看懂题意了”也常常会在三个地方出错。第一个陷阱是高度比较的方向。题面说的是苹果离地面的高度不是苹果离陶陶手的位置的高度。有些孩子会写出“150 - 苹果高度 30”这类错误不等式把方向搞反了。正确的逻辑不是用身高去减苹果高度而是把身高和板凳加在一起形成“可摘上限”再和苹果高度比较。第二个陷阱是等于号的处理。当 hb 刚好等于 a 时陶陶正好能够到应该算能摘到。所以判断条件必须是 hb a而不是 hb a。这个细节虽然只差一个符号但在严格判分的环境中就是0分和满分的差别。第三个陷阱出现在“最多能摘到几个”这句表述上。个别题面会写“陶陶最多能摘到几个苹果”这并不意味着要去做选择优先摘哪些不摘哪些。因为题目没有设置“摘了这个就不能摘那个”的限制能摘到的都会摘本质仍然是对全部苹果做一次遍历统计。我在正式搭积木之前一定会让学生先在白板上把判断条件写对。代码可以慢慢调条件要是错了后面全是无用功。1.3 动手之前先规划变量Scratch里拖积木之前先把需要用到的变量列出来这个习惯对初学者特别有帮助。陶陶摘苹果这道题最少需要三个变量变量名作用初始值可摘高度存放 hb 的计算结果15030摘到数量统计满足条件的苹果个数0序号列表循环时记录当前读取第几项1有些学员会困惑为什么要单独设一个“可摘高度”直接每次判断时写“150 30 苹果高度”不行吗答案是可以但可读性差而且如果题目改成运行时输入板凳高度你就得在每个判断里都改一次。用变量把“可摘高度”提前算出来整个程序的逻辑就清晰了先是准备阶段再是判断阶段最后是输出阶段。2. 第一版实现顺序结构逐条比较先把逻辑跑通2.1 初始化和询问输入第一版不追求代码精简只求把判断逻辑跑通。我一般要求学员在舞台上创建好变量之后按以下顺序搭积木当绿旗被点击将“摘到数量”设为 0将“可摘高度”设为 150 30询问“请输入第1个苹果的高度”并等待如果 回答 可摘高度那么 将“摘到数量”增加 1重复第4步和第5步一直处理到第10个苹果说“可以摘到 [摘到数量] 个苹果”这套逻辑主要用到Scratch里的“询问并等待”和“回答”两个积木。“询问并等待”是一个交互积木程序运行到这一行时舞台下方会弹出输入框用户输入数字后点击对勾输入的内容就存进“回答”这个内置变量里。需要说明的是“回答”变量不需要手动创建Scratch会自动维护但它的值会随着每一次询问变化所以每次判断都要紧跟在那次询问之后。2.2 十个条件的“笨办法”积木搭法十个苹果就需要写十组“询问-判断”积木。虽然看起来冗长但我刻意不让学员直接跳到循环。原因是先亲眼看懂“重复做同一件事”的过程后面引入循环时他才知道循环到底替代了什么。这十组积木结构上完全一样唯一的区别是“询问”里的提示文字从“第1个苹果”变成了“第10个苹果”。判断部分用到的一律是“可摘高度”和“回答”。这里有一个我强烈建议的操作细节把第一组积木复制成十份之后一定让学员自己手动去改掉每一条“询问”里的编号文字。这个动作看着不起眼却能让人在改文字的过程中潜意识地感受到“这十段东西几乎一模一样明明应该有办法只写一次。”等到讲循环的时候学员的接受度会高很多因为他自己已经产生了“想要偷懒”的念头这时候再给他一个合理的偷懒方式他会非常愿意接受。全部搭完之后运行一遍依次输入10个数字比如100、200、150、140、129、134、167、198、200、111。手算一下可摘高度是180那么100、150、140、129、134、167、111这7个都能摘到。程序说出7就说明这一版逻辑跑通了。2.3 为什么我还要让学员先写笨办法有些同行会觉得顺序结构版太低级不如直接上列表和循环。但按我的经验直接上抽象结构的结果往往是学员确实能把积木拖出来可一旦判断条件变化、苹果个数增加就完全不会改了。顺序结构版虽然笨但它的每一步都对应题面的一句话学员能指着积木说清楚“这是在判断第一个苹果”。这个“能说清楚”比“能拖出来”重要得多。另外顺序结构版也方便调试。如果统计结果多了或者少了直接从第一组判断开始人工模拟手动算一遍答案马上就能定位到是哪一组积木出了问题。这对初学阶段来说是非常有价值的排错训练。3. 第二版实现用列表和循环消除重复代码3.1 列表在这里解决了什么问题顺序结构版跑通之后我会接着问学员一个问题如果树上不是10个苹果而是100个呢顺序结构版就得写100组一模一样的积木这显然不合理。这时候列表就该登场了。可以把Scratch的列表理解成一串带编号的盒子每个盒子里放一个数据。苹果的高度数据可以提前存进列表然后用循环从第1项一路遍历到第10项每一项执行同样的判断。判断逻辑只写一次却执行了10次。这就是“数据与操作分离”的雏形也是很多复杂作品的基础。3.2 完整积木逻辑录入、遍历、判断、计数第二版的搭建可以拆成四步。第一步创建列表“苹果高度”把10个数据录入进去。录入有两种常见方式一种是用“将 100 加入 苹果高度”这类积木把数据直接写在代码里另一种是用询问让用户运行程序时手动输入。如果是准备等级考试我建议用第一种因为数据是题目给定的提前写死在列表里更稳定完全避开手动输入可能出现的格式问题。第二步设置初始变量。把“摘到数量”设为0把“可摘高度”设为15030再把“序号”设为1。这个“序号”变量用来指定当前读取列表的第几项。第三步重复执行直到“序号 10”。循环体内先取出“苹果高度”的第“序号”项判断它是否小于等于“可摘高度”如果是就把“摘到数量”增加1。最后一步非常关键一定要让“序号”增加1。漏掉这一步程序会永远停留在这个判断上形成死循环列表第1项被反复判断计数疯狂上涨。第四步循环结束之后让角色说出“可以摘到 [摘到数量] 个苹果”。这里有个很容易混淆的点Scratch提供了多种循环积木这道题适合用“重复执行直到”而不是“重复执行10次”。原因在于“重复执行直到”把结束条件写得特别明确当数据量从10变成20时只需要把“序号 10”改成“序号 20”对初学者来说更好理解。而“重复执行10次”虽然也能实现但要额外处理序号逻辑上绕了一层。3.3 判断条件的边界 还是 这一步我每次都要专门停下来强调。在Scratch的运算积木里“”表示小于等于。如果误用成“”当苹果高度恰好等于可摘高度时陶陶本可以摘到程序却会判为摘不到。边界条件在等级考试里经常被用来设置干扰项题目给出的数据很可能就包含一个“刚好等于可摘高度”的苹果用来检验你有没有把等号考虑进去。还有一个容易忽略的点如果题面把身高或板凳高度也作为运行时输入的变量而不是固定数值那么“可摘高度”这个变量在初始化时要写成“身高 板凳高度”的加法表达式不能直接写成180。这样后续即使题目把板凳高度从30改成50程序依然正确。下面用表格对比一下第一版和第二版的差异方便课程设计时直观参考维度顺序结构版列表循环版判断积木数量10组1组数据修改方式改代码改列表可扩展性每加一个苹果加一组积木改循环结束条件初学者的理解难度低中调试便利度适合逐条人工核对适合整体观察4. 第三版进阶把“算题”变成“摘苹果”——动画与克隆4.1 舞台布局与角色设计前两个版本本质上是个计算器结果对但视觉效果很差。到了进阶阶段可以把它真正做成一个小游戏树上挂着10个苹果陶陶站在树旁点击绿旗后陶陶开始判断摘到的苹果从树上消失或者切换成被咬了一口的造型。舞台布局要做三件事选一张合适的院子背景创建一个陶陶角色再创建一个苹果角色。苹果不需要复制出10个角色直接用克隆体生成就行。舞台上只需要放一个“苹果”作为原型运行时通过Scratch的“克隆自己”积木产生10个副本这样既简洁又方便统一管理。4.2 克隆体编号与坐标映射这个版本里列表依然保存每个苹果的高度数据但每个克隆体要代表一个特定编号的苹果。关键点在于克隆体必须知道自己是第几个苹果。做法是给苹果角色创建一个“苹果编号”变量然后在生成克隆体的循环里先把“苹果编号”设为当前的循环次数再执行“克隆自己”。每个克隆体启动后读取自己的“苹果编号”就可以根据编号去列表里拿到对应的高度数据。真正让动画生动起来的是坐标映射。Scratch舞台的y坐标范围大约是-180到180苹果离地高度则是100到200左右的数值不能直接用。我通常会先设定一个“地面y坐标”比如-150然后用“地面y坐标 (苹果高度 - 100)”来换算苹果的显示位置。这样高度越大的苹果就显示在越高的位置视觉上看起来和题目描述完全一致。判断摘取逻辑可以放在陶陶角色上陶陶根据列表数据依次判断凡是满足“苹果高度 可摘高度”的编号就向对应编号的苹果克隆体广播一个“摘取”消息。苹果克隆体收到消息后判断自己的“苹果编号”是否和消息里携带的编号一致如果一致就播放音效并切换造型或隐藏。这种“广播-接收”的写法是Scratch动画开发里非常经典的模式学会了以后做其他作品也都能用上。4.3 反馈设计造型切换、音效与亮度检测有些老师喜欢在这个版本加入更丰富的反馈比如让摘下来的苹果变暗、显示得分飘字或者加一段陶陶移动的动画。这里有一个非常容易踩的坑如果克隆体收到消息后同时执行“隐藏”和“停止其他脚本”会导致下一次点击绿旗时克隆体无法正常显示。正确做法是克隆体启动时先执行“显示”摘取后才“隐藏”。而且每次点击绿旗都要先执行“删除此克隆体”相关的清理逻辑或者重新生成一批克隆体时先让旧的消失干净避免新旧苹果叠加。如果想让交互更有意思还能用Scratch的“亮度”检测积木做入场动作。比如玩家用手电筒或环境光改变舞台亮度程序检测到亮度变化后才让陶陶开始摘苹果。这个玩法适合课程展示和创意编程活动但在等级考试中不推荐因为判分环境通常不提供额外外设而且亮度传感器的稳定性受环境影响较大容易让程序行为变得不可预期。5. 学员最容易踩的坑与完整排查思路5.1 列表索引从1开始带来的混乱Scratch的列表项从1开始编号这一点和Python等文本编程语言从0开始完全不同。学员写循环时如果循环次数设置成10但起点用了0或者结束条件多算了一次最后就会访问到第11项而第11项根本不存在程序会报错或者给出错误结果。排查这类问题最快的方法是在循环体内临时加一个“说 列表的第(序号)项”积木运行一遍看看序号是从1递增到10还是跳到了11。如果发现序号跑出了范围就检查循环变量的初始值和结束条件。这个“把过程可视化”的排错思路可以套用到几乎所有Scratch程序里。5.2 计数器与列表的清零问题这是最隐蔽的错误之一。“摘到数量”变量如果只在角色刚创建时设为0而列表数据没有清理第二次运行程序时计数会从上一次的结果继续累加导致结果翻倍。我曾经让学员连续点三次绿旗每次输入相同数据结果第一次说7第二次说14第三次说21。学员自己也觉得很奇怪明明什么都没改。问题就出在“摘到数量”没有在绿旗点击后清零。完整的初始化应该是三个动作摘到数量设为0序号设为1列表如果使用了“询问加入”的方式录入那还要在开始录入前先把列表清空。很多学员只记得清“摘到数量”忘了清列表于是列表越积越长判断也会出错。5.3 阻塞式询问与输入格式问题Scratch的“询问并等待”是阻塞积木意思是程序运行到这里会停下来一直等用户输入并点击对勾才继续。如果程序里连续出现多个“询问并等待”用户必须一个一个回答完程序才能继续往下走。这本身不是问题但初学者容易因此误以为“回答”是全局的、不会被覆盖的实际上每次新的询问都会把上一次的回答冲掉。输入格式是另一个坑。如果用户在输入框里输入了文字那么在后续数字比较时Scratch往往会把它当成0处理或者直接比较失败。所以当“回答”要参与数字运算或比较时最好先确认输入内容是数字。等级考试中我通常建议直接使用列表预置数据只有在演示交互功能时才使用询问这样能把输入格式问题完全挡在门外。5.4 一个典型的错误排查全流程我带学员时经常展示这样一个场景程序跑完说“可以摘到12个苹果”但手工计算明明只有7个。这时候我会带着学员走一遍完整的排查流程。第一步检查列表项数量。在程序里临时加一句“说 列表的项目数”如果显示20说明列表没有清空上一次运行的数据混了进来。第二步检查循环起点。让程序说出“序号”的初始值如果是0那么第一次判断访问的是第0项Scratch会把它当作空值处理计数就会少算或者多算。第三步检查判断条件。把“可摘高度”的输出显示出来看它是不是等于180。如果加法表达式拼接得不对比如把“150 30”写成了字符串“15030”结果就会完全错乱。第四步检查累加时机。看看“摘到数量增加1”是不是被放进了错误的“如果”分支里。有时候学员把增加1的积木放在了判断外面于是不管能不能摘到每个苹果都让计数器加1。这套流程做完95%的问题都能暴露出来。我建议所有学员都记住这个排查顺序数据、循环、判断、累加。按照这个顺序走比东改一下西改一下要高效得多。6. 当题目变形时从Scratch到Python的迁移与考试应对6.1 Python等价实现陶陶摘苹果的价值不止于Scratch。学员进入Python阶段之后我会经常让他们把这套逻辑翻译成文本代码。拿Python来写逻辑几乎是Scratch列表版的一比一映射apple_heights [100, 200, 150, 140, 129, 134, 167, 198, 200, 111] bench_height 30 body_height 150 reach body_height bench_height count 0 for h in apple_heights: if h reach: count 1 print(count)这里的for循环、if判断、计数器累加和Scratch里的“重复执行”“如果那么”“将变量增加1”一一对应。我经常拿这道题作为图形化编程到文本编程的“桥梁题”因为学员在Scratch里已经理解了逻辑翻译成Python只是换个语法外壳接受度特别高。6.2 输入进阶空格分隔的数据如果题目要求输入10个苹果高度并且数据之间用空格隔开Python里可以用split方法把字符串拆成列表这也是等级考试Python方向常见的输入处理方式data input().split() apple_heights [int(x) for x in data]这段代码先把一行输入按空格拆成若干字符串再逐个转成整数存进列表。对应的Scratch理解则是用户一次性输入一串文本程序通过“分割字符串”积木把它变成列表项。理解了数据存储在列表里这件事后面学各种文本编程语言的输入处理都会顺畅很多。6.3 等级考试里的变体与应对策略这类题目在青少年等级考试图形化编程一级、二级中很常见我总结过三种主要变体。第一种修改比较条件。把“陶陶摘苹果”改成“小明够书架”把身高、板凳高度换成书架层高逻辑完全一样只是换了个场景。应对策略是把题目里的实际意义剥离掉提炼出“上限值”和“被比较值”两个抽象概念。只要找到这两个概念不管题面怎么换场景代码框架都不用变。第二种把固定数据改成运行时输入。题目要求用询问让用户依次输入10个苹果高度和板凳高度一起参与计算。这时建议用列表存储输入的数据避免每一次判断都临时询问导致代码结构混乱。这里也正好考察学员对“阻塞式询问”的理解以及“回答”变量会被覆盖的意识。第三种增加统计维度。比如不仅要统计能摘的总数还要找出能摘的苹果里最大高度是多少。这时只需在判断成立的内部再加一个嵌套判断“如果当前高度 已记录的最大值那么 将最大值设为当前高度”。这个操作能很好地把“分支嵌套”的用法带出来是进阶的好题目。6.4 继续扩展从这道题延伸到排序和九九乘法表学员一旦掌握了“列表循环判断”这个铁三角组合很多经典题目都可以开始做了。九九乘法表就是双重循环嵌套的入门案例冒泡排序则是列表操作的高级应用。陶陶摘苹果是这一切的开端因为它用最少的变量、最简单的条件完成了最核心的编程结构训练。我对这道题还有一个特别的执念它天然带有生活场景能让学员直观地感受到编程不是在“做数学题”而是在解决“陶陶到底能不能摘到苹果”的真实问题。这种把抽象逻辑和具体场景绑定在一起的学习方式比单独讲一百遍“什么是循环”都有效。教学时我会让学员轮流当“陶陶”自己报出一个身高和板凳高度然后让其他同学用程序帮他算能摘到几个苹果。课堂活跃度一下就上来了而且大家对条件的理解也更深。在Scratch教学这条路上陶陶摘苹果这道题我至少带几十个学员做过。每个阶段的孩子都会给出不一样的解法有人用顺序结构硬算有人第一时间想到列表有人在动画版里折腾克隆体玩得不亦乐乎。我从来不会说哪种解法是唯一正确答案但我一定会要求每个学员解释清楚自己的每一个判断条件为什么这样写。能把条件说清楚这道题才算真正吃透了。最后分享一个教学小技巧如果学员的列表版程序总在累加时出错可以让他用纸笔把循环执行三次的过程完整写下来。不写代码只写“第1次取到几号苹果、值是多少、是否满足条件、当前总数是多少”。这个看起来原始到不行的“人肉模拟”过程往往比反复改代码更能帮他建立对循环和变量变化的理解。等他能在纸上推演正确再回到Scratch里修改积木问题往往会自己消失。