这是在极客时间学习《AI 大模型应用开发实战营》课程时，进行的学习记录。由于平时工作比较忙，缺乏大块连续的时间，没有功夫对OpenAI-Translator进行专门的二次开发，仅是完成作业。并且，我更喜欢说明软件工程中容易被人忽视的内容，如整体结构等，而不是关注于具体的编程细节。作为一个专业的软件工程人员，阅读代码理应是最基本的能力。
由于没有时间，懒得去实现具体代码，只是对相关具体代码或特性进行描述。
实现一个简单的界面很容易，无论是Qt，还是其他gui框架的python封装，结合chatgpt进行实现对于有一定经验的人员都不是太麻烦的事情。但如果考虑到特性3中要求的服务化，以及后续开发等问题，最好的情形应当是给出一个纯界面，只对通信、命令进行解析和显示。而不应当是从CLI改成GUI，这违反了特性3的要求。另一方面，将界面和实际提供功能的服务进行彻底的分离，即便是单机程序，能够有效的降低工程复杂度。只要是协同开发，只要不先行划定功能界限，最终大概率是编程一个巨无霸，大规模重构可能都改不动。
这个特性是需要GUI支持，甚至更简单一点，换一个提供pdf预览功能的python库，使用库功能进行显示。按照我对相关python库的使用，都能够对pdf的具体一页进行提取，结合GUI就能够显示了。另一方面，如果要有GUI，要有对源PDF的原始布局支持，这必然会带来更大的功能需求，就我个人感觉，如果显示源PDF，那就应当必须能够对比显示翻译后的文件，但为了保证对比显示的效果，最好的方式就是取消源PDF的原始格式，而是采用文件比较相互对应的方式。如果仅仅是显示源PDF，我不觉得这是个有必要的功能，即便是有一个GUI。所以仅从软件工程开发来看，这个特性似乎不是很有必要，当然，也有可能我理解错这个特性的目的。
这是一个相当基本的功能，无论是封装成http还是用zmq，目前来看都可以完成要求，具体看后续功能的要求。封装成API的形式，在使用这种开发方式时，往往忽略了其在划定功能范围、降低复杂度上的长远影响。
PDFTranslator的translate_pdf中参数有一项即是设置语言的，修改这一项就可。
作为一个专业的软件开发人员，在ChatGPT上线的时候就已经尝试着使用它生成项目，但就实际体验来说，只能说一言难尽，只要项目超过一定复杂度，ChatGPT马上就体现出自身的局限性。就软件开发而言，依然是必须由使用者提前构思好项目的整体结构，然后根据整体结构逐步细化逐步生成。但是吧，如果不具体参与到实际开发过程中，又怎么能深入理解该如何给出一个合适的整体结构呢？除非实际开发过一遍或是有大量的经验。而在ChatGPT对话中，如果思路出错了，之前的对话记录可都是保存着了，新对话很难进行全面的调整，但如果要重启一个会话，那之前保留的记录又需要重新输入了。就以项目开发，必须要进行充分的结合，才能够有效的提升效率，至少目前，大模型的能力依然不足以承担主体功能，而是要充分发挥其辅助性作用。