一家直播公司，不用再从空白表格开始排下周的班。

基本情况

商家

TikTok Shop 直播代运营公司，美国（不公开名字）

类型

代运营品牌直播间，主播和运营都是兼职

排班对象

约 30 名兼职主播和运营，8 个品牌直播间，每天大约 10 点到 21 点，周末也开

客户要的

只要从 0 到 1 那一步：一版能用的下周班表草案

不在系统里的

考勤、工资、每日通知和最终发布，全部照旧

状态

已上线。每周出草案，运营负责人审核、修改、发布

以前和现在

一位运营负责人每周挨个私聊要下周的可播时间，再在表格里一格一格填人。“只能到 4 点却排到了 5 点”这类冲突，靠排完以后肉眼找。

以前每周从零排出第一版班表大约要 6 小时，现在这一步已经自动生成。最终班表仍由运营负责人审核、修改并发布。

搭了什么

一个 Cloudflare Worker 加定时触发。每人一条带签名的链接，只对本周、只对本人有效，按天选开始和结束时间。提交记录进客户的 Lark 多维表格。

每周四 Worker 读取可播时间、客户的打分表和直播间要求，把草案写回 Lark：每天一个页签，加一页汇总，再加一页用大白话写的排班逻辑。

规则归客户。主播和直播间的匹配分、运营分、谁和谁不能同场、每周工时范围、哪个直播间几点开，全在客户的表格里。改规则是改单元格，不用找人改代码。

系统不做的事：发布班表、给员工发消息、考勤、临时换班的判断。

为什么用确定性代码，不用 LLM

排班的核心是确定性代码，没用 LLM。

做这个项目之前，客户试过把两个月的历史班表交给聊天机器人，让它照着往下排，结果规则没学会。第一次开会，运营负责人说模型“学得一坨”，老板的要求是“if A then B，不给它操作空间”。

原因到后面才看清。历史班表里混着例外和残余，这些不是规则。过去的班表里有 5% 是一小时的场次，看着像规律，其实是主播临时请假留下的。只要是从历史里学，就会把残余和规则一起学进去。

这条工作流要的是写明白的约束和可预期的兜底：搭档分是负数，就是永远不同场；周工时有上限，就是上限；排不上的场次，必须说明卡在哪条约束。LLM 在这类工作流的外围仍然有用，比如把主管随手写的一句备注整理成一条规则建议，再交给人确认。真正做排班决定的那部分，是确定性代码。

需要处理模糊信息的地方用 LLM；业务规则必须一条不差执行的地方，用确定性逻辑。

实现说明

• 第一版按小时逐格找人，排出来的班没法上：一个人一天跑五个直播间，一场播到一半换运营。拿真实的一周对照才看出毛病在哪，人排班想的是“一场”，代码想的是“一小时”。后来排班单位改成 2 到 3 小时一场，每场一个主播配一个运营。
• 先定运营，再配主播。这是客户的主管提的：下午两点有几个运营有空，决定了两点能开几个直播间。
• 搭档分是负数的两个人，任何兜底阶段都不会排到一起。客户说得很清楚：能勉强一起播的，都没写负数。
• 一场配不齐人时，先缩到两小时，再放宽到低一档的人，再允许别人来补剩下的一小时。还是不行就留空，汇总页写明卡在哪条约束、卡住了几个人。
• 有一位主播是客户指定的例外：在这位主播唯一常播的直播间，把报上来的可播时间全部排满，不休息，不看上限。触发条件是客户表格里的一个标记，代码里没有写任何人的名字。
• 每个日期页签第一行写着自己是星期几、几号。原因见下面“哪些地方坏过”。
• 周三以后表格对员工关闭。运营负责人仍然可以打开任何人的链接，输入管理密码替对方提交。
• 每次部署前跑 32 个自动测试，其中 10 个复现的是客户真实遇到过的 bug。

测了什么

排班单位从“小时”改成“场”前后，生成结果和一份真实人工班表的结构对比：

同一周里，规则逐条加进去之后的覆盖情况，以及还没排上的必排场次数。单位是角色小时：一个直播间开一小时算两份，主播一份，运营一份。

剩下的 10 个是晚上 7 点以后和周末的场次。汇总页给的原因是：二十多个人报的时间都够不到这些时段。这是人手问题，调排序解决不了。

真正上线前，哪些地方坏过

1. 周五、周六、周日写进了错的页签。 加了一个页签，之后每天整体错了一格。没有任何报错，错位后的结果看着还挺正常，因为周六和周日的班长得一样。是客户发现的：“周五很多人可以上班，但是都没排。”后来加了写入前的硬校验，再加上首行自报日期。
2. 有大半天所有人都提交不了。 为了“同一个人本周只留一条记录”加的查询，用了 Lark 不接受的日期过滤写法。客户替别人提交时撞上的。
3. 从历史数据里推出了一条不存在的规则。 过去的班表里 5% 是一小时的场次，于是提议允许一小时场次。其实那是主播临时请假留下的残余。
4. 关键词匹配写得太松。 有人的备注写着“尽量多排运营”，被当成了“排满”的标记，结果排了 40 小时，而这个人的上限是 30。
5. 两个工作会话互相覆盖部署。 一边走 CI 推送，一边本地直接部署，谁后跑谁生效。现在只允许走推送。
6. 自动催收一直没开。 Lark 不允许个人账号跨组织发消息，短信和邮件服务商也还没接。运营负责人现在手动复制链接发出去。

还没验证的

• 每版草案有多少能原样留到发布。还没有人把生成的草案和客户最终发布的班表逐格比过。
• 每周净省多少时间。以前第一版班表大约要 6 小时。现在审核和修改还要花多久没有正式计时，所以暂时不写“净省 6 小时”。
• 晚间和周末的覆盖，取决于有没有人报这些时段。
• 同一个直播间同一时段放两个运营，客户手排的班表里偶尔有。
• 提前两周排班。系统现在只处理下周。

为什么没有“净省了多少小时”：第一个完整周期是 2026 年 9 月才跑的，客户每周还在改规则。值得发的数字是运营负责人发布前改了多少格，这个还没数。

这个案例说明了什么

1. 历史数据不等于业务规则。 两个月班表里的一小时场次是请假留下的，不是规则。把规律写进系统之前，先问流程的负责人。
2. 先选对工作单位。 人排班想的是“一场”，第一版代码想的是“一小时”。单位一改，中途换运营的比例从 41% 降到 0%。
3. 客户的规则放在代码外面。 匹配分、搭档、工时范围、直播间开播时间都在客户的表格里，改规则就是改单元格。
4. 做不到的时候，要说明原因。 没排上的场次会写明卡在哪条约束、卡住了几个人。最后剩下的 10 个空缺，就是这样看出来是人手问题。
5. 重复的那一步自动化，需要判断的留给人。 第一版自动生成；审核、修改、发布和临时换班，仍由运营负责人决定。
6. 设计 AI 工作流，不等于到处都放 LLM。 客户已经试过聊天机器人。必须一条不差的那部分，最后写成了代码。

企业 AI 培训里教的就是这套方法：选一项真实任务，把规则写下来，再定好哪些地方必须由人核验。更多运营场景见运营团队的 AI 应用和工作流库。