按下按钮，产生的是一个会影响别人的请求
你在等电梯，楼上的人也在等，电梯里还有人要下楼。电梯该先去接谁？只看谁离得近，还不一定够。
这里比较三种办法：先接较早等的人、先接近处的人、沿着当前方向顺路接送。每种办法都可能让一些人少等，让另一些人多等。
比较时，把同一批人放回同样的到达时刻，再换一种规则。这样才看得出，差别究竟来自接送办法，还是客流本来就不同。
把同一批人，交给三位不同的调度员
- 跟住一个等电梯的人。 看电梯去接别人时，他还要等多久。
- 重放同一批乘客。 只换接送规则，比较谁先上车、谁还在等；每种办法都照顾了同样的人吗？
一个好看的平均数，可能藏着什么？
想细看：完整过程与器件说明
先盯住一个在大厅等电梯的小人：电梯去接别人时，他就要多等一会儿。我们要比较的，是怎样安排接送，才能让大家少等。
一位乘客希望电梯尽快到自己这一层。可同一时刻，另一位乘客在楼上等待，梯内还有人想去别的楼层。电梯不能只问“我离谁最近”，还要考虑已有乘客、行驶方向和未来可能接到的请求。
实验用两部电梯与固定的一批乘客，把这些冲突放进同一座小楼。开始运行后，注意每位乘客的状态：尚未到达、正在等待、已经乘坐、已经送达。系统效率是这些人的体验共同构成的。
这里有三种可解释的规则。先来先服务优先处理较早的请求；最近任务优先尽量缩短下一段空跑或送达距离；顺路停靠则保持方向，沿途接送同向乘客。
这些规则各有偏好。一次看起来最省距离的选择，不一定让最终平均等待最短；最早按按钮的人，也不一定在最短路径上。
更细的操作
先选择早高峰。乘客从大厅陆续进入，目的楼层不同。让一种策略运行一段时间，然后点击“对比同一客流的三种结果”。它会从头运行相同请求，比较平均等待与平均乘坐时间。
再换成各层往来。你会看到需求分布改变后，策略的表现也可能变化。不要只记住一张表里谁领先，更值得问的是：哪种请求结构，让它的规则占了便宜？
设定新增乘客的目的地，再点击某层旁的 +。试着在电梯刚刚经过后加入乘客。对这个人来说，等待可能很长；但立即掉头，也可能影响更多梯内乘客。
设想一个新目标：尽量降低“等得最久的那个人”的等待。它可能需要与降低平均等待不同的策略。
展开：为什么实时平均等待只统计已上梯的人？
仍在等待的人尚未得到完整等待时长。如果只看已上梯乘客的平均数，可能过早觉得表现很好，因为最难处理的请求还留在队列里。因此界面同时显示当前等待人数、送达人数和总乘客数。
完整对比会运行到所有人送达，或达到明确的模拟时间上限。若未送达完毕，会标出未完成，不能把结果当成完整客流的平均体验。公平比较还需要相同的到达时间、起点和目的地，而不只是“人数相同”。
展开：真实电梯为什么更复杂？
真实系统要考虑加减速、开关门、载重、不同楼层高度、通行限制、故障与更复杂的交通预测。目的层派梯还可以在乘客上梯之前知道其目的地，从而把相近需求分组。
本实验固定每梯容量 6 人、速度 1 层每秒、停靠开门时间 1.5 秒，使用简单规则展示权衡。它没有实现任何厂商专有算法，也不能用于安全控制或楼宇运力设计。