Scratch-陶陶摘苹果这个题目在少儿编程圈里算是“元老级”的经典案例了。它最早源自信息学奥赛的一道入门算法题后来被大量图形化编程教材和等级考试反复采用尤其是在青少年图形化编程一级考试里你经常能在真题和模拟卷里看到它的身影。我带着学生做这个项目时发现很多孩子搭积木搭得很开心但一碰到“判断苹果够不够得着”这个环节就卡住了有的是变量设置不对有的是把“身高加板凳”这个关键条件给漏掉了。这篇就把我带课过程中的完整思路、积木安排和踩坑记录整理出来给正在带娃学Scratch的家长、准备等级考试的孩子还有刚入门的信息科技老师做个参考。内容不绕弯子直接讲怎么拆题、怎么选方案、怎么一步步搭出来。1. 项目拆解这道经典题到底在考什么1.1 题目背景和适合的人群陶陶摘苹果的原始版本是一道考查顺序结构、循环结构和条件判断的入门算法题陶陶家的苹果树上有10个苹果每个苹果离地面有一定高度陶陶伸直手能碰到的高度是一个固定值她还有一个30厘米高的板凳帮陶陶算一算最多能摘到几个苹果。到了Scratch里这道题有了各种可视化版本但核心逻辑一点没变仍然是“输入或随机生成10个苹果高度输入陶陶身高判断每个苹果是否在陶陶伸手可及的范围之内最后统计数量”。这类题目非常适合用来检验初学者是否真正理解了Scratch的三大基本控制结构所以在等级考试一级中特别高频。它适合三部分人一是准备参加图形化等级考试的孩子二是想用项目式学习带娃的家长三是需要一套完整课例的信息科技老师。完成这个项目后孩子基本能独立使用变量、列表、随机数、条件判断和循环算是从“照着搭积木”走向“自己设计算法”的一个分水岭。1.2 顺序、分支、循环三种结构一个都不少这道题最值钱的地方在于它把一个看起来很简单的故事拆成了三种编程结构的组合。顺序结构体现在整个流程是固定的初始化数据生成苹果判断每一个苹果统计结果输出答案。这个流程不能乱你不能还没生成苹果就去判断也不能还没判断就统计。对刚接触编程的孩子来说“程序按顺序执行”这件事看起来简单但实际搭积木时经常有人把“初始化”放在最后导致一运行就是上一轮留下的旧数据。分支结构体现在“判断够不够得着”这个环节如果陶陶身高加上板凳高度大于等于苹果高度就摘到否则摘不到。在Scratch里对应的是“如果...那么...否则”积木块。这个分支看起来只有一个条件但很多孩子会漏掉“等于”的情况恰好够到算不算摘到按常规题意算所以判断条件要写成“ ”而不是“”。循环结构体现在“把10个苹果逐个判断一遍”。无论是用列表遍历还是用克隆体逐个处理本质上都是重复执行同一段判断逻辑10次。这里用的是“重复执行直到”或者“重复执行10次”取决于你选择哪种设计方案。所以说这个项目就是热词里常提的“顺序分支循环实例”一个项目同时覆盖三种控制结构比单独做十个“小猫走路”之类的小例子要高效得多。1.3 两种主流实现路线怎么选我在实际教学中发现同一个题目孩子会用两种完全不同的思路来搭第一种是“算法模式”用列表或十个变量存苹果高度输入陶陶身高通过循环遍历把所有苹果判断一遍最后说出结果。这种方案更贴近原始算法题和等级考试真题代码逻辑严谨画面相对简洁适合作为考试复习和算法思维训练。第二种是“游戏模式”把苹果做成可点击的角色或克隆体陶陶在舞台上移动碰到苹果就触发判断够得着就摘走够不着就提示。这种方案画面丰富、互动性强孩子做起来更有成就感适合日常项目课或者比赛作品。两条路线我都带学生做过。我的建议是如果目标是等级考试就用算法模式因为考试时环境相对受限考的是逻辑清晰度而非画面效果如果目标是培养兴趣或做作品集就用游戏模式。这两种方案的共同核心是那一个判断条件学会了这个条件其他都是锦上添花。下面我把两种方案的细节都拆开讲清楚。2. 搭积木前的准备角色、坐标和“高度换算”怎么设计2.1 素材准备角色画法和造型建议做这个项目不需要导入复杂素材Scratch自带的矢量绘图就能搞定这也是它适合教学的原因之一。陶陶这个角色我建议用最简单的人形一个圆形头一个长方形身体两条线做手臂两条线做腿。不需要画得很精细关键是让孩子理解“角色”只是算法的载体真正起作用的是背后的变量和判断逻辑。如果你想省事也可以直接从Scratch角色库里选一个“Bear”之类的动物角色只要孩子能区分是哪个人物在摘苹果就可以。苹果角色最简单的做法是画一个红色圆形加一个浅绿色小长方形当果柄。如果想把效果做得精致一点可以给苹果做两个造型一个正常状态的苹果一个“被摘掉”的状态。摘掉时切换到第二造型同时做一个缩小或变暗的效果。板凳这个角色是可选的。严格来说原题里板凳高度只是一个数值不需要真的画出来。但从可视化角度看椅子上放一个板凳能帮孩子直观理解“身高板凳”的含义。板凳画法就是一个长方形加四条腿放在陶陶脚下用“移到”积木跟住陶陶即可。我提醒一点角色数量不用贪多。一个简单的角色配上正确的逻辑远比一个精美的角色配上混乱的代码有价值这也是Scratch作品评审时的常见标准。2.2 用变量代替“乱跑的数字”变量设计的核心思路很多孩子在做这个项目时最大的障碍就是不知道哪些数字需要存成变量。我给他们的口诀是会变化的数字就存进变量。这个项目里必须存进变量的有四个陶陶身高输入或随机生成后面所有判断都要用到它。板凳高度题目固定值是30厘米但最好也存成变量方便后续修改参数观察效果。摘到数量每判断成功一个苹果就加1。苹果高度这是最关键的数据既可以用十个独立变量也可以用列表里的每一项。为什么非要用变量我们可以做个生活类比变量就像贴了标签的收纳盒。如果你把陶陶身高这个数字直接写死在积木里一旦想改成另一个数值就要去翻无数个积木块如果把它存在“陶陶身高”这个盒子里所有积木只要看见这个盒子就能自动取到最新值。对孩子来说这个类比比讲“内存”“存储”好懂一万倍。变量命名的技巧是“一看就懂”。我见过有孩子建了a、b、c三个变量两天后再看代码完全不记得分别代表什么。一定要用“陶陶身高”“苹果高度”“摘到数量”这种完整名称虽然搭建时打字多一点但后续调试和给别人讲解时会轻松太多。2.3 苹果高度到舞台坐标的换算为什么判断时别用坐标Scratch舞台纵向坐标范围是-180到180而题目里的苹果高度是100到200厘米这两个数值口径不一样不能直接拿来比较。所以我们需要一个映射公式把“厘米高度”转换成“舞台y坐标”。我常用的映射方式是苹果显示的y坐标等于“苹果高度减去90”。这样当苹果高度是100厘米时y坐标是10位置在舞台中部下方一点点当苹果高度是200厘米时y坐标是110位置明显更高。这个映射的好处是100厘米和200厘米这两个边界值算起来都是整数而且苹果不会跑到舞台边缘外面去。但这里有一个特别容易犯的错误直接用y坐标作为判断依据。比如孩子看到某个苹果在y60的位置就直接写“如果y60就摘不到”这种写法看起来方便但实际上把两个体系搞混了。你拿苹果的视觉坐标去跟陶陶的身高数值比单位都不统一结果就是改参数时到处碰壁。正确做法是视觉上让苹果显示在对应坐标但判断时使用“苹果高度”这个变量本身。也就是说“苹果高度”负责逻辑判断“y坐标”只负责展示位置。这两个职责分开程序的可维护性会高很多孩子也不会被“为什么苹果看着很高却摘不到”这种问题绕晕。3. 核心实现从“考试标准”到“游戏手感”3.1 方案A列表加循环判断考试和算法思维优先如果你是为了等级考试复习我强烈推荐这一版因为它最接近真题的解题逻辑而且不需要复杂的克隆体技术。整个程序流程分五步第一步初始化。绿旗被点击时把“摘到数量”设为0把“板凳高度”设为30清空“苹果高度”列表。这一步看似琐碎但漏掉它会出现一个很经典的bug每次点绿旗上一次的苹果数据和统计结果还残留在变量里。第二步生成苹果高度数据。可以用“重复执行10次将随机取100到200加入苹果高度列表”来做。如果是考试环境有时候要求“输入10个苹果高度”那就用“询问”积木加“重复执行”来完成输入这里根据题目要求灵活处理。第三步输入陶陶身高。用“询问 请输入陶陶身高 并等待”然后把“回答”存入“陶陶身高”变量。要注意的是考试真题里输入通常是第一行是10个苹果高度第二行是陶陶身高所以如果你要完全还原输入过程需要先循环10次询问高度再单独询问一次身高。第四步核心循环判断。用“重复执行10次”循环变量i从1到10每次取出列表第i项判断“第i项 陶陶身高 30”是否成立。成立就把“摘到数量”增加1。这里还有一个细节值得教给孩子你可以把“陶陶身高 30”这个计算结果单独存成一个变量“能够到的高度”既不重复计算也让逻辑更清晰。第五步输出结果。用“说 我摘到了 (摘到数量) 个苹果”的积木块告诉观众结果。如果想把结果拼成更有信息量的句子可以用“连接”积木把文本和数字串起来。这套方案里列表的使用是关键。列表可以理解成一排带编号的储物柜第1格放第一个苹果的高度第2格放第二个苹果的高度循环时每次打开一格取数字。对孩子来说列表比循环嵌套更容易理解。我再分享一个调试小技巧在循环判断时可以用“说”积木把每次比较的结果打印出来比如“第3个苹果高度156够不到”。这样运行一遍就能看出来判断逻辑对不对比盯着变量面板猜测要直观得多。3.2 方案B克隆体加点击交互孩子更喜欢如果你带的孩子对密密麻麻的列表和循环提不起兴趣那就走游戏路线。这个方案的核心是用克隆体生成10个苹果每个克隆体自带一个“我的高度”变量陶陶移动过去进行判断。实现路子是先用“当绿旗被点击”建一个“苹果本体”把它隐藏然后用“重复执行10次”创建克隆体。每个克隆体生成时把“我的高度”设为随机100到200再根据这个高度算出y坐标移到对应位置并显示出来。陶陶角色的控制可以用方向键这是大多数孩子熟悉的操作方式。陶陶碰到苹果时用“碰到苹果”积木触发判断判断内容依然是“陶陶身高30大于等于对方的高度”。这里的关键是从克隆体身上读取“我的高度”这个变量。写成积木大概是当陶陶碰到苹果克隆体时“如果 陶陶身高 30 我的高度”那么这个苹果克隆体广播“摘到了”然后隐藏自己让“摘到数量”加1否则就说“还差一点”苹果克隆体做一个摇晃动画。为什么游戏方案也要用“我的高度”而不用随机数因为每个克隆体生成时的随机数如果不保存之后判断时你根本不知道这个苹果到底多高。很多孩子在这里犯迷糊生成完克隆体后才发现没法判断最后只能把所有苹果设成同一个高度。保存变量这个动作是克隆体项目的核心经验。这套方案孩子做起来兴致非常高因为可以实时看到陶陶在舞台上跑来跑去够得着的苹果会消失够不着的会摇头。但是要提醒孩子画面越花哨代码越容易乱所以要把“多媒体反馈”和“核心判断”分区摆放积木不要混在一起。3.3 变量还是列表针对不同阶段的选型建议等级考试里有一部分孩子还没系统学过列表如果用列表方案会有点吃力。没关系你完全可以用十个独立变量代替列表名字就叫“苹果1高度”到“苹果10高度”。十个独立变量的写法稍微繁琐一点生成时用十个“设定”积木分别赋值判断时用十组并列的“如果”积木或者用“重复执行”配合“如果...那么”依次讨论每一个。这种写法不够优雅代码很长但每一步都清晰直白对一级阶段的孩子来说其实是更稳妥的。反过来如果孩子已经学过列表我建议用列表方案理由是代码量小、扩展性好。比如你想把10个苹果改成20个用列表方案只需要把循环次数改一下用十个变量方案就要再复制粘贴十组积木非常痛苦。我的建议是备考阶段以孩子熟悉的方案为准不要临时换新方法日常练习阶段优先用列表方案因为它是从基础向进阶过渡的重要技能点。两个方案都试一遍孩子对“数据如何存储”这件事的理解会深很多。4. 分步搭建流程完整还原一个能跑的陶陶摘苹果4.1 新建变量与列表完成初始化积木块下面我以“列表循环判断”的算法版为主线带你完整搭一遍。先打开Scratch新建这些变量陶陶身高、板凳高度、能够到的高度、摘到数量。再新建一个列表名字叫“苹果高度”。第一段积木是初始化放在“当绿旗被点击”的下面。依次做四件事把“摘到数量”设为0把“板凳高度”设为30删除“苹果高度”列表的全部项目把“陶陶身高”和“能够到的高度”也都设为0或者留着等待后续输入。这段初始化逻辑孩子们经常漏。有一次我的学生把“删除列表全部项目”漏掉了导致第一次运行生成10个苹果第二次运行又追加10个列表里变成20项循环判断只跑10次结果怎么都不对。后来我让他把初始化积木放在最前面问题立刻消失。这个教训我后面还会详细说。4.2 生成10个苹果随机高度和列表的配合初始化完成后生成苹果数据。用“重复执行10次”循环在循环体内做两件事将“随机取100到200”加入“苹果高度”列表把小变量“临时高度”设为刚才生成的数方便后续使用。这里有个小坑Scratch的“将随机数加入列表”积木是把一个随机生成的数字直接丢进列表但你接下来如果还要用这个数字去设置苹果的位置需要把它同时存进一个变量。很多孩子只把随机数加进列表回头想用这个数时就找不到了。所以我的习惯是先用“临时高度”变量接住随机数再把这个变量加入列表这样后续积木可以直接引用“临时高度”。如果你希望苹果真实显示在舞台上跟着做一个“显示苹果”环节每加入一个列表项就在舞台上克隆一个苹果角色并根据“临时高度”设置它的y坐标。注意本体要隐藏因为本体一旦显示会重复出现在舞台上。4.3 核心判断为什么是“身高加30”不是“身高”接下来是重头戏判断逻辑。在循环之前先把“能够到的高度”这个变量设为“陶陶身高30”。这个预处理很关键因为10个苹果的每一次判断都要用到这个数值提前算好可以避免在判断积木里写一大串运算。然后开始循环判断用一个循环变量i从1数到10取出“苹果高度”列表的第i项如果“第i项 能够到的高度”就把“摘到数量”加1否则什么都不做或者加一个“没摘到”的提示。这个判断条件的形式我见过很多孩子写反写成“能够到的高度 第i项”。两者的区别在于前者是“苹果够得着我摘得到”后者是“苹果比我高我摘不到”逻辑正好相反。为了帮孩子记牢我喜欢用生活中的例子你站在30厘米的板凳上身高加板凳是135厘米能不能拿到150厘米高柜子上的东西当然不能因为135小于150。所以判断条件应该是“苹果高度小于等于能够到的高度”。这里“等于”也别漏。题目里通常是“碰到苹果苹果就会掉下来”身高正好等于苹果高度时算摘得到所以用“”而不是“”。4.4 摘取反馈和收尾让作品从“能算”到“能看”纯算法版可能运行结束就在舞台上说一个数字孩子会觉得不够好玩。为了兼顾考试和体验可以在每判断一个苹果成功后让对应编号的苹果说一声“摘到了”再做一个消失动画。具体做法是在循环里判断成功后先广播“摘到第i个苹果”然后让苹果角色收到广播后缩小或隐藏。如果你不想用广播还有更简单的办法直接把苹果角色复制10份分别命名为苹果1到苹果10然后在循环判断里直接操作“苹果i”。但这样代码会非常冗长不推荐作品里用。广播是Scratch里解耦的好工具值得从小项目开始练。最后别忘记结束环节“说 陶陶一共摘到了 结合 摘到数量 结合 个苹果”。如果想让作品更有仪式感可以加一个“全部摘完”的背景切换或者播放一段音效。音效在Scratch里可以用“播放声音Pop”之类的内置音效不需要导入外部文件。还有一个自己实测发现的小技巧判断完10个苹果后用“询问”积木问用户“再来一次吗”如果回答“是”就广播重新开始。这个小设计让作品从一次性的演示变成了可循环的小程序孩子们展示给同学时效果会好很多。5. 孩子最容易踩的坑调试实录与排查清单5.1 常见问题速查表在做这个项目的过程中我整理了一个高频问题速查表按出现频率排序。下面这张表基本覆盖了孩子独立完成时可能遇到的绝大多数问题。问题现象可能原因解决办法点绿旗后列表里不断累积旧数据初始化时没有“删除列表全部项目”在初始化阶段先清空列表摘到数量永远是0判断条件写反了检查“”方向确认是苹果高度小于等于能够到的高度苹果显示位置很乱没有把苹果高度换算成y坐标用“y 苹果高度 - 90”做映射运行结果和手动计算对不上漏掉了“板凳高度30”确认“能够到的高度”包含了身高和板凳高度克隆体出现好几个重复苹果本体没有隐藏把苹果本体隐藏只保留克隆体显示循环判断只处理了第一个苹果没有使用循环变量i去取列表第i项检查“重复执行”里的列表索引是否用了i程序运行很慢像卡住了一样等待时间设置太长或循环里放了不必要的等待把等待改为0.2秒以内或移到循环外面角色说话内容显示不全连接积木使用不当用“连接”积木逐层拼好字符串再放到“说”里这张表是典型的“经验表”孩子自己做不出来的时候对照着排查能省很多时间。我通常打印出来贴在教学电脑边上让孩子先自己查原因再问我效果比直接告诉他答案要好得多。5.2 调试技巧用“说”积木和变量监控看到问题所在Scratch虽然不像Python那样有控制台日志但“说”积木就是最好的调试输出工具。我有段时间要求学生在关键节点加“说”积木把变量值打出来效果非常显著。具体做法是在生成苹果之后加一句“说 第1个苹果高度是 结合 苹果高度列表第1项”在每次判断成功之后加一句“说 判断到第 i 个苹果结果是摘到了”。这样运行一次你就能看到程序每一步在干什么而不是只看到一个最终答案。还有一个小技巧把变量面板拖到舞台上勾选“大型显示”变量会变成一个悬浮框。运行时你盯着“摘到数量”和“能够到的高度”这两个变量一旦发现数值不对马上暂停就能定位到是哪个环节出了问题。这种方式对低龄孩子特别友好比“阅读代码”更直观。另外分享一个经验带着孩子调试时不要直接替他把错误改掉而是问他一个问题“你觉得这个变量运行到这一步应该显示多少”让他先猜再运行看结果对不上再找原因。这个过程就是在培养程序员的调试直觉也是Scratch教学最有价值的部分。5.3 典型bug复盘判断条件写反了我印象最深的一次是一个四年级学生搭完程序运行后陶陶“摘到”的全是最高处的苹果低处的反而摘不到。我让他把判断条件念出来他念的是“如果苹果高度 能够到的高度那么摘到数量加1”。问题一目了然他写反了。这个bug的微妙之处在于程序能正常运行不报错有时候甚至看起来“很有逻辑”苹果很高就摘到不是很奇怪吗但孩子因为太投入反而看不到这个荒谬。我当时没有直接纠正而是让他拿尺子在桌上比划他自己身高140厘米假设站在30厘米板凳上伸手最高够到170厘米。桌上放一个150厘米的标志物他能不能碰到他说能。我又问150大于170还是小于170他说小于。我接着问那“苹果高度大于等于能够到的高度”这个条件对不对他这才恍然大悟。这个案例说明很多逻辑错误不是孩子不懂而是符号表达和自然语言之间存在差异。对初学者来说把判断条件用自然语言先写出来再翻译成积木是避免这种错误的最好方法。这也是我在教学中一直强调的先写字再搭积木。6. 怎么往深处走从摘苹果到算法思维的进阶路线6.1 加需求让项目从“会做”变成“有想法”基础版做完后我会让孩子自己提需求把项目扩展成更丰富的作品。常见的扩展方向有几个都是课堂上实践过的。第一个是加倒计时。用“计时器”积木或“重复执行直到”配合一个“剩余时间”变量让游戏有紧迫感。比如60秒内看能摘多少苹果。这需要把一次性循环改成“持续检测”判断逻辑要放在“重复执行”里而不是只做10次。第二个是加关卡。第一关苹果高度范围100到150第二关150到200第三关120到200同时加快陶陶移动速度。改起来只需要把随机数范围变成变量每次过关时更新这个变量即可核心判断条件完全不用动。这个扩展能让孩子理解“参数化设计”的价值。第三个是加分机制。摘一个苹果得10分没摘到扣5分最终比谁分数高。这涉及到新的变量和更复杂的分支逻辑非常适合作为进阶练习。不过提醒孩子加分减分不要影响“摘到数量”的统计两者的逻辑要分开。这些扩展看起来花样很多但核心仍然是那一个判断条件。孩子做完这些扩展后会慢慢意识到所谓复杂的游戏本质上都是“基础逻辑丰富反馈”的组合。6.2 串联进阶知识点九九乘法表、冒泡排序与更复杂的逻辑陶陶摘苹果做完之后学习路径可以很自然地往两个方向延伸。一个方向是“嵌套循环”典型代表是Scratch里的九九乘法表代码。九九乘法表需要两个循环变量分别控制乘数和被乘数是理解循环嵌套的经典入门任务。做九九乘法表的时候可以回头对比陶陶摘苹果里的单层循环让孩子体会“循环里套循环”和“循环里做判断”的区别。另一个方向是“数据排序”典型代表是Scratch冒泡排序。冒泡排序需要双重循环和频繁的列表元素交换比摘苹果的“遍历列表”复杂一个量级。但它的基础仍然是“用列表存数据用循环访问数据”这套思维。陶陶摘苹果里“把列表第i项取出来做判断”的动作本质上和排序里“比较第i项和第i1项”是同一种能力。很多家长问我孩子学Scratch是不是就是玩玩我一般用这个例子回答如果孩子能把陶陶摘苹果的列表遍历逻辑理解透再去做冒泡排序会发现排序不过是“列表遍历交换变量”完全不是新知识而是同一个底层能力的组合扩展。这才是学编程的意义所在它练的是拆解问题的能力不是某几个积木的用法。6.3 关于Scratch作品的整理与展示建议孩子做完陶陶摘苹果之后不要急着关掉。我建议做一个“作品卡”内容包括项目名称、核心算法点、操作说明、主要变量表。这张卡既是复习材料也是未来做作品集的素材。等级考试或者升学面试时如果孩子能拿出一份“变量设计合理、逻辑清晰、能讲清楚设计思路”的作品集比单纯说“我会Scratch”有说服力得多。展示作品时教孩子一个套路先演示效果再打开代码区要求他指着每个关键积木解释这个积木在做什么最后讲一讲“我做的时候遇到什么困难怎么解决的”。这种叙述结构不只在Scratch里用以后做任何项目汇报都用得上。所谓的项目经验不是“我做过什么”而是“我做过、遇过坑、我能讲清楚”。陶陶摘苹果虽然小但足够让孩子完整经历这个过程。我在实际教学中发现只要孩子能把“板凳高度、陶陶身高、苹果高度、判断条件”这四件事编成自己的话讲出来这个知识点基本就内化了。有个孩子给同学讲解时用的比喻是“像在游乐场排队身高线够到就能坐过山车”当时我就知道他是真懂了。等他把这句话翻译成“能够到的高度 陶陶身高 板凳高度”时整个项目的教学目标就已经全部达成。