FPGA+RK3588+NPU三核协同：超高清图像预处理与AI推理实战
2026/10/7 21:59:40
毕设最崩溃的时刻不是代码跑不起来，是导师在群里 @你：“开题报告这周交”，而你连文档模板还没下载。
更麻烦的是：开题报告、设计文档、答辩 PPT 看起来是三份材料，其实是同一份内容的三种切法。分别写，等于把同一件事讲三遍，还容易互相矛盾——开题说要做 8 个模块，设计文档里只剩 5 个，答辩 PPT 又变成另一个说法。
这篇用一套真实导出的材料说话：大学生就业咨询系统，设计文档 61 页、开题报告 6 页、答辩 PPT 22 页，三份同时产出、同源一致。下面每份材料的页数都是把文件真实渲染出来数的，不是模板说明。
一、三份材料的分工：同一件事，三种切法
| 材料 | 回答什么问题 | 给谁看 | 篇幅节奏 |
|---|---|---|---|
| 开题报告 | 要做什么、为什么做、怎么做 | 导师（决定你能不能开题） | 短，6 页左右 |
| 设计文档 | 怎么设计的、依据是什么 | 评阅老师（决定你的分数档） | 长，几十页 |
| 答辩 PPT | 做完之后讲什么、怎么讲 | 答辩组（决定现场表现） | 20 页上下 |
本项目的真实页数分布是6 : 61 : 22。这个比例很有参考价值：开题短、设计长、答辩精。很多同学反过来，开题报告写了 20 页，设计文档只有 10 页——评阅老师一眼就看出轻重颠倒。
二、答辩 PPT 的 22 页该讲什么
先看真实的第 1 页（封面页），信息量控制得刚好：系统名、场景定位、技术栈（数据库名college_employment_consultation、数据库类型mysql、项目平台VUE）。
22 页的页序可以按这五段切：
| 段落 | 页数 | 内容 |
|---|---|---|
| 问题与目标 | 1–3 | 封面、课题背景、要解决什么问题 |
| 方案与设计 | 4–10 | 功能结构图、系统架构图、E-R 图、用例图 |
| 实现要点 | 11–15 | 核心流程、关键表与接口、界面示意 |
| 测试与结果 | 16–19 | 测试用例表、关键结论、数据统计 |
| 总结与展望 | 20–22 | 完成情况、不足、后续可做的事 |
答辩 PPT 的编辑界面长这样，改文字和换图都在同一个工作台里：
最容易丢分的一点：PPT 上的图直接截屏文档里的图，放大就糊。正确做法是把系统图原图单独导出再插进 PPT（本项目 48 张图都是独立 PNG，插哪张取哪张）。
三、设计文档 61 页里应该有什么
封面页之后，61 页的骨架一般是：
| 章节 | 大致页数 | 关键内容 |
|---|---|---|
| 需求分析 | 8–12 | 用例图、功能结构图、角色与权限 |
| 数据库设计 | 10–15 | E-R 图、三线表（字段/类型/约束/说明） |
| 系统设计 | 10–15 | 架构图、模块划分、接口说明 |
| 系统实现 | 15–20 | 核心流程、关键界面、代码片段 |
| 测试 | 5–8 | 测试用例表、结果与结论 |
本项目那份设计文档里嵌了 21 张图（E-R 图、流程图、三线表、测试用例表都在里面），所以它不是"文字堆出来的"，而是图文配合——这也是评阅老师区分"认真做"和"凑字数"的第一眼印象。
文档生成与编辑在同一个工作台里完成，改完直接导出 Word：
四、开题报告 6 页怎么把"要做什么"讲清楚
开题报告不需要长，需要清楚：
6 页的经典结构：
| 页 | 内容 | 常见错误 |
|---|---|---|
| 1 | 封面：课题名称、姓名、学号、指导教师、学期 | 课题名写成"XX 系统设计"，看不出做什么 |
| 2 | 课题背景与意义 | 空话三页（“随着互联网的发展…”） |
| 3 | 国内外研究现状 | 参考文献编号对不上 |
| 4 | 研究内容与技术路线 | 与技术栈对不上（写 Java 却选了小程序） |
| 5 | 进度计划（16 周） | 计划与答辩时间冲突 |
| 6 | 预期成果与参考文献 | 预期成果写得比能力高一个数量级 |
第 4 页的"技术路线"是最容易被追问的：写清楚前端用什么、后端用什么、数据库用什么、怎么部署，本项目这一页的表述是 Vue 全栈 + MySQL，和后面设计文档、源码保持一致。
五、三份材料怎么保持一致（这是最大的返工来源）
我见过最多的返工不是写不出来，而是三份材料打架：
- 开题报告写"8 个功能模块"，设计文档里只有 5 个；
- 设计文档的 E-R 图是 v1，答辩 PPT 上贴的是 v2；
- 数据库表数量在三处写得不一样。
避免的方式只有一个：三份材料从同一份结构派生。本项目的做法是先定死实体字段（11 张表 / 117 个字段 / 15 个外键），再让文档、PPT、三线表、建库脚本从这份结构出——改字段时四份材料一起变，不会出现"图改了文档没改"。
实测收益：这份 61 页设计文档 + 6 页开题报告 + 22 页答辩 PPT，是同一次导出拿到的，版本天然一致。
六、答辩前必须自查的 3 件事
- 数字对得上：设计文档里的表数量、模块数量，和 PPT、开题报告是否一致（不一致就是送分题变送命题）。
- 图能看清：把 PPT 投到教室大屏的距离看一遍，最远的同学能不能看清最小的字。
- 每张图能讲 30 秒：讲不出所以然的图，不如不放。
七、说实话的部分
- 这三份材料是初稿：章节结构、图表、数据统计都按课题生成了，但研究现状、参考文献必须自己核实，写不存在的文献是致命问题。
- 页数是真实渲染出来的（61 / 6 / 22），但学校模板不同，最终页数会有差异，按你学校的要求增删章节。
- 文档能省掉的是排版、造图、凑结构的重复劳动；"你为什么这么设计"必须你自己答得出来。答辩组问的从来不是"这文档谁写的"，而是"这个模块你为什么这么拆"。
一句话总结：开题短、设计长、答辩精，三份材料同源才不打架——先把实体字段定死，图、文档、PPT、脚本一起出，剩下的时间留给真正要想清楚的设计问题。