★ FEATURED ARTICLE 带过几轮图形化编程的课后我发现一个特别稳定的规律学员在1到3级训练场几乎不会卡住因为那些关卡本质上是“把一条看得见的路线翻译成积木”顺序执行就行错了也就是某一步方向反了。真正开始有人挠头、有人反复提交十几次、有人干脆把整段积木推翻重来基本都是到了4级训练场。这条分界线往往就是一块看起来最不起眼的积木——如果。图形化编程里的“如果”积木对应文本代码里的条件判断它让程序第一次具备了“自己看情况做决定”的能力。4级训练场围绕它设计的关卡考的不是手速也不是记积木在哪个分类下而是能不能把一个会变化的场景拆成“什么条件下、做什么事”。这篇内容面向正在刷4级训练场的学习者也面向带孩子或带学员过这一关的教练我会把“如果”积木在4级关卡里的出场方式、底层逻辑、典型关卡的完整过法以及我实际踩过的那些坑一次讲透。1. 4级训练场到底在考什么从“照着走”到“看着走”1.1 三个级别之间的能力断层在哪里先把这个断层说清楚后面所有的判断技巧才有落脚点。1级和2级训练场的关卡地图、障碍、目标位置在打开关卡的那一刻就是完全确定的学员要做的事是“观察—记忆—翻译”看一眼路线数一下格子然后把前进、左转、右转按顺序排好。这类关卡的反馈非常直接跑一遍就知道对错错误类型也单一无非是方向转反或者步数多一步少一步。3级训练场引入了循环本质变化在于“把重复动作压缩表达”但路径规律通常还是固定的。学员只要能识别出“这段是重复的、重复几次”用重复积木一包基本就过了。所以3级考的是模式识别还是静态的。到4级情况变了。关卡开始出现“程序运行时才知道的信息”前方是不是墙、脚下有没有物品、当前朝向是什么、已经走了几步、还剩多少能量。这些东西在写积木的时候是看不见的必须让程序在跑的过程中自己去问、自己去答。这就是从“照着走”变成“看着走”。一字之差思维模型完全不同——前者是录制后者是决策。我带过一个A同学3级刷得飞快到4级第一关就卡了四十分钟。他的原话是“我知道要转弯但我不知道它什么时候该转”。这句话其实已经把问题说得很准了他知道动作但不知道触发条件。4级训练场真正训练的就是把“动作”和“触发动作的条件”拆开思考的习惯。1.2 “如果”积木在4级关卡里的四种典型出场方式摸清出场方式比死记某一关的答案有用得多。我把4级训练场里“如果”积木的用法归成四类基本覆盖了绝大多数关卡。第一类是感知型触发条件来自环境探测比如“前方有障碍”“脚下有物品”“右侧是空地”。这类关卡的经典结构是先走一步走之前先问一句能不能走。第二类是状态型触发条件来自程序自己维护的变量比如“已收集数量等于目标数量”“剩余步数小于阈值”“能量不足”。这类关卡的关键不在判断本身而在于变量有没有被正确更新。第三类是互斥型选择同一个位置有多个可选动作必须二选一甚至多选一典型结构是“如果……否则……”。这类关卡最容易出现的错误是用两个独立的“如果”去表达互斥关系结果两个分支都被执行。第四类是兜底型判断用来处理“其他所有情况”比如“如果前方可走就前进否则原地转向”。它看起来简单但涉及到判断顺序顺序排错就会死循环。提示这四类不是互斥的很多关卡是两三类混在一起。判断某一关属于哪一类最快的办法是问自己一句——“这个决定依赖的信息是我写积木时就知道的还是程序跑起来才知道的”凡是后者就一定要用“如果”。2. “如果”积木的底层逻辑条件、判断、分支三件套2.1 布尔条件到底是怎么被“算”出来的很多学员把“如果”积木当成一个整体去记其实它内部是三段结构条件槽、条件成立时的执行段、可选的条件不成立时的执行段。条件槽里放的是一个能返回“真”或“假”的表达式图形化环境里通常表现为六边形或带缺口的块只能塞比较运算和逻辑运算塞不进普通动作积木。这个形状限制其实是个很好的教学设计它在视觉上就告诉学习者这里要的是“一个问题”不是“一个动作”。条件表达式的构成无非三种原料比较大于、小于、等于、状态读取前方是否有障碍、当前朝向、剩余步数、逻辑组合且、或、非。举个具体的例子“如果前方有障碍并且右侧没有障碍那么右转”这句话拆开来是状态读取“前方有障碍”得到一个真假值状态读取“右侧没有障碍”得到另一个真假值两者用“且”连接结果送进“如果”的条件槽。理解了这个拆解过程学员就不会再写出“如果 右转”这种把动作当条件的错误结构。这里有个很实用的类比条件槽就像一个只能回答“是/不是”的问题框。你往里塞“前方有墙吗”它回答是或不是你往里塞“右转”它没法回答因为它不是问题。我让学员每次写“如果”之前先在心里默念一遍“……吗”念不通就说明条件写错了。这个方法看着土实测纠错率很高。还有一点常被忽略条件的求值是有顺序的。当条件里用了“且”连接两个判断多数图形化环境是从左到右依次判断前一个为假时后面可能就不算了。这个特性在简单关卡里看不出差别但在需要防止越界读取的关卡里就很关键——比如“如果 前方有物品 且 物品类型是目标类型”把“前方有物品”放在左边可以避免在没物品的时候去读物品类型。2.2 单分支、双分支、多分支的选型对照图形化环境里的“如果”通常有几种形态选错形态是4级阶段最常见的结构性错误。我整理了一张对照表方便直接照着选。形态结构适用场景典型误用单分支如果条件成立才执行不成立什么都不做可选动作比如“有物品就收集”用它表达互斥导致不成立时状态没处理双分支如果否则成立走A不成立走B必居其一二选一比如“能走就前进不能走就转向”两个分支动作不对称漏掉一种情况多分支链如果…否则如果…否则如果…否则三种以上互斥情况判断顺序随意被更宽的条件先截胡独立多条如果多条互不影响的条件依次判断多个可同时成立的条件本该互斥却写成独立动作被执行两次重点说两个最容易出问题的地方。第一个是双分支和两条独立“如果”的区别。假设场景是“如果脚下有物品就收集否则就前进”。写成双分支收集和前进永远只执行一个写成两条独立的“如果”当脚下有物品时第一条成立执行收集第二条的条件“脚下有物品”如果不成立就前进——看起来没问题但如果第二条写成“如果 未收集 那么 前进”这种取反条件逻辑上还能对一旦学员偷懒写成两条都以同一条件判断就会出现收集完又前进的诡异行为。第二个是多分支链的判断顺序。假设三种情况剩余步数为0、剩余步数小于3、其他。这三条必须按“最严格到最宽松”排如果先把“小于3”放前面那“等于0”这一条永远轮不到。这个道理和筛子一样孔大的先筛细的就漏不下去了。我在课上会直接说范围窄的条件往上放范围宽的条件往下放兜底的放最后。2.3 嵌套与提前判断什么时候该套娃什么时候该拆开嵌套是4级训练场里让学员最上头的东西。所谓嵌套就是“如果”里面再放“如果”。它在逻辑上完全合法但在实操中要控制深度。我的经验是两层嵌套是舒适区三层要谨慎四层以上必须重构。为什么因为图形化积木是横向铺开的每嵌套一层积木整体就往右缩进一段屏幕宽度有限缩到第四层时条件槽已经挤得看不清了改一个条件要来回滚动出错概率直线上升。更要命的是嵌套深了以后人脑很难同时跟踪所有分支的进入条件调试时根本说不清“现在到底走在哪条路径上”。那什么时候该嵌套当第二个判断依赖第一个判断的结果时。比如“如果前方有障碍那么如果右侧可走就右转否则左转”内层判断只在外层成立时才有意义这种嵌套是合理的。反过来如果两个判断互相独立比如“如果有物品就收集”和“如果能量不足就补充”它们之间没有依赖关系就应该是两条并列的“如果”硬套在一起纯属给自己找麻烦。拆开嵌套有两个常用手法。一是提前返回的思路把最特殊、最该优先处理的情况放在最外层单独判断处理完就不再往下走。图形化里没有真正的return但可以用“否则”把后续逻辑挂到不成立分支上效果类似。二是抽成独立逻辑块如果平台支持自定义积木或函数把一段嵌套逻辑打包成一个有名字的块主流程里只留一句调用。名字起得好逻辑自然就清楚了比如叫“确保朝向目标”。注意嵌套层数不是能力指标。我在复盘时见过学员为了炫技把三层嵌套压成一行结果自己第二天都读不懂。可读性永远优先于“看起来简洁”。3. 实操拆解四类典型关卡的完整过法3.1 障碍感知型关卡先问再走别先走再问这类关卡的结构通常是角色要从起点走到终点中间散布障碍撞上就失败。核心思路只有一句——每走一步之前先确认前方能不能走。伪代码结构大致是这样重复执行 如果 前方有障碍 转向选择可走的方向 否则 前进一步看起来简单但细节全在“转向”那一段。转向怎么选取决于关卡给的信息。如果障碍只在正前方、左右都是通的那固定右转就能过如果障碍是连续的一段墙固定右转会导致在墙角来回打转这时就需要“如果右侧可走就右转否则左转”这样的二段判断。我让学员处理这类关卡时养成一个习惯先手动画一遍走位标出每一个需要做决定的格子。比如一张15×15的地图其实真正需要判断的位置可能只有五六个其余都是直线走。把这几处决策点在图上圈出来再针对每一处写条件积木数量能少一半逻辑也清爽。这里有个特别容易踩的坑判断的时机。是先前进再判断还是先判断再前进如果写成“前进一步然后如果前方有障碍就转向”角色已经撞上去了判断再及时也没用。正确的顺序永远是判断在前、动作在后。我在批改时看到这类错误不会直接说答案而是让他把角色跑一遍看它停在哪一格——撞墙的那一格会非常直观地告诉他顺序反了。另一个坑是死循环。当角色被三面围住只剩来路可走时“如果前方有障碍就右转”可能会让它原地转四圈回到原点。解决办法是在转向逻辑里加一层判断或者用“重复直到”配合一个“已尝试方向数”的计数变量。后者对4级来说略重多数关卡用两段判断就能覆盖。3.2 目标选择型关卡条件要写在“到达”之后不是“出发”之前这类关卡里地图上有多个物品只有特定类型的物品需要收集或者需要按顺序收集。典型结构是走到某格检查脚下有什么符合条件就执行收集不符合就继续走。关键点在于判断位置。很多学员把“如果有物品就收集”写在移动之前逻辑上就变成了“在上一格判断下一格有没有物品”除非平台提供了“前方有物品”这种探测否则判断必然错位。正确做法是移动完成、角色停稳之后再判断脚下状态。重复执行 如果 脚下有目标物品 收集 如果 未到达终点 前进一步注意这里用了两条独立的“如果”而不是“如果否则”。原因是这两件事在逻辑上不互斥——收集完照样要继续走。如果把“前进”塞进“否则”分支角色收集完就会停住不动这是4级阶段出现频率极高的一类错误。判断两条逻辑该并列还是该互斥问自己一句就行这两件事会不会同时发生会就并列不会才用否则。顺序收集类关卡还要多一层考虑收集顺序必须和关卡要求一致。这时条件里要带上“当前需要收集的序号”这个变量收集成功后序号加一。变量更新这一步最容易被漏掉漏了就会反复收集同一个物品或者卡在某个序号上永远不动。我在教学时会让学员在变量旁边手写一张小纸条标上“收集后必须1”贴在屏幕边上提醒三次基本就形成条件反射了。3.3 状态切换型关卡变量不更新判断就是摆设到了4级后半段关卡开始引入步数限制、能量限制、收集数量目标这类状态量。这类关卡的特点是判断本身不难难在状态维护。程序里有一个变量记录当前状态每次动作后要更新它判断时读它。举个具体设计角色有固定步数预算每前进一步消耗一格预算耗尽必须停止。结构是重复执行 如果 剩余步数 0 停止 否则 前进一步 剩余步数 剩余步数 - 1这段逻辑里最脆弱的不是判断是最后那行减法。漏掉它剩余步数永远是初始值判断永远不成立角色会一直走到撞墙为止。我见过学员排查了二十分钟以为是条件写错了其实是变量没减。这类关卡我总结了一个检查清单三步走初始值对不对、每次动作后有没有更新、更新后的值有没有被下一轮判断读到。三步都过一遍基本不会出问题。第三步常被忽略原因是变量的作用域——如果变量是在某个循环内部新建的每轮循环都会被重置那更新就白做了。图形化环境里变量的创建位置不像文本代码那么显眼需要专门确认。另外提醒一点判断“小于等于0”还是“等于0”差别很大。如果一次动作让变量从1直接跳到-1比如消耗量是2那“等于0”就永远不成立程序会漏掉停止时机。凡是涉及累加累减的状态判断条件一律用范围比较别用等号。这个习惯从图形化阶段就该养成后面转文本代码时能省掉大量边界bug。3.4 组合型关卡循环里放如果如果里再放循环4级训练场最后几关基本是组合结构最典型的是“外层循环控制整体推进内层用如果处理局部情况”。比如一片区域需要逐格扫描遇到物品收集、遇到障碍绕行、扫完一片再进下一片。这种关卡我的建议是分层写、分层测。先把外层循环写出来内层什么都不放跑一遍确认循环次数和推进节奏对再往里加一层“如果”加完立刻跑再加第二层。千万不要一口气写完几十块积木再点运行一旦出错你根本不知道该从哪一层开始查。组合结构里最隐蔽的错误是循环终止条件写错。外层循环如果依赖“是否到达终点”来判断而这个判断又写在循环体内部就有可能出现“已经到终点了但循环还没退出”的情况。稳妥的写法是把终止条件直接放进循环的退出条件里或者用“重复直到 到达终点”。这一点和文本代码里while循环的写法是完全一致的思路图形化只是把语法换成了积木形状。还有一个实操层面的经验组合关卡里“如果”块的数量最好控制在个位数。如果超过十块说明逻辑该抽象了。可以把重复出现的判断组合打包成自定义积木主流程里只留调用。这么做不只是为了好看主要是降低修改成本——改一处定义所有调用点同步生效比在十几块积木里逐个找要可靠得多。4. 调试与排错条件写对了为什么还是过不了4.1 五类高频错误速查表4级训练场卡关九成以上能归到下面五类。我把它们整理成表遇到问题时从上往下对一遍比盲目改积木快得多。错误类型典型表现根因处理办法条件写反该走的时候转该转的时候走把“有障碍”写成“无障碍”每条条件后面加“吗”读一遍分支不互斥同一格执行了两个动作用两条独立如果要表达二选一改成如果否则状态未更新判断永远成立或不成立变量后忘了加减检查每个动作后的更新语句判断顺序错某个分支永远进不去宽条件排在前面窄条件上移兜底下移边界差一最后一步多走或少走循环次数或终止条件算错手数格子验证首尾两步表格里的第三类也就是状态未更新我要多说两句。它之所以高频是因为它的表现很有迷惑性——程序不报错积木也没少就是行为不对。学员第一反应往往是怀疑条件写错了于是反复改条件越改越乱。正确做法是先怀疑变量在判断前后各插一个输出或者观察点看变量的值到底有没有变。这一步花三十秒能省掉二十分钟。第五类边界问题也值得展开。凡是涉及计数的循环差一是常态。我的处理办法是手数前两步和最后两步假设循环要执行6次手工推演第1次和第6次时角色在哪一格、变量是多少推得出来就说明边界对推不出来就说明还没想清楚。这个方法笨但它不依赖任何调试工具随时随地能用。4.2 打点法用最小验证快速定位问题我教给学员最实用的排查手段叫“打点法”。思路很简单不要试图一次看懂整段程序而是把程序切成几段每段单独验证。具体操作是在关键位置插入一个可观察的动作比如让角色做一个明显的转向、播放一个短提示、或者把某个变量显示在屏幕上然后运行看这个点有没有被执行到。比如一段嵌套三层的逻辑卡住了不知道走到哪一层。在每层分支的入口各插一个不同的可见动作跑一遍看出现的是哪一个立刻就知道实际走的是哪条路径。这比盯着屏幕推理快十倍。打点法的另一个变体是减法验证把一半积木暂时禁用多数图形化环境支持右键禁用或者拖出去看剩下的部分能不能正常跑。能跑问题在被禁用的那一半不能跑问题在保留的这一半。对半砍两三轮就能把问题范围缩到几块积木。这个方法在几十块积木的组合关卡里特别好用比从头读一遍高效太多。提示打点用的那些临时积木问题解决后一定要删干净。我见过学员调完忘了删结果关卡能过但评分不高回头查了半天才发现是残留的输出动作拖慢了节奏。4.3 边界条件第一步和最后一步最容易翻车无论什么类型的关卡首尾两步永远是最脆弱的。第一步的问题通常是初始状态没设对角色初始朝向、变量初始值、起始格是否算作已访问这些在关卡开始时如果没处理好后面全错。最后一步的问题则是终止判断的时机是在动作之前判断还是之后判断决定了角色会不会多走一步或者提前停下。我的建议是每写一个循环先在纸上或心里明确回答三个问题起始时状态是什么、每轮结束后状态变成什么、什么状态下应该退出。三个问题答完循环的骨架就对了剩下的只是往里填动作。还有一种边界容易被忽略地图边缘。当角色走到地图最外侧前方探测可能返回“不可走”或者“越界”不同平台的处理不完全一样。稳妥的做法是在转向逻辑里把“可走”的判断写完整不要假设某个方向一定通。我在实际带练时会让学员专门找一张四周都是墙的关卡试一遍看看角色在角落里的行为符不符合预期——这个测试五分钟能把大部分边界问题提前暴露出来。5. 训练节奏与能力迁移5.1 4级训练场的刷关顺序建议4级训练场里的关卡顺序我建议不要完全按编号刷而是按类型分组刷。理由很实在同一类型的关卡连着做条件结构高度相似学员能在一两个小时里把这类问题的解法固化下来形成肌肉记忆按编号刷则是类型来回跳每关都要重新切换思路效率低很多。具体分组可以参考我前面讲的四类先把障碍感知型集中刷完再刷目标选择型然后是状态切换型最后用组合型收尾。每组刷完之后留十分钟做复盘问三个问题这类关卡的共同结构是什么、我这次用错了几次条件、下次遇到同类能不能直接套。复盘这一步看着费时间但它决定了十关的经验能不能变成一关的能力。刷关过程中还要控制一个节奏每关限制重试次数。我的经验是三次。三次之内过不了就停下来把积木全删了重写一遍而不是在原有积木上修修补补。原因很简单修补到第三次的时候那堆积木已经是一团乱麻了你自己都说不清哪块是对的。重写一遍反而快而且重写的过程本身就是一次逻辑梳理。5.2 从图形化到代码如果积木的文本形态对照最后说一个很多人关心的点这些“如果”积木的经验转到文本编程还有没有用。答案是极其有用因为条件判断的思维模型完全一致变的只是语法外壳。图形化结构文本形态需要注意的差异如果条件if (cond) { }括号和花括号不能少如果否则if (cond) { } else { }else后面不跟条件多分支链if / else if / else判断顺序同样重要且、或、非、状态变量更新x x - 1和图形化完全一致差异主要在细节上。文本代码多了括号、分号这些语法负担少了积木形状的视觉提示条件表达式写错时不会有形状限制拦着你所以更容易出错。但反过来文本代码在缩进、命名、复用上的表达能力远强于图形化嵌套三四层的逻辑写成函数之后反而比积木更清楚。我的建议是在图形化阶段就把两个习惯养好一是条件表达式先想清楚再写别边写边试二是给关键变量起有意义的名字哪怕是图形化里的变量命名框也别用默认名。这两个习惯迁移到文本代码时价值会被放大好几倍。至于语法层面的东西那是几小时就能补上的真正难补的是“把场景拆成条件和动作”的思维方式——而这恰恰是4级训练场反复在练的东西。我在实际带练中的体会是4级训练场真正的门槛不在积木本身而在于学习者要第一次接受“程序可以不按我写的顺序、而是按我看到的情况去执行”。这个观念一旦转过来后面的关卡会突然变简单没转过来就会一直试图用顺序执行的思路去硬凑条件判断越凑越乱。遇到卡住的学员我通常不再讲积木怎么拖而是让他用嘴把过关思路说一遍——说得清楚积木自然写得出来说不清楚写多少遍都是碰运气。
阅读完成 · 觉得有帮助？
