我家所在的这栋楼有四十余层高，四户俩梯。如果楼层数不是这么高，俩梯应该算是够用的配置。房子建好后其实就有很多业主有顾虑，但毕竟已经建好了，再加电梯也不是很现实。最后给出的方案是把电梯都升级成“高速电梯”。
“高速电梯”的优点就是高速，加速得快，最大运行速度也高。这听起来很不错，但停靠的楼层多了以后优点就发挥不出来了，就像让运动员跑100米，但每10米必须停下来一次。
电梯的物理性能固然重要，但更重要的可能是电梯的调度算法。虽然没办法黑进电梯的调度系统中查看准确的调度算法，但平时候梯时多观察也能大概感受出这个算法的“性格”。
观察了好一段时间，发现了这俩电梯调度并不一定是为了最高效率，似乎是在挑战住户的耐心，并尽可能给自己省电。
没有人唤梯的时候一般他们会停在21层左右的位置，这个策略比较能理解，在楼层数的中位，哪边有人唤梯都能马上服务。这俩电梯就叫做A和B吧，我发现A在21层休息、B在40层服务的时候，如果10楼有人要下楼，A是死活不动的。感觉听见A在说：“B在40层干活，等下下来就顺便接了，我不想动”，像这样A摸鱼B拼命干活的场景我经常能遇到。
以前我也研究过单梯的调度算法，因为单梯调度算法与磁盘调度算法其实是类似的。对于机械硬盘来说，磁头相当于电梯轿厢，磁道相当于楼层，读写请求就和按下唤梯按钮类似。
当时单梯调度最好的算法应该是LOOK，而这个算法实现起来也比较简单。现在单梯比较少见了，而且调度与楼栋功能和时间段都有关系，调度算法的复杂度就提升了。
早些年出差的时候有遇到过一栋楼，电梯间可以通过语音交互来确定是要上还是下，并且还可以说明清楚是要去哪一层。这样的唤梯方式除了“上/下”以外还带有目标楼层信息，对电梯的调度系统来说应该是更好的。
想了下如果直接用LLM来进行电梯调度应该是不太可靠的，优势也不太明显。但电梯间引入LLM去询问用户目标楼层或许不错。简单一想，有些场景楼层比较多，不同楼层的“功能”还不同，这一步甚至可以直接问对方想到什么地方，LLM来回复楼层数并记下这个需求。