Scratch条件执行语句全解析：布尔逻辑、嵌套与实战避坑

很多人带初学者学 Scratch前面几节课都很顺角色会动、会说话、会换造型孩子兴奋得不行。可一旦讲到控制模块里的条件执行语句进度就会突然卡住。原因不复杂——在此之前所有脚本都是“从上到下一条条跑完”的直线思维而条件积木第一次引入了“脚本要自己做决定”这件事。这一步跨过去孩子才算真正有了编程意识跨不过去后面克隆、广播、变量、列表全都学得磕磕绊绊。所以我在做课程设计时一直把 Scratch 条件执行语句当成整条学习路线上最关键的分水岭它决定了一个学习者是从“搭积木”转向“写逻辑”还是停留在“鼠标点一点角色动一动”。这篇文章我想把这块内容彻底拆开三种条件积木各自的适用边界、六边形插槽背后的布尔值逻辑、几个可以直接抄作业的实操案例、参数阈值怎么调才顺手、以及我在实际带练过程中反复踩到的坑和对应的排查路径。无论你是刚接触图形化编程的新手还是已经带过几轮课的从业者下面的内容应该都能找到可以直接复用的部分。1. 条件执行语句到底在解决什么问题1.1 从“一路到底”到“分岔路口”要理解条件语句的价值得先看清楚没有它的时候脚本有多难受。假设你要做一个键盘控制角色移动的 Demo没有条件判断只能写成“当按下右方向键就 x 增加 10”四个方向键就要挂四段帽子积木每个角色都要重复一遍。脚本会长得像摊开的扑克牌而且只要需求稍微变一下——比如“按住 Shift 时加速”——就完全没法在原结构上叠加了。条件语句把这种“一个触发对应一段固定动作”的硬编码变成了“一个循环里根据当前状态选动作”的软逻辑脚本从多条平行线收敛成一条主干可维护性完全是两个量级。我习惯用生活场景给初学者打比方程序执行就像开车顺序结构是“沿着这条直路一直开”条件结构是“到了路口看红绿灯红灯停绿灯行”。这个类比的好处是能顺手带出一个关键点——判断必须发生在路口而不是开到一半再回头看。对应到 Scratch 上就是条件积木必须放在循环体里或者挂在一个合适的帽子积木下面否则它只会在脚本启动的那一瞬间判断一次之后再不理会。还有一个容易被忽略的事实条件语句本身不产生“动作”它只决定“要不要做动作”。很多新手会下意识地把“如果〈碰到边缘〉那么〈说‘撞墙了’〉”当成一个碰撞事件其实它只是在轮询。真正的事件驱动应该用“当角色被点击”“当接收到消息”这类帽子积木。把“轮询”和“事件”的区别讲透后面写游戏循环时就不会乱。这个区分我在课堂上要反复强调三四次仍然会有人搞混属于典型的认知惯性——人天生倾向于把“条件成立”理解成“事情发生了”。1.2 三种条件积木的适用边界对比Scratch 控制模块里跟条件直接相关的积木其实有三块很多人只记住了“如果…那么”另外两块用得少结果脚本写得又长又别扭。下面这张表是我自己整理的使用场景对照贴在教案第一页积木形态执行特性典型用途常见误用如果〈条件〉那么不阻塞条件为真执行内部积木为假直接跳过循环体内部的状态判断、按键响应放在循环外只判断一次如果〈条件〉那么〈否则〉不阻塞二选一必走一边移动与停止切换、正确与错误提示用来处理三种以上的分支嵌套过深等待〈条件〉阻塞条件为假时整个脚本停在这里等待用户点击、等待角色到位、等待计时器条件永远不成立导致脚本卡死重复执行直到〈条件〉阻塞条件为假时反复执行内部积木倒计时、持续推进直到命中与“等待直到”混淆写成空循环空转第四行的“重复执行直到”严格说也属于条件类控制因为它内部同样挂着六边形插槽判断逻辑和“等待直到”一致只是多了循环体。这块积木最实用的地方在于它天然带“推进”语义——我在做打砖块和跑酷类项目时几乎全靠它来控制“球一直飞直到碰到挡板”。值得单独提醒的是“等待直到”和“重复执行直到”的混淆。两者的判断时机完全相同先判断条件成立就结束不成立就继续。区别只在于“不成立”的时候做什么——前者原地干等后者执行循环体。“等待直到〈计时器 5〉”和“重复执行直到〈计时器 5〉”在没写循环体的情况下效果一模一样都是卡五秒。但如果循环体里写了“移动 10 步”那就变成“一边跑一边等”完全是两种东西。这个区别用一句话总结等待是“停下来等条件”重复执行直到是“边做边等条件”。2. 拆开看条件积木的底层结构与求值逻辑2.1 六边形插槽布尔值被可视化的样子Scratch 最精妙的设计之一就是把“布尔类型”做成了形状约束。六边形的凹槽只能插入六边形的积木而六边形积木的输出永远只有“真”和“假”两个值。这种形状级别的类型检查让初学者根本不可能犯“把数字塞进条件槽”的错误——物理上插不进去。对比一下文本编程里if (x 5)和if (x 5)这个经典笔误图形化在这件事上确实省了很多事。但形状约束只解决了“类型对不对”没解决“逻辑对不对”。六边形插槽里可以放的东西分几类比较运算、、、逻辑运算与、或、不成立、侦测积木碰到边缘、按下空格键、鼠标按下以及布尔类型的变量——如果你勾选了变量的“布尔值”显示方式。这四类东西输出的都是真或假插进条件槽都能用。这里有个细节我建议所有带课的人都提前验证一遍如果六边形插槽留空会怎样。实测下来Scratch 不会报错脚本照常运行只是这个空槽会被当成“假”分支永远进不去。初学者遇到“我明明写了如果…那么角色就是不动”的情况十有八九是插槽空着或者插进去的是个数字积木的残留有时候复制粘贴会留下奇怪的东西。养成“写完之后扫一眼所有六边形槽是不是都填满了”的习惯能省掉大量排查时间。还有一类容易被忽略的布尔来源运算分类下的〈 〉包含〈 〉?。这个积木在做字符串类判断时非常好用比如判断玩家的回答里有没有包含“正确”这个词就不用做精确匹配。它返回的也是布尔值同样能塞进条件槽。我做过一个猜词小游戏判定逻辑就全靠这个积木撑着比一堆等号比较简洁得多。2.2 嵌套与缩进脚本的“读图”能力条件积木是可以套娃的。一个“如果…那么”内部可以再放一个“如果…那么”理论上嵌套层数没有硬限制但实际写起来超过三层就开始难以阅读了——这里说的“阅读”不是给机器看是给人看。Scratch 用缩进和色块宽度变化来表达层级左侧那一条条竖线的长度就是嵌套深度。我在做代码审查是的图形化编程也需要代码审查时第一眼看的不是逻辑对不对而是这个锯齿状轮廓是不是太深了。嵌套过深带来的直接后果是调试困难。假设一个三层嵌套的判定角色行为异常你得一层层往上排查是哪一层的条件出了问题。更麻烦的是Scratch 的脚本区不支持断点没法单步执行只能靠插入“说”积木打日志。所以我的经验是两层以内的嵌套可以接受三层就该考虑拆分了。拆分手段有两个一是用“与”“或”把多个条件合并成一层二是把内层逻辑抽成一个自定义积木自制积木或者干脆用广播把控制权交给另一段脚本。举一个真实的例子。做一个角色在平台上行走的判定逻辑是“如果按下右方向键那么如果没碰到墙那么如果不在跳跃状态那么移动 5 步”。三层嵌套看着就头大。改成“如果〈按下右方向键 与 不成立〈碰到墙 或 处于跳跃状态〉〉那么 移动 5 步”一层搞定而且读起来是一句完整的自然语言“如果按了右键并且既没碰墙也不在跳跃中就移动”。逻辑运算在这里的作用不是炫技是把垂直的嵌套压成水平的表达。2.3 逻辑运算的组合与、或、不成立的取舍与、或、不成立这三个积木是条件语句的放大器但用起来有两类坑。第一类是德摩根定律式的逻辑反转搞错。比如“不成立〈碰到角色 A 或 碰到角色 B〉”它的等价形式是“碰到角色 A 的否 与 碰到角色 B 的否”很多人会错误地写成“不成立〈碰到角色 A〉 与 不成立〈碰到角色 B〉”以外的形式或者把“与”“或”搞反。这类错误不报错只是行为微妙地不对排查起来特别费劲。我的建议是只要用了“不成立”包裹“与/或”就在旁边加一句注释Scratch 支持在积木上右键添加注释把你想要表达的中文写清楚下次回头看能省很多脑力。第二类是求值顺序带来的隐性成本。与和或的两边如果都是侦测积木那么整个表达式每次判断都会把所有侦测跑一遍。侦测积木里碰到颜色是开销最大的一种它需要做像素级比较。如果一个循环里每帧都要对多个角色做颜色检测卡顿就会非常明显。我在一个含有 20 多个克隆体的项目里就栽过这个跟头帧率掉到肉眼可见的级别。解决办法是把开销大的判断往后放、把廉价的判断比如变量比较、坐标范围判断往前放用条件组合做“短路”式的提前排除——虽然 Scratch 不保证短路求值但当你把廉价条件写成外层嵌套时一样能起到筛选作用如果〈x 坐标 -200 与 x 坐标 200〉那么 如果〈碰到颜色 [#ff0000]?〉那么 执行危险动作外层先做数值范围筛选大部分情况下内层根本不会执行到性能立刻回来了。3. 由浅入深的三个实操案例3.1 案例一边界拦截与按键移动的最小闭环这是我认为最适合作为第一课的例子因为它把“循环 条件”的结构压缩到了最小却又包含了一个真实的坑。目标很简单按方向键让角色移动但不能移出舞台。先给出完整脚本结构角色“小球”两个变量速度x、速度y用来存状态当 绿旗 被点击 将 [速度x] 设为 0 将 [速度y] 设为 0 移到 x: 0 y: 0 重复执行 如果〈按下 [右移键]?〉那么 将 [速度x] 设为 5 如果〈按下 [左移键]?〉那么 将 [速度x] 设为 -5 如果〈按下 [上移键]?〉那么 将 [速度y] 设为 5 如果〈按下 [下移键]?〉那么 将 [速度y] 设为 -5 如果〈不成立〈按下 [右移键]? 或 按下 [左移键]? 或 按下 [上移键]? 或 按下 [下移键]?〉〉那么 将 [速度x] 设为 0 将 [速度y] 设为 0 如果〈〈x 坐标 速度x〉 220 或〈x 坐标 速度x〉 -220〉那么 将 [速度x] 设为 0 如果〈〈y 坐标 速度y〉 160 或〈y 坐标 速度y〉 -160〉那么 将 [速度y] 设为 0 将 x 坐标 增加 (速度x) 将 y 坐标 增加 (速度y)这里用“速度变量”而不是直接改坐标是刻意的设计。直接写“如果按下右键那么将 x 坐标增加 5”边界判断就必须写成“如果 x 坐标 220 那么……”嵌在外面两层结构。而用速度变量的写法把所有条件判断拍平到同一层逻辑是“先决定这一帧要往哪走、走多快再统一执行移动”。这个模式在游戏开发里叫“分离决策与执行”是后面做物理效果重力、摩擦、反弹的基础。我一般在第二节课就把这个概念埋下去学生当时未必懂但等到做弹球时会有“原来如此”的瞬间。关于边界数值 220 和 160 的来历得说清楚。舞台坐标系 x 从 -240 到 240y 从 -180 到 180这是 Scratch 的硬约束。但角色有大小如果角色宽度是 40 像素、以中心点为锚点那么中心点移到 240 时角色有一半已经出界了。所以安全边界应该是 240 减去半个宽度也就是 220。同理 y 方向 180 减半高 20 得 160。这两个数字不是随便填的换一个大小不同的角色就得重算。我见过学生把角色大小调成 200% 之后角色还是能半截跑出画面原因就是边界值没跟着改。提示判断边界时用x 坐标 速度x而不是当前x 坐标。因为速度可能很大只判断当前坐标的话一次移动就可能直接穿墙出去。这个“预判下一帧位置”的思路是所有防穿模处理的原型。3.2 案例二弹球反弹与胜负判定第二个案例做弹球重点在“条件判断的时机”。舞台上放一个球角色 A、一块挡板角色 B、一排砖块角色 C 的克隆体。球在循环里持续移动碰到边缘反弹碰到挡板反弹并加速碰到砖块则砖块消失、球反弹。核心脚本球当 绿旗 被点击 将 [速度x] 设为 4 将 [速度y] 设为 4 移到 x: 0 y: 100 重复执行直到〈碰到 [挡板]? 与 y 坐标 -140〉 如果〈碰到边缘?〉那么 将 [速度x] 设为 (0 - 速度x) ...反弹处理 如果〈碰到 [挡板]?〉那么 将 [速度y] 设为 (0 - 速度y) 将 [速度x] 设为 (速度x * 1.05) 如果〈碰到 [砖块]?〉那么 删除 [砖块] 的克隆体 ← 这里是个坑见下 将 [速度y] 设为 (0 - 速度y) 将 x 坐标 增加 (速度x) 将 y 坐标 增加 (速度y)这里有个真实的坑必须点出来“碰到砖块”判断里不能直接“删除此克隆体”。原因是这段脚本运行在球的角色里“删除此克隆体”删的是球自己。正确做法是用广播通知砖块或者用“砖块”角色自己的脚本监听“当作为克隆体启动时 → 重复执行 → 如果〈碰到球〉那么 删除此克隆体”。后者更符合 Scratch 的思维习惯而且天然并行。我在第一次做这个 Demo 时就删错了对象球直接消失找了半小时才发现。另一个坑是反弹方向的处理。“碰到边缘”的自动反弹是 Scratch 内置的它会把角色的方向反转但如果你是用 x/y 坐标手动控制的球这个内置反弹就不生效了必须自己算。上面脚本里“将速度x 设为 0 减 速度x”就是水平反向。但这里不能简单粗暴地双向反转否则球在水平边缘会变成往回飞看着像撞了墙又弹回来很怪。正确的做法是先判断撞的是哪一边如果 x 坐标绝对值接近 240就只反转速度x如果是 y 方向贴近 180就只反转速度y。这就需要在“碰到边缘”之外再加一层坐标判断又是一个条件嵌套的使用场景。胜负判定的写法在这里也值得说。用“重复执行直到〈碰到挡板 与 y 坐标 -140〉”作为主循环的退出条件意思很明确“一直打到球掉到底部”。但这里与的两边为什么不能只写“碰到挡板”因为球在游戏过程中必然会碰到挡板很多次如果只判断碰到挡板就退出游戏刚开始就结束了。加上y 坐标 -140这个限定才是“碰到挡板并且掉到底部”语义才对。这种“条件组合要表达完整语义”的意识比记住语法重要得多。3.3 案例三答题判定与血条变化第三个案例换赛道做问答或闯关类项目重点讲嵌套条件和变量组合。目标是出一道选择题玩家输入答案正确则加分并进入下一题错误则扣血血量归零游戏结束。当 绿旗 被点击 将 [血量] 设为 3 将 [得分] 设为 0 重复执行直到〈血量 1〉 询问 [3 4 等于几] 并等待 如果〈(回答) [7]〉那么 将 [得分] 增加 10 说 [答对了] (1) 秒 否则 将 [血量] 减少 1 说 [再想想] (1) 秒 如果〈血量 1〉那么 说 [只剩最后一次机会了] (2) 秒 如果〈血量 1〉那么 说 [游戏结束得分连接(得分)] (3) 秒 停止 [全部]这里的回答是侦测分类里的全局变量用户输入的内容自动存进去。有几个细节值得展开。第一回答和数字比较时的类型问题。Scratch 在比较时会先尝试把两边转成数字7和7判定为相等所以不用做类型转换。但如果用户输入的是“7 ”带空格或者“七”就会判错。我一般会在提示语里明确写“请输入阿拉伯数字”减少这种干扰。如果要做更宽松的判定可以用〈回答〉包含〈7〉?这样的组合容错率会高很多。第二否则分支里的嵌套条件判断“血量 1”用来做“最后一次机会”的提示。这其实就是用嵌套条件实现了三态输出正确、错误且还剩一次、错误且还有多次。如果硬要用“如果…那么”平铺就得写两遍判断逻辑重复。这里正好可以作为教学点讲清楚“否则分支天然就是互斥的”能省掉大量重复判断。第三停止 [全部]放在主循环外面是因为循环的退出条件是血量 1循环结束后再判断一次确认是正常通关还是失败退出。如果放在循环内部脚本会在扣血之后立刻停止最后那句“游戏结束”根本来不及说。血条的视觉呈现也值得一提。Scratch 里没有现成的血条控件通常的做法是画三个造型满血、半血、空血然后根据血量切换造型或者用一个矩形的 x 缩放来表示。用造型切换的方案在如果里写“如果〈血量 3〉那么 换成 [满血] 造型”这种三分支就得写三个平铺的条件或者用“否则如果”式的嵌套。这个时候脚本会变长正是前面提到的“三层嵌套要考虑拆分”的场景可以借机引入自制积木来封装“刷新血条”这个动作。4. 参数、阈值与性能那些踩过才知道的细节4.1 数值参数的选取与手感调节条件语句里的数字参数直接决定了作品的“手感”而手感这件事文档上是不会写的。移动速度 5 步和 3 步肉眼差别很大反弹系数 1.05 和 0.95直接决定游戏是越玩越爽还是越玩越难。我整理了一套自己常用的起步参数可以拿来调参数建议起步值调整方向说明方向键移动步数4~6手感太飘就减太笨重就加与角色大小相关大角色用大步数重力加速度每帧 -1 到 -2想要飘就取 -0.5想要干脆就 -3每帧累加到 y 速度上跳跃初速度10~15与重力配合调跳跃高度约等于 v²/(2g)挡板反弹加速系数1.02~1.08超过 1.1 容易穿模每次碰挡板乘一次碰撞检测容差2~5 像素出现“擦边不判定”时加用坐标范围代替像素碰撞循环内等待秒数0.01~0.03太大会卡顿太小会吃满 CPU大部分情况不需要手动加表格里最后一行值得多说两句。“重复执行”在 Scratch 3 里默认是每帧执行一次迭代30 帧每秒也就是说一个空的重复执行每秒跑 30 次。这个频率对大多数逻辑判断是够的不需要额外加等待。但如果你在循环里放了大量重型侦测或者做了很多克隆体的运动计算适当加一个 0.01 秒的等待能明显降低资源占用——代价是动作略微不跟手。这个取舍没有标准答案得根据项目规模试。跳跃高度那个公式h v²/(2g)是我在带课时会顺手教的。初速度 12、重力 1.5跳跃高度就是 144/3 48 像素差不多是角色身高的两三倍看起来刚刚好。学生不用记公式但知道“改跳跃初速度影响的是高度的平方”调参时候的方向感就出来了不会盲目地一个个试。4.2 侦测开销与克隆体规模控制Scratch 里最贵的几个操作按我的实测排序大致是碰到颜色碰到角色距离 坐标与变量比较。这个排序不是绝对精确但量级关系是对的。造成差异的原因是碰撞检测的实现方式“碰到颜色”要做像素级的颜色比对“碰到角色”至少还能靠包围盒先筛一遍。这就带来一个很实际的建议不要在每帧对所有克隆体做碰到颜色判断。一个典型场景是做“草地减速”效果20 个敌人克隆体每帧都检测自己是不是踩在绿色上帧率会急剧下滑。改用“判断 y 坐标是否小于某个值”来代替颜色检测性能立刻回来视觉效果几乎没差别——玩家根本分辨不出你是用颜色判定还是用坐标判定。克隆体的数量上限是 300 个这是硬限制超过就创建失败。但真正的瓶颈往往不是 300 这个数字而是每个克隆体都在跑一个带条件的无限循环。100 个克隆体 × 每帧 5 个侦测判断 × 30 帧 每秒 15000 次判断这个量级在 Scratch 里已经能感受到卡顿了。我的经验是把克隆体的循环体压到最简能用公共变量算的就不要每个克隆体各算一遍能在生成时就确定的值就不要每帧重新判断。还有一个容易被忽视的性能点是“触发条件的脚本停不下来”。比如“当接收到消息 → 重复执行 → 如果…那么…”如果这个脚本永远不停止广播又发得很频繁就会不断叠加新的脚本实例内存和 CPU 双爆。正确的写法是在脚本末尾加一个终止条件或者用停止这个脚本在合适的地方退出。我在审查学生作品时经常靠“绿旗重启后仍然卡顿”这个现象判断出有脚本没退出——因为刷绿旗只重置变量不一定会终止所有残留的脚本链。5. 常见问题与排查速查表5.1 现象、原因、解决三步定位条件语句的 bug 有个共同特点不报错。脚本照跑只是行为不对所以必须靠现象反推。下面这张表是我这些年攒下来的高频问题清单基本能覆盖 80% 的求助场景现象最可能的原因快速验证与解决条件里的动作从来没执行过六边形插槽为空或条件永远为假在条件内加“说 [进来了]”看是否触发检查插槽是否填满只执行了一次就再也没反应条件积木放在了循环外把整块拖进“重复执行”内部按键一次角色连续移动很多步循环体内重复累加且没有清零逻辑把速度变量在决策前重置或改用“当按下键”帽子积木“等待直到”之后整个脚本不动了条件永远不成立脚本阻塞检查条件是否是“永远不会变真”的组合或加超时兜底角色穿墙而过只判断当前坐标没预判下一帧用坐标 速度做判断或缩小单次移动步数克隆体行为互相影响用了全局变量存每个克隆体的状态改成“仅适用于当前角色”的私有变量广播之后脚本越跑越卡脚本没有终止实例不断叠加加停止这个脚本或改用布尔变量做重入保护数字比较结果不对输入含空格或特殊字符用包含做宽松匹配或在提示语里限定输入格式表格第四行值得再展开一句。“等待直到”的阻塞特性是一把双刃剑用得好可以做出非常干净的时序控制用得不好就是死锁。我的做法是给它配一个兜底用一个计时器变量记录开始等待的时刻条件写成〈条件成立〉或〈计时器 - 起点 10〉十秒还没等到就放行。这样万一逻辑有漏洞作品也不会完全卡死至少能继续往下走方便定位问题。5.2 几条能省下大量返工的书写习惯第一条每个条件分支里至少留一个可观察的反馈。哪怕只是“说 [A] 0.1 秒”也比什么都不加好。调试阶段这些提示可以保留发布前再统一删掉。Scratch 没有断点靠“说”积木打日志是最朴素也最有效的手段。我甚至见过用“角色大小变化”当调试信号的也算是一种可视化日志。第二条变量命名带上前缀。速度x、速度y、得分、血量这种命名在单人项目里够用但一旦项目变大建议改成obj_速度x、ui_得分这样的前缀风格一眼能看出归属。Scratch 的变量列表是全局平铺的同名变量在不同角色里各有一份没有前缀极容易搞混。这个习惯从第一天就养成后面能省掉无数“为什么这个角色的变量改了另一个也跟着变”的困惑——顺便说那个困惑的真实原因通常是某个变量忘了勾“仅适用于当前角色”。第三条每个条件积木加上注释。Scratch 支持在积木上右键添加注释很多人从来没用过。我的标准是凡是用了不成立或者与/或组合的条件必须写一句中文说明意图。比如〈不成立〈碰到 [墙]? 或 处于 [跳跃状态]?〉〉旁边写“不在跳跃且没碰墙才允许移动”。半年后回来看注释救你一命。第四条定期整理脚本区。Scratch 的脚本区没有折叠功能条件嵌套多了以后会横着铺开很远。我习惯把功能相近的脚本块上下对齐用注释块做分隔重要的循环体单独放在画布左侧。这个动作看似无关逻辑实际上能大幅降低“看错层级”的概率——毕竟条件语句的 bug有一大半是积木放错了缩进层级。5.3 从条件语句延伸到更复杂的控制结构把这套东西吃透之后往下的学习路径其实很清晰。第一步是把条件语句和广播结合做“状态机”——用一个变量记录当前游戏状态开始、进行中、暂停、结束所有脚本都先判断状态再动作。这是从“一堆平行脚本”走向“有组织架构”的关键一步也是很多人做中型项目时卡住的地方。第二步是把条件判断搬进自定义积木。自定义积木支持传入参数可以把“判断是否碰到障碍物并返回结果”这类逻辑封装起来复用。Scratch 的自定义积木没有返回值但可以用一个约定好的变量当输出或者干脆让积木内部直接完成动作。这个思路本质上就是函数抽取对提升项目可维护性的帮助非常大。第三步是尝试用列表配合条件做更复杂的数据判断比如做一个小型的背包系统或者题库系统用列表的第 n 项和条件组合来判断物品是否存在、答案是否匹配。到这个阶段条件语句已经不再是孤立的知识点而是所有逻辑的地基。我在带完条件语句这一课之后通常会先让学生用两周时间自由做项目把这块内容彻底用熟再往列表和克隆推进。跳过这个消化期直接学后面往往是学了就忘。最后分享一个我在实际教学里反复验证过的小技巧让学习者在纸上画出“如果…那么”的流程图再对照着搭积木。图形化编程看起来已经很直观了但正是这种“看起来直观”让人跳过了思考步骤直接开始拖积木然后卡在“不知道下一步该放什么”。先画后搭多花的那五分钟能省掉后面半小时的来回试错。