简介：面向全国青少年电子信息智能创新大赛图形化编程（Scratch）备赛者，这份文档是按“必做题模拟三卷”整理的选择题练习集。它系统覆盖角色中心点与旋转、背景与绘图工具、舞台管理、隐藏/显示指令、重复执行与条件判断、碰撞检测、音量控制、坐标移动等编程基础，并穿插图形序列推理、真假话判断、组合计数等逻辑思维题，能帮助选手快速熟悉赛题题型与难度分布。资源包为1个docx文件，压缩包大小约866KB，轻量便于打印或导入阅读；目前已有1579人学习下载。通过完整练习这套模拟卷，参赛者可检验对Scratch核心指令的实际掌握程度，结合题目后的答案解析和难度标注，定位自身薄弱环节，进而完善知识体系，提升竞赛中的分析与解题能力。
1. 不只是一张卷子：从模拟题反推图形化编程的考点体系
这套「必做题模拟三卷」拿到手的时候，第一反应是：40 道单选题，难度标注全是「一般」，看上去像是给小学生刷题用的。但真正逐题拆完，发现它其实把 Scratch 运行时的关键机制全部压进了选择题里。中心点与旋转、坐标与方向、隐藏与显示、音量链路、布尔逻辑、进制判断，甚至「代码写错了角色导致另一个角色动起来」这种典型排错场景，都能在这 40 题里找到对应位置。
刷这套题的正确姿势，不是背答案，而是把每道题当成一个运行时的行为预测题：给定积木序列，预判角色状态。这种方式对准备全国青少年电子信息智能创新大赛图形化编程赛项的选手有用，对带赛的教练同样有价值——题目本身已经替你划好了知识边界。接下来按运动、外观、数据与逻辑、调试验证四个层面拆解，每个层面都会落到可复现的代码和参数说明上。
2. 运动与坐标：旋转角度、路径移动与碰撞检测的运行时逻辑
2.1 先搞清 Scratch 的方向约定和坐标范围
Scratch 的方向体系与日常直觉略有差异：0° 方向朝上，90° 朝右，-90° 朝左，180° 朝下。舞台坐标范围 x 轴大约 -240 到 240，y 轴大约 -180 到 180，中心点是 (0, 0)。「移动 10 步」的本质是在当前方向向量上位移 10 个单位，方向变了，位移方向跟着变。
中心点的概念也常考：角色围绕中心点旋转，且中心点可以设置在角色之外的某个位置，但中心点位置可以被修改。第 1 题里「中心点不能设置在角色之外」是常见错误选项，实际恰恰相反，把中心点挪到角色外部后，旋转轨迹会变成绕外部点公转，这是做钟摆、行星轨道类动画的常用手法。
| 方向值 | 朝向 | 移动 10 步后的坐标变化 |
|---|---|---|
| 0 | 上 | y 增加 |
| 90 | 右 | x 增加 |
| -90 | 左 | x 减少 |
| 180 | 下 | y 减少 |
2.2 用一段状态模拟器理解「面向 + 移动」的叠加效果
很多旋转类选择题，比如「角色向右旋转 180 度后状态如何」「角色初始面向左边(-90°) 执行某段程序后最终效果如何」，本质上都是方向值加减与坐标变化的计算。这里用 Python 写一个极简状态模拟器，方便逐条验证：
# 模拟 Scratch 角色的坐标与方向变化 x, y, direction = 0, 0, 90 # 初始坐标(0,0)，方向90°(向右) def move(steps): global x, y # 按 Scratch 方向约定：0°向上，90°向右，-90°向左，180°向下 if direction == 90: x += steps elif direction == -90: x -= steps elif direction == 0: y += steps elif direction == 180: y -= steps def turn(angle): global direction direction = (direction + angle) % 360 if direction > 180: direction -= 360 # 归一化到 -180~180，与 Scratch 显示一致 # 模拟：向右转180度，再移动10步 turn(180) move(10) print(x, y, direction) # 输出: 0 0 -90? 实际要看初始方向这段代码把方向和坐标拆成独立变量：direction存角色朝向，move负责按方向更新坐标，turn做角度累加并归一化。参数steps对应 Scratch 里的移动步数，angle对应左转/右转的度数。竞赛题里常见的「右转 180 度」就是direction += 180，转向后的朝向一定是原方向的反方向，角色外观上会呈现头尾颠倒的状态。
2.3 重复执行与碰到边缘：持续运动结构怎么选
第 23 题问「重复执行移到鼠标指针」的运行效果，答案是角色会持续追踪鼠标位置。这里要区分两个容易混的指令：单独一个「移到鼠标指针」只执行一次，角色移动一次后立即停止；外套「重复执行」后，每帧都会重新获取鼠标坐标并更新位置，实现跟随效果。
碰撞检测是另一个高频考点。第 21 题「角色移动过程中碰到舞台边缘说『你撞到我啦』」，红框处应选择带问号的侦测指令「碰到舞台边缘？」，而不是「碰到颜色？」或单纯的移动指令。用代码表示这个循环判断：
while True: move(10) # 持续移动 # 侦测条件：碰到舞台边缘 if touching_edge(x, y): say("你撞到我啦") break这里的touching_edge(x, y)对应 Scratch 里的「碰到舞台边缘？」侦测积木，它是一个条件表达式，返回值是布尔值。注意「碰到边缘就反弹」和「碰到边缘停止」是两种不同的处理策略：前者在旋转模式下会改变方向继续走，后者直接中断循环。做题时如果选项里同时出现这两种结构，要看清题目要求的是「说一句话」还是「反弹」。
2.4 坐标终态计算：连加之后的位置在哪里
第 25 题给出一段运动指令后问角色最终坐标，这类题只需要把每次位移的 x、y 增量做累加。比如角色从 (0, 0) 出发，先沿 x 轴移动 100 步，再沿 y 轴移动 100 步，终态就是 (100, 100)。难点不在计算，而在识别「移动」指令带不带方向约束。
一个常见误判是：认为「移动 100 步」永远向右。实际上「移动」指令沿角色当前方向前进，只有先把方向设为 90°，移动 100 步才会让 x 增加 100。做题时我习惯先在草稿上画出方向向量，再标每次位移的 x、y 分量，最后合并。这个过程和调试真实 Scratch 工程时观察坐标变化完全一致——把「x 坐标」「y 坐标」勾选显示在舞台左上角，就能实时看到数值跳动。
3. 外观、舞台与声音：状态切换背后的隐藏指令与资源管理
3.1 舞台与角色：哪些能做、哪些不能做
舞台的机制和角色不同：舞台可以有多个背景，背景之间可以切换，但舞台背景本身不能像角色那样自由移动。第 4 题「舞台中背景可以移动」是不正确描述，这是舞台区别于角色的核心边界。另外，「把角色当背景来用」是允许的——常见做法是把一个大矩形角色放在舞台最底层充当静态背景，虽然通常不推荐，但技术上可行。
背景的编辑操作也会考：要去掉背景中不需要的部分，应该用绘图编辑器里的「橡皮擦」工具，不是画笔或选择工具。这里有个细节：Scratch 3.0 的位图模式下橡皮擦是像素级擦除，矢量图模式下橡皮擦直接删除选中的矢量对象。题目问的是工具选型，实际开发中这决定了你要用「选择工具」删对象还是「橡皮擦」擦像素。
3.2 外观积木的运行语义：隐藏、显示与大小累加
第 6 题考隐藏指令。Scratch 里让角色隐藏的标准积木是「隐藏」，显示是「显示」。但要注意，隐藏只是让角色在舞台上不可见，角色仍然参与运动、侦测和声音播放。这在调试时常被忽略：角色看不见了，但音量还在响，其实是因为隐藏没有停止代码执行。
外观类的另一类考点是大小变化。第 24 题要求「苹果」角色当前大小为 30，执行后大小增加 10，正确选项应该用「将大小增加 10」。这里要区分「增加」和「设为」的差异：「将大小增加 10」是在当前值上加 10，多次执行会累加；「将大小设为 40」则直接设置基准值，重复执行永远停留在 40。
| 外观积木 | 运行时效果 | 常见误用 |
|---|---|---|
| 隐藏 | 角色不可见，但代码继续运行 | 误以为代码也被停止 |
| 显示 | 角色重新可见 | 隐藏后忘记恢复显示 |
| 将大小增加 10 | 当前大小加 10，可累加 | 误以为会重新设置基准值 |
| 将大小设为 100 | 直接设为指定值，不累加 | 与「增加」混用导致大小漂移 |
| 下一个造型 | 切换到造型列表的下一个 | 与「换成指定造型」混淆 |
第 27 题问「运行完程序后回到最开始状态」应选哪个指令，答案是用「当绿旗被点击」配合「移到 x/y、面向、将大小设为」一组的初始化积木。编程习惯上这叫做重置状态：把坐标、方向、大小、造型全部显式设回初始值，避免上一次运行残留的状态干扰这一次的判断。竞赛中角色状态不重置导致的「灵异现象」，占了调试问题的一大半。
3.3 声音管理：音量链路与「静音」的正确实现
声音相关的选择题集中在音量控制和静音实现上。第 20 题是典型链路计算：音量从 80 开始，经过若干「将音量减少」积木后，最终值是多少。只要按顺序做加减法即可，但要注意「将音量设为」和「将音量增加/减少」混用时的语义差异：
# 模拟音量积木链的执行过程 volume = 80 volume -= 20 # 将音量减少20 -> 60 volume -= 30 # 将音量减少30 -> 30 volume -= 10 # 将音量减少10 -> 20 print(volume) # 输出 20这段计算对应第 20 题的答案 20。参数说明：每次「减少」都是对当前音量值做减法，不是相对初始值。第 40 题问哪组指令能精确定位声音大小，正确选项是「将音量设为 XX %」这类赋值型积木，因为「音量增加 10」只能在当前基础上递增，无法保证绝对精确。
第 12 题和第 22 题都涉及静音：动画初始需要静音效果，应该用「将音量设为 0%」，而不是「停止所有声音」。「停止所有声音」会中断所有正在播放的音频，但音量设置本身仍然是 100%，下一次播放声音时会直接恢复响度。把音量设为 0 则更彻底，相当于在声音链路的输出端做了衰减。如果想要背景音乐循环播放且不产生噪音干扰，常见做法是：设置音量为 0% 启动，播放到指定循环次数后再逐步调高音量。
4. 数据、进制与条件判断：逻辑推理题的编程化求解
4.1 三个盒子问题：把自然语言编译成布尔表达式
第 14 题的盒子问题很经典：玩具放在蓝、红、黄三个盒子之一，三个盒子上各有一句话，只有一句真话，问玩具在哪。这类题不用硬推，直接穷举三种放置假设，用 Python 验证哪组假设让真话数量恰好为 1：
# 蓝色盒子：「玩具在这个盒子里」 # 红色盒子：「玩具不在这个盒子里」 # 黄色盒子：「玩具不在蓝色盒子里」 # 三个陈述中只有一个为真，验证玩具位置 def only_one_true(pos): s1 = (pos == "blue") # 蓝色盒子陈述 s2 = (pos != "red") # 红色盒子陈述 s3 = (pos != "blue") # 黄色盒子陈述 return (s1 + s2 + s3) == 1 # 布尔相加：True=1, False=0 for pos in ["blue", "red", "yellow"]: print(pos, only_one_true(pos))运行结果是：玩具放在蓝色盒子时真话数是 2，放红色盒子时真话数是 1，放黄色盒子时真话数是 2，所以答案是红色盒子。把布尔值直接相加是这类题最省力的解法。Scratch 里没有「真值数量求和」这一积木，但可以用「如果…那么」逐条累加一个变量来实现相同逻辑。做题时记住：唯一真话题优先做真值表统计，别凭直觉定性。
4.2 二进制与十六进制：识别数据表示的基本约束
第 34 题问哪个数可以表示为二进制，答案是「10111」。二进制数的每一位只能是 0 或 1，所以包含 2、8 的数字全部排除。第 32 题考十六进制符号：10 用小写字母 a 表示，15 则用 f 表示，对应关系是 a=10、b=11、c=12、d=13、e=14、f=15。
| 十进制 | 十六进制 | 二进制 |
|---|---|---|
| 10 | a | 1010 |
| 11 | b | 1011 |
| 12 | c | 1100 |
| 13 | d | 1101 |
| 14 | e | 1110 |
| 15 | f | 1111 |
进制题在图形化编程里不算高频操作，但竞赛中经常作为「程序员的通用素养」出现。Scratch 没有直接的进制转换积木，不过可以用「运算」类积木做字符串拼接模拟：反复除 2 取余数，倒序拼接就是二进制结果。
4.3 条件选择与顺序执行：输入 100 为什么会输出「半票」
第 39 题输入 100，程序输出「半票」，说明代码里嵌套的是「如果 输入 < 某值 那么 全票 否则 半票」这种结构。用 Python 写逻辑等价式：
num = int(input("请输入数值：")) if num < 100: print("全票") # 条件满足执行分支 else: print("半票") # 条件不满足执行分支把 100 输入进去，num < 100为假，落到 else 分支输出「半票」。第 30 题单独考查这种结构的语义：如果满足条件，执行指令包含的脚本模块，答案选 B。注意区分「不满足条件执行」和「满足条件重复执行」：条件积木后面接的是单次分支，不是循环；如果需要循环，必须再套「重复执行直到」或「重复执行」外层结构。
第 33 题考嵌套条件：键盘输入的数大于 10 就改变角色大小，否则改变角色特效。这类题的关键是找对「如果…那么…否则」的结尾位置，否则容易把两个分支的执行范围看混。我的检查方法是：从「如果」开始层层配对，像检查括号一样确认每个「否则」对应哪个「如果」。
4.4 找规律题：从图形序列到取模运算
第 10 题是图形找规律，第 35 题是三角形旋转 100 圈后顶部编号。图形序列题在 Scratch 场景下通常可以转化为「造型编号 + 取模运算」：图片缺失不影响做题逻辑，关键是找出图形的周期性变化周期。
第 35 题的三角形三个顶点编号 1、2、3，顶部编号为 1，每旋转一次顶部编号按顺序变化，旋转一圈回到原状态。100 次旋转相当于 100 % 3 = 1，余数是 1，所以顶部编号变成 2。用代码验证：
top_id = 1 # 初始顶部编号 cycle = 3 # 三个顶点构成旋转周期 rotations = 100 # 旋转次数 result = (top_id + rotations % cycle - 1) % cycle + 1 print(result) # 输出 2这段代码的思路是：把编号先减 1 归零，加上旋转次数对周期的余数，再取模并加 1 还原。参数rotations可以随意替换，比如旋转 99 次结果就是 1，旋转 101 次结果就是 3。图形推理题一旦发现「循环」「重复」特征，就往取模方向思考，比逐次画图快得多。
5. 把静态选择题改造成可调试的图形化代码片段
填空题和选择题只能验证「结论对不对」，验证不了「过程中间发生了什么」。实操中我习惯把每道疑似有争议的单选题，在 Scratch 里改造成一个最小验证工程，用绿旗启动后直接观察舞台状态。
第一个技巧是用「说」积木当调试输出。比如验证「重复执行移到鼠标指针」和「移到鼠标指针」的差别，在循环里加一句「说 连接 (x坐标) 和 (y坐标)」，舞台角色头上会实时显示坐标，肉眼就能看到坐标是否跟随鼠标持续更新。这个思路等效于在代码里埋 console.log 打印中间变量。
当绿旗被点击 重复执行 说 [x: (x坐标) y: (y坐标)] 移动 (10) 步 如果 <碰到舞台边缘?> 那么 说 [撞到了] 结束 结束这段积木流程把「移动 + 侦测 + 输出」三件事串在一起，调试第 21 类碰撞题时可以直接套用。把「碰到舞台边缘？」换成「按下鼠标？」或「碰到颜色？」，也能快速验证不同侦测条件的触发时机。
第二个技巧是针对第 8 题这类「代码跑错角色」的问题：在角色 A 的脚本区完成编程，运行时却是角色 B 在执行。本质是脚本区的积木归属错了，代码被拖到了角色 B 的脚本区。排查时先看舞台下方角色列表的高亮状态，点中角色 A 后查看脚本区里是否有完整代码，再用「说」积木在脚本开头输出当前角色名，立刻能分辨代码挂在谁身上。
第三个技巧是双角色对照验证：新建两个角色，一个执行候选正确代码，一个执行候选错误代码，同时点击绿旗运行。两个角色同步运动时，行为差异会在几秒内暴露。第 29 题这类「左转与右转」的选项差异，用双角色对照比盯着积木块推理直观得多——一个往左转一个往右转，方向立刻分开。
最后一个建议是输出层的问题：把整理好的题解和验证结果导出分享时，注意保存格式选.docx，不要用某些文字处理软件的私有默认格式，避免传到比赛群里对方打不开。WPS 环境里如果默认新建的是私有格式，手动「另存为」选择 Word 文档即可，后缀必须是.docx才符合通用办公软件互换规范。
本文还有配套的精品资源，点击获取
