说实话CS50这门课我前后跟了不下三轮每一年第0讲和配套的Scratch练习都会重新看一遍。很多人一看Scratch就默认它是“给小朋友玩的积木工具”直接跳过但我个人强烈建议如果想把计算机思维彻底打通Scratch这一关必须好好过。2024版CS50在Scratch单元依然保持了相当大的比重而这篇第六篇学习笔记正好是整段内容里最容易拉开差距的分水岭——变量、条件判断、自定义积木、列表这些概念开始密集登场课程从“照着示例搭积木”切换到“自己设计程序结构”。这篇笔记既适合正在跟CS50、想扎扎实实做作品的人也适合少儿编程教学场景里备课到进阶阶段的老师我会把这一课的核心概念拆开讲透再带大家做一个可以直接复用的中秋主题小项目最后把实验过程中踩过的坑整理成速查表。1. 第六课到底在讲什么从“搭积木”跃迁到“编程思维”1.1 CS50为什么迟迟不放你走Scratch背后的教学逻辑CS50第一课用Scratch开场不是因为它简单到可以糊弄两小时而是因为哈佛教学组想让学生第一眼就看到“程序设计到底是什么”。如果一开始就上C语言的指针和内存对零基础的人来说全是语法噪音根本顾不上思考结构。Scratch把语法错误几乎清零剩下的全是纯逻辑问题先做什么、在什么条件下做什么、重复多少次、什么时候停止。到第六课这种优势开始转换成真正的门槛。前几课你可能还在拖“移动10步”“说话2秒”到这一课开始要求你同时管理多个角色、多个变量、多条并行脚本。我自己跟学几轮之后才意识到第六课真正想训练的不是“记住某个积木在哪”而是抽象能力能不能把一个复杂任务拆成模块再把模块安排成可运行的剧本。什么叫抽象打个比方给一个完全没下过厨的人一张复杂菜谱他大概率手忙脚乱。但如果有经验的厨师会把菜谱拆成“备料、腌制、煎制、装盘”四步每步再拆出具体操作这就是模块化。Scratch第六课的练习目标就是用事件、自定义积木、消息广播这些元素帮你在图形界面里完成同样的拆解动作。CS50之所以“不放你走”是因为这一课对后续C语言、Python的课程影响深远后面所有函数思想、状态管理、事件驱动概念都可以在Scratch里提前“预演”一遍。1.2 第六课的新维度模块化、事件驱动与“设计模式”启蒙第六课相比前面几节课最大的变化是出现了“程序结构”意识。前五课更多是单向脚本一个精灵从开始到结束按顺序跑第六课开始频繁出现多个角色同时响应事件、边界条件触发、并发逻辑。几个核心变化特别值得记在心里。首先是事件驱动。Scratch里最常见的“当绿旗被点击”只是起点真正让程序活起来的是“当收到消息”“当角色被点击”“当按下空格键”这类分散在各处的触发器。第六课的练习作品里你几乎不可能用一条顺序脚本完成必须让不同角色各自挂上事件。我上课给学生的比喻是舞台上不是只有一个导演而是每个演员都有自己的剧本导演喊“action”之后大家按各自的剧本并行工作。其次是广播消息。广播相当于角色之间的“暗号”一个角色发出“开始下月饼”另一个角色收到消息后才启动生成逻辑。很多初学者会反问为什么不直接让月饼脚本跟着绿旗一起启动答案是解耦。按下开始键时篮子、月饼生成器、计分器都要分别启动如果全部绑在一个事件里后续想单独暂停某个环节就很麻烦。广播把“什么时候运行”和“运行什么”分开了这其实是“事件发布与订阅”思想的最朴素版本后面到JavaScript或者Python GUI编程还会遇到一模一样的模式。最后是状态管理。复杂一点的Scratch作品都会有“游戏开始”“游戏中”“游戏结束”这些状态第六课的半命题作业会要求你在同一个作品里管理这些状态切换。最简单的办法是设一个全局变量比如“游戏状态0/1/2”条件分支根据状态决定是否响应键盘、是否继续生成敌人、是否停止计分。别小看这个操作这是你在图形化编程里第一次主动使用“状态机”思想后面写任何复杂项目都用得上。2. 绕不开的三大基础元件变量、条件判断与循环的组合2.1 变量全局与局部、命名与初始化的实际影响Scratch里的变量分为“适用于所有角色”的全局变量和“仅适用于当前角色”的局部变量。这个区分看着简单实际编程时坑不少。我在做练习时遇到的最经典问题就是两个角色都用了同名变量“速度”以为是分开的结果因为其中一个变量是全局另一个角色的脚本无意中把它改了整个游戏节奏突然失控。后来我给自己定了两条硬规矩全局变量统一加前缀比如“全局_得分”并且只允许一个角色去写它角色内部的临时变量一律勾选“仅适用于当前角色”。命名也要讲究。变量叫“a”还是叫“得分”对程序运行没有区别但对调试体验有天壤之别。我见过很多学生的作品里变量叫“x1”“x2”三十分钟后再看脚本完全忘了x1是速度还是分数。CS50课堂上老师反复强调代码的可读性在Scratch里也一样变量名至少让人一眼看出用途比如“月饼速度”“生命值”“连续接住次数”。初始化是另一个被低估的大坑。舞台启动那一刻所有变量如果不是在“当绿旗被点击”的初始化脚本里主动赋值就会延续上一次运行留下的旧值。我踩过一次特别典型的游戏结束时把生命值改成0第二次重新开始忘了初始化生命值依然显示0新玩家一点开局就输。正确做法是把初始化操作集中放在舞台或者出场角色的一张脚本里一开跑就全部重置不要分散到各个角色的各自事件中。2.2 条件判断边界、顺序和逻辑运算条件判断在Scratch里就是“如果/那么”和“如果/那么/否则”别看积木简单真正让它有力量的是里面的比较运算和逻辑运算。第六课的项目里判断月饼是否被接住、是否掉出屏幕、游戏是否结束全部靠条件堆出来。最容易翻车的是边界条件也就是“等于某个值”或者“在两个数之间”的判断。举个例子我做的接月饼游戏里判断月饼落进篮子篮口不能用“如果 碰到篮子”这么粗糙因为月饼那么多碰到就加分会导致一个月饼连续加分好几轮。正确的做法是检测碰到的同时给月饼设置一个“已被接住”的标记然后立刻把它变成不可见并删除克隆体保证同一块月饼只触发一次得分。很多人做游戏卡在分数乱跳上核心原因就是“事件触发后缺少一次性保护”。条件判断的顺序也值得专门讲。多个条件里优先级最高的要先判断。我习惯的顺序是先检测是否跌出边界游戏结束的边界状态再检测是否接到得分状态最后检测是否还在空中继续下落状态。如果顺序反了可能月饼已经掉出屏幕还被“碰到篮子”判断拦住了。实际调试时建议把边界条件的数值稍微放宽。比如屏幕底部判断不是“y坐标 -180”就立即结束而是先让它隐藏、再等0.5秒再结算这样视觉上不会突兀。逻辑运算并且、或者、不成立是第六课真正需要掌握的另一个点。比如游戏快到结束时想增加难度当“生命值 1”并且“月饼速度 3”这时速度再增加一个档位。这种复合条件如果用嵌套的“如果”写脚本会很长用“并且”合并成一个条件逻辑清楚又好维护。2.3 循环嵌套与游戏主循环别把CPU跑炸了Scratch提供了三种循环重复执行、重复执行N次、重复执行直到。第六课最常用的其实是“重复执行直到”因为它能表达“在条件满足前一直做某事”的语义。但很多人一看需要持续检测条件就直接上“重复执行”结果整个程序每秒跑几百次判断风扇狂转。这里有个经验如果循环体里没有明显的等待积木系统会以极快的速度空转。我之前做过一个测试让一个角色在重复执行里不断判断一个变量不加上任何“等待”Scratch的运行速度肉眼可见变卡。解决方案不是不用循环而是给循环一个节奏。常用做法循环体末尾加“等待0.05秒”这样每秒最多执行20次对人眼、对CPU都友好。但注意如果是要追求动画流畅的移动脚本每帧等待也不能太长0.01秒~0.03秒之间比较合适再长了就能看到明显卡顿。游戏主循环是第六课进阶作品的典型结构一个永远执行的循环体里依次完成“检测输入、更新状态、绘制界面”三件事。用Scratch实现时不需要那么严格但基本的套路可以拆成三个独立脚本并行一个脚本监听键盘改变移动方向一个脚本更新所有的月饼坐标和得分一个脚本检查游戏结束条件。并行脚本并行跑反而比把所有事情塞进一个大循环更清晰这也是事件驱动编程的优势。3. 自定义积木与列表Scratch里的函数与数据结构3.1 自定义积木函数参数、局部变量与“返回值”的实现第六课最大的一个认知升级是理解“自定义积木”就是函数。Scratch的“制作新的积木”对应到Python就是def对应到C就是函数定义。你可以给它起名、传入参数然后整个程序里反复调用不用复制粘贴一大堆脚本。自定义积木最实用的一点在于它自带局部变量空位。点击积木定义区域的“选项”可以勾选“运行时不刷新屏幕”还能添加数字参数和文本参数。比如我定义了一个“月饼下落(速度)”积木它接受一个“速度”参数那么每次通过这个参数传入不同的下落速度就能生成难度不同的月饼。参数在这里的角色就是函数调用时传入的值值不同行为就不同。关于“返回值”Scratch的自定义积木默认不直接返回值这一点和真正的函数不太一样。怎么解决我的惯用技巧是借助全局变量自定义积木负责计算把结果存入一个变量调用处马上读取这个变量。举个例子我想判断两块月饼是否会碰撞写一个自定义积木“计算距离”它算出距离后写入“现距离”这个变量主脚本在调用完积木后立刻检查“现距离”。这个方法不优雅但很可靠。Scratch 3.0后续版本里有“用于所有浮动的块”这个需要安装扩展模块才能实现类似返回值的效果如果不想折腾全局变量方案完全够用。封装的好处体现在维护上。以前改下落速度得去每个克隆体的每个脚本里找现在只要改自定义积木定义处的参数逻辑所有调用点全部生效。我上第六课的时候一定要求学生凡是重复出现过3次以上的脚本片段统统封装成自定义积木。这一条做到位后面维护大项目会轻松非常多。3.2 列表的实操场景排行榜、抽屉与随机抽取列表在Scratch中的角色相当于高级语言里的数组。第六课开始引入列表是因为项目复杂度上来了单靠变量已经装不下多个数据。想想看一个游戏要记录玩家前五轮的总分你用五个变量还算能忍如果要做本地排行榜记录前十名玩家和分数再用变量就完全失控了。列表的价值就是在一个有序容器里存一片数据。列表的基础操作看起来简单无非是添加、删除、替换、读取第几项但真正的实操难点在于“在什么时候修改列表”。我做过一个“月度累计得分”功能本来想每接住一个月饼就往列表尾部加一条记录结果因为循环跑得太快一次点击记录了十几条。后来改为用一个“是否已计分”的标记配合事件触发确保一次接住只写一条。列表还有几个经典应用很值得在第六课练一遍。第一个是随机抽取。把一堆奖励写在列表里用“列表[随机数1~项数]”取值实现随机奖励池这比用一堆单独变量去做随机分支要优雅得多。第二个是滑动窗口。记录玩家最近十次接月饼的得分每次新得分加入列表尾部同时删除第一项这样就能算出“近十轮平均分”。这个模式在真实数据分析里也很常见相当于一个环形缓冲区。第三个是排行榜的插入位置。用循环遍历列表找到第一个比当前分数小的位置把新分数插进去然后把多余的项删除保持列表只保留十项。这一段逻辑在Scratch里要嵌套好几个判断才能写完但写完一次以后你会对“排序”这个概念有非常直观的感觉。我带着学生走完这套流程后再回到C语言的排序章节几乎所有人反应都快了很多。4. 第六课实操项目中秋节接月饼小游戏的完整落地4.1 需求拆解与变量设计光讲概念不落地是学不会编程的。CS50课程的作业也强调Scratch部分必须自己做一个能运行的作品。恰好赶上中秋节我就把第六课的半命题作业做成了“中秋接月饼”小游戏。玩法很简单天上不断落下月饼玩家用篮子左右移动去接接到加10分漏掉扣1点生命生命归零游戏结束。先讲需求拆解。我拿到项目第一件事不是动手拖积木而是先列功能清单背景与角色月亮背景、兔子角色固定、月饼角色克隆生成、篮子角色玩家控制变量设计全局得分、全局生命值、当前月饼速度、连续接住次数、游戏状态事件流程绿旗点击进入开始界面按下空格游戏开始生命归零显示结束界面碰撞规则篮子颜色碰到月饼色块判定为接到接到后得分并删除该克隆体难度递增每接住一个月饼速度增加0.05速度越快生成间隔越短变量是整个设计的中心。我特意把“当前月饼速度”设成全局变量因为生成器要根据当前速度刷新克隆体“下落”脚本也要读取这个速度如果设成角色私有两边数据就同步不了。反过来“连续接住次数”这种只跟得分逻辑相关的量我就做成篮子角色的私有变量减少全局命名空间污染。4.2 月饼生成、碰撞检测与计分逻辑月饼生成用的是克隆这一步是第六课实操含金量最高的部分。生成器角色的脚本框架如下当绿灯亮起绿旗被点击 重复执行直到 游戏状态 结束 等待 (0.5 - 得分/1000) 秒 创建自身克隆体 拾取随机x坐标这样一个简单的循环配合克隆体启动脚本就能实现连续不断的月饼雨。但有个性能常识Scratch的克隆体上限是300个如果一个克隆体掉出屏幕后只是隐藏却不删除自己它会一直占用资源。我的克隆体脚本里有一条如果 y坐标 -190 隐藏 删除此克隆体删除自己这个操作能保证掉出屏幕的月饼立刻释放资源这是很多新手第一次做克隆作品时完全想不到的关键点。碰撞检测可以有两个路线。第一个路线是让月饼的克隆体每隔一小段检测“碰到篮子”第二个路线是让篮子在移动时检测“碰到月饼”。我实测下来前者的检测频率更容易控制因为月饼只有一个角色它会一直检测自己是不是被接住如果被接住就先加分再删除自己。分数不能直接加10分因为同一块月饼在碰到篮子那帧之后如果循环还在跑它可能会被判定第二次。我用一个“已接住”的私有变量判断一旦为真随即跳过之后的碰撞检测脚本。计分逻辑的细节值得展开。基础分10分连续接住会有连击奖励今天的床上连续接住第1个是10分第2个是12分第3个是14分依次递增每次漏掉清零连击这个规则用文本描述是三四行转换成Scratch就是如果 碰到篮子 将 连续接住次数 增加 1 将 得分 增加 (10 连续接住次数 * 2) 将 月饼速度 增加 0.05 删除此克隆体连击逻辑会推动玩家追求操作稳定性也让游戏画面更有情绪反馈。速度递增的幅度不要太大我一开始设成每次增加0.2没想到接到第三个就快得没法玩了调试之后改成0.05难度曲线才变得正常。这个参数调整没有任何文档会告诉你全靠现场试出来的手感。4.3 我踩过的坑与优化记录这个作品我前后改了三版三版里各有代表性的坑。第一版的问题是月饼下落脚本没有用局部变量所有克隆体共用同一个速度变量。结果是第一个克隆体创建后拉着速度变量从2变成2.05第二个克隆体启动时读到的已经是2.05等第一个克隆体还没掉落一半速度又被后续克隆体改大了。画面里所有月饼几乎以差不多的速度下落完全体现不出“新生成的更快”这个规律。解决方法是把每个克隆体的下落速度作为一个私有变量在克隆体启动时从全局变量读取一次之后各自独立。第二版的问题出在游戏结束判断。我把“生命值0”的判断放在月饼生成器的循环里没想到生成器循环里有一个“等待”积木导致游戏真正结束后还会多看几次循环偶尔出现“结束画面闪了一下又回到游戏”的怪象。后来我在每个关键流程入口加了“游戏状态”判断生成器只会在“游戏中”状态下继续生成结束脚本一旦置状态所有并行循环立刻退出效果稳定许多。第三版的是素材处理问题。中秋主题本来就该明亮温暖我一开始选了一张星空背景素材篮子用了深红色结果红色篮子和深色背景混在一起玩家总是看不清楚误判碰撞位置。换成高饱和橙色篮子加白色背景后游戏体验一下子上来了。重要经验游戏元素的可视性优先级高于视觉华丽度小孩子玩游戏第一反应是看到目标而不是欣赏美术。5. 常见问题与排查技巧实录5.1 高频问题速查表我在带着不同学生做CS50第六课作品和少儿编程中级项目时反复遇到下面这些相同的问题这里直接整理成一张速查表方便大家按图索骥。现象真正的原因排查思路克隆体出生后不动克隆体启动脚本没有被触发检查是否在“当作为克隆体启动时”里写了移动逻辑而不是普通绿旗里同一块月饼多次加分碰撞检测没有一次性保护加“已接住”判断接住后立刻删除克隆体游戏结束画面闪回并行循环未检查游戏状态在每个循环入口加“游戏状态”判断结束时就跳出循环得分变量数值巨大循环重复执行同一个加分操作加分操作应该绑定事件而非循环扫描或者用等待标记限制频率角色被挡住看不见图层层级设置问题用“移到最前面/移到最后面”调整角色层序第二次运行时数据没重置初始化没有放在统一入口把变量初始化集中到绿旗脚本覆盖延迟或被跳过的情况程序跑一段时间明显卡顿克隆体只隐藏没删除所有出界/用过的克隆体都要执行“删除此克隆体”按键移动方向反了坐标系理解错误Scratch里y坐标向上为正向右移动对应x坐标增加捋清后再写“说/思考”气泡永远不消失没有设置持续时间在“说”积木的第二个下拉参数里填入秒数不填会一直显示这张表我建议直接保存。我自己在辅导过程中发现初学者80%的报错都能归到这九类里面处理完这些剩下的才是真正的算法问题。5.2 独家调试思路让游戏告诉你问题在哪Scratch没有单步断点也没有print控制台输出但我摸索出了一套很实用的排查路子。第一个技巧善用“说”积木当调试输出。想知道某段脚本有没有执行就在里面加一句“说 调试信息2秒”如果画面里角色说出这句说明这段脚本确实跑了。比看代码猜测高效得多。这个招数用到真正编程语言里就是日志打印趁早在Scratch养成习惯很有好处。第二个技巧打开舞台“监视器”。在舞台左侧方块里有个“监视器”选项可以显示所有变量的实时数值。我调试月饼速度递增时就盯着监视器看每秒数字变化很快发现问题确实出在克隆体共享变量上。建议编程时把监视器固定在桌面角落养成实时观察数据的好习惯。第三个技巧让单个角色单独测试。程序崩的时候不是所有角色都得跑完全可以把不相关角色的事件块拖到一边只保留正在排查的那个角色配合空格事件逐步触发。这种“可控重现”是缩小问题范围最快的路径很多复杂问题其实都是多个角色脚本相互干扰导致的。第四个技巧每改一个逻辑就另存为一个版本文件。我原以为多存文件是浪费时间直到某次大改把整个下落的物理手感改坏了然后想回退到前一天版本才发现自己从没存档。现在我的项目文件夹里都是“接月饼_v1”“接月饼_v2”这种命名永远可以随时回到上一个稳定状态这相当于给项目管理建立了版本控制意识。最后再说一个很多人忽略的点Scratch的在线编辑器会自动保存但如果用的是“Scratch桌面版”离线编辑时一定要手动CtrlS。我见过辛苦两小时的作品因为断电直接丢了大半那种心痛经历一次就够。备份意识在编程的任何一个阶段都不过时。我自己在反复试验中最大的体会是第六课真正卡住大家的不是某个具体积木不会用而是心态上还没有从“照着做”切换成“自己规划”。一旦你把“变量是数据、自定义积木是函数、列表是数组、广播是事件通知”这层对应关系想明白Scratch就不再是玩具而是你通往C语言和Python的一座稳定桥梁。做完接月饼这个项目后面再去挑战《Scratch植物大战僵尸》或者任何带实时对战逻辑的作品就会发现骨架子都差不多。如果后续还有时间我会把同一套项目对比着移植到Python的pygame版本里那才是真正检验你理解深度的一步。