先说结论：最值得学的是解释路径，最需要补的是验证路径

《Elevators》从一个人人经历过的问题开场：按钮按了，电梯为什么还不来？作者没有先扔公式，而是让读者从单轿厢开始，看 LOOK 怎样沿当前方向接人；再增加轿厢、客流和早午晚模式，让“派最近一台”逐步暴露问题。等读者已经看到长尾等待，页面才引入 p50、p90 和 RSR 式评分。这个顺序很适合中文科普、课程和产品解释：先给可操作对象，再给指标，最后才给算法名称。

它的传播力还来自一个反直觉结论。页面中的简化 RSR 会综合预计到达、载客量、同向扎堆等因素，并周期性重新分配；Destination Dispatch 则要求乘客在厅外先输入目的层并接受固定轿厢。作者的模拟因此显示，在不少设定下，传统上下键反而有更低等待。这个结论很容易被改成爆款标题，却也是最该踩刹车的地方。

负责任的复刻，要让读者看到结果怎样被假设改变

Otis 的 RSR 专利确实以相对响应和奖金/惩罚给轿厢分配呼叫，但商业系统、后续算法和具体楼宇远比网页公式复杂。Destination Control 研究也不会只问“电梯多久到”，还会比较乘客在车内多久、总旅程、容量、上行高峰与层间交通。目标函数一换，排序就可能变化。原文自己也承认极高楼层、八台以上轿厢等场景可能让目的层派梯占优，这更说明结论依赖场景。

最好的中文选题不是照译，而是公开一个可复现的小实验：固定随机种子，逐项改变客流、容量和重分配频率，同时展示平均数与 p90；再把作者模型、专利思想、论文模型和商业产品分成四层。这样既能借到交互文章的叙事方法，也不会让漂亮动画替代证据。对创作者而言，这张卡真正可迁移的模板是“可玩机制 + 可见指标 + 反例按钮 + 事实边界”，而不是某个电梯算法的赢家宣言。

评论区也应只当问题清单使用：读者提出的排队体验、无障碍、满载跳站和目的层输入摩擦，可以转成后续实验变量，却不是经过抽样的用户研究。创作者若引用某条经验，应标注它来自社区个案，并让真正的工程结论回到公开模型、可复现实验或专业资料。