简介面向全国青少年电子信息智能创新大赛图形化编程Scratch备赛者这份文档是按“必做题模拟三卷”整理的选择题练习集。它系统覆盖角色中心点与旋转、背景与绘图工具、舞台管理、隐藏/显示指令、重复执行与条件判断、碰撞检测、音量控制、坐标移动等编程基础并穿插图形序列推理、真假话判断、组合计数等逻辑思维题能帮助选手快速熟悉赛题题型与难度分布。资源包为1个docx文件压缩包大小约866KB轻量便于打印或导入阅读目前已有1579人学习下载。通过完整练习这套模拟卷参赛者可检验对Scratch核心指令的实际掌握程度结合题目后的答案解析和难度标注定位自身薄弱环节进而完善知识体系提升竞赛中的分析与解题能力。1. 不只是一张卷子从模拟题反推图形化编程的考点体系这套「必做题模拟三卷」拿到手的时候第一反应是40 道单选题难度标注全是「一般」看上去像是给小学生刷题用的。但真正逐题拆完发现它其实把 Scratch 运行时的关键机制全部压进了选择题里。中心点与旋转、坐标与方向、隐藏与显示、音量链路、布尔逻辑、进制判断甚至「代码写错了角色导致另一个角色动起来」这种典型排错场景都能在这 40 题里找到对应位置。刷这套题的正确姿势不是背答案而是把每道题当成一个运行时的行为预测题给定积木序列预判角色状态。这种方式对准备全国青少年电子信息智能创新大赛图形化编程赛项的选手有用对带赛的教练同样有价值——题目本身已经替你划好了知识边界。接下来按运动、外观、数据与逻辑、调试验证四个层面拆解每个层面都会落到可复现的代码和参数说明上。2. 运动与坐标旋转角度、路径移动与碰撞检测的运行时逻辑2.1 先搞清 Scratch 的方向约定和坐标范围Scratch 的方向体系与日常直觉略有差异0° 方向朝上90° 朝右-90° 朝左180° 朝下。舞台坐标范围 x 轴大约 -240 到 240y 轴大约 -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 # 布尔相加True1, False0 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 表示对应关系是 a10、b11、c12、d13、e14、f15。十进制十六进制二进制10a101011b101112c110013d110114e111015f1111进制题在图形化编程里不算高频操作但竞赛中经常作为「程序员的通用素养」出现。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才符合通用办公软件互换规范。本文还有配套的精品资源点击获取