初赛不看你代码写得多优雅，评委只能看到你的报告和一段视频——很多队伍的技术不差，是死在这两份材料上。
一、初赛提交的到底是什么
初赛是线上评审，你交的是「项目文档 + 演示材料」。评委看不到你的波形，也摸不到你的板子，他能判断的只有三件事：
1. 你解决的问题清不清楚；
2. 你的方案在技术上站不站得住；
3. 你的结果可不可信。
所以文档和视频不是「收尾工作」，它们和代码一样是评分项。
二、技术报告的骨架
按这个结构写，评委读起来最省力：
| 章节 | 写什么 | 常见问题 |
| 一、选题背景与目标 | 要解决什么、为什么值得做、做到什么程度算成功 | 空话多，没有量化目标 |
| 二、系统方案 | 总体框图、模块划分、数据流与控制流 | 框图缺时钟域与接口标注 |
| 三、详细设计 | 每个模块的接口、时序、状态机、关键算法 | 只贴代码，不解释设计取舍 |
| 四、测试与验证 | 仿真波形、上板结果、性能与资源数据 | 只有「功能正常」，没有数据 |
| 五、优化与难点 | 时序收敛、资源压缩、踩坑与解决 | 难点写成「遇到了编译报错」 |
| 六、总结与展望 | 还有什么没做完、下一步怎么做 | 过度夸大，写成产品说明书 |
必须有的量化数据：LUT / FF / BRAM / DSP 占用，最高工作频率，延迟或吞吐，资源优化前后对比。没有这些数字，技术深度无法被证明。
三、演示视频的 3 分钟脚本
| 时间 | 内容 |
| 0:00–0:20 | 问题：一句话说清你要解决什么 |
| 0:20–0:50 | 系统：框图动画 + 实物连接 |
| 0:50–2:20 | 效果：真实运行画面，最好带对比（处理前/处理后） |
| 2:20–2:50 | 亮点：资源占用、帧率、优化前后对比 |
| 2:50–3:00 | 结论：做到了什么，下一步是什么 |
拍视频的三个硬要求：画面能看清、结果能复现、声音能听清。屏幕录制务必全屏，不要用手机拍显示器。
四、可复现的工程记录
这部分很多人忽略，但它是「你不是抄的」最有力的证据：
· 源码目录结构清晰，有 README 说明每个文件夹做什么；
· 约束文件、工程文件、版本记录齐全，能一键打开跑通；
· 关键调试过程留痕（改了什么、为什么改、结果如何）；
· 如果有参考开源项目，注明来源与自己的改动部分。
五、十种最常见的失败模式
1. 选题过大——做不完，只能交半成品；
2. 只做仿真不上板——没有实物演示，直接影响结果可信度；
3. 文档写成实验报告——只写步骤，没有设计与取舍；
4. 没有量化数据——说不出资源占用和性能；
5. 演示视频翻车——画面模糊、时间超限、效果跑不出来；
6. 时序没收敛——跑起来就随机出错，稳定性测试直接暴露；
7. 模块没分工——两个人改同一个文件，版本冲突吃掉一周；
8. 时间失控——10 月才定稿方案，11 月赶工；
9. 忽略官方资源——没参加企业技术培训，平台特性完全不了解；
10. 答辩没准备——讲不清难点，被追问两句就哑火。
每一项都有补救办法，但补救的时间点越早越省力。
六、初赛前两周的自查清单
· 报告里的每个数字，我能不能当场解释怎么测出来的？
· 视频里出现的效果，换一台电脑能不能复现？
· 系统连续运行 30 分钟会不会挂？
· 找一位没参与的同学看一遍报告，他能不能复述你的创新点？
· 提交物的格式、时长、命名是否符合当年要求？
四个问题里只要有一个答不上，就先解决它，再谈优化。
评论 0