第16天-2026-8-21-cnblog

今天是时隔多日又一次写每日笔记了，前端时间因为岗培，需要学习非常多的前端知识，我没有精力来写，特别是后面使用公司前端组件UI来进行开发的时候，因为不熟悉，所以总是会有许多bug，重要的还是学习组件使用吧，还是学到了很多东西，比如查看官方文档进行开发，拿到一个任务进行需求分析，任务拆分，测试等等。

今天开始继续写吧，后面一段时间是后端岗培了，我觉得相对来说难度不会有前端那么大，我还是好好整，我想的是继续学习，特别是如果有时间，可以多补一下现在自己的技术栈，我后端开发技术栈上面现在还差的一个就是消息队列和docker，这个可以有空学习一下。

我要好好规划一下自己的时间了，今天需要学习：

• git
• 后端开发环境搭建

我打算git看一下文档即可，了解一下基本原理，会一些基本操作指令即可。

后端开发环境就采用先看视频，后面再看文档的方式。

因为之前是了解了一下git的，所以这里我先学一个git中的diff算法，因为对这个比较感兴趣。

顺便写一下22号的吧，晚上睡得晚，上午直接12点多才起来吃饭，直接也是睡安逸了，但是睡得我脑壳痛。下午看了一下岗培后端的内容，主要讲了一下开发规范，比较不同的是标准springmvc框架的controller层，在公司框架下是用的rest层，其实实际效果也是一样的，公司在这上面封装了一下，其他的就没有什么了。在mapper层和service层都要读写分离，在这个目录下，建两个文件夹read和write实现读写分离，方便后续架构升级。然后命名按照公司规划即可。

接着是讲了一下springboot基础，主要就是介绍了一下springboot，然后就是注解，自动装配等等。

接着就没有看这个了，看着实在无聊。

然后就还是想着要做一个双人情侣网站，哈哈。我先让ds写了一下prompt，然后用了一下dsh，感觉还行，然后让它写，我感觉还是很快，就是消费比较快，就停了，它直接给我开了两个子代理，三个并行运行，才一会用了我3块钱，我就停下来了，我还是想后面可以自己先写一写，所以就暂停了。我在github上找了一个类似的项目，我看做的真不错，所以就准备git下来看一下别人的效果，但是git速度太慢了，我选择下载下来，但是之后运行项目有一点问题，而且我看好像这个项目还接入了大模型的，不知道用在哪一方面，害可能我还是太抠了，哈哈，只想要白嫖，现在来看我应该只需要先大概设计一下，可以快速上手，设计要具有高拓展，后续还可以继续升级。

我觉得这个还是非常有意义的，毕竟记录还是非常有意义的，每天可以花一点时间，记录一下今天的心情，有倾诉对象也是非常不错的，能够说出来写出来，还是非常好的，特别是我觉得如果还能够基于这个拓展其他功能，但是目前我还想不到。

如果我自己来写，我选择的是java spring搭建后端，vue3来写前端，ui组件选择element-ui，先写完这个之后，后续看能不能还接入agent吧，agent可以给我们提供服务，可以来管理我们的知识库。所以还是需要学习一下的，以及项目部署，我还一次没有整过。

今天学了一个特别有意思的知识点PID，这样的场景：现在水的温度是20度，我们需要使用金属棒将其加热到80度，咋一看这不是很简单吗？如果是人来做，用一个测量温度的（这里我们先忽略测量温度的准备性），可能一开始就会有聪明人知道，我们不能将其恰好加热到80度时，我们再减小金属棒的功率，而是应该提前就减小，但是这是非常难以控制的，很大情况会出现还没有加热到80度就因为减小功率导致温度达不到80度，因为水会挥发热量，或者因为减小功率太慢，最后温度超过80度，大概情况下，最后的温度就会在[75,85]之间徘徊，很难恰好80（误差很小我们就可以认为是恰好80），非常有经验的人可能可以控制温差在2度以内，人来控制太困难了。

所以我们想，能不能设计一套数学模型，然后机器来进行控制呢，这就是上面的PID算法模型了，我听那个博主说是这个是比较老的控制算法了，可以运用到许多地方，比如无人机上升到一个指定高度，或者机器人抬手到一个指定高度，都是可以基于这个算法模型，现在这个算法模型随着时间发展，有了许多优化，但是我还是只了解了一下这个，我们来试着复现一下这个算法模型。

定义一个\(e=D-S\)，其中\(D\)是目标温度，\(S\)是当前温度，\(e\)就是温差，我们的目标就是让\(|e|\)尽可能小。

上面PID算法分别是有三个参数\(K_p,K_i,K_d\)，其中\(K_p\)是一个系数，比如说\(K_p=2\)吧，那么每个时间点我们设置功率\(P=K_p\cdot e\)，最后形成的一个温度曲线应该是这种：

一直在80度上下振荡，几乎没有机会恰好到80度，因为水会挥发热量，如果恰好到达80度之后，\(e=0\)，那么功率\(P=0\)，温度一定会下降，之后\(P>0\)，又升温，所以几乎不可能温度到达80度。

我们再考虑加入一个参数\(K_i\)，这是一个用来纠正那种较小距离的，比如这样的：

t	T	P
1s	22c	116w
...
20s	79c	2w
21s	79c	2w
22s	79c	2w
...	79c	2w

也就是现在79度时，恰好金属棒的功率和水挥发热量想同了，那么温度就不会上升，达到稳定，这时候我们引入一个\(P_2\)功率，前面那个称之为\(P_1\)。

我们会设定一个阈值温度\(T'\)，当\(T=T'\)时，我们开始使用\(K_i\)这个参数，\(P_2=\sum_{t=T'} K_i\cdot e_t\)，这个会一直累加，也就是他会一直累加，直到可以产生影响，当温度逐渐升高，\(P_2\)增加的越来越少，当温度恰好达到80度时，\(P_1=0\)，这时候\(P_2\)恰好就是可以满足平衡的功率，温度也就保持在了80度。

不加入\(K_i\)：

引入\(K_i\)后，我们完全可以等\(P_1\)恰好和挥发热量相同时，这时引入\(P_2\)，开始累加，然后\(P_1\)逐渐减小，\(P_2\)逐渐增大，但是增长速率越来越慢，直到刚好可以让温度稳定在80度。

但是为什么还需要一个\(K_d\)呢，这又是干嘛的，从感觉上来说，前面两个已经足够解决了，但是一个前提就是\(K_p\)可以在80度以下保持到一个平衡，这时候再引入\(K_i\)，那么恰好稳定在80度，其实我在这有一个疑问。

我的假设是：

只要 Kp 使得温度在 80 度以下达到热平衡（比如 79 度），然后引入 Ki 缓慢累加，就能恰好停在 80 度。

这个逻辑在纯数学的"静态"场景下成立，但现实物理系统有一个致命特性——惯性（滞后性）。

我问了以下ds，说是物理系统有惯性，而引入\(K_d\)就是用来解决这个问题的，让它可以平滑到达80度，也就是只引入\(K_p,K_i\)，最后温度也还是会到达80度，但是不够平滑。还是会振荡，最后趋于80度，但是我们不希望它发生振荡，\(P_3=K_d\cdot de/dt\)，也就是一个关于\(e\)的微分，用来削弱其惯性。因为有惯性，也就是金属棒的热量传播到水中需要时间，然后这时候在\(T=79.5\)时，可能功率已经就是稳定时的功率，但是因为温度还没达到，那么\(P_2\)继续增大，导致最后超出80度，而我们知道靠近80度时，\(P_2\)的增加是逐渐变慢的，这时候\(P_3<0\)恰好可以进行一个抵消，最后就可以恰好稳定在80度，我只能说非常叼啊。

害算了，哈哈，让ds给我写了一下python代码，准备仿真跑一下，但是跑出来加了kd也不是太明显。

最后功率的公式为\(P=K_p\cdot e+K_i\cdot\sum e +K_d\cdot de/dt\)。

• P：比例系数；
• I：积分系数；
• D：微分系数；

一般来说引入\(K_d\)要明显，是对于那种响应要快，同时又存在惯性的系统，这时引入\(K_d\)就会非常明显，这也是很显然的，因为反应快，意味着时间短，那么惯性就非常大，\(K_d\)影响占比就变得很大。