电赛E题满分视频制作指南：把视频当工程交付物

“2026电赛E题满分视频”这个说法，乍看会让人以为是一篇教“剪片”的教程。但真到参赛时你才会理解，评委观看视频时能接收的信息量非常有限：他们没有条件反复回看你的工程细节，也没有义务从模糊的画面里替你补全逻辑。一个拿到高分的视频，本质上不是“视频做得好”，而是“系统在几分钟内被证明是完整且可信的”。

电赛的现场测评和视频提交规则每年会有差异，但评委的判断方式通常是稳定的：先看功能是否齐全，再看指标是否经得起推敲，最后看系统是否像一个可以交付的工程作品。E题往往涉及信号链、测量、控制或数据处理的综合应用，这类题目最容易出现一种情况——功能代码写了，板子也调通了，但视频里没有把关键读数、波形、操作流程清晰地串起来，导致评委无法快速建立“这个系统真的能工作”的印象。

所以这篇文章想聊的，不是特效、转场和背景音乐。而是把“满分视频”当成一个工程交付物来准备：从踩分点拆解、演示脚本设计、录制规格，到剪辑原则和提交前自检。这套方法不依赖具体的 E 题题目，2026 年的比赛细则以官方发布为准，但你完全可以在题目公布前就把这套制作流程练熟。

1. 先搞清楚：评委看视频时，到底在看什么

1.1 视频是“功能复现”，不是“宣传片”

很多队伍在做视频时会陷入一个误区：用好看的转场、高级的配乐、炫酷的界面动画来包装作品。但评委真正需要的是一个东西——复现证据。

复现证据的意思是：在什么条件下，你执行了什么操作，系统产生了什么结果，读数是多少，这个结果和题目要求之间的差距是多少。只要这个证据链清晰，画面朴素一点也没关系。反过来，哪怕画面再精致，如果关键操作被跳过了，或者波形读数模糊不清，评委就无法确认你“真的实现了”，而不是“截图拼出来的”。

我在看往年优秀作品时发现一个规律：高分的演示视频往往不追求花哨，而是追求“每一步都能被观众看懂”。它更像是把现场测评的过程搬到了屏幕上，甚至比现场测评更友好，因为你可以通过字幕、箭头、对比图把信息密度提上来。

这才是“满分视频”的第一性原则：让评委在最短时间内确认你的系统能做什么、做到什么程度、稳定不稳定。

1.2 决定分数的不是镜头，而是指标的可验证性

电赛评分的核心从来不是“看起来不错”，而是“指标达成了”。所以视频里最值钱的素材，不是系统开机那一瞬间的灯光闪烁，而是那些可以直接对应题目要求的测量画面。

举例来说，如果题目要求某个输出信号的频率误差不超过某个百分比，那么视频里就需要出现这样一组画面：信号源设置信息、输出端波形、频率计或示波器的读数、记录值。如果少了其中任何一环，这个指标的可信度就会下降。

一个很容易被忽视的点是：评委通常不会把视频暂停到一个画面去仔细辨认数值。他们更可能以正常播放速度看一遍，然后对某个模糊数字产生疑问。所以在录制和后期加字幕时，要默认一个前提——观众不会放慢倍速。你需要用字幕、高亮框、箭头把关键读数再标一次。

实际操作时，我一般会建议队伍在拍摄前先列一份“指标证据清单”：每一个题目要求都对应一种画面证据。没有对应证据的分数，本质上就是碰运气。

2. 把题目翻译成“踩分点映射表”

2.1 从题目要求出发，拆出三类镜头

拿到 E 题后，第一件事不是写代码，也不是画板子，而是拆题。拆题的目标是得到三类镜头：

• 基本功能镜头：题目明确要求的基础功能，每个功能都必须有清晰的演示段落。
• 发挥部分镜头：可能拿到加分的进阶功能，需要有比“能跑”更进一步的展示，比如可调节、可切换、多组参数对比。
• 鲁棒性镜头：体现系统稳定性的镜头，例如连续运行、多组重复测试、温度变化或输入波动下的表现。这类镜头往往是高分视频里的加分项，因为很多队伍不刻意拍。

以一类需要“输入某种信号、经过处理、显示结果”的系统为例，基本功能镜头是正常的信号输入和结果输出；发挥部分镜头可以是不同信号类型、不同参数范围下的表现；鲁棒性镜头则是切换 10 组参数后结果仍然稳定。

这里要提醒一句：2026 年 E 题到底考什么方向，目前还不适合拍胸脯预测。但无论题目怎么变，拆解逻辑是一样的。把“题目要求”翻译成“可拍摄的证据”，这一项工作可以在题目公布后的半天内完成。

2.2 五步映射法：读题、拆指标、排风险、定镜头、测录制

我建议每个队伍用一张“踩分点映射表”来组织工作，具体分五步：

1. 读题：把题目要求逐条复制到一个表格里，不要自己总结，直接抄原文。
2. 拆指标：把每个要求拆成可测量的指标，例如“频率误差不超过 1%”拆成需要展示信号源、示波器读数、计算过程。
3. 排风险：标记哪些要求最容易在演示时出现意外，比如不稳定、需要长时间预热、对线缆接触敏感。风险项要设计“备份演示方案”。
4. 定镜头：为每个指标安排一个或一组镜头，明确拍摄对象和画面内容。
5. 测录制：在正式录制前先做一次全流程试录，确认每一步都拍得清楚，再开始正式素材。

这套方法的本质，是把视频制作从“最后两周的额外负担”变成“开发过程中的验收工具”。每个功能做完后，先录一段素材，而不是等最后统一补录。这样不仅减轻最后阶段压力，还能倒逼你把每个功能真正调到可演示状态。

踩分点映射表还有另一个好处：当团队里几个人各负责不同模块时，表格可以让每个人清楚地知道——我负责的部分需要在镜头前呈现什么效果。

3. 录制前三天：把演示流程做成“不会临场翻车”的工程

3.1 第一步：确定系统“演示就绪状态”

很多录制失败，问题都出在系统状态不明确：线缆没插好、默认配置没加载、上位机弹出了警告窗口、FPGA 下载器没有拔、电源线挡在了屏幕前。这些问题在开发时无伤大雅，但一旦进入镜头，就会让视频看起来像“未完成品”。

所以，正式录制前三天，应该先确定一份“演示就绪状态清单”。这份清单至少包括：

• 系统上电后的默认界面和状态灯
• 外部信号源、万用表、示波器的连接顺序
• 上位机软件的界面布局和字体大小
• 需要提前加载的默认配置
• 备用电池、备用线缆、备用测量设备
• 录制空间的光源布局和设备固定位置

我见过的常见翻车点有两个：一是示波器或万用表的读数由电池供电，录到一半电量过低，屏幕变暗甚至自动关机；二是某个测试点需要使用特定的探头，但在录制时用了另一根线，导致波形毛刺明显。这类问题如果在录制前一小时才发现，基本只能放弃当天的录制计划。

3.2 第二步：写操作脚本，而不是写演讲稿

演示视频的旁白和普通介绍视频的旁白完全不一样。普通介绍视频要解释“我们做的是什么、有什么创新”，而演示视频只需要说清楚“我现在做了什么、看到了什么”。所以操作脚本的核心是动作，不是抒情。

一个有效的操作脚本长这样：

• 打开系统电源，等待 5 秒，观察 LCD 进入主界面。
• 按下 S2 键，切换到“信号测量”模式。
• 将信号源输出频率设置为 10kHz，示波器 CH1 接入系统输入。
• 等待系统自动锁定，记录当前测量值。
• 再将频率切换为 50kHz，重复一次。

每一行都对应一个镜头。如果某一步失败，你不需要重头开始背稿子，只需要回到上一步的状态重新执行。这就是操作脚本和演讲稿的区别：演讲稿靠记忆，操作脚本靠状态恢复。

在写脚本时，还要标注“预期结果”。例如“按下 S2 键后，屏幕应显示测量结果，误差应在 1% 以内”。如果实际录制时预期结果没有出现，不要尝试在镜头前临时解决，先暂停，排查完成后从头录这一段。视频里最怕的就是“现场 Debug”，因为观众无法判断你是解决问题还是掩盖问题。

3.3 第三步：提前试录，不要等到最后一天

试录的目标不是得到完美素材，而是确认三件事：

1. 机位是否能看到所有关键操作和显示。
2. 自动对焦是否会频繁拉风箱。
3. 音频是否清晰，有没有明显底噪或啸叫。

试录后回看素材时，用“陌生人的视角”来观看。你会立刻发现很多开发时完全意识不到的问题，比如手指挡住了镜头、屏幕反光导致数字看不清、操作太快导致按键流程根本没法跟读。

4. 录制规格与镜头语言：丢分最隐蔽的几个地方

4.1 分辨率、帧率、焦点和曝光，先按最小可读标准来

我建议至少 1080P、30fps 以上录制。分辨率不是越高越好，但 1080P 是一个稳妥的最低标准。关键不是分辨率，而是信息字体是否足够大。很多手机用默认镜头拍摄时，系统界面上的小数点和单位符号会糊成一团。解决方法是：在录制前把上位机或屏幕上显示的字体调大，或者推近镜头重新构图。

自动对焦和自动曝光是两个大坑。自动对焦会在镜头前出现变化时反复拉风箱，导致波形一会儿清晰一会儿模糊；自动曝光会在环境亮度变化时突然调整画面明暗，让读数短暂不可读。所以条件允许时，用支持手动锁定焦点和曝光的相机 App；如果只能用默认相机，就用胶带固定好手机位置，尽量减少画面中突然出现的明暗变化。

另一个常见问题是示波器屏幕的刷新率与摄像机帧率不匹配，导致画面出现滚动的条纹或闪烁。简单处理方法是调整拍摄角度，或者略微降低屏幕亮度。如果拍摄设备支持调整快门速度，可以尝试设置较低的快门速度来减少条纹，但注意不要让画面过曝。

下面是常见的通用做法：如果需要从原素材中截取片段，先不要重新编码，直接按时间区间切出，确认无误后再统一导出。

ffmpeg -i original.mp4 -ss 00:01:30 -t 00:00:45 -c copy part1.mp4

这里的-ss表示起始时间，-t表示时长，-c copy表示不重新编码、切割速度快。具体参数可以根据自己需要的时长调整。如果最终提交平台有大小限制，再考虑统一压缩。

4.2 让读数在画面里“自己说话”

满分视频和信息密度直接相关。评委看视频时不会像看论文一样去推演逻辑，而是依赖画面中的视觉信息来做判断。所以，关键读数必须要有二次标注。

具体做法有几种：

• 在关键数值出现时，用后期字幕重复一遍数值，避免观众倒回去看。
• 用红色或黄色方框框出仪表读数区域。
• 在波形图旁边用箭头指向特征点，例如峰值、频率读数值。
• 多组对比测试时，用表格把预期值和实测值并列展示。

但要注意：这些标注不能替代原始画面，只能作为辅助。原始仪表读数才是证据，字幕只是帮助你理解证据。如果视频中只出现字幕而没有清晰的原始读数，评委反而会怀疑数据来源。

另外，如果有上位机界面，尽量把界面做成“演示模式”：关闭无关弹窗、清空桌面、放大关键区域。有一年我发现一个队伍的视频里，屏幕角落一直闪烁着系统的编译错误提示窗口，虽然不影响功能演示，但整个视频的可信度瞬间降低了不少。

4.3 录制时要不要用多机位？

有条件时，两个机位比一个机位稳妥得多。主机位负责整体操作和系统外观，副机位负责拍摄测量仪器或示波器屏幕的特写。后期剪辑时再根据叙事需要切换视角。

如果只有一个机位，那就必须把最关键的操作和测量尽量安排在同一个镜头里。这样虽然牺牲了特写，但保证了连续性。比起切换镜头，评委更看重“整个过程没有断点”。

这里有一个容易被忽略的点：操作者手部动作要尽量慢且稳定。开发时我们操作按键很快，因为每天都按几十次；但镜头前观众需要跟上你的节奏。按下一个按键后，稍微停顿一秒，等屏幕或仪表反应稳定后再进行下一次操作，这个习惯会让视频的节奏感好很多。

5. 剪辑时最容易让视频“失真”的操作

5.1 先顺结构，再补信息层，最后调音频

剪辑的顺序决定了最终成片的质量上限。我先给一个普适的剪辑顺序：

1. 粗剪结构：按照踩分点映射表，把对应素材按顺序放到时间线上，不添加任何特效，只保证叙事逻辑完整。
2. 补信息层：在需要强调的地方加字幕、箭头、方框、参数表格。
3. 调音频：把环境底噪降下来，统一旁白响度，保持语速稳定。
4. 最最后压缩导出：确认提交平台要求的格式、分辨率、编码和大小后再导出。

粗剪时不要沉迷于某一小段的完美，先看整体时长和节奏。如果题目要求较多，视频时长可能比较长，这时要敢于精简：每个功能点的演示控制在 20 到 40 秒，不要在一个功能上反复展示多次。

剪辑时最容易犯的错误是“用加速掩盖等待时间”。比如系统某个步骤需要等待 10 秒才出结果，然后你直接把这段等待时间加速或剪掉。这种做法有时是合理的，但必须配合字幕说明“等待 10 秒后”。否则评委无法判断系统是响应快还是延迟大，甚至会怀疑你在中间用剪接跳过了问题步骤。“等待时间”本身是系统行为的一部分，重要的等待过程必须保留原始时长或者明确标注时间流逝。

5.2 不要把剪辑当成掩盖问题的工具

这是最重要的一条原则：视频里展示的所有数据，必须是系统真实运行得到的结果。

剪辑出现误操作镜头，可以剪掉重录；信号不稳定导致波形难看，可以重新调整系统后录；但绝对不要通过拼凑、加速、跳帧、替换读数来制造“系统每一步都很成功”的假象。

原因很简单：电赛的测评不只依赖视频，评委可能要求现场复现，也可能在答辩环节追问细节。一旦被发现问题，整个作品的信任度都会崩塌。更重要的是，通过剪辑掩盖问题会反向影响团队自己的判断——你以为系统已经稳定，实际上问题还藏在硬件或代码里，最终在现场测评中暴露出来。

更推荐的做法是：如果某个功能在视频中不能完整演示，那就正面拍出“当前存在的一个限制”，然后在旁白里说明原因。这种诚实会在测评时转化为“这个队伍对自己系统边界有清晰认知”的印象。

5.3 音频要清楚，不要成为干扰

很多电赛视频的旁白声音很小，背景里全是实验室风扇声和队友讨论声。这个问题不难解决：录制旁白时使用带海绵套的外接麦克风，或者直接用手机靠近嘴边录音。剪辑时用自带的降噪功能，把底噪压低到不影响听感的程度。

旁白的语气也很重要。演示视频的旁白节奏应该平稳、清晰，不需要播音腔，但要保证每个数字、单位、操作名称都发音清楚。语速宁可慢一点，也不要让关键信息滑过去。

6. 提交前自检：用一张检查表和一条排查链兜底

6.1 满分视频自检表

在最终导出和提交之前，建议用下面这张自检表过一遍：

如果某一行不通过，不要直接进入下一项，先解决掉问题再继续。自检表的价值在于把“感觉视频还行”变成“每条标准都有明确结论”。

6.2 如果视频“看起来不对”，按什么顺序排查

临近提交时发现视频有问题，最容易慌。这里给一条排查链，按顺序来：

1. 看不清楚：先判断是分辨率不够、焦点没锁住，还是环境反光导致。如果只是局部看不清，优先补拍特写镜头，而不是整套重录。
2. 数字异常：先确认是不是真实运行数据，再看是不是截错了画面或用了错误版本的代码。不要用后期修改数字的方式去“修正”。
3. 节奏拖沓：先看操作脚本是不是写了太多不必要动作，再看剪辑结构是否需要精简。把每个功能点控制在紧凑的 20 到 40 秒内。
4. 文件过大或格式不对：先查提交平台的具体要求，再用 ffmpeg 等工具重新编码，不要反复导出无损文件。
5. 音频模糊：先看是不是收音设备距离太远，再决定是重录旁白还是用滤镜降噪。重录旁白的成本通常比重拍画面低得多。

这条排查链的核心逻辑是：先判断问题出在素材采集环节还是后期处理环节，不要一上来就推倒重来。

6.3 别忘了：视频是工程能力的延伸，不是包装手段

做了多年项目之后，我越来越觉得，演示视频这项能力会在未来的工作里持续带来收益。无论是技术汇报、产品评审、项目复盘，还是开源项目展示，本质上都是同一件事：把复杂工程快速、准确、可信地传达给别人。

电赛只是第一站。你在视频里展示系统的方式，某种程度上也反映了你对系统的理解深度。如果视频逻辑混乱，说明你对题目要求的拆解还不够清楚；如果操作过程反复出错，说明系统的稳定性还不到位；如果关键读数模糊，说明你还没有真正站在评委角度审视过自己的作品。

所以，最后一个建议是：别等到 2026 年的题目发布才开始练。现在就可以拿出某个课程设计、小项目或者去年的赛题，完整地走一遍拆解、录制、剪辑、自检的流程。这套流程练熟了，等真正比赛时，你只需要替换掉具体的功能模块，而整套“满分视频”的制作思维已经长在团队身上了。