电梯
文章摘要
这是一篇带交互式仿真动画的科普长文，作者 John 用一句话概括了主题：「你如何按它们的按钮，以及它们如何按你的按钮。」文章拿到了 1678 分，是本期最热门的条目。
从 SCAN 到 LOOK。最简单的电梯算法叫 SCAN，1961 年获得专利：电梯从大堂出发一路开到顶层，然后反向下行，沿途接送所有人。但多数时候你并不需要真的去顶层，如果电梯只上升到被请求的最高楼层就掉头，这个算法叫 LOOK——这也是大多数人认知中、并期待的电梯行为。
多轿厢协调。当有多部电梯时，谜团才真正开始。最基本的系统里有一个中央调度器告诉每部电梯该在哪些楼层停靠，新请求来了就分配给最近的电梯。但文章很快说明我们可以做得更好。
如何衡量好坏。最直观的指标是你等电梯等了多久。简单版本是「电梯在 30 秒内到达的频率有多高？90 秒呢？」更严谨的做法是看等待时间的分布：把上千次乘梯的等待时间画成直方图。p90 为 2 分钟意味着 90% 的情况下乘客等待不超过 2 分钟；p50 为 1 分钟意味着一半时候电梯 1 分钟内到达。文章点出了关键的心理学：人们通常不记得平均等待时间，他们死死记住的是那些电梯花了「一万年」才来的时刻，也就是 p90 的情形。
流量模式。并非所有客流都一样。想象一栋大型企业办公楼：早晨几乎所有流量都是从大堂到高层；傍晚则完全反转；午餐时段两者兼有；剩余流量常常是楼层之间的横向移动。等待时间的分布会随时段和电梯面对的流量模式剧烈变化，而早高峰的等待统计出了名地最差。
RSR：更聪明的电梯。文章的技术核心是奥的斯的 RSR（Relative System Response，相对系统响应）算法。它给每部电梯打分，衡量它有多适合去接这位乘客，分数越低越好。评分公式是：接客预计到达时间 + 载客量惩罚 + 同向防聚集惩罚 - 方向匹配奖励 - 附近空闲奖励 - 低负载奖励。其中「防聚集」（Anti-Bunching）指的是如果已有另一部电梯正朝同一楼层同方向前进，就惩罚这部电梯；「附近空闲」指奖励距呼叫者两层以内的空闲电梯。
而 RSR 最关键的特性是：它每 5 秒重新优化一次。原本要由 A 电梯接的乘客，如果 A 遇到延误，可以被重新路由给 B 电梯。文章明确指出，这个重优化才是理顺交通流的关键。
LOOK vs RSR：反直觉的结果。文章用自建的仿真做了基准测试，得出了两个有意思的发现：随着客流速率升高，LOOK 反而开始跑赢 RSR——当电梯总是满载、每层都停时，那些额外规则就没那么重要了。另外，在电梯组内轿厢数较少的小型建筑里，LOOK 也倾向于优于 RSR。「有时候保持简单反而更好。」
目的层调度：最反直觉的部分。一些高档新电梯在每层设了触摸屏，让你在电梯到来之前就指定目的楼层，屏幕随即告诉你去等哪部电梯。这叫目的层调度（Destination Dispatch）。乍看之下这应该很棒：优化器现在完全掌握了谁要去哪里，肯定能减少等待时间吧？
结果是：这些花哨的触摸屏在等待时间上普遍比传统的上下按钮更差。确实存在触摸屏胜出的边缘情形（极高的楼、每组 8 部以上轿厢），但对绝大多数情况来说，简单的上下按钮才是王者。
作者对此的解释是：这个反直觉的结果完全归功于那个每 5 秒重新优化各电梯路径的再平衡步骤。触摸屏强制了刚性——你必须进入被分配的那部电梯。而在你呼叫电梯 30 秒之后，世界的状态可能已经大不相同，但系统无法适应。「结果表明，损失的灵活性抵不上优化器多得到的那点信息。」
文章末尾提供了一个包含全部旋钮的完整仿真器（楼层数、轿厢数、客流速率、时段模式、三种算法切换），并以一句温柔的话收尾：下次你被困在电梯前时，别往心里去，电梯听见你了，只是它有很多事情要考虑。
HN 评论精华
这条讨论有 1678 分和 400 多条评论，气氛非常欢乐。除了对算法本身的讨论，很大一部分内容是三类东西：怀旧游戏（SimTower、Elevator Saga）、真实建筑里的电梯惨案，以及大量关于「人类根本不懂怎么用电梯」的吐槽。
这曾经是一道经典面试题
好几个人的第一反应是面试创伤。shadeslayer_ 说这篇文章让他闪回到五年前一场特别烦人的面向对象设计面试。jhaile 则说这曾长期是他最喜欢的面试题之一：「这是那种没有候选人能完全解决的问题，但你能看到他们如何思考。而且它看起来一开始很简单，复杂度却像洋葱一样一层层剥开——就像这篇文章做的一样。」duderific 说他们公司用过这道题，甚至只要求单部电梯，「即便在这个相对降低的复杂度下，弄清楚谁该先被服务也相当棘手」。stkni 说这题的好处在于开销极低：每个人都懂基础，所以铺垫成本最小，但总能引出大量有趣讨论。
crabbone 讲了一个更有意思的版本。他被第 N 次要求设计电梯时已经决定不去这家公司了，于是决定用一种意想不到的方式作答：他不用等待时间衡量效率，而是纳入了（加权的）行程时间。然后在计算不同行程的各种结果时，他突然意识到电梯的效率和公平性似乎指向不同方向。他的发现是：如果有两名乘客，一位从底层去顶层，另一位中途加入做一段较短的下行，那么让电梯绕一下的做法更高效——但让那位从底层去顶层的乘客反方向哪怕走一层，怎么看都不公平。「在那之前我一直活在一种幻觉里，以为一个问题最高效的解法必然对每个参与者都最公平。发现这个反例把我送上了一场伦理学和不同哲学家的『发现之旅』……虽然最后并没让我变得更聪明，但我很高兴发现了这个领域。」
来自行业内部的声音
dbcurtis 是本帖信息密度最高的评论者，他做过多个第三方电梯集成（与电梯控制器通信、协调其他设备的软件）。他说，一旦你能完整看到所有轿厢的位置和运动，最让他震撼的是它们的排程有多繁忙：「在电梯厅等一部轿厢感觉像一辈子那么长，但从调度侧看是一片活动的旋风，在建筑正常有人的任何时段，轿厢几乎从不空闲。看着状态面板就能宅出乐趣。」他还澄清了一个常见误解：「不是电梯调度软件迟钝，那套软件被投入了大量思考。但电梯很贵，业主不会一时兴起超支。通常他们的轿厢数量刚刚好够应付预期负载（如果够的话）。」关于优化目标，他也给了明确回答：「基本就是吞吐量。单个轿厢的资本支出压倒任何其他成本，所以减少轿厢总数的唯一途径就是优化吞吐量。」他还附赠了一条行业冷知识：如果电梯技工说「我们明早第一件事见」，他指的是凌晨四点左右——他们想在人们开始一天之前进出。
关于「电梯空闲时停在哪」，dbcurtis 确认这是控制器里的一个编程选项：空轿厢策略确实存在，如果所有轿厢都空闲（非常罕见），它们通常会被分散开。
besil 说他目前在全球顶级电梯公司之一做 R&D 软件：「我从没想过一个上下移动的箱子背后有这么多挑战。这个行业如此小众而独特。电梯行程调度只是众多挑战之一。」
cyberax 提供了一条重要的物理学冷知识：现代电梯有再生制动，下行时能回收大部分能量（老电梯用制动电阻）。而且由于有配重，空轿厢下行通常反而更耗电。他还接了一句救命的知识：「这也是为什么火灾时不该用电梯。如果机房里的刹车失效，轿厢不会坠下去，它会向上走，可能把你拖进火里。很多消防员因此丧生。」
userbinator 补充了一条历史：在上个世纪大约一半的时间里，电梯完全由继电器控制，没有任何计算机，这些算法是用硬连线逻辑实现的，奥的斯的老专利里有包括电路图在内的有趣细节。swiftcoder 补了一句更惊人的：「这是个演进极其缓慢的行业。十年前，这个领域的一个大玩家还在用他们原始硬件继电器逻辑的软件仿真，因为那比重新培训所有技工便宜。」
目的层调度：最激烈的技术辩论
文章关于目的层调度更差的结论引发了本帖最实质的技术争论。
richk449 提出了核心质疑：「不可能仅仅因为拥有更多信息就导致更差的结果。最起码你可以忽略额外信息，达到和上下按钮相同的效果。看起来这个仿真里它表现更差的真正原因是：实现目的层调度时，他们在请求时就分配了电梯，且没有任何复审和更新分配的机制。」
sambellll 给出了现实约束层面的反驳：「我不认为在现实世界里可以同时拥有目的层调度和更新分配。如果用户点了 26 层而你告诉他去 G 号电梯等，你没法在它太慢时告诉他改去 F。但如果你不告诉他去哪部等，你就得让他在可能 5 到 8 部电梯之间跑来跑去找哪部去他那层？那显然不现实。那你就只能让他上第一部开门的——但那就跟上下按钮没区别了。」
hypersoar 提供了实际运作方式的说明：电梯厅有触摸屏，你点一个楼层，屏幕说「C 号轿厢」（还有语音播报），问题在于系统之后就无法把你重新分配到别的轿厢——通常会有一堆人去一堆不同楼层，没有可靠方式把新分配传达给每个个体。他说理论上可以让乘客在轿厢到达时自己检查它去不去自己那层，但那实际上会太混乱。
围绕这一点，好几个人独立提出了同一个改进方案。JoshTriplett 说：在头顶大屏幕上显示一组楼层（按楼层顺序排列便于查找），「电梯」那一列先留空，直到分配完成，让人们盯着自己那一列看会显示哪部电梯。joshjob42 提议在每部电梯上方放一排楼层号，电梯到达时它被分配去的楼层亮起，去那些楼层的人就上这一部——每个人只需要快速看一眼它去不去自己那层，就像现在看它是上行还是下行一样。namibj 提议给每个人一个类似 diceware 词表的「ID」，配一块类似快餐店取餐屏的调度屏。salberts 说他们楼的四部电梯上方就显示了计划停靠层，而且能在等待中途改变轿厢与楼层的分配并发出声音提示。JoshTriplett 在自己的方案后加了句无奈的注脚：「但是的，这似乎是一个『很不幸，人类』的案例。」
omoikane 从另一个角度质疑了文章的结论：这可能是作者使用随机目的地造成的假象。他工作过的目的层调度楼里常见的出行模式是：不在一层的人一般都想去一层；在一层的人一般成大群去同一个目的地。这是因为同层工作的人常常同时出去吃午饭、再同时回到同一层，而目的层调度在这种情况下有帮助，因为它把去同一目的地的大群人打了包。alexpotato 也认同这是目的层调度更好的最大原因之一，并提到有文章记载办公楼或酒店切换到目的层调度后等待时间大幅下降。dawnerd 说用目的层调度的游轮体验好得多，用老算法的船在高峰期等得很痛苦。
darkwater 则指出文章的前提对酒店完全不成立：「早晨流量主要从大堂到各层」在酒店里完全是错的，因为人们下楼吃早餐、上楼、再下楼；他见过酒店的触摸屏系统会在早餐高峰期切换界面。icosian 说他第一次遇到目的层调度是十五年前在伦敦一家酒店：任何不熟悉该系统的人会本能地冲向敞开的电梯，然后发现自己站在一部没有按钮的电梯里，完全茫然。「这对流动性人口来说不是对的系统。」
账面之外：满载检测
「电梯满了还一层层停」是本帖被吐槽最多的真实痛点。theodorejb 描述了最糟的情形：大型会议结束后所有人同时离店，电梯下行时很快满员，之后却还要在接下来 15 层的每一个有呼叫的楼层停靠——门开、等电梯的人看到已经挤满、门关，一层层重复，最后到底所有人才下去。StableAlkyne 讲了同样的场景，并指出对二楼行动不便的人来说这基本是绝境。sorz 从中国的兽迷展会带回了更极端的案例：房间全订满、年轻兽迷常四到六人合住一间、客房与大堂和宴会厅之间流量更大、客房层之间的横向流量远超普通游客，而且「一个穿全套毛偶装的人占 1.5 到 2 个人的空间」——酒店电梯完全没为这种场景设计，全天超载，排队几十分钟不罕见。DoneWithAllThat 说他曾在退房日花了半小时都没能让任何一部轿厢停在他那层（酒店有 8 组电梯），最后放弃改成「有氧运动时间」，扛着全部行李在 14 层楼梯上跑了五个来回。
Quinner 和 barrkel 都指出文章其实覆盖了这点——RSR 的评分公式里就包含载客量惩罚。hahahaa 猜测可以用重量判断，因为电梯本来就需要在超载时拒绝运行。yccs27 提出了一个不需要传感器的巧妙信号：可以检测电梯刚离开某层后呼叫按钮立刻又被按下——那意味着有人没能挤上去。Neywiny 认为只能靠重量，因为按钮方案会被滥用，摄像头方案有隐私问题。vova_hn2 提到有一栋楼的满载检测显然失灵了，导致电梯下行时每层都停，每次都上演一出尴尬场面：电梯外一大群人和电梯里一大群人对视，所有人都在毫无意义地等待。wrs 说他见过确实这样工作的电梯（大概用重量传感器），还读到过某些电梯有「小孩模式」，如果有孩子出去时按了所有按钮，电梯会取消这些呼叫。
关于人类如何误用电梯
olex 抱怨最大的问题不是算法，而是人们似乎无法理解要根据自己要去哪儿按上或按下：「几乎每次我都会碰到有人两个都按，因为『这样电梯来得更快』，完全无视了他们有一半时间会先走错方向、还给电梯里已有的人增加了一次没必要的停靠。」
但接下来几条回复很有意思地为这种行为做了辩护。gene91 说：「在有些地方我确实看到人们这么做。这不是愚蠢。我观察后学到了背后的逻辑：在某些繁忙建筑的高峰时段，电梯容量不足。因此如果你要下到一层，先上去再下来可能比等一部不满的下行电梯更好（更不坏的最坏情况，甚至更好的平均结果）。这种情况下按两个按钮是合逻辑的。」vel0city 描述了完全一样的机制。qurren 则给出了一个相反方向的精妙用法：他经常故意按错方向——假设电梯在 5 层，他在 1 层想去 3 层，而在他之前已经有人在 1 层想去 -1 层，他会跟着他们按下行进去，这样电梯上行时就不用第二次停在 1 层。
dsego 说在克罗地亚人们相信要按相反方向来「召唤」电梯：如果电梯在下面，他们会按上箭头把它叫上来。「然后当然，门开时他们会问『上还是下？』，这很荒谬。当我指出一层只有上箭头时，他们就无视我（根深蒂固的信念很难消除）。」nubg 回了句「太搞笑了」。
trivo 抱怨电梯门开时人们会问里面的人「你们是上还是下？」，「那儿有个箭头显示着呢，看在上帝的份上」。但反驳也很到位：themaninthedark 说有时候有人按错了内部按钮，或者有人本来要下去又改主意了。wpm 说：「是啊，你可以到处甩头找那个箭头，也可以直接问。尤其在繁忙的电梯厅可能有多部电梯同时开门，你甚至没法从叮声分辨。」SoMomentary 给出了最温暖的解读：「有时候我觉得这类『愚蠢』问题只是一种破冰方式，在我们各奔东西之前，用来友善地承认彼此在我们生命中片刻的存在。」ButlerianJihad 补充了一条冷知识：方向也由提示音表示，「似乎只有盲人和 YouTube 观众知道这一点」，并顺手链接了维基百科的「货物崇拜」词条。
davnicwil 提供了一个心理学解释：「这种情况下答案通常来自反过来假设他们确实理解，然后问为什么这么做有道理。老实说这大概就是『假进度条』心理学。不知道电梯什么时候到地等着很无聊/令人沮丧，而进入一部会动的电梯——哪怕方向是错的——感觉像是进展。事情在发生，即便最终花的时间更长，那也是个不那么令人沮丧的状态。」
「为什么不能取消已按的楼层」
Wowfunhappy 提出了本帖最多人共鸣的诉求：「我只想知道为什么我不能取消我误按的按钮。这应该非常简单。按一次开，再按一次关。」magarnicle 提出反对：「那些不想等的混蛋取消你的按钮怎么办？被动攻击式的按钮战争，升级成主动攻击式战争……」Wowfunhappy 反击：「我不知道，那些想让你等而按下所有按钮的混蛋又怎么办？这里的下行风险在我看来比上行收益小得多。」voyagerfan5761 说混蛋确实会按下所有按钮，所以新的电梯系统常被配置为在一次按下太多楼层时忽略它们——Wowfunhappy 立刻抓住这一点：「这就是我的论点。如果能取消按钮，这种攻击就消失了。」
事实层面的回应很丰富：ericbarrett 说他住过的高层楼支持双击取消，「可以确认非常好用」；dguest 说十年前在韩国就有这个功能，并列出了人们听说后的反应光谱——热情（太棒了所有人都该这么做）、怀疑（听起来是个糟糕主意，人们会取消你的楼层然后陷入混乱）、否认（你没看见那个）、以及文化/种族式的（那在某某国家永远行不通，肯定只是因为韩国人如何如何）。userbinator 补充了一条机械史：在一些旧系统里，按钮是真的按进去、到达时弹出来的，你可以把它拉出来取消呼叫。cwillu 给出了技术解释：最常见的控制电路是按钮触发一个继电器，继电器随后给自己的触发供电直到电路在别处被中断，这与用同一按钮取消呼叫不兼容。dsego 提供了一个野路子：某些电梯有紧急停止杆，他发现它同时会清除所有已选楼层，所以在他楼里如果按错了或者小孩按了所有楼层，他可以扳一下停止开关重置一切。（他后来又讲了这招的翻车版：邻居忘带手机，在门刚关、电梯开始下行时按了停止，电梯已经下移了一点，卡在两层之间，他们带着小孩在里面，「不太愉快」。）
关于把 LLM 塞进电梯
shepherdjerred 随口问了句「不知道我们会不会看到 LLM 电梯调度」，引发了本帖最欢乐的一串接龙。noisy_boy 立刻仿写了 AI 道歉腔：「很抱歉我把您带到了 29 层而不是您要求的 3 层。这是我的问题。下次我会做得更好。」brookst 接力：「我想承担一下责任：这是我连续第四次在您要 3 层时把您带到 29 层。我正在创建一条记忆，要求永远去 3 层而不是 29 层，这应该能防止再次发生。」breakingcups 补刀：「小小的褶皱：现有文档指出 29 层其实就是 3 层。」ufmace 结尾：「抱歉，我忘了这栋楼只有 18 层，您的电梯现在在空中飞行，这是我的问题。」
Ekaros 给出了严肃回应：「LLM 在这个用途上不会更优，很可能远为逊色。没有必要为一件不涉及语言的事情使用语言模型。每次有人把 LLM 当作所有问题的神圣解法我都觉得怪异。机器人手术让 LLM 控制。机器人做饭 LLM。核电站和炼油厂 LLM……业界找到了一把大锤，现在一切都是钉子。」Terr_ 提议：那时候就该建立一套全新的软件认证体系，纯粹为了能把造这种东西的人除名。而 omoikane 用《银河系漫游指南》的梗收尾：「听起来你在找的是带有真实人格的快乐垂直载人运输机。」
一条被高票认同的「优化过头」的长论
_kb 提到数据其实早就存在，而且如果把范围从电梯扩展到整体建筑占用和人流会更有意思：他见过把这套接进门禁闸机的做法——人们刷卡进楼时，等他们走到电梯厅，电梯已经在为需求做好移动；再进一步可以从人数计数走向身份识别（以及已知/最可能的工作楼层）；再从那里进入 WiFi 三角定位，得到一个既准确又实时的物理空间交互视图，可以馈入 HVAC 负载削减、会议室或工位的即时预订。「另一面是，它也有成为绝对反乌托邦式隐私噩梦的潜力。」
TeMPOraL 的回应成了本帖最被认同的长评之一。他认为在办公空间里隐私是个红鲱鱼——当每个角落都有闭路电视、每隔一扇门就有刷卡器、会议室都有存在感应时，WiFi 三角定位并不会让事情更糟；反乌托邦不会在没有严重政权变更的情况下降临。「不，我主要担心的恰恰是可持续性和优化，也就是成本削减——你给企业的优化工具越多，你给企业的胡扯借口（『可持续性！拯救地球！』）越多，对用户（这里是员工）的结果就越糟。而其中很多还是双重恼人的，因为它是反生产力的。」他举了两个例子：装了智能传感器、刷卡器和自动重订算法之后，一周有一半时间所有会议室都显示订满，可你实际去看有一半是空的，而这似乎成了不可能解决的问题；卫生间墙上写着「使用节水器具，本楼用水大幅减少」和「我们现在每次冲水节约 2 升」，这全是胡扯，因为那些环保发明意味着他要冲三次而不是一次，洗手要花一分钟而不是十秒——尤其因为肥皂和给皂器也被优化过，得花 20 秒才挤够肥皂，再花 20 秒才洗掉，因为它不知为何会让手一直滑腻腻的。「他们还说『科学家说你只用两张纸巾就能擦干手』。到这我就要红温了，因为是的，我 15 年前也看过那个 TED 演讲，是的，那完全是胡扯。也许当时是真的，但产业和会计们在那之后已经把纸巾『价值优化』了 15 轮。」
他的总结被多人引用：「余量是好的。幸福住在余量里。存在优化过头这回事。而且那些被拿来优化的、小而孤立的系统，在现实中既不小也不孤立。」ufmace 接道：「有一类工程师心态热爱优化事物的想法。但如果你真想优化某样东西，你必须仔细考虑每一个可能的因素、情形和用例。漏掉任何一个，灾难都会比省下 2% 资源大得多。这很少值得。」
TeMPOraL 还在另一处给这篇文章补了一个视角：电梯在某种意义上是一堆社会和心理问题被塞进一个上下移动的箱子里。他观察到两条规律：如果存在一个可用的控制元件，你就会（哪怕是心里）为别人使用它而责怪他们——「要不是这个该死的某某偏偏在这个时刻按了按钮，我一分钟前就到了，而且他们根本不是往这个方向走的！」；如果存在一个指示元件，人们就会围绕它显示的东西做优化——比如有人在 N 层进电梯，看到自己到 M 层之间的按钮大多亮着，就立刻按 N+1 下去再叫另一部；但如果按钮从外面就足够可见，他们可能一开始就不进去，从而为自己和别人省下时间和麻烦。「我越想越觉得电梯里按钮和指示灯的摆放本身就是一个 UX 工程问题，每个决定对用户福祉的影响都异常之大。」他还半开玩笑地补了一句：讽刺的是，很多电梯问题——调度的和社会心理的——只要电梯跑快个 2 到 4 倍、某些情况下还能横向移动，就都解决了，也就是《星际迷航》的涡轮电梯。
关于「等待」的心理学
psadri 讲了一个广为流传的故事：机场行李转盘至少要 x 分钟才出第一批行李。某个版本里乘客从登机口直接走到转盘，等 x 分钟，很不高兴；后来机场加了一条绕远的长步道从登机口通向行李区，烧掉了其中一部分分钟——总等待时间相同，但乘客更开心。
oliv__ 提出了尖锐的反驳：「我看不出这怎么是感知问题？这只是故意把它变得低效了。如果我走 10 分钟到行李区再等 10 分钟，和走 5 分钟等 15 分钟，总时间相同但一种可以接受因为感觉不可避免、在自己控制之下（人不可能移动得更快），另一种不行因为感觉本可以改进（工作人员本可以卸得更快）。」ImPostingOnHN 把它拉回电梯：「等 2 分钟电梯再在车里坐 1 分钟的人，很可能觉得这 3 分钟比等 1 分钟电梯再坐 2 分钟更难以忍受。」ericpauley 则提出了事实质疑：「这个故事到处被引用，但到底是哪个机场真这么做了？我不知道有任何美国大型枢纽会这样有意义地延迟乘客离场。」psadri 老实承认：「说实话我也只是读到过。不过每次路过希思罗，我都觉得有人真把这想法当真了。」
Gabrys1 给出了一个更通用的表述：应该两者兼顾，就像在餐厅排队——等 5 分钟位子、5 分钟服务员、10 分钟饮料、25 分钟上菜，比等 25 分钟位子然后 5 分钟上齐全部要好。「基本上你有一种非理性的进展感，即使事情被拖延了。」
游戏、怀旧与彩蛋
至少八条独立评论提到了 Elevator Saga（play.elevatorsaga.com），一个让你编程电梯调度的浏览器小游戏。vova_hn2 贴出了自己第 5 关的解法并说「不敢相信这居然能用」，fragmede 一个词点评：「bogosort！」
SimTower 是另一个高频关键词。wlesieutre 挖出了一条史料：一位不具名的 Maxis 员工说「你猜对了，SimTower 是围绕一个我们从一个日本人那里买来的真实电梯仿真程序建的」。pavlov 补充了创作者 Yoot Saito 本人的说法：「一天深夜，我在楼里的大堂等电梯。我们楼的井道里有两部轿厢。我按了按钮，但来的不是最近的那部，而是最远的那部。以我一贯的追问方式，我问自己：『这里发生了什么？这些轿厢在逻辑上是怎么同步的？』这就是 SimTower 的开端。」somat 说他小时候没「懂」SimTower，多年后读到它其实是个被充实了的电梯模拟器，才终于喜欢上它。stackskipton 指出后继作《Project Highrise》没有电梯仿真，「电梯只是把市民传送到正确楼层的传送门」，jcranmer 认为这正是它挠不到同一个痒处的原因。
dbcurtis 还贡献了本帖最好的一条八卦。回应 jhallenworld 那句「不是所有人都平等——你想让你新办公楼的 CEO 排在一堆平民后面吗？至少得留一部轿厢给更好的人」，他说这确实存在。他曾在一栋高端公寓（有礼宾和代客泊车的那种）做过目的层调度系统，住户的门禁卡当然会自动呼叫一部电梯送他们回自己那层——但安保系统里还有诸如「养狗者」和「对狗过敏」这样的条目，好让目的层调度系统永远不会把他们排进同一部轿厢。
关于「三部电梯的 60 层楼」
woeh 说他正住在一栋 60 层塔楼的 Airbnb 里，三个电梯井显然扛不住（他认为这栋楼设计时没考虑出租给游客）。周末电梯彻底饱和，意味着电梯每层都停但没人能进去，因为已经满了；排队人数一直增加直到高峰过去，他有一次等了半小时以上。「我从中学到的是：电梯需要一个合适的满载检查，满了就跳过楼层。」他后来补充说这是吉隆坡的一栋塔楼，而且因为天很热、电梯不带空调，格外难受。他推测的机制是：大量带着大件行李的人不断进出，也许有基于重量的满载传感器，而行李骗过了系统（一件行李比一个人轻但有时占更多地板空间），而且带行李的人进出更慢。
pudgywalsh 说他从没见过低于 4 部电梯的 20 层楼，「这种严重不足本该在城市检查员的办公室里就被拦下」。grishka 说他今天才知道有些国家的建筑规范不强制最少电梯数：「在俄罗斯，超过 5 层是 1 部，超过 9 层是 2 部，我相信超过 16 层是 3 部（我去过的每栋 20 多层的楼都至少有 3 部）。」Animats 甚至试图凭这个描述猜出是多伦多的 ICE Condominiums Tower I，并指出电梯载重测量是个可以买的选项，「有人没买」。
其他值得一提的碎片
peterldowns、SoftTalker 等多人指出了 CS 教科书里的经典连接：旋转硬盘的磁头调度算法就叫「电梯算法」，SCAN 本来就是一个磁盘调度算法。amenghra 补了一个精妙的观察：「同一个算法适用于两个不同问题这件事很有趣。在磁盘的情形里，唯一不可预测的是未来的请求。电梯要应对两件不可预测的事：未来的请求，以及人类进出电梯要花多久。所以同一个算法在两种情形下都管用，就更有意思了。」
ericmcer 分享了一个安全侧信道：他以前在旧办公楼里用这些算法进入受限楼层——只要坐到自己有权限的那层，门关时留在里面，它就会把他带到某个随机楼层，按开门键，「瞧，我就到了某家公司的私人楼层」。cruffle_duffle 推荐了 Deviant Ollam 和 Howard Payne 的 DEF CON 电梯黑客演讲（本帖至少三人独立提到），并分享了一条建筑冷知识：大多数电梯井顶部被尽可能严密地封死，以防它在火灾中变成一根巨大的烟囱。「我从没想过这件事，直到我在机房里纳闷『往下看井道的检修口在哪？』答案是『没有，而且这是特性不是 bug』。」
danfunk 就页面本身表了态：「这篇文章创作中使用 AI 与否无关紧要。这里有显而易见的喜悦和高保真的信息。也许一些 vibe coding 让动画更容易开发，让它在合理时间内被生产出来。谁在乎。对手艺的热爱显而易见。」newswangerd 说他用一台老 iPhone SE，「想给你点个赞，动画在这个页面上跑得丝滑无比。很多网站光是广告就能让我的手机彻底冻住」。vivzkestrel 用一句话概括了本帖的气氛：「史诗级历史饶舌对决——john.fun vs neal.funnnnnnnnnnn，谁赢了？你来决定！！」