这篇写公交公司的调度员和运营管理人员。核心要先说清一件事：排班这件事大部分不需要人工智能，需要的是运筹和规则。你要在系统里找的不是一个会说话的助手，是几个具体的工具。
先把排班拆成三层
很多系统做不出来是因为它把这三层当成一件事在解，实际上难度差很远。
第一层是时刻表编排，就是纸面上那张表：几点几分从哪站发车。这是最经典的一层，也是唯一真正需要算法的层。原因是它被公认为 NP 困难问题，意思是找不到一个能保证最优的算法，只能靠启发式搜索。常见做法是贪心、模拟退火、禁忌搜索、遗传算法、粒子群，都有人用过。
第二层是实时调度，就是路上堵了怎么办：要不要加车、要不要跳站、要不要改派。这个层的性质完全不同，它不是优化问题而是决策问题。每一分钟都要做一次决定，等待的代价和加车的代价实时对比。这种场景规则比算法好用，因为你需要的是「三十秒内出结论」，不是「全局最优」。
第三层是司机排班，也就是谁开哪辆车、哪个人上哪个班。这一层几乎全是约束满足。不能连续工作超过多少小时、休息怎么排、班次之间间隔够不够，都是硬边界。这一层的模型只是用来在硬约束下找一个可行解，不要指望它有什么创新能力。这一层和调度员的实际经验冲突最大。系统算出来的可行解在纸面上合法，但不符合某个班组的实际情况，执行时就得手工改回去，改多了就没人信系统了。这一层的落地顺序应该是先让调度员自己排，人只做冲突检查和合规校验。这一层放到最后做，前两层的运行数据积累下来才有意义。
知道了这个分层，你就知道钱该花在哪。第一层值得投入，第二三层用规则和求解器就行。
第一层怎么做才有效
如果你要改进时刻表，关键不是换一个更花哨的算法，而是把历史数据的用法改对。
主流做法是：先做无监督聚类，把月份按延误模式分成几类，比如夏冬季和春秋季分开、雨季和旱季分开。然后每一类单独排时刻表。为什么要分类？因为同一个线路在一月份的延误模式和七月份根本不是一回事，用一张表去套所有月份，怎么调都不准。
这一步的价值在于把一个「全年通用」的问题，变成了「几个分场景」的问题。听起来简单，但很多运营单位就卡在这一步没做，导致后面的算法再优化也白费力气。
然后是路网拥堵状态要作为变量进去。有研究用这条思路做过双阶段模型：路网轻微拥堵时，用非支配排序遗传算法优化发车间隔；路网严重拥堵时，改用全程车和区间车组合调度，用模拟退火求解。报告的结果是准点率提升 82.38%，乘客平均候车时间减少 182.2 秒。
这个数字要怎么看。它是论文里的结果，基于一条具体线路的历史数据验证的，不能直接套到你的线路上。但它说明一个方向：拥堵和不拥堵需要两套不同的调度策略，用一套参数硬套两头都不行。这一点和先做单点还是先做平台那篇讲的是同一件事。分场景、分阶段做判断，比一次性上一个大平台更容易验证效果。
新能源车要多算一个约束
如果你线路上有电动车，事情会复杂一档，而且这个约束必须放进模型里，不能靠人记着。
电动公交要充电，充电要时间。续航里程有限，单车一天能跑的班次因此有上限。这个约束一旦不考虑，算出来的时刻表在纸面上很漂亮，实际跑两天就乱。
正确的做法是把单车的日行驶里程和充电时间作为硬约束写进模型，让求解器在满足这些约束的前提下再优化发车间隔。有的线路还能进一步做区间车优化，让一部分车在高峰时段跑大段走廊，一部分车负责接驳，这比全线都跑同一种路径效率高得多。物流供应链的分拣调度里有类似的多层调度思路，可以对照着看。
为什么很多系统上线后没人用
这一节可能对你更有用，因为这是实际项目里最常见的失败原因。
第一个原因是数据质量不行。车辆的 GPS 设备老旧、信号接收不稳定，会直接导致位置延迟甚至中断。2026 年多地公交主管部门的公开答复里都提到这类问题，有的城市因为终端设备使用年限较长、老化、精度下降，导致乘客看到的实时位置偏差很大。
更麻烦的是第二种：调度信息本身没进系统。衡南县交通运输局 2026 年的一则公开答复写得很具体。掌上公交显示「等待发车」而实际已经发车，原因之一是部分临时发车调度信息未纳入系统实时推送。这句答复说的是乘客端的误差，调度端的道理是一样的。
这句话对调度员的意义是：你如果在群里通知临时加车，没录入系统，乘客那边看到的就是错的。系统只认它自己的数据，你的手势和电话不算数。所以规范要求的是「必须录入」，「记得通知」不够，两件事差很远。
第三个原因是时间点策略用错。公交车靠少数几个「时间点」来对齐，也就是在几个关键站点努力按计划到。这种设计在理论上有效，但前提是那几个点确实卡得住。如果卡不住，后面所有站都会顺延。选时间点要选那些有物理约束的地方，比如红灯多、掉头难、或者有发车场的站，不要选直线段。
别把这件事交给模型去做
有几件事看起来很聪明，实际做不了。
一是让模型预测「这一趟会不会晚点」，然后据此自动改时刻表。问题在于晚点本身是随机事件，模型能做的是给出概率分布，而调度需要的是在概率分布下选一个最不坏的方案。这是决策不是预测，别用预测的壳做决策的活。
二是让模型决定要不要跳站。这涉及乘客的知情权和合同关系，跳站必须由人决定并且告知乘客。这不是技术边界，是责任边界。
三是用历史数据当现状直接推。车辆老化、线路改造、周边施工都会让历史数据失效。数据要用，但要有衰减，比如只用近半年的，且按季节分组。
怎么判断这套东西有没有用
别看平均数。看三个数。
原因很简单。那 15% 的人每周都要经历一次，剩下 85% 的人一次也没赶上过。对乘客来说这就是准点率，对调度员来说这是另一件事。
二是候车时间的分布同上，看中位数和尾部，不要看平均。
三是司机的加班时长。这是调度员最容易忽略但最该看的指标。优化系统如果让司机每天多跑两小时，准点率上去了，人员流失率也会上去，最后总运营成本更高。这就是典型的多目标冲突，两个指标方向相反，必须事先说清哪个优先。指标和样本怎么分开看这套方法在评估调度效果的时候直接能用。另一个参照是网约车派单算法怎么调那篇。派单和排班表面上是两件事，底层都是带硬约束的多目标优化，他们怎么处理多目标之间的权重取舍，可以对照着看。
本文讨论调度技术思路，不构成运营指导意见。具体参数需要结合本地线路、路网和车辆情况测算。
乘客端看到的到站信息为什么不准，和调度员在系统里看到的为什么对不上，根源都在数据录入这一环。到站信息是司机在终端上手工报的，漏报一次乘客那边就空一次。准点率考核也一样，它衡量的是系统里的时间戳，不是乘客的实际体感。这两个指标的偏差都能反推回去核对：拿同一班次的计划时刻、实际到站记录和乘客端显示做三方对照，差在哪一栏就清楚了。
