人机交互发展历史

1. 批处理阶段；

2. 联机终端时代；

3. 图形用户界面 GUI 时期：相较于命令行的优点是依赖识别而非记忆。

4. 新的界面变革包含了上一代界面：作为一种特例

5. 旧的交互方式仍有其存在的必要性：以前的用户从未消失

执行隔阂与评估隔阂

1. 执行隔阂：用户想要执行的动作和系统允许的动作有差异，比如想要提交找不到提交按钮；

2. 评估隔阂：（评估阶段中）用户执行一个操作后总是想感知一下自己的操作的情况（是否结束、是否需要修改），但是系统没有给反馈。

软件开发四大本质难题

1. 不可见性（不因项目而异）、复杂性、可变性、一致性

软件发展三大阶段

1. 软硬件一体化：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更；measure twice cut once、code and fix；

2. 软件成为独立的产品：摆脱了硬件的束缚、功能强大、需求多变、兼容性要求、来自市场的压力；形式化方法、结构化程序和瀑布生命周期模型、成熟度模型；

3. 网络化和服务化：功能更复杂 、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享文化；迭代式开发、敏捷开发、开源软件开发方式、DevOps；

4. 管理的三大关键要素：目标、状态、纠偏

5. 软项目管理的三大目标：成本、质量、工期

1. “Measure twice, cut once” 描述的是下述哪个软件开发场景：

   A. 软件设计；

   ==B. 代码评审；==

   C. 需求开发；

   D. V&V；

2. 整体来看，我们可以把软件的发展分为三大阶段，以下不属于三大主要阶段的是：

   A. 软硬件一体化； (1950s - 1970s)

   B. 网络化和服务化； (1970s - 1990s)

   ==C. 云计算化和云原生；==

   D.软件成为独立产品；(1990s - )

   阅读全文 »

🎮 外设推荐 —— 樱桃Cherry MX2.0S 白色 有线 🍒

🌟 写在前面

本系列是我推荐的一些 个人喜爱的外设，全凭主观感受，没有任何专业性，仅供参考！

如果你和我一样追求高颜值和高性能，那一定不要错过这个系列！

今天推荐的产品，是我在 2021 年 10 月买的一款键盘——CHERRY MX2.0S 机械键盘。 这张键盘陪了我也有三年了，一直是我的主力键盘，可以说是颜值无敌，声音无敌，手感无敌。

嵌入式方向实践 小车实验报告

实验任务

背景

主要学习和考核以ROS为主的机器人相关知识、非常符合目前机器人产业界的人才需求，同时其更高的技术门槛，以及更激烈的对抗性。

为保证线上比赛的公平性，智能车室外光电组线上仿真比赛平台统一用「Gazebo」。赛道模型和无人车三维模型统一提供。线上比赛需要先把赛道模型导入Gazebo，采用ROS中建地图的方式构建赛道地图，通过自主导航算法实现无人车完成从起到到终点的运动。仿真平台的传感器可以使用IMU，激光雷达或摄像头，仿真平台自主导航算法不限。

实践四_评估LLM对约束表达式的匹配能力 实验报告

实验要求

在实践二中，大家已经将约束表达式交由大语言模型去生成相应的测试用例输入，而在现实的工程环境 下，并没有所谓的正确代码，只有需求文本（即功能说明注释）与待测试的代码，这时我们可以将待测 试代码的约束表达式交由大语言模型，让其辅助判断是否与功能说明相符，是否有错误或遗漏。

本次实践的主要任务是模拟在没有标准代码的情况下，通过将待测试代码的约束表达式与功能说明注释 交给大语言模型，让其判断是否相符，以评估大语言模型对约束表达式的理解能力与匹配能力，从而探 索待测代码的约束表达式能否直接交给大语言模型判断对错，使得测试代码更加方便，准确。

本次实践的原材料依旧为上交实践一成果后分发到的约束，要求大家将每份代码的约束表达式与对应的 功能说明注释交给大语言模型，设计提示语，让其判断是否相符，是否有遗漏等匹配情况，记录下大语 言模型的判断结果（正确/错误/遗漏/……）并计算其判断正确率。

为了防止大语言模型的惯性回答，要求将分发得到的约束表达式进行一定的变异（比如故意改成错 的），来测试其判断正确率。也可以将功能说明进行一定的改动，使其与约束表达式不相符。对于一份 正确的约束，要求至少变异为一份错误的/遗漏的约束。 同时由于大语言模型的不稳定性，在评估判断正确率时，应用相同的提示语多次向大语言模型提问（无 上下文，开新的对话框提问才算为多次），取平均值，本次实践要求每份正确/错误的约束至少重复提 问 3 次，方可评估其判断正确率。

本次实践的成果要求为一份实验报告，包含你所设计的提示语（prompt）、每条约束表达式及判断结 果（文本形式记录）与大语言模型对话的截图（两三张即可），并记录下大语言模型对于约束表达式判 断正确率（请按照上述要求重复生成后再计算正确率）。

实践三_通过LLM生成测试用例输出 实验报告

实验任务

本次实践的主要任务是模拟在没有标准代码的情况下，通过将测试用例输入（实践二得到的）与功能说明注释交给大语言模型，让其生成一系列的测试用例输出，以评估大语言模型在解析能力与计算能力， 同时连同实践二的内容一起，探索该借助大语言模型生成完整测试用例集的方法的可行性。

而大语言模型基于测试用例输入与功能说明注释所生成的输出并不一定是正确的，因此需要检查其生成的输出（即以实践一所转换的 Cpp 代码运行测试用例输入来核对其输出是否正确），并将正确的输出作为最终的测试用例输出，也请记录大语言模型生成的测试用例输出的准确率，由于大语言模型的不稳定性，在评估准确率时，应用相同的提示语多次向大语言模型提问（无上下文，开新的对话框提问才算为多次），取平均值，本次实践要求每份代码生成测试用例输出时至少重复提问 3 次，方可评估准确率。

本次实践的成果要求与前两次实践类似，为各份代码各个输入所对应的测试用例输出（由大语言模型生成的多份 + 由程序跑出来的一份），与实验报告。实验报告需包含你所设计的提示语（prompt）与大语言模型对话的截图（两三张即可），并记录下大语言模型生成的测试用例输出的准确率（请按照上述要求重复生成后再计算准确率）。

实践二_通过约束生成测试用例输入 实验报告

实验任务

本次实践的主要任务是将实践一转换得到的 CPP 代码通过约束求解得到的约束，借助大语言模型得到相 应约束的测试用例输入，一是进一步评估大语言模型对于抽象表示的识别能力，二是探索生成测试用例 输入的新方法，在下述样例中会详细阐述。 在上交实践一成果后，助教会生成好对应代码的约束，分发给各位同学作为实践二的原始材料，不需要 大家去仔细学习约束求解的过程，大概了解约束是怎样的东西即可，想了解的同学也可以查看附录内容 自行探索。

实践一_ 利用大模型将python程序转换成C++程序 实验报告

实验任务

请大家将认领到的程序, 尝试借助大语言模型将本文件夹中的 Python 代码转换为 C++ 的代码。应该提 交: 1.原始python代码, 2.大模型输出的C++代码 (标注由哪个模型输出, 以及驱动大模型的prompt), 3.以 及手动修正后的C++代码(需要通过编译, 且可执行, 执行结果正确.)

输入的 Python 代码均由两部分组成，主要功能函数（函数名不确定，函数中含有功能说明注释）与测 试函数（ check(candidate) 函数）; 手动修正后的 C++ 代码由三部分组成，由主要功能函数（函数名 不确定，请手动将功能说明注释同样补充在其中, 粘贴过去即可）与主函数（ main 函数，用于调用主 要功能函数来进行测试，不需要包含原有 check(candidate) 中的所有用例）。

开始

在第二章中，我们讲了如何将 Hexo 生成的网页部署到 GitLab Pages，但有一个比较麻烦的地方：每次改写网页或新增 Markdown 文件后，运行 hexo deploy 部署时，都需要重新在 GitLab 项目中上传 .gitlab-ci.yml 文件以触发流水线。这无疑非常麻烦。

经过两小时的研究，我发现问题的根源在于：通过 hexo deploy 部署网站实际上是 GitHub Pages 的惯用方式，而 Hexo 官方文档中对于 GitLab Pages 的部署建议则是另一种方法。

本章将讨论部署到 GitHub Pages 和 GitLab Pages 的区别，以及当我们错误地使用 GitHub Pages 的方式部署到 GitLab Pages 时（是的，这种“粗心”就是我了），有没有快捷的补救办法来避免每次上传 .gitlab-ci.yml 文件。

说明：这里所说的部署是指改写网页或新增 Markdown 文件后，重新部署更新网站，而非从零开始的部署流程。