毕设日记（二）

报告是一种文字艺术，答辩是一种语言艺术。

---

准备开题（续）

其实我本来以为这个选题小众到可以让我学着钱伟长先生一样在论文中写上“本文不必参考任何文献”，但搜罗了一波文献资料之后发现国内居然还算有些研究，只是这些文章大多数写得吧，不能说不好，起码对我写综述还是能够提供很多帮助的，但是基本无法为项目本身提供帮助，不过这倒也不算什么大问题，全球范围内的开源社区存在相当高质量的项目啊，凭借我多年在网上闲逛填出来的收藏夹，真的有项目的实现效果非常符合我的设想。

现在文献综述根本就是小事，反正论文是不缺的，关键任务是我需要确定项目能够实现哪些功能，并且各功能要怎么去实现，下载下来的论文给不了我答案，脑海中模糊的想法也不太切合实际，我的心思很难不放在上面所说的开源项目。当我真的找到那些在论文中意味着“关键技术”的代码片段时，一切迷雾在此刻都悄然散去，尽管我的需求所采用的编程语言与它不同，但是它的方案让我看到了一种可能，一种绕开当前最大障碍的可能，它巧妙地运用了编程语言和环境提供的特性，而我在后续要做的，就是用我自己的方案去把这种可能的概率做到100%。

开题报告

我是不喜欢写报告的，尤其是对格式有严格要求的报告，所以开题报告写起来断断续续，花了很多天才陆续将各个部分写完。三年来大大小小的报告和论文都写过了，可以说写报告就是一种文字艺术。

老师不是工程师，很多老师事实上对软件项目的开发并不是那么了解的，甚至一些比较新的编程语言对他们来说都不一定接触过。术业有专攻，学者就是学者，不能妄想他们随手就能写出漂亮的代码，就像全栈工程师开发专业软件也少不了专家提供理论基础一样，能够同时集两种角色于一身的人才少之又少，我们是不可以用这样的标准去要求所有老师的🤣。

而学生写的报告又是给老师们看，所以写报告时需要假设老师们啥也不懂啥也不会，但同时还不能丢失作为开题报告的那一份学术性，因此写作时的目标就是用偏学术的语言把你的项目掰开揉碎了去解释，这样就能达到一个比较高的水准了，说白了就是卖拐，通过表达方式的转变，简单的项目也能写出技术含量，只要让导师看到你发的word文档后能发出“写得不错”的评价目的也就达到了（当然我的选题看起来和做起来都远没有那么简单）。曾经的一项大作业我印象比较深刻，在代码里我无所不用其极，琢磨了各种优化代码结构的点子，但在写报告时划水太严重，最终的成绩并不如人意，因此在这方面可以说已经吃过亏了。

对于各种大作业，代码之外往往是才更需要认真思考做足准备的工作。

说到这儿，想象着那些程序员们在岗位上每个礼拜写周报描述自己所做的工作，到头来却是给并不了解技术栈的领导看，也就不难理解互联网行业黑话诞生的合理性了。

开题答辩

经过了上半年其他大作业答辩的折磨，我也算是有那么点领悟到答辩的精髓了，半年前线上答辩时边开大会边开小会的场景恐怕很难会忘记。我时常在想，这其中到底存不存在一些不合理的东西，存不存在起初没有要求而答辩时突然变卦，存不存在压分降分，存不存在老师其实根本不懂相关技术，甚至存不存在撒娇卖萌就可以混过工作量要求？很难保证不存在。

但是当答辩成为一种语言艺术，那项目本身的地位就不再那么高了，如何描述自己的项目、如何介绍自己的工作才是首要的。由于导师们大多并不对技术细节很感兴趣，所以如果你讨巧地去加入一些技术性的描述，就会使整体内容充实很多，工作量的问题自然迎刃而解。而对于那些『炼丹』选题，我对AI并不够了解，但我看下来基本上只要把训练目的、训练数据、训练模型这几点讲清楚，那导师多半是不会为难你的（不过我始终觉得在本科毕设炼丹不是一个很讨巧的选择）。

当然，毕业设计的开题答辩相对来说要正式得多，至少从我的主观视角来看，即使是一些AI和机器学习方向的选题被导师们『大力输出』了一波，也没有出现无中生有的情况，一些十分尖锐的评价都是言之有理的，几个信管系统的选题获得的提问大都从是业务出发延伸出来的技术问题，到我这导师们居然统一口径都表示没什么问题，这着实出乎我的意料，不知是不是被导师打过招呼了，不过一听给的建议是看看工作量不要太大了做不完，那想必确实是没什么问题了，所以感觉我还是挺幸运的。

答辩的PPT我其实准备得还挺认真，甚至对一些细节已经写好了文案，不过世事本就不可预测，在意料之外也实属正常，权当是顺手给毕业答辩做了个模板吧🤣。