巧lq幼儿园中班下学期正好是逻辑思维和观察力训练的关键期，“找影子”这类游戏卡片我做了不止一套，但纸质的用几次就皱、就丢，而且每个班三十多个孩子，老师得准备好几份才能轮流转。后来我干脆把这套练习做成了HTML课件，直接投到希沃白板上用，触屏点一点、拖一拖就能玩，效果比预想好不少。这篇就说说我怎么做这套“找影子01”课件的，从页面结构到拖拽判定逻辑，再到怎么在希沃白板里稳定跑起来，适合想自己动手做课堂小游戏的老师参考。
做这套课件之前我给自己定的要求很明确：课件以HTML + 原生JavaScript实现，最终运行环境是希沃白板，整个课程场景是幼儿园或小学低年级的课堂互动。目标不是做得多花哨，而是够直观、够好点、不会在课堂上出岔子。下面把设计和实现一步步拆开讲。
1. 课件定位与整体设计思路
1.1 “找影子”这个题型背后的认知逻辑
“找影子”不是简单的“看着像就连线”，它对幼儿来说是一个典型的视觉感知与图形匹配任务。孩子看到彩色物体，再看到对应的黑色轮廓，需要在大脑里完成一轮“形状提取”和“轮廓比对”。这个过程锻炼的是图形辨别能力、细节观察力和空间对应感。如果课堂上只是让小朋友在纸上圈一圈，其实缺少了动手验证的环节，互动性也不够。
我把它做成课件后，交互方式变成“观察影子—拿起卡片—放到影子上面验证”。这个动作比拿笔圈画更能调动孩子的参与感。配合上即时反馈——“对了”会打勾并播放小动画，“错了”会轻轻弹回并提示再试，孩子会在一次次尝试中记住物体轮廓之间的差异。这个设计完全是围绕儿童认知节奏来的，不是为技术而技术。
1.2 为什么选HTML而不是希沃自带的课堂活动
希沃白板自带的课堂活动模板确实方便，选个模板填词就行。但我做这套“找影子”时，为什么绕开它自己写HTML？原因有三个。
一是匹配模式不灵活。希沃自带的配对活动更适合“词语配图片”“单词配中文”这类有明确答案的文本型配对，对“彩色图对黑色剪影”这种既要看出轮廓、又需要漂亮视觉呈现的场景，模板的表现力有限。
二是改动成本不一致。自带的课堂活动一旦要换题型逻辑，基本等于重做一遍。而HTML课件是纯文本代码，我在备课时想调题目、换图形、加减难度，只要改一个数组，刷新页面就生效，根本不用重新开发。
三是这套课件不只是在这一个班级用。HTML文件拷到任何能打开浏览器的设备上都能运行，不管是希沃一体机、普通电脑加投影，还是后续想让学生自己在平板上玩，都无障碍。跨设备的自由度是课堂活动模板给不了的。
各方案对比可以看这张表：
| 对比项 | 希沃自带课堂活动 | HTML自研课件 |
|---|---|---|
| 模板灵活度 | 受限于内置题型 | 完全自定义 |
| 题目修改成本 | 逐个编辑 | 改数据数组即可 |
| 跨设备能力 | 依赖希沃账号体系 | 任意浏览器即可打开 |
| 视觉表现力 | 中规中矩 | 可自由设计 |
| 备课上手门槛 | 低 | 需要一点代码基础 |
1.3 页面布局与交互模式的规划
“找影子01”是第一课，整体难度设置为基础匹配，总共设计了6组物体，同一屏全部展示。页面采用左右分栏结构：左侧是一列黑色影子，右侧是彩色物体卡片，卡片顺序做了打乱处理。孩子们需要把右侧的彩色图拖到左侧对应的黑色轮廓上，匹配成功时卡片吸附到影子上，匹配失败则自动弹回原位。
这个布局参考了纸质练习册的分栏习惯，因为孩子对这种“左边是答案区、右边是素材区”的版式已经很熟悉。交互上每张卡片做得够大，间距拉开，避免手小的孩子误触相邻元素。重点是把误操作的可能性降下来。
为了照顾不同习惯的孩子，我还预设了两套操作方式。默认是拖拽式，直接按住彩色卡片拖去影子区域松手；同时支持点击式，点一下彩色卡片选中它，再点一下目标影子完成匹配。幼儿手指控制力不够精细，很多孩子拖到一半就松手了，这时候点击式就是很好的兜底方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零搭建课件页面结构与资源准备
2.1 页面基础结构
HTML的结构我保持得尽量简单。外层用一个容器限定宽高比例，因为希沃白板屏幕比例是16:9，页面就按16:9来定。标题栏放在上方，游戏区占剩余空间。游戏区左侧是影子列表，右侧是卡片区。
html复制<!DOCTYPE html>
<html lang="zh-cn">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>找影子01</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<div class="game-container">
<header class="game-header">
<h1>找影子</h1>
<p class="subtitle">把右边的卡片拖到它对应的影子上面</p>
</header>
<main class="game-main">
<div class="shadow-zone" id="shadowZone"></div>
<div class="card-zone" id="cardZone"></div>
</main>
</div>
<script src="game.js"></script>
</body>
</html>
对于不熟悉代码的老师再说一句，这段HTML管理的是“页面上要显示哪些区域”，类似盖房子先搭框架。真正的房间隔断和装修，要交给CSS；负责通电和智能响应的，是后面的JavaScript。三者各司其职，缺一不可。
2.2 游戏中“图形素材”的选择与处理
课题是找影子，影子必须是黑色轮廓。做图案素材时，我用了两种方案结合。第一种是直接用SVG图形，适合外形有典型特征的物品，比如太阳、房子、树；第二种是使用Emoji字符加上CSS的亮度滤镜，把彩色Emoji压成黑色剪影。
css复制.emoji-shadow {
filter: brightness(0);
-webkit-filter: brightness(0);
}
这个方案能大大减少找图的时间。例如“苹果”用红苹果Emoji，“雨伞”用雨伞Emoji，显示成黑色剪影效果时轮廓绝对清晰，毕竟苹果的果蒂、叶子的分叉都能保留下来。
需要注意，开发时按对象存储数据时，每个物品配了三个属性：主要用于显示的彩色图地址、影子图地址、名称。结构如下：
javascript复制const items = [
{ id: 'apple', name: '苹果', icon: '🍎', shadowIcon: '🍎' },
{ id: 'umbrella', name: '雨伞', icon: '☂️', shadowIcon: '☂️' },
{ id: 'sun', name: '太阳', icon: '🌞', shadowIcon: '🌞' },
// 更多题目...
];
这里我踩过一个坑，值得专门提出来：Emoji在不同操作系统里的渲染风格差异非常大，比如苹果系统和安卓系统里的“树”或“蘑菇”，轮廓细节各不相同。同一个Emoji做成影子，如果一台设备上是圆角的，另一台上是直角轮廓，就会造成孩子识别上的困扰。
所以在选定题目后，我在本地浏览器、希沃白板内置浏览器里都做过渲染测试，优先选用跨平台差异较小的Emoji，实在不行的换成SVG手绘轮廓。这个“渲染一致性”的检查，是这次制作中最耗时间也最关键的一环。
2.3 影子与卡片的DOM渲染
页面里所有卡片和影子都由JavaScript动态生成，不在HTML里写死。原因很简单，以后换第二课、第三课，只需要换数据数组，页面结构自动适配。
javascript复制const shadowZone = document.getElementById('shadowZone');
const cardZone = document.getElementById('cardZone');
// 生成影子
items.forEach((item, index) => {
const shadowEl = document.createElement('div');
shadowEl.className = 'shadow-item';
shadowEl.dataset.id = item.id;
shadowEl.innerHTML = `<span class="shadow-icon">${item.shadowIcon}</span>`;
shadowZone.appendChild(shadowEl);
});
// 生成打乱顺序的卡片
const shuffled = [...items].sort(() => Math.random() - 0.5);
shuffled.forEach((item) => {
const cardEl = document.createElement('div');
cardEl.className = 'card-item';
cardEl.dataset.id = item.id;
cardEl.innerHTML = `<span class="card-icon">${item.icon}</span>`;
cardZone.appendChild(cardEl);
});
动态渲染有另一个好处是方便调整难度。比如后面要出难度高一级的《找影子02》，把影子乱序、背景换成更复杂的图案，只要改CSS类名和数组内容就完成新的一课。一次开发的模板可以反复用，后续做“找影子02”“找影子03”都只需要复制工程改数据，效率会高很多。
3. 拖拽匹配与交互反馈的核心实现
3.1 匹配判定是怎么做的
匹配判定不是拿两张图片逐像素比对，那是图像识别要干的事。这里用的是几何逻辑：判断被拖动的卡片中心点，是否落入目标影子所在的矩形范围。
具体分成三步：
- 拖动结束时，获取卡片当前的中心点坐标，通过
getBoundingClientRect()计算； - 遍历所有尚未匹配成功的影子元素，同样用
getBoundingClientRect()获取它们的矩形区域； - 逐一检查卡片中心点是否落在某个影子的矩形内，如果命中就再判断数据ID是否一致。
javascript复制function getCenter(el) {
const rect = el.getBoundingClientRect();
return {
x: rect.left + rect.width / 2,
y: rect.top + rect.height / 2
};
}
function checkMatch(cardEl) {
const cardCenter = getCenter(cardEl);
const shadows = document.querySelectorAll('.shadow-item:not(.matched)');
for (const shadowEl of shadows) {
const rect = shadowEl.getBoundingClientRect();
const isInside = cardCenter.x >= rect.left && cardCenter.x <= rect.right &&
cardCenter.y >= rect.top && cardCenter.y <= rect.bottom;
if (isInside) {
const cardId = cardEl.dataset.id;
const shadowId = shadowEl.dataset.id;
if (cardId === shadowId) {
return { matched: true, shadowEl };
} else {
return { matched: false };
}
}
}
return null;
}
判定容差是个容易被忽略的细节。从视觉上看，孩子不一定会把卡片端端正正放在影子正中间。如果判定范围占满整个影子格子，就容易出现“卡片只搭了一个边也算对”的误判。我实际测试后，把有效判定区域设定为影子元素矩形内部向中心收缩10像素的范围，这样既不会太苛刻，也不会过于宽松。
3.2 两类事件的兼容处理
卡片要能被“拿起来、放下”，需要监听三类常用事件：鼠标事件、触摸事件、指针事件。希沃白板运行时，我测试下来最稳定的是直接用Pointer Events指针事件，一套事件同时覆盖鼠标和触摸屏操作，并且能拿到按压、移动、松开的完整过程。
但考虑到有些电脑用的浏览器版本稍旧，对Pointer Events支持不好，稳妥起见我加了一层兼容降级处理。核心逻辑是写一个统一的事件注册函数，优先注册Pointer Events，不支持时自动回退到mouse和touch事件。实际开发中我用了一个小的分发辅助函数来做。
javascript复制function bindDrag(el) {
if (window.PointerEvent) {
el.addEventListener('pointerdown', onPointerDown);
} else {
el.addEventListener('mousedown', onMouseDown);
el.addEventListener('touchstart', onTouchStart, { passive: false });
}
}
移动卡片时注意一个关键点：如果用 touchmove，必须加上 preventDefault() 阻止页面滚动，否则在触屏上一拖卡片，整张页面会跟着滚动，这是第一次触屏调试时最让人头痛的问题。
另外，触摸事件里拿坐标的方式和鼠标不一样，触摸事件要从 event.touches[0] 里取。如果不区分这两类事件，直接写 event.clientX，触摸时就会拿到 undefined，掉进“拖不动”的坑。
3.3 拖拽过程的视觉跟随
卡片被选中后要能跟着手指或鼠标动，我用的方案和多数轮播组件一样：拖动开始时把卡片设为绝对定位，并提升层级，防止被其他元素盖住；拖动过程中不断更新它的 left 和 top 值；拖动结束再判断是否匹配。
javascript复制let dragging = null;
let offsetX = 0, offsetY = 0;
function onPointerDown(e) {
const cardEl = e.target.closest('.card-item');
if (!cardEl) return;
dragging = cardEl;
dragging.style.position = 'fixed';
dragging.style.zIndex = 1000;
dragging.style.transition = 'none';
offsetX = e.clientX - dragging.getBoundingClientRect().left;
offsetY = e.clientY - dragging.getBoundingClientRect().top;
}
function onPointerMove(e) {
if (!dragging) return;
e.preventDefault();
const x = e.clientX - offsetX;
const y = e.clientY - offsetY;
dragging.style.left = x + 'px';
dragging.style.top = y + 'px';
}
这里把定位直接设成 fixed，好处是不管卡片原来在什么容器嵌套里，拖动时都能相对于视口移动，不用去换算父容器的偏移量。结束匹配后，再根据匹配结果决定卡片“留在影子处”还是“弹回原位置”。弹回时需要用到过渡动画，也就是把 transition 从 none 改成 all 0.3s ease，就能做出很顺滑的归位效果。
3.4 成功的激励反馈设计
幼儿课堂对“答对了”的反馈要求很高，光是一个对勾，孩子们看了两轮就会没兴趣。反馈得“有声音、有动画、还有集体感”，才接得住课堂气氛。
我的反馈组合是：匹配正确后，卡片变成一个缩小的绿色光圈，同时底部弹出“对了”的提示文字；全部完成时，顶部播放一段撒花效果，模仿奖杯闪光的氛围。
音效部分要提醒一下，尽量不用外链音频，因为课堂网络不稳定，一旦音频加载失败，反馈就哑了。我采用的是Web Audio API直接合成简短的提示音：
javascript复制function playSuccessTone() {
const ctx = new (window.AudioContext || window.webkitAudioContext)();
const osc = ctx.createOscillator();
const gain = ctx.createGain();
osc.connect(gain);
gain.connect(ctx.destination);
osc.frequency.setValueAtTime(523, ctx.currentTime); // 高音
osc.frequency.setValueAtTime(784, ctx.currentTime + 0.12);
gain.gain.setValueAtTime(0.2, ctx.currentTime);
gain.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + 0.4);
osc.start(ctx.currentTime);
osc.stop(ctx.currentTime + 0.45);
}
用代码生成音频的优势在这个场景非常明显：没有外部文件依赖、不存在跨设备播放兼容问题、不需要网络加载，课件复制到任何一台机器上都能稳定发声。
3.5 点击匹配兜底方案
点击模式的具体逻辑是：如果孩子长按卡片超过了500ms还没开始拖动，就判定为“选择模式”，卡片进入高亮选中状态。此时孩子松手，再点任意一个影子，系统会直接拿选中卡片的ID去和影子比对，匹配逻辑完全复用拖拽模式里的判定函数。
这里要注意交互状态管理和拖拽状态不要冲突。我用一个状态变量 selectedCard 独立于 dragging，点击模式启动时不会触发拖拽的 pointermove 逻辑。核心代码就是在 onPointerUp 里判断：
javascript复制let selectedCard = null;
// 在pointerup时判断，如果是短按且没有明显位移
function onPointerUp(e) {
if (!dragging) return;
if (hasMovedShortly) {
// 当作点击，选中该卡片
selectedCard = dragging;
dragging.classList.add('selected');
} else {
// 常规拖拽匹配
checkAndMatch(dragging);
}
dragging = null;
}
设计这个兜底的出发点是观察到真实的幼儿操作：低龄孩子对“按住不放并移动”这个动作的掌控力差异很大，有的孩子总是一碰到屏幕就松手，卡片只移动了一点点距离就掉下来。如果只提供拖拽交互，这部分孩子就会一直失败，进而产生挫败感。课堂互动公平性也是老师备课要考虑的维度。
4. 导入希沃白板并保障课堂稳定运行
4.1 两种在希沃白板中打开HTML的方式
课件在浏览器上测试没问题，下一步就是投到希沃白板。希沃白板本质上是运行在教学一体机上的互动课件软件，它本身内置了浏览器内核，所以支持两种打开HTML文件的方式。
第一种是插入网页组件。在希沃白板的编辑页里选择“网页”工具，输入HTML文件的本地路径或线上URL。这个方式的缺点是本地HTML文件如果以file://协议打开，有部分浏览器能力会被限制，比如音频自动播放策略可能不允许。
更稳妥的是第二种方式：在课件页里插入一个“多媒体”对象，选中本地HTML文件。这样可以通过双击打开外部浏览器窗口来运行。我在实际使用中更倾向于第二种，因为可以自己控制浏览器窗口的大小，能全屏投放，也不要受希沃网页组件的沙箱限制。
实际操作时，我每隔两节课还会更新一次HTML文件内容，只要在希沃里重新插入一次即可，旧版本删掉，避免把答案改动的旧文件留在课件里造成混淆。
实际操作步骤是：
- 打开希沃白板课件，进入要放置游戏的页面；
- 点击工具栏里的“多媒体”，在文件框里选中做好的
找影子01.html； - 把页面上的图标拉大到合适尺寸；
- 在授课模式下点击这个图标，选择“打开文件所在位置”或用默认浏览器打开全屏运行。
提示：如果HTML的配套资源是单独的图片或CSS文件，务必把整个文件夹一起拷贝到教室电脑上，不要只拷单个HTML，否则页面会因找不到素材而全面崩版。我做的时候把所有CSS和JavaScript直接内联在一个文件里，就是为了免去这个麻烦。
4.2 讲课前的设备设置
课件在教室里投放，有几个细节会影响最终效果，这里必须专门提醒。
第一是分辨率。希沃一体机通常是1920×1080或更高，但有些老型号在“扩展屏幕”模式下会以较低分辨率运行，导致页面右侧被截掉。我的建议是课件启动后直接提示老师按F11让浏览器全屏，同时在CSS里用百分比或 vw/vh 做适配，不要写死像素宽度。因为16:9固定比例，可以直接让主容器占满视口。
第二是触摸校准。一体机有时候会触摸偏移，尤其屏幕贴了保护膜以后，中心坐标判断会不准。我解决的办法是设置一个“校准检查按钮”，启动时按一下按钮，触点会高亮显示，老师能快速判断触摸是否有偏移。这个小功能5分钟就能写完，但关键时刻能救命。
第三是声音设备。课件用了音效反馈，课前务必确认教室音箱已连接并打开，否则所有“对了”的反馈都会变成无声的动画，互动感直接减半。
4.3 关于希沃Linux版本和跨系统部署的补充观察
不少老师问我希沃白板Linux版怎么装HTML课件。希沃官方有面向国产操作系统的Linux版本，通常以deb安装包或麒麟系统适配包的形式提供。在Linux版希沃里，对HTML课件的支持程度和Windows版有些差异，主要体现在网页组件对本地文件访问的限制更严格。
绕开这个问题的方法依然是：把HTML文件导出后用默认浏览器打开全屏运行。只要设备上有任何一个现代浏览器（Firefox或Chromium系均可），HTML课件的核心功能就不受影响。
我测试过在麒麟系统上通过默认浏览器打开课件，CSS和JavaScript表现正常，触屏事件也没问题。所以如果学校统一配的是国产系统终端，这套方案也适用。关键是课件本身不要强依赖Windows专有的能力——内置浏览器能跑通的课件，Linux下通常也没问题。
5. 常见问题与调试经验实录
5.1 高频问题速查表
| 现象 | 原因 | 解决方案 |
|---|---|---|
| 卡片拖不动 | 只监听了mousedown，没监听touchstart | 统一改用Pointer Events，或同时注册鼠标与触摸事件 |
| 拖动时页面跟着滚 | touchmove没有阻止默认滚动 | 在touchmove回调中调用 e.preventDefault() |
| 图片/图案在部分电脑上不显示 | 素材放在单独文件路径中，路径不对 | 把素材内联到HTML中，或完整拷贝项目文件夹 |
| 卡片匹配后瞬间闪回原位 | 动画过渡和位置更新冲突 | 匹配成功后移除过渡属性，等位置固定后再打开过渡 |
| 全部匹配后无完成提示 | JavaScript报错，后续逻辑中断 | 打开浏览器控制台查看报错信息，优先修复脚本错误 |
| 字体或图标在希沃上显示异常 | 系统缺少对应字体或Emoji版本老 | 使用系统通用字体栈；核心图形用SVG替代Emoji |
| 页面在课堂上打不开 | HTML默认被系统安全策略拦截 | 右键HTML文件，选择用浏览器打开，并设置浏览器为默认程序 |
5.2 几个容易被忽略的“真坑”
第一个坑是双击误触发问题。电脑上运行HTML课件时，孩子拖完卡片后指尖离开瞬间，鼠标事件会触发两次点击（一次是拖动结束，一次是click冒泡），导致卡片刚匹配成功就被弹回。解决方案是在匹配成功后给卡片加一个 pointer-events: none 的锁定样式，或者在事件处理函数里加一个“500ms内禁止重复处理”的节流标记。
第二个坑是拖拽元素的坐标跳变。刚开始用 position: absolute 定位时，卡片在拖动过程中会突然跳到左上角，排查半天发现是没考虑卡片本身的偏移量。按下瞬间要记录手指到卡片左上角的距离（就是前面代码里的offsetX和offsetY），每次移动时减去这个偏移量，位置才能保持稳定。这个逻辑初次实现时不仔细想，很容易翻车。
第三个坑比较隐蔽，是浏览器窗口尺寸变化引起的坐标错位。上课时老师如果调整了浏览器窗口大小，卡片原先记录的坐标和实际位置就会偏离。处理办法是窗口 resize 时把拖拽中卡片的坐标重新计算一遍，匹配结果不受影响。由于我在课堂上习惯固定全屏，这个坑只在教师机调试时遇到过一次，但也值得写出来。
5.3 分组计分与课堂管理
最初版本的“找影子01”没有计分功能，后来在试讲时发现一个问题：孩子轮流上来操作，如果缺少外在的正向反馈，台下坐着的孩子会很快走神。我给课件补了一个简单的分组计分条——将全班分成红蓝两队，每队答对一题加一分，投到白板右上角。计分纯粹靠点击事件完成，不用数据库，所有状态都存在页面内存中。
计分的好处非常明显，它把“个人操作”变成了“全组参与”。一个孩子在台上拖拽，台下的孩子会忍不住喊“红队加油”“蓝队加油”，课堂参与度一下子提高了。加上这个功能之后，课件才第一次出现“孩子们不想下课”的情况。老师的成就感，很多时候就是被这种瞬间拉满的。
6. 从“找影子01”到更丰富的课堂形态
6.1 模板化的二次开发经验
这套课件我用完第一节课，就把整个工程改造成了一个可配置的小模板。实际改起来只涉及三个部分：题目数组、主题样式、反馈文案。题目数组负责决定这一课学什么；主题样式决定背景色、卡片边框，对应节日或活动主题；反馈文案则配合当节课的口令。
比如想改成一节“动物影子”课，就把数组换成五个动物：
javascript复制const items = [
{ id: 'cat', name: '小猫', icon: '🐱' },
{ id: 'dog', name: '小狗', icon: '🐶' },
{ id: 'fish', name: '小鱼', icon: '🐟' },
{ id: 'bird', name: '小鸟', icon: '🐦' },
{ id: 'rabbit', name: '兔子', icon: '🐰' }
];
原来的整段拖拽、判定、反馈逻辑完全复用，不写新代码。这也是HTML课件相比课堂活动模板最大的优势——逻辑是抽象好的，内容才是可变的。有基础老师可以把这份代码当脚手架，没有基础也可以直接替换数组内容，普通办公软件熟练度就够用。
6.2 课件外的更多应用场景
“找影子”这堂课的HTML交互模式，往深了想，还能整体迁移到别的内容。比如配对记忆游戏：左边是数字，右边是相同数量的小圆点；或者拼音学习：左边是字母，右边是含这个字母的图片；再或者颜色认知：左边是色块名称，右边是色块本身。底层逻辑都是“从一堆素材中拖一个去匹配另一个”，数据结构统一了，应用场景就是无限的。
如果要做计时挑战版，只需要在最外层加一个setInterval倒计时，到时间没完成就算失败，自动播放鼓励话术。这个做法适合大班或幼小衔接阶段训练反应速度，但小班不太建议用计时压力，容易让小朋友紧张。
最后再说一个和希沃相关的使用技巧：课堂上一体机如果突然卡顿，先把浏览器窗口缩放回普通比例，再把后台在跑的无关程序关掉，通常问题就能缓解。HTML课件本身占用极低内存，页面上如果卡，八成是电脑后台太拥堵，不是课件的问题。
我个人的体会是，给幼儿课堂做互动课件，技术指标并非越高越好，真正的评价标准是孩子上完课之后眼睛是否发亮。HTML给了老师无限的自由度，但自由度最终要服务于课堂节奏和儿童经验。每次做完一个课件，我还会放给同年级的老师试玩一遍，从他们的反馈中调整卡片大小、配色、音效这些大人容易忽视、孩子却很介意的细节。磨课件的过程和磨课一样，慢功夫里才出真效果。