公司动态
电赛E题满分视频制作指南:把视频当工程交付物
“2026电赛E题满分视频”这个说法乍看会让人以为是一篇教“剪片”的教程。但真到参赛时你才会理解评委观看视频时能接收的信息量非常有限他们没有条件反复回看你的工程细节也没有义务从模糊的画面里替你补全逻辑。一个拿到高分的视频本质上不是“视频做得好”而是“系统在几分钟内被证明是完整且可信的”。电赛的现场测评和视频提交规则每年会有差异但评委的判断方式通常是稳定的先看功能是否齐全再看指标是否经得起推敲最后看系统是否像一个可以交付的工程作品。E题往往涉及信号链、测量、控制或数据处理的综合应用这类题目最容易出现一种情况——功能代码写了板子也调通了但视频里没有把关键读数、波形、操作流程清晰地串起来导致评委无法快速建立“这个系统真的能工作”的印象。所以这篇文章想聊的不是特效、转场和背景音乐。而是把“满分视频”当成一个工程交付物来准备从踩分点拆解、演示脚本设计、录制规格到剪辑原则和提交前自检。这套方法不依赖具体的 E 题题目2026 年的比赛细则以官方发布为准但你完全可以在题目公布前就把这套制作流程练熟。1. 先搞清楚评委看视频时到底在看什么1.1 视频是“功能复现”不是“宣传片”很多队伍在做视频时会陷入一个误区用好看的转场、高级的配乐、炫酷的界面动画来包装作品。但评委真正需要的是一个东西——复现证据。复现证据的意思是在什么条件下你执行了什么操作系统产生了什么结果读数是多少这个结果和题目要求之间的差距是多少。只要这个证据链清晰画面朴素一点也没关系。反过来哪怕画面再精致如果关键操作被跳过了或者波形读数模糊不清评委就无法确认你“真的实现了”而不是“截图拼出来的”。我在看往年优秀作品时发现一个规律高分的演示视频往往不追求花哨而是追求“每一步都能被观众看懂”。它更像是把现场测评的过程搬到了屏幕上甚至比现场测评更友好因为你可以通过字幕、箭头、对比图把信息密度提上来。这才是“满分视频”的第一性原则让评委在最短时间内确认你的系统能做什么、做到什么程度、稳定不稳定。1.2 决定分数的不是镜头而是指标的可验证性电赛评分的核心从来不是“看起来不错”而是“指标达成了”。所以视频里最值钱的素材不是系统开机那一瞬间的灯光闪烁而是那些可以直接对应题目要求的测量画面。举例来说如果题目要求某个输出信号的频率误差不超过某个百分比那么视频里就需要出现这样一组画面信号源设置信息、输出端波形、频率计或示波器的读数、记录值。如果少了其中任何一环这个指标的可信度就会下降。一个很容易被忽视的点是评委通常不会把视频暂停到一个画面去仔细辨认数值。他们更可能以正常播放速度看一遍然后对某个模糊数字产生疑问。所以在录制和后期加字幕时要默认一个前提——观众不会放慢倍速。你需要用字幕、高亮框、箭头把关键读数再标一次。实际操作时我一般会建议队伍在拍摄前先列一份“指标证据清单”每一个题目要求都对应一种画面证据。没有对应证据的分数本质上就是碰运气。2. 把题目翻译成“踩分点映射表”2.1 从题目要求出发拆出三类镜头拿到 E 题后第一件事不是写代码也不是画板子而是拆题。拆题的目标是得到三类镜头基本功能镜头题目明确要求的基础功能每个功能都必须有清晰的演示段落。发挥部分镜头可能拿到加分的进阶功能需要有比“能跑”更进一步的展示比如可调节、可切换、多组参数对比。鲁棒性镜头体现系统稳定性的镜头例如连续运行、多组重复测试、温度变化或输入波动下的表现。这类镜头往往是高分视频里的加分项因为很多队伍不刻意拍。以一类需要“输入某种信号、经过处理、显示结果”的系统为例基本功能镜头是正常的信号输入和结果输出发挥部分镜头可以是不同信号类型、不同参数范围下的表现鲁棒性镜头则是切换 10 组参数后结果仍然稳定。这里要提醒一句2026 年 E 题到底考什么方向目前还不适合拍胸脯预测。但无论题目怎么变拆解逻辑是一样的。把“题目要求”翻译成“可拍摄的证据”这一项工作可以在题目公布后的半天内完成。2.2 五步映射法读题、拆指标、排风险、定镜头、测录制我建议每个队伍用一张“踩分点映射表”来组织工作具体分五步读题把题目要求逐条复制到一个表格里不要自己总结直接抄原文。拆指标把每个要求拆成可测量的指标例如“频率误差不超过 1%”拆成需要展示信号源、示波器读数、计算过程。排风险标记哪些要求最容易在演示时出现意外比如不稳定、需要长时间预热、对线缆接触敏感。风险项要设计“备份演示方案”。定镜头为每个指标安排一个或一组镜头明确拍摄对象和画面内容。测录制在正式录制前先做一次全流程试录确认每一步都拍得清楚再开始正式素材。这套方法的本质是把视频制作从“最后两周的额外负担”变成“开发过程中的验收工具”。每个功能做完后先录一段素材而不是等最后统一补录。这样不仅减轻最后阶段压力还能倒逼你把每个功能真正调到可演示状态。踩分点映射表还有另一个好处当团队里几个人各负责不同模块时表格可以让每个人清楚地知道——我负责的部分需要在镜头前呈现什么效果。3. 录制前三天把演示流程做成“不会临场翻车”的工程3.1 第一步确定系统“演示就绪状态”很多录制失败问题都出在系统状态不明确线缆没插好、默认配置没加载、上位机弹出了警告窗口、FPGA 下载器没有拔、电源线挡在了屏幕前。这些问题在开发时无伤大雅但一旦进入镜头就会让视频看起来像“未完成品”。所以正式录制前三天应该先确定一份“演示就绪状态清单”。这份清单至少包括系统上电后的默认界面和状态灯外部信号源、万用表、示波器的连接顺序上位机软件的界面布局和字体大小需要提前加载的默认配置备用电池、备用线缆、备用测量设备录制空间的光源布局和设备固定位置我见过的常见翻车点有两个一是示波器或万用表的读数由电池供电录到一半电量过低屏幕变暗甚至自动关机二是某个测试点需要使用特定的探头但在录制时用了另一根线导致波形毛刺明显。这类问题如果在录制前一小时才发现基本只能放弃当天的录制计划。3.2 第二步写操作脚本而不是写演讲稿演示视频的旁白和普通介绍视频的旁白完全不一样。普通介绍视频要解释“我们做的是什么、有什么创新”而演示视频只需要说清楚“我现在做了什么、看到了什么”。所以操作脚本的核心是动作不是抒情。一个有效的操作脚本长这样打开系统电源等待 5 秒观察 LCD 进入主界面。按下 S2 键切换到“信号测量”模式。将信号源输出频率设置为 10kHz示波器 CH1 接入系统输入。等待系统自动锁定记录当前测量值。再将频率切换为 50kHz重复一次。每一行都对应一个镜头。如果某一步失败你不需要重头开始背稿子只需要回到上一步的状态重新执行。这就是操作脚本和演讲稿的区别演讲稿靠记忆操作脚本靠状态恢复。在写脚本时还要标注“预期结果”。例如“按下 S2 键后屏幕应显示测量结果误差应在 1% 以内”。如果实际录制时预期结果没有出现不要尝试在镜头前临时解决先暂停排查完成后从头录这一段。视频里最怕的就是“现场 Debug”因为观众无法判断你是解决问题还是掩盖问题。3.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 先顺结构再补信息层最后调音频剪辑的顺序决定了最终成片的质量上限。我先给一个普适的剪辑顺序粗剪结构按照踩分点映射表把对应素材按顺序放到时间线上不添加任何特效只保证叙事逻辑完整。补信息层在需要强调的地方加字幕、箭头、方框、参数表格。调音频把环境底噪降下来统一旁白响度保持语速稳定。最最后压缩导出确认提交平台要求的格式、分辨率、编码和大小后再导出。粗剪时不要沉迷于某一小段的完美先看整体时长和节奏。如果题目要求较多视频时长可能比较长这时要敢于精简每个功能点的演示控制在 20 到 40 秒不要在一个功能上反复展示多次。剪辑时最容易犯的错误是“用加速掩盖等待时间”。比如系统某个步骤需要等待 10 秒才出结果然后你直接把这段等待时间加速或剪掉。这种做法有时是合理的但必须配合字幕说明“等待 10 秒后”。否则评委无法判断系统是响应快还是延迟大甚至会怀疑你在中间用剪接跳过了问题步骤。“等待时间”本身是系统行为的一部分重要的等待过程必须保留原始时长或者明确标注时间流逝。5.2 不要把剪辑当成掩盖问题的工具这是最重要的一条原则视频里展示的所有数据必须是系统真实运行得到的结果。剪辑出现误操作镜头可以剪掉重录信号不稳定导致波形难看可以重新调整系统后录但绝对不要通过拼凑、加速、跳帧、替换读数来制造“系统每一步都很成功”的假象。原因很简单电赛的测评不只依赖视频评委可能要求现场复现也可能在答辩环节追问细节。一旦被发现问题整个作品的信任度都会崩塌。更重要的是通过剪辑掩盖问题会反向影响团队自己的判断——你以为系统已经稳定实际上问题还藏在硬件或代码里最终在现场测评中暴露出来。更推荐的做法是如果某个功能在视频中不能完整演示那就正面拍出“当前存在的一个限制”然后在旁白里说明原因。这种诚实会在测评时转化为“这个队伍对自己系统边界有清晰认知”的印象。5.3 音频要清楚不要成为干扰很多电赛视频的旁白声音很小背景里全是实验室风扇声和队友讨论声。这个问题不难解决录制旁白时使用带海绵套的外接麦克风或者直接用手机靠近嘴边录音。剪辑时用自带的降噪功能把底噪压低到不影响听感的程度。旁白的语气也很重要。演示视频的旁白节奏应该平稳、清晰不需要播音腔但要保证每个数字、单位、操作名称都发音清楚。语速宁可慢一点也不要让关键信息滑过去。6. 提交前自检用一张检查表和一条排查链兜底6.1 满分视频自检表在最终导出和提交之前建议用下面这张自检表过一遍检查维度检查点是否通过功能覆盖题目要求中的每一个基本功能点是否都有对应画面指标可读每个关键读数的原始画面是否清晰能否直接辨认数值流程真实是否有完整操作过程有没有为掩盖问题而做的可疑剪接画面清晰波形、数字、图标是否无摩尔纹、无焦点抖动、无严重反光音频清楚旁白是否清楚环境底噪是否可接受信息标注关键读数是否通过字幕或框选二次强调格式合规分辨率、时长、编码、文件大小是否符合官方要求备份留存是否保留了原始素材和工程文件方便后续重新导出如果某一行不通过不要直接进入下一项先解决掉问题再继续。自检表的价值在于把“感觉视频还行”变成“每条标准都有明确结论”。6.2 如果视频“看起来不对”按什么顺序排查临近提交时发现视频有问题最容易慌。这里给一条排查链按顺序来看不清楚先判断是分辨率不够、焦点没锁住还是环境反光导致。如果只是局部看不清优先补拍特写镜头而不是整套重录。数字异常先确认是不是真实运行数据再看是不是截错了画面或用了错误版本的代码。不要用后期修改数字的方式去“修正”。节奏拖沓先看操作脚本是不是写了太多不必要动作再看剪辑结构是否需要精简。把每个功能点控制在紧凑的 20 到 40 秒内。文件过大或格式不对先查提交平台的具体要求再用 ffmpeg 等工具重新编码不要反复导出无损文件。音频模糊先看是不是收音设备距离太远再决定是重录旁白还是用滤镜降噪。重录旁白的成本通常比重拍画面低得多。这条排查链的核心逻辑是先判断问题出在素材采集环节还是后期处理环节不要一上来就推倒重来。6.3 别忘了视频是工程能力的延伸不是包装手段做了多年项目之后我越来越觉得演示视频这项能力会在未来的工作里持续带来收益。无论是技术汇报、产品评审、项目复盘还是开源项目展示本质上都是同一件事把复杂工程快速、准确、可信地传达给别人。电赛只是第一站。你在视频里展示系统的方式某种程度上也反映了你对系统的理解深度。如果视频逻辑混乱说明你对题目要求的拆解还不够清楚如果操作过程反复出错说明系统的稳定性还不到位如果关键读数模糊说明你还没有真正站在评委角度审视过自己的作品。所以最后一个建议是别等到 2026 年的题目发布才开始练。现在就可以拿出某个课程设计、小项目或者去年的赛题完整地走一遍拆解、录制、剪辑、自检的流程。这套流程练熟了等真正比赛时你只需要替换掉具体的功能模块而整套“满分视频”的制作思维已经长在团队身上了。