排班这件事，几乎每个需要值班的团队都躲不开，而几乎所有人还在手工做。
门店店员、客服坐席、运维值班、护理排班——规则看着不复杂，真排起来一堆约束：同一人不能同时上两个班、连续夜班不能超天数、每周工时不能超、夜班后要留足休息间隔、有资质的人才能上特定岗位、节假日要公平轮转，还要扣掉请假和调休。
最耗时间的往往不是排，而是解释：表发出去，总有人来问「为什么我连了三个晚班」「为什么这个周末又是我」，于是改一版、再改一版。
这一篇讲的是怎么让 OpenClaw 把排班做成一条可重复跑的流程。站内已经写过 用 OpenClaw 定时发日报周报 和 搭企业内部知识库，这一篇补的是「约束求解 + 多版本调整」这一类任务，和它们不重叠。
一、排班难在哪：不是排不出来，是改不动
先把这个问题的性质说清楚，后面所有设计都从这里来。
- 约束多且互相牵扯。「小李不能上夜班」和「周五夜班至少两人」放在一起，可能就无解。人手工排的时候会自动降级取舍，而 Agent 需要你提前告诉它：哪些能退，哪些不能退。
- 输入天天在变。请假、调班、临时支援，任何一条变动都可能引发连锁调整。手工排最怕的就是这时候从头再来一遍。
- 结果需要被接受。排班表是给人看、也是给人遵守的。算法觉得最优的方案，如果没人能理解，照样执行不下去。
所以排班自动化真正的目标不是「算出一个最优解」，而是「算出一个说得清、改得动、能重复跑的方案」。
二、第一步：把规则分成硬约束和软偏好
这是全篇最重要的一步。规则没分清，后面全是返工。
硬约束（绝不违反）：
- 同一人同一时段不能出现在两个班次
- 连续班次之间必须留足休息间隔（例如不少于 11 小时）
- 连续夜班上限（例如不超过 3 天）
- 每周 / 每月总工时上限
- 岗位资质要求（没证的人不能排上去）
- 制度与法定规定的休息安排
软偏好（尽量满足、可让步）：
- 夜班数量在团队内尽量均衡
- 周末与节假日公平轮转
- 尽量照顾已报备的个人时段偏好
- 同一组人尽量排在一起（彼此熟悉协作流程）
分完之后还要明确一件事：硬约束一条都不能破，软偏好按优先级排序。这样当约束打架时，Agent 才知道该牺牲什么。很多排班工具用不起来，就是因为把所有规则当成同等重要，结果一冲突就卡死。
三、第二步：准备输入，四样东西缺一不可
- 人员清单：姓名、岗位、可上班次类型、资质与有效期、是否兼职或实习。
- 请假与调休表：起止时间、类型、是否已审批。未审批的要单独标出来，不能让 Agent 默认当作已生效。
- 班次定义：每个班次的起止时间、每天需要几人、是否有最低资质要求。
- 历史排班：至少往前看一个月，用来统计夜班次数和周末次数，做公平轮转。
这四样凑齐，排班才有依据。少了历史排班，结果就是「每次都排同一个人」；少了资质有效期，可能排上一个证书下月就到期的人。
四、第三步：先算缺口，再排人
很多人直接让 Agent「排一个下周的班表」，结果它硬凑出一个违反规则的表。正确的顺序是先算再排：
- 算缺口。逐日逐班次对比「需要几人」和「可用几人」（可用 = 总人数 − 请假 − 资质不符），差多少先摆出来。
- 标风险日。缺口最大的那几天单独提示——这类日子通常要靠提前协调支援解决，而不是让算法硬排。
- 再排班。按硬约束生成初版，软偏好作为排序依据，而不是约束条件。
把这个顺序固定下来，Agent 的输出会稳定很多：先告诉你「哪几天本来就排不满」，再给「能排出来的方案」。这两件事必须分开说，混在一起，人会误以为方案已经解决了人手不足的问题。
五、第四步：五类冲突必须自动校验
排完不能直接用，要跑一遍校验：
- 同人叠加：同一时段被排了两个班次。
- 休息间隔不足：晚班结束到早班开始的时间低于规定下限。
- 连续班次超限：连续夜班或连续上班天数超过上限。
- 工时超限：周 / 月累计工时超过制度规定。
- 资质不匹配：岗位要求的证书缺失或已过期。
校验要输出的是具体到人、到日期、到原因的清单，而不是一句「存在冲突」。这样人改起来才知道从哪儿下手。这套「生成 + 校验 + 只保留通过项」的思路，和 变更后验证清单 一样：结果不能只靠生成，要有独立的检查环节。
六、第五步：输出调整说明，这一步最省事
这是最容易被忽略、但回报最高的一步。
发排班表的时候，让 Agent 顺手生成一份说明：
- 本周哪几个人上了夜班、各几天（用来说明公平性）
- 哪几条软偏好没满足，原因是什么（例如「周五夜班需要两名持证人员，当周人手不足」）
- 和上周相比有哪些变化、为什么变
- 哪些时段还存在缺口，需要谁支援
有了这份说明，大部分「为什么又是我」会在一开始就被解释掉，沟通成本能省一大截。可解释性不是锦上添花，它是排班能不能落地的前提。
七、第六步：导出与定时重排
最后接上两块：
- 导出。生成按人看的表（每个人自己那一周）和按班次看的表（每天每班是谁），前者发给个人，后者贴在现场。格式固定成模板，不用每次重做。
- 定时重排。固定节奏出表（例如每周四出下周排班），同时支持事件触发——请假审批通过后重跑一次并标出变化。定时任务怎么配 那一套在这里可以直接复用。
有个细节值得单独说：重排后要输出「和上一版的差异」，而不是只给新表。排班表最怕的就是「悄悄变了但没人发现」，尤其是已经通知到个人的班次。
八、三条边界，别越
- 不要在排班依据里放主观评价。「这人配合度低所以少排」这种判断不能进模型。排班只依据规则、资质、考勤和已报备的偏好。
- 考勤和请假属于个人信息。数据范围要控制在「排班必需」，发给现场的表不必带请假原因和历史记录。Agent 处理个人信息怎么合规 那四道闸在这里同样适用。
- 不要让 Agent 直接发给个人。排班表先由负责人确认再发出，尤其是涉及调班、加班和夜班的安排。权限边界参考 权限管理。
优缺点和适合人群
优点：重复劳动大幅减少，一周排班从两小时压到十几分钟；冲突校验比人工可靠，尤其是休息间隔和连续班次这类容易算错的项；调整说明让方案更容易被接受；历史数据沉淀之后，公平性可以量化、可以追溯。
缺点：前期要把规则和班次定义整理成文本，这一步最费功夫；约束冲突严重时仍需要人来取舍；结果不能只看算法输出，发布责任还在人；输入数据质量差（考勤表不统一、请假未审批）会直接让结果不可用。
适合：班次固定、规则明确、人数在十几到几十人的团队——门店、客服坐席、运维值班、安保、餐饮、护理。反过来，如果排班靠的是「现场喊人」这种高度随机的模式，先别急着上系统，把规则理清楚更重要。生成结果的质量控制可以参考 人工复核抽检：不用每周全查，但每月抽一周核对工时和间隔。
总结
- 分清规则：硬约束一条不能破，软偏好按优先级排。
- 备齐输入：人员、请假、班次定义、历史排班，四样缺一不可。
- 先算缺口：先告诉人「哪几天本来排不满」，再给方案。
- 独立校验：五类冲突逐条查，输出具体到人到日到原因。
- 附上说明：解释公平性和让步原因，省掉大半沟通。
- 版本可控：定时出表，重排要输出与上一版的差异。
最后一句：排班自动化的价值不在「算出最优解」，而在「把两小时的重复劳动压成十分钟，还让每个人都看得懂为什么这么排」。做到这一点，它就已经值回票价了。
