企业官网建设流程全解析

1. 元宵节和Scratch碰撞后的第一个问题：做什么才不像"大杂烩"？

每次到传统节日，我的Scratch交流群里都会冒出一批"求节日作品"的帖子。中秋要月亮嫦娥，端午要粽子龙舟，到了元宵节，最常看到的是把一堆和元宵沾边的元素硬塞进一个程序里——汤圆、花灯、灯谜、烟花全堆在舞台上，看起来热闹，但玩起来完全不知道重点在哪。

这个问题的根源在于，Scratch作品和PPT不一样，它不是用来"展示元素"的，而是用来"交互"的。观众打开你作品的第一秒就要明白：我该做什么？如果开场三秒内没有任何可点击、可操作、可回应的东西，那这个作品就失败了。

我自己在给孩子们设计元宵节案例时，会先画一张"玩法优先"的草图。什么是玩法优先？就是在动手写积木之前，先确定一件事：这个案例的核心交互动作是什么。比如"接汤圆"，核心动作是移动碗接东西；"猜灯谜"，核心动作是输入答案；"点亮花灯"，核心动作是点击目标。只要核心动作清晰，哪怕角色是个方块、背景是纯色，作品也能好玩。反过来，如果一开始就纠结"汤圆要画多圆""灯笼的流苏要几条"，很容易陷入美术细节，结果逻辑上一塌糊涂。

今天这篇分享，我整理了三个可以直接抄作业的元宵节Scratch案例，全部免费分享思路和关键积木逻辑。三个案例分别覆盖了Scratch中最常用的三类知识点：随机与变量、列表与条件判断、自定义积木与事件广播。它们不是花架子，是实实在在上过课堂、被小学生验证过好玩的作品。

先说明一点：我不会贴出完整截图式的项目文件，因为那些东西你拿走后不改一行代码，你的学生或孩子学不到任何东西。我更愿意做的是把每个案例的"积木设计思路"拆开讲透——你理解了逻辑，用Scratch积木搭出来只是时间问题。

2. 案例一：接汤圆小游戏——变量、随机数与碰撞检测的黄金组合

这个案例是三个案例里最基础也最适合新手的。游戏规则不复杂：舞台上不断从上方掉落汤圆，玩家用鼠标或键盘控制一个碗左右移动，接住汤圆得分，漏掉汤圆扣生命值，生命值为零游戏结束。

2.1 舞台与角色的准备细节

新建项目后，建议按以下方式准备素材：

• 舞台背景：可以用Scratch自带的"spots"风格背景，或者自己画一个深蓝色的夜空背景。如果你想更有节日气氛，可以在背景里画上几盏灯笼的轮廓——用椭圆工具画灯笼身体、线条画挂绳，不用画得多精致，模糊的剪影就够。
• 汤圆角色：用椭圆工具画一个白色圆形，加两个小黑点当眼睛、一条弧线当嘴巴。注意造型中心要设在汤圆的正中间，否则旋转时位置会偏移。
• 碗角色：用椭圆工具画一个半圆（碗身），加一个深色矩形（碗底）。同样，造型中心放在碗口的中心位置。

这里有个新手很容易忽略的点：角色的造型中心。默认情况下，Scratch角色的造型中心在图片的正中心，但用画板画图时，如果你从左上角开始画，中心点可能会偏到角落。选碗时尤其明显——如果中心点不在碗口中心，你移动鼠标时碗会"歪着跑"，手感非常差。修方法很简单：选中画板里的所有图形，用"左右居中+上下居中"按钮把图形对齐到画板中心。

2.2 汤圆的随机掉落逻辑：克隆体是主角

汤圆的掉落不建议直接用多个角色副本，而是用"克隆体"来实现。核心逻辑这样写：

1. 在汤圆角色里，先写"当绿旗被点击"的代码：每隔1到3秒（用"在1和3之间取随机数"）克隆一次自己。
2. 在"当作为克隆体启动时"代码块里，先让克隆体移动到舞台顶部的随机X坐标，然后让它不断向下移动，直到碰到边缘或碗。

为什么用克隆体而不是复制多个角色？因为克隆体能完美复用同一个角色的造型、变量和代码，而且克隆体的数量可以在运行时动态控制。你用"复制"方式做的话，得手动拖十几个汤圆角色到舞台上，每个都要单独写代码，改一个地方要改十几遍，维护成本极高。

汤圆的代码大致逻辑如下：

当绿旗被点击 重复执行 等待 在1和3之间取随机数 秒 克隆 [我自己]

克隆体启动后：

当作为克隆体启动时 移动到 x: 在-220和220之间取随机数 y: 170 显示 重复执行直到 <y坐标 < -160> 将y坐标增加 -3 如果 <碰到 [碗] ?> 那么 广播 [接到汤圆] 删除此克隆体 如果 <y坐标 < -160> 那么 广播 [漏掉汤圆] 删除此克隆体

2.3 碗的控制方式：鼠标跟随和键盘控制

这里我建议给玩家提供两种控制方式，让不同熟练度的玩家都能玩：

• 鼠标跟随：碗角色里写"重复执行，将x坐标设为（鼠标的x坐标），将y坐标设为（-140）"。鼠标在哪，碗就跟到哪。这个方式上手最快，但高手会觉得"太简单，没挑战"。
• 键盘控制：用左右键控制碗移动，每次移动5步。这个方式需要一定的反应速度，操作感更强。

一个进阶技巧：如果你想做"低门槛、高上限"的游戏，可以在开场时让玩家选择控制方式——用"询问并等待"积木问"请选择：鼠标（输入1）或键盘（输入2）"，然后用条件判断切换到不同代码。注意，键盘控制时要处理"按下多次方向键"的连续移动问题，不要用"重复执行直到"，要善用"如果按键按下"这个积木嵌套在重复执行里。

2.4 计分与生命值：变量是最直观的交互反馈

接住汤圆加分、漏掉汤圆扣命，这是变量应用的最好场景。建议新建两个变量："得分"和"生命值"。

• "得分"要在绿旗点击时初始化为0，每次接到汤圆时增加1（或5）。
• "生命值"初始化为5，每漏一个减少1。当生命值小于等于0时，广播"游戏结束"，停止所有脚本。

这里有一个非常重要的细节：变量的初始化和显示位置。很多新手会在"当绿旗被点击"里初始化变量，但忘了勾选"在舞台显示"复选框，结果玩家根本看不到自己的得分。请在舞台上右键点击变量显示块，选择"大字显示"或"正常显示"，并拖到合适位置（右上角是计分板的老传统）。

2.5 接汤圆案例的避坑经验与改进方向

我在课堂上跑这个案例时，遇到过几个很有意思的问题，写出来帮你避坑：

第一，"汤圆重叠"问题。因为随机掉落间隔是1到3秒，如果玩家运气好，两个克隆体可能同时出现在同一X坐标附近，视觉上像"两个汤圆合并成一个"，但计分却算两次。加一个简单判断可以缓解：创建克隆体前，让汤圆先在舞台顶部的随机位置"等待0.1秒再掉落"，或者限制随机X范围（比如只在-200到200之间取整数值，不要连续落在同一区间）。

第二，"接住判定"过于苛刻。我用"碰到碗"做判定时，发现汤圆下落速度设置为3时，玩家用键盘操作碗的移动速度是5步/次，经常出现"汤圆明明碰到碗边但又弹出去了"的情况。原因在于：汤圆的判定是基于角色碰撞边缘的，如果碗的边缘太薄，"碰到"积木的检测不稳定。解决方式是：把碗的碰撞区域画得大一些，或者用"距离小于某值"代替"碰到碗"，比如：

如果 <<距离 [碗] < 30> 或 <碰到 [碗] ?>> 那么 广播 [接到汤圆] 删除此克隆体

第三，"游戏结束"的清理工作。游戏结束广播后，舞台上可能还剩很多汤圆克隆体，如果不清理，它们会继续运动甚至穿过碗。正确的做法是：在汤圆角色里写一段代码响应"游戏结束"广播，将所有克隆体删除（可以用"当我收到[游戏结束]广播时，删除此克隆体"）。如果你用"停止所有脚本"，它会直接终止汤圆角色的所有脚本，但克隆体的删除需要显式处理，否则观众会看到"场上还有汤圆在飘"。

扩展方向也很明确：把汤圆换成其他元宵馅料（黑芝麻、花生、豆沙），做不同颜色；每接10个汤圆出现一个"金元宝"加分项；或者加入"冰糖葫芦"特殊道具随机出现，接住后5秒内速度翻倍。这些都能让作品从"能玩"变成"好玩"。

3. 案例二：元宵灯谜猜猜猜——列表、询问与条件判断的实战演练

如果说接汤圆偏"动作类"，那猜灯谜就是标准的"智力类"Scratch作品。它的逻辑更简单，但知识点密度高：要用到列表（存放题目和答案）、询问积木、条件判断和变量计分。这也是我们编程课堂上练习"循环+判断"组合拳最经典的项目。

3.1 题目从哪来：列表管理的两个思路

灯谜本质上是"题目+答案"的配对。Scratch用列表存题目和答案有两种思路：

思路一：用两个列表，一个存题目，一个存答案，用"编号"对应。

实现方式：

删除[题目]的全部项目 删除[答案]的全部项目 将[什么动物蹦蹦跳跳，耳朵长，尾巴短？]加入[题目] 将[兔子]加入[答案] 将[白白胖胖，猜一食物]加入[题目] 将[汤圆]加入[答案]

这种做法的好处是结构清晰，容易理解和修改。坏处是题目和答案必须一一对应，删改时要同步操作两个列表。

思路二：用一个列表，每个项目存"题目=答案"的格式，用分割符分开。比如：

将[白白胖胖，猜一食物=汤圆]加入[题库]

读取时用"记号"积木把"="左边和右边的文本分别提取出来。这种做法适合题量大的场景，代码稍微绕一点，但维护起来只有一个列表。

考虑到是零基础教学，我建议先做思路二，原因很简单：思路二只有一个列表，在小学生学习"列表索引"这个概念时，更容易理解"第几项"。等你熟悉之后，再升级成思路一对维护更友好——因为例子中两个列表的"第几项"是对应的，你可以在一个循环里同时读取两个列表的同一下标。

3.2 猜灯谜的主流程设计：不是简单的"一问一答"

很多初次接触这个案例的同学，写出来的代码是这样的：

询问 [问题] 并等待 如果 <回答 = 答案> 那么 说 [答对了] 否则 说 [答错了]

这种代码单题确实行得通，但放到"多题连答"场景就有问题了：怎么出下一题？怎么跳题？怎么随机抽题？怎么记录总共答对几题？所有这些都是这个案例的价值所在。

我的设计思路是：用编号变量控制出题顺序，用随机数打乱出题顺序，用计分变量记录得分。

3.3 具体步骤：出题、答题、反馈、计分

出题部分，以列表方式存储题目和答案，配合一个"编号"变量。在绿旗被点击时，初始化列表数据，并将编号设为1。

玩家点击"开始猜灯谜"角色（或直接按绿旗）后，进入主循环：

将[答对题数]设为[0] 重复执行直到 <编号 > [题目]的项目数> 将[当前题目]设为 [题目]的第 (编号) 项 将[当前答案]设为 [答案]的第 (编号) 项 询问 [当前题目] 并等待 如果 <回答 = 当前答案> 那么 说 [回答正确，你真是聪明的小灯笼！] (2) 秒 将[答对题数]增加[1] 否则 说 [不对哦，正确答案是：当前答案] (2) 秒 将[编号]增加[1] 说 [全部答完！你答对了 答对题数 题！]

这里有几个关键点值得展开：

第一，"询问并等待"积木有个坑。玩家输入答案时，Scratch会显示一个输入框，但如果玩家直接点对勾而不输入内容，回答会变成空字符串。空字符串不等于任何答案，会判错。如果想更友好，可以在判断前先检查："如果回答是空，则重新询问"。不过这个属于高级玩法，零基础阶段可以先不管。

第二，答案匹配的容错问题。玩家输"兔子"和"兔兔"算不算对？Scratch的"="积木做的是精确匹配，所以你要么严格出题，要么在出题时把题目问得足够具体，减少错误输入的概率。如果想做模糊匹配，可以用"如果 <[当前答案] 包含 [回答]> 或 <[回答] 包含 [当前答案]>"。这个技巧能让判断更宽容，但也会带来误判风险（比如答"子"就算对），看你的使用场景决定。

第三，随机抽题怎么实现？常规的做法是：出题前把编号随机打乱，比如用"将编号设为（在1和题目列表项目数之间取随机数）"，但这样可能连续出同一题。更好的做法是：另建一个"抽题顺序"列表，初始化时把1到N的编号加入列表，然后随机取一个编号，取过后从列表中删除，保证每个题目只出现一次。这个"随机抽题不放回"的逻辑，在Scratch里用列表操作也能做，是训练逻辑思维的好素材。

将[抽题顺序]的全部项目删除 重复执行 (题目列表的项目数) 次 将[编号]加入[抽题顺序] 重复执行直到 <抽题顺序的项目数 = 0> 设置[随机编号]为 (在 1 和 (抽题顺序的项目数) 之间取随机数) 设置[当前题目号]为 (抽题顺序的第 (随机编号) 项) 删除 抽题顺序 的第 (随机编号) 项 ...（用当前题目号查题目和答案）

3.4 进阶玩法：把灯谜变成"翻牌游戏"或"抢答赛"

光有列表和询问的灯谜，玩过一次后新鲜感会下降。我建议做两个升级方向：

方向一：灯谜翻牌。准备12张"灯笼牌"（用列表记录状态，比如"1表示未翻开，0表示已翻开"）。玩家点击灯笼牌时，如果状态是1，则翻开显示题目；如果是0则不可点。答对后灯笼牌变亮，答错则翻回去。这个设计加入了"记忆翻牌+答题"的双重机制，可以用来做课堂竞赛。

方向二：抢答赛制。两个玩家共用一个键盘，通过按"嗅探键"抢答：比如按A键代表左边玩家抢答，按L键代表右边玩家抢答。用"按下按键"事件或循环检测，结合变量记录抢答的玩家编号，答对加分，答错扣分。为什么用抢答？因为Scratch的"询问并等待"在多人场景下会阻塞，你需要改成"先抢答、再输入答案"的设计。

3.5 在这个案例中最值得教给学生的一个点

这个案例我每次上课都特别强调一个概念：程序里的数据存储结构决定了程序的上限。用多个角色堆故事、用一堆变量存问题、写几十个"如果那么"分支的程序，是小作品；而用列表统一管理数据、用循环批量处理、按索引取值的程序，是能无限扩展的作品。学生在做这个灯谜项目时，如果只满足于"我加了五道题就跑通了"，过两周再加二十道题就会发现：数据结构设计得不好，加题就是灾难。我说这句话可能有点抽象，但你亲自试一次就懂了——把题目放进列表前后维护成本的差距，是十万八千里。

4. 案例三：元宵花灯巡游——自定义积木、事件广播与造型切换的综合运用

前两个案例偏"游戏"，这个案例偏"动画+互动"。元宵节最浪漫的意象之一是花灯，而Scratch角色可以做花灯巡游：一排花灯在舞台上缓慢游动，玩家点击某一盏灯时，它会变亮、变色、讲一句祝福语，或者播放一段音乐。这个案例虽然没有那么强的"输赢感"，但在气氛烘托、交互体验和美术表现上做得好了，观赏性极强。

4.1 为什么要用自定义积木来组织这个案例

花灯巡游这个项目里有大量重复逻辑：每盏花灯都要做"上浮下沉摆动"、"闪烁"、"被点击后响应"。如果你复制十几个角色，每个角色的代码一模一样（只是换了造型），那维护成本就高了。自定义积木（"制作新的积木"）可以解决这个问题：定义一次通用的"花灯动画"积木，所有花灯角色调用同一个积木。

Scratch的自定义积木有两种类型：命令型（直接执行一系列动作）和报告型（返回一个值）。在这个案例里，我们主要用命令型。另外，自定义积木可以带参数，如果你是进阶用户，可以定义一个"花灯摆动速度"参数，这样每盏灯的摆动节奏可以不同，视觉上更有层次。

要提醒的是，自定义积木默认是"运行时不刷新屏幕"的选项，很多人会在这里卡一下。如果你在自定义积木里想让舞台立即更新显示，要去掉勾选"运行时不刷新屏幕"；如果你的自定义积木是纯计算逻辑（比如算一个数字），就可以勾选它来加速。区分这一点非常重要，否则你会遇到"灯半天不动"的怪问题。

4.2 一盏花灯的完整动作拆解

以单独一盏花灯角色为例，它的完整动作包括：

1. 绿色指示器闪烁：用造型切换模拟——花灯从"暗"造型切换到"亮"造型，间隔0.2秒。
2. 上下浮动：把y坐标在-5到5之间来回变化，用"将y坐标增加-1到1之间的随机数"配合边界判断，做出轻盈感。
3. 左右旋转轻微摇摆：角度变化控制在-15度到15度之间，太小看不出来，太大像杂技。
4. 被点击时播放一段优雅的动画：角色放大缩小、说祝福语、播放音效。

把这三段逻辑分别做成三个自定义积木：

定义 [闪烁动画] 重复执行 下一个造型 等待 [0.2] 秒 定义 [浮动动画] 重复执行 如果 <y坐标 < 20> 那么 将y坐标增加 [1] 否则 将y坐标增加 [-1] 等待 [0.05] 秒 定义 [点击响应] 重复执行 如果 <按下鼠标? 且 碰到 [鼠标指针] ? > 那么 说 [元宵节快乐！] (2) 秒 播放声音 [pop] 重复执行 [10] 次 将大小增加 [-2] 重复执行 [10] 次 将大小增加 [2]

4.3 事件广播的真正价值：让所有花灯响应同一个节日信号

如果你只想做"一盏灯"，那写分支就够了。但花灯巡游的亮点在于"多灯联动"：你点击广场中央的主灯，舞台上的所有花灯同时闪烁、变色、播放音效，形成"全城同庆"的观感。这时候"事件广播"就派上用场了。

主灯的点击响应代码里，广播一个"元宵节到啦"的消息。所有花灯角色都编写"当我收到[元宵节到啦]时，闪烁10次"，或者切换到下一套"节日模式"造型。广播可以带参数吗？Scratch自带的广播不能带参数，但它可以广播多条消息来传递信息（比如"开始闪烁"和"停止闪烁"）。如果你想在广播时传递更多信息，可以把参数存入"全局变量"再广播，接收方去读取这个变量。这是一种常见的Scratch模式。

事件广播还有一个用法：它能让不同角色之间解耦。比如舞台上除了花灯，还有一个"月亮"角色和"祝福词"角色。当广播"元宵节到啦"时，月亮角色可以播放一段"变亮+缓慢移动"动画，祝福词角色显示"团圆"两个大字飘过舞台。设计良好的广播体系，即使以后加20个角色，也不用改动彼此的代码——每个角色只管"我收到消息后怎么做自己的事"。

4.4 造型设计的经验：同一个角色，多套造型的力量

花灯巡游最大的工作量在美术，但有个性价比极高的方法：一个角色只画一个含多套"灯造型"的角色，通过造型切换实现"未点亮""点亮""更亮"三种状态。不要做三个角色，这样你就能用"下一个造型"积木快速切换，而且计分/碰撞检测都不受影响。

打开画板工具，先画一盏"普通花灯"（比如六角宫灯）：用椭圆+线段+矩形组合。然后右键克隆这个造型，改动一下颜色（比如把黄色改成橙红），作为"点亮"状态。再克隆一个，把亮度调高（用填充色更亮），作为"全亮"状态。这样一套三个造型，代码里"下一个造型"循环就能做出呼吸般的闪烁效果。

如果想让花灯巡游更有动感，可以给每个花灯角色设置不同的"巡游路线"。Scratch可以给角色设置"在(-200, -100)和(200, 100)之间随机位置"，但如果你希望它们沿着一条弯曲路径游行，可以用"滑行积木"串接多个控制点。比如主灯从舞台左边滑到中间，停顿2秒，再滑到右边，中间通过广播触发其他角色的跟随动作。

4.5 这个案例里我踩过的坑：噪音、角色重叠和"灯不走"

这个项目我实际在教学里跑过很多次，有几个常见坑值得单独写一写。

坑一：音效循环导致程序卡顿。花灯巡游要播放背景音乐，很多人习惯用"重复执行 + 播放声音直到播放完毕"，结果发现角色操作响应变慢，因为播放声音会占用大量CPU。建议用"播放声音[背景音乐]并等待，等待完后再从头播放"，或者用Scratch的"声音"标签页把背景音乐设为循环播放——比在代码里用循环更流畅。

坑二：花灯与花灯之间相互重叠。如果你让多个花灯角色都做"上下浮动"，它们的浮动相位往往相同，于是它们会"齐刷刷"一起上下，像一支训练有素的军队。这种整齐划一反而失去了节日街头的热闹感。解决方法是：在每个花灯角色里用"将y坐标增加（在-1和1之间取随机数）"来代替固定步长，再配合"等待（在0.1和0.3之间取随机数）秒"扰乱节奏。每个角色的浮动节奏略有不同，视觉上就活了。

坑三：广播消息积压在队列里。如果你在"当作为克隆体启动"里收到广播并执行长时间动画，同时主灯又频繁广播，克隆体可能根本来不及处理完上一条就收到下一条。解决思路：广播前用"等待"间隔，比如主灯点击后广播一次，然后等待0.5秒再允许下一次广播，避免消息风暴。

5. 三个案例怎么选：给家长、老师和自学者的一次性决策指南

前面三个案例，内容量和难度是逐步上升的。很多人看到"三个案例都分享"，第一反应是"那我全做"。但以我的经验来看，全做不是最优策略——选最合适的一个做精、做透，比三个都浅尝辄止更有收获。下面给出我的筛选建议。

5.1 按学习目标选案例

如果你是零基础家长带孩子入门，我强烈建议从"接汤圆"开始。原因很朴素：它有即时的视觉反馈（汤圆掉下来、碗接到、分数变化），孩子的成就感来得快，不容易中途放弃。编程教育的最大敌人不是"难"，而是"无聊"——给零基础的人做一个纯文本问答的灯谜，对他来说就是打字练习，毫无编程乐趣可言。

如果你是老师，计划在课堂里带一个元宵节主题的Scratch课程，我建议做"猜灯谜"或"花灯巡游"。因为这两个案例天然适合"先给框架、再让学生填充内容"的课堂模式：老师搭好列表和主循环，学生负责往列表里添加自己的灯谜题目；或者老师搭好广播体系，学生完善自己的灯角色造型。这样每个学生的作品最终都是不一样的，能激发创作欲。

5.2 按教学场景选案例

• 单次课（45分钟）：推荐接汤圆，但要做减法——只保留碗的移动+汤圆掉落+得分变量三个主干；不要求做生命值、多个道具和多种馅料。先跑通核心玩法，再慢慢加内容。
• 两三次课的短期项目：推荐猜灯谜，第一课时搭好列表和出题逻辑，第二课时加随机抽题和计分，第三课时美化界面或加抢答功能。
• 期项目：推荐花灯巡游，它适合多个课时持续迭代：每个课时加一个新角色或一种新动画，最后合成一台完整的"元宵晚会"。

5.3 一个容易踩的规划坑：过度设计

在选案例阶段，最大的坑不是选错案例，而是在设计阶段就野心太大。有个学员曾经跟我说他想做一个"元宵节大世界"：有汤圆工厂、灯谜塔、烟花秀、舞龙队……听到这个计划，我第一反应就是劝他砍掉至少一半内容。Scratch项目不是越复杂越好，它是越小越精越好。一个只有一朵烟花但控制得优雅的程序，胜过十个功能堆砌但逻辑混乱的项目。

我的实践原则是：一个作品只讲一个核心知识点，其他都是辅助。接汤圆的核心是变量和随机，灯谜的核心是列表和条件，花灯的核心是事件广播。加再多的花活，核心不能乱。这样不仅代码清晰，你在分享或教学时也更容易把知识点讲透。

6. 三个案例背后的编程思维课：变量、列表、广播的"节日化"拆解

做完这三个案例，认真复盘的话，你会发现它们不只是在做"元宵节主题"，而是在用编程思维重新组织一个节日场景。这一部分才是真正的隐藏知识点。

6.1 变量：让程序"记住"你玩了什么

在接汤圆案例里，"得分"和"生命值"是玩家状态的标记；在猜灯谜案例里，"答对题数"记录答题结果。这些变量背后的思维是：程序需要状态。没有状态的程序，做任何事都是"一次性"的——今天打开和明天打开没有区别。

很多初学者在学完变量积木后，经常会问"为什么我的变量不加分？"这类问题。排查方法很简单：先看变量是否初始化了（绿旗点击时设成0），再看加分指令所在的位置是否被触发了（比如"碰到碗"的碰撞检测是否写在了克隆体代码里而不是本体代码里）。我见过太多错误的"克隆体加分没生效"案例，最终都是把加分代码写在了"当绿旗被点击"里，而不是"当作为克隆体启动时"里——克隆体根本不会执行本体初始化的代码。这个排查思路本身，比做游戏更有价值。

6.2 列表：程序可以"有序地"处理大量数据

猜灯谜案例里的"题目列表"和"答案列表"，以及花灯巡游里控制巡游路线的"路径点列表"，都是在用数据驱动程序。这是Scratch教程容易忽略的一层：很多时候，Scratch学习者以为编程就是"拖积木"，但其实真正重要的是"定义数据结构"。

你留意观察：用列表做出题系统，和用"一个大字符串，中间用逗号分隔"来存题目，是完全不同的体验。前者结构清晰、方便增删；后者虽然代码手写快，但维护时容易出错。这些选择的背后的逻辑，其实就是计算机科学里的"数据结构选型"。虽然Scratch不会跟你说"数组""对象"这些概念，但你已经通过拖积木建立了朴素的认知，这对以后学真正的编程语言是极好的铺垫。

6.3 广播：程序各部分可以"解耦地"协同

花灯巡游里，主灯点击时广播"元宵节快乐"，其他角色各自有回应。这个机制的思维是：发起者和接收者不需要互相认识。主灯不需要知道花灯有几个、叫什么名字，它只管广播；任何角色只要接收广播，就能响应。

这个"间接通信"的思维在Scratch里看似简单，但它其实是软件工程里"观察者模式"、"事件驱动架构"的启蒙。很多孩子学完Scratch广播，再去学Python或JavaScript时，理解"事件监听""消息队列"会快很多——因为脑子里已经有了具象的"广播-接收"模型。

6.4 节日主题项目的一个隐藏优势：跨学科拓展

这三个案例还不只是编程。它们天然包含数学（分数的计算、随机数的概率感、计时与速率）、语文（灯谜的修辞与谜面创作）、美术（角色造型、背景构图、色彩搭配）、音乐（背景音效和节日音乐的选择）。做元宵节主题项目，其实是一个小型STEAM项目。

比如说，猜灯谜列表里的每一道谜题，设计谜面时就得想修辞和逻辑；接汤圆的随机掉落要理解"在一定范围内取随机数"带来的概率分布（为什么0到100之间每个数概率都相等，但"数值很大"和"数值很小"的感觉不一样）；花灯巡游里的摆动幅度涉及三角函数的直观感受（虽然Scratch不需要你用正弦函数，但你能直观看到"平滑的摆动"和"跳变的闪烁"之间的区别）。这些内容，如果单独做练习题，孩子会觉得枯燥；但揉在节日作品里，一切都变自然了。

7. 发布与分享环节：零成本做一份能拿得出手的元宵节Scratch作品

做完了案例，下一步自然是分享。但"分享"不等于把.sb3文件发到微信群里让朋友下载后打开——这样做门槛太高，很多人不知道如何用Scratch离线包打开，更别说跨平台分享了。所以这一节专门聊聊如何"零成本"让你的作品传播出去。

7.1 将作品打包成可执行文件：3分钟做到

Scratch 3有自带"文件-保存到电脑"的功能，这是给编辑者用的。但如果你不想让别人看到你的代码（或者对方电脑没有Scratch），可以做两步：

第一步，导出为视频。用Scratch 3的"录制视频"功能，或者用系统自带的录屏（Windows按"Win+G"、Mac用"QuickTime Player"）录下运行画面，再剪掉多余部分。视频的好处是人人能看，适合放社交媒体或发给家长群。缺点是无法交互，适合展示"动画型"作品（比如花灯巡游），不适合展示"游戏型"作品（比如接汤圆，观众自己不能玩）。

第二步，如果一定需要"别人能玩"的独立文件，Scratch 3可以用"打包器"工具（如turbowarp）导出HTML、Windows exe或macOS应用。Turbowarp是个开源在线编译工具，它能把Scratch项目打包成单个HTML文件——通过浏览器直接玩，不需要安装Scratch。要注意的是，Turbowarp默认会把项目编译成更快的运行方式，绝大多数情况下效果稳定，但个别复杂的项目（依赖音效循环或某些特殊扩展）可能会表现异常。发布前一定要自己测试一遍。

7.2 发布到社区：去哪儿、怎么写简介

很多Scratch学习者不知道，Scratch官网（scratch.mit.edu）有官方社区，注册后可以上传作品，任何人在线玩。中国境内访问Scratch官网有网络限制问题，如果打不开，可以用国内一些Scratch在线平台、编程猫社区、网易卡搭等——这些平台各有优势，上传作品前注意查看平台的版权和年龄要求。

上传作品时，标题和简介很关键。我的经验是两个原则：

原则一：标题里明确"互动点"。不要写"元宵节作品"这种泛泛的标题，而是写"接汤圆小游戏-你能接住多少分""元宵灯谜大挑战-10道题等你答""花灯巡游-点击每盏灯有惊喜"。这样别人在信息流里一眼就能知道"我能在这个作品里做什么"。

原则二：简介里写清楚"适合谁"和"怎么玩"。举个示例：

这是一个元宵节主题的Scratch小游戏。用鼠标或键盘左右键控制碗，接住从天上掉下来的汤圆，每接住一个得5分。漏掉一个扣1条命，一共5条命。看看你能坚持多久！适合Scratch初学者学习变量和克隆体的用法。欢迎点赞留言，我会更新更多节日主题案例。

这样写的好处是，老师/家长在搜索素材时，一眼就能判断作品的适合度和用法，省去下载后摸索的功夫。

7.3 分享时的"防坑"提示

一个很常见的坑是："作品运行起来没问题，但打包成HTML后音效不见了"。原因一般是：Scratch项目里用到的音频文件没有正确嵌入。Scratch官方在线编辑器是自动嵌入的，但Turbowarp等工具需要你在"项目文件"里确认音频已经作为"项目资产"包含进去。打包前先在Turbowarp里预览一次，如果没声音，回到Scratch项目文件里重新导入音频。

另一个坑是字体问题。如果你在作品里使用了特殊字体（比如汉字书法体），Scratch项目文件不会嵌入字体文件。别人打开时，如果系统里没有该字体，会显示为默认字体，排版可能错乱。"中秋快乐"变成"中秋快乐"还是同一字体的话没问题，但如果你的标题用的是美术字设计，可以转换成图片形式，用图片显示而非文本显示。

8. 从"做完一个案例"到"做出自己的元宵节系列"：我的四个复盘问题

最后想和大家聊聊做项目这件事本身。我见过太多人做Scratch作品是"教程说做什么就做什么"，做完一个案例发给老师或家长后，再也不打开那个项目。这样的学习效果，说实话很低。真正有效的学习方式，是在做完项目之后进行"复盘"。我每次带学生完成一个项目，都会要求他们回答这四个问题，我自己在设计案例时也以这四个问题为验收标准。

第一个问题：作品里最核心的3个积木块是什么？你能不能说清楚"它们各自做什么、少了它们作品会变成什么样"。答不出这个，说明你对程序设计还停留在"拖积木"层面，没有上升到"理解逻辑"层面。比如接汤圆里，"克隆"和"等待随机时间"这两个积木如果拿掉，游戏会瞬间失去动态性；"碰到碗"如果拿掉，计分就断了。你能不能说出来？

第二个问题：如果我要把这个作品改成另一种节日，需要改哪些地方？这是检验"数据结构设计"是否合理的关键。如果改中秋节只需要换背景和角色造型，改成春节只需要换祝福语，那说明你把"不变的程序逻辑"和"可变的主题内容"分开了——这是非常成熟的编程思维。反之，如果换个节日要把所有代码重写一遍，那一定是因为逻辑和内容没有解耦，下次设计时可以调整。

第三个问题：我有没有想过"如果用户不按我想的去操作会怎样"？一个优秀的Scratch创作者会考虑异常输入：如果玩家在灯谜里输入了空文本怎么办？如果玩家同时碰到碗和生命值边界会怎样？如果玩家连点两次按钮会不会卡死？这些问题体现了"用户思维"和"鲁棒性测试"，同样是软件工程师的核心素养。

第四个问题：我的作品有没有"好玩到我自己愿意再玩一遍"？这一点最容易被忽略。很多学生做完一个作品，自己只运行一遍验证"没有bug就交差"，往后根本没动力打开玩。如果一个作品连作者都不愿意玩，又怎么能指望别人玩呢？所以我在带项目时，会让学生先把自己的作品当"别人的作品"来玩三遍，记录下玩的过程中哪里觉得没意思、哪里卡住了、哪里想做却做不了，然后带着这些记录去迭代升级。我常说的那句话是："你造的第一个版本，永远是给你自己改成第二个版本用的垫脚石。"

这三个元宵节案例，从接汤圆的"动手感"，到灯谜的"烧脑感"，再到花灯的"氛围感"，每个案例都可以沿这个复盘路径深挖。做完一个，你可以试着去改造它：换题材（中秋节、春节、生日派对）、换玩法（限时模式、多人在线）、换角色（卡通汤圆、真人头像、自绘角色）。你会发现，"做例子"只是起点，"改例子"才能真正让知识长在自己身上。

最后给一个特别实用的小建议：把你做过的所有元宵节作品放到一个Scratch项目合集页里。用Scratch的"工作室（Studios）"功能，把接汤圆、猜灯谜、花灯巡游都加进去。这样你的分享不是孤立的一个个文件，而是一条"元宵节主题系列"的内容流。等明年元宵节再翻出来看，你能非常直观地看到自己一年来的成长轨迹。这种复盘带来的成就感，比任何外部的夸奖都有用。