用AI应用生成器自建餐厅排班系统实战指南

大多数餐厅的排班表，起源于经理笔记本电脑上的一张电子表格。每周四，有人复制上周的标签页，挪动几个名字，打印出来，钉在冷库旁边，再拍张照片发到群里。接着就是换班请求的洪流：群里有人问"谁能替我上星期六的双班？"，打印纸上贴了张便利贴，副厨口头说了句"行，没问题"——可他并不是有权批准换班的人。

这套流程运转到某个临界点就会崩掉。有人上了个不在任何版本排班表上的班次；加班工资出现在工资单上，谁都没预料到；一名服务员说早就跟你提过考试周的事，她大概确实提过，但你找不到那条短信了。

现成的排班软件能解决其中很多问题，如果有合适的，直接用就好。本文针对的是那些现成方案"不太合身"的餐厅：被软件当成两天处理的分班、无法映射到"角色"概念的工作站、拥有三家门店和共享厨师池的餐饮集团，或者就是不想再为按人头订阅付费的老板。以下是用AI应用生成器自建排班应用的完整步骤，包括你实际会敲进去的那些提示词。

作者使用Mythex作为演示工具，但整套思路适用于任何AI应用生成器。

第一步：先写清楚你的排班到底怎么运转

在敲下第一条提示词之前，花十分钟回答以下问题。每个答案都会变成提示词里的一句话，每个没回答的问题都会变成AI的一次猜测。

四个核心问题

一个班次是什么？ 餐厅排的不是"天"，而是"餐段"。午餐10:30到15:00，晚餐16:00到收档，周末有早午餐。一个双班是两个班次，不是一段长班，因为人可以只换其中一半。

谁有资格上某个班次？ 通常由工作站决定：烤炉、炒锅、冷菜、洗碗、吧台、服务员、迎宾、传菜。一个人可以覆盖多个工作站。新员工不能单独收吧台。

谁能改什么？ 员工设置可用时间、申请休假。员工可以把自己班次挂出来供换班。经理审批换班和休假。总经理看总工时。

经理最先看什么？ 通常是两件事："每个餐段都有人覆盖了吗？"和"有人快超工时了吗？"这两项应该成为首页。

不要忽略法规因素

如果你的餐厅所在城市有预测性排班法规，也要写下来。美国多个城市（纽约、旧金山、西雅图、芝加哥、费城、洛杉矶等）和俄勒冈州有"公平工作日"规则，要求提前发布排班表，并对临时变更支付额外补偿。各城市细节不同，但这是让应用记录每版排班表发布时间的好理由。

什么是预测性排班法规？

预测性排班（Predictive Scheduling）法规，也被称为"公平工作日"（Fair Workweek）法律，是美国部分城市和州为零售、餐饮等排班波动大的行业劳动者设立的用工保护规则。核心要求通常包括三项：一是提前通知，雇主须在排班生效前 7 至 14 天发布排班表；二是变更补偿，若雇主在截止时间后临时调整班次，需向受影响员工支付额外时薪（通常为 1 小时工资或半天工资）；三是新增工时优先权，新增班次需先向现有兼职员工提供，再招新人。纽约市于 2017 年率先针对快餐业施行，旧金山、西雅图、芝加哥、费城、洛杉矶以及俄勒冈州随后跟进，各城市在覆盖范围、罚款额度和生效天数上差异较大。正因如此，应用若能在每次排班发布时自动写入时间戳、记录首次发布与后续修改的时间差，就能在员工投诉或劳动部门稽查时作为合规凭证，而不是靠经理回忆。

第二步：发出第一条提示词

把上面的答案几乎原样粘进去就行。提示词长一点没关系。

为一个餐厅构建排班应用。员工有姓名、电话、邮箱、可工作的工作站（烤炉、炒锅、冷菜、洗碗、吧台、服务员、迎宾、传菜）和每周目标工时。经理在周历上创建班次：每个班次有日期、餐段（早午餐、午餐、晚餐）、工作站、起止时间和一名分配人员。员工登录后看到自己的班次、设置每周可用时间、申请休假并挂出班次供换班。另一名有资格的员工可以接单，且必须经经理批准。经理首页显示本周未覆盖的班次和每个人的排班工时，超过40小时的人高亮显示。

几分钟后你就会得到一个带真实数据库的可运行预览。在评判外观之前，先以流水线厨师的视角在手机上点一遍，再以经理的视角在笔记本上点一遍。

第三步：在碰设计之前先检查数据模型

几乎每个排班应用的第一版都会犯三个错误。现在就修，别等真实班次录进去再改。

换班应该是记录，而不是编辑

如果换班只是把班次上的名字换掉，你就丢失了原始持有人和审批人的信息。要求AI建一张换班请求表：班次、发起人、接单人、状态、审批人、时间戳。

为什么"可审计性"对排班系统至关重要？

可审计性（Auditability）指系统能够完整还原"谁在什么时间做了什么"的历史轨迹。排班系统涉及工资、加班、休假和合规四大敏感领域，任何一处状态变更都可能引发争议。当换班被实现为"直接编辑班次记录"时，原始持有人、发起时间、接单人、审批人这些字段都会随覆盖操作永久消失——一旦某人后来主张"我从没同意过这个班"或"我加班那天明明是别人",经理无从对证。将会话、请求、审批拆成独立表和独立记录，本质是把"状态"变成"事件流"，这与会计系统用流水账而非期末余额记账是同一原理。代价是数据模型稍复杂，收益是任何时点都能回放整条换班链路，也为未来接入自动加班计算、纠纷仲裁或合规报表打下基础。

工作站应限制可分配人选

如果分配下拉框列出所有人，迟早有人会被排到从未做过的烤炉岗。

工时应该是算出来的

每人每周的排班工时应该从班次计算得出，而不是某个人手动填进去的数字。

将换班存储为链接到班次的独立请求，包含发起人、接单人、状态（已挂出、已接单、已批准、已拒绝）和审批人。分配班次时，只显示有该工作站资格且未标记该时段不可用的员工。根据班次计算每人每周排班工时。

第四步：导入现有员工名单

不需要重新录入。把员工表格导出为CSV，告诉生成器怎么处理：

将此CSV导入员工表。"Positions"列包含用逗号分隔的工作站名称。保存前先给我看前十行的预览。

先要预览是个好习惯。它能在40行数据变成乱码之前，抓出"电话号码被读成日期"这类问题。

第五步：只建两个每天都会用的界面

抵制加功能的冲动。排班应用的生死取决于两个界面。

员工端：手机优先

"我的下一个班次"、挂出换班按钮、可接班的班次列表、休假申请状态。大字体，不要表格。

员工视图做成移动优先：我即将到来的班次列表，含日期、餐段、工作站和时间；每个班次有一个挂出换班的按钮；一个"你可以接的班次"区域，按我的工作站过滤；以及我的休假申请及其状态。

经理端：周网格加审批队列

经理周视图以餐段为行、日期为列，每个单元格显示该工作站分配的人。空格为红色。添加一个审批面板，列出待处理的换班和休假申请，带批准和拒绝按钮。

再加一个能消灭真实工作量的功能："发布周排班"按钮——锁定排班、记录发布时间、让员工可见。发布后的编辑要记录原因。如果你受公平工作日法规约束，这条日志就是你要的凭证。

什么是"周网格"视图，为什么它比列表更有效？

周网格（Weekly Grid）是一种二维排班可视化布局：横轴是周一至周日，纵轴是早午餐、午餐、晚餐等餐段，每个单元格内列出被分配到该餐段该工作站的员工姓名，空格用红色高亮表示无人覆盖。它之所以成为餐饮排班的事实标准，是因为两个认知优势：其一，经理最常见的判断是"今天这个餐段这个岗位有没有人"，网格让空缺一眼可见，比按人罗列班次的列表快得多；其二，空格形成的红色视觉块会形成天然的压力，推动经理主动填充而不是等到出餐时才发现问题。多数现代排班软件（7shifts、HotSchedules、Sling）都以此为核心界面。自建时要注意单元格需要支持同一工作站多人分配、拖拽换位、以及点击展开该班次的资格员工列表，否则网格会退化成只能看的静态图片。

第六步：用三个身份测试

建三个测试账号，走完真实的一周。

1. 作为服务员： 你能只看到自己的班次吗？能编辑别人的吗？（不应该。）把你的周六晚餐挂出来换班。
2. 作为第二名服务员： 你能看到挂出的班次吗？如果你没有那个工作站的资格，就不该看到。接单。
3. 作为经理： 批准换班。检查班次是否显示新人、请求是否记录了审批人、两人的周工时是否都变了。

然后试边界情况：跨午夜的班次、两人同时接同一个挂出班次、某人在已被排班的日子申请休假。如果出错，描述你看到的现象（"服务员能打开另一名服务员班次的编辑按钮"），而不是你想象中的修复方案。

第七步：发布时限定只有团队能打开

排班表上有电话号码和可用时间，不应该公开。在Mythex的Business计划上，你可以把应用发布为仅成员可访问：只有团队工作区中已登录的人才能打开。你可以把它放在自己的子域名上（比如 schedule.yourrestaurant.com），方便员工保存到手机主屏幕。如果经理使用Google Workspace，可以验证域名并让员工用工作账号登录。

最终你会得到什么

• 一个带真实Postgres数据库的Web应用，有班次历史和每次换班审批的日志。
• 员工登录，含员工、经理和老板三种角色。
• 团队在出餐间隙真正能用的移动端视图。
• Business计划上的仅成员访问和团队登录，Pro以上可绑自定义域名。
• 代码本身，随时可以编辑或导出交给开发者。

诚实的局限

• 工资单和POS集成需要额外工作。 把工时导出为CSV给工资服务商很简单。与POS或打卡机做实时双向同步是一个项目，取决于对方是否有可用的API。
• 通知需要配置。 新排班和已批准换班的邮件通知可以加。短信需要服务商账号（如Twilio），要自己设置和付费。
• 劳动法规仍需你自己核查。 应用能高亮加班和记录迟变更，但不能告诉你你的城市要求什么。
• 得有人负责维护。 应该由一位经理负责应用的变更。这比维护电子表格省事得多，但不是零成本。

多门店餐饮集团怎么处理

如果经营多家门店，给每个班次和每位员工加一个"门店"字段，让经理只看到自己门店，老板看到全部。这种"位置维度"的数据模型改动不大，但能让一套系统服务整个集团，避免每家店各自维护一份表格。

什么是"门店维度"（Location Dimension），为什么它比想象中更重要？

在数据建模里，位置、门店、分店都属于"维度"（Dimension）——用来切分数据的属性轴，与之相对的是"事实"（Fact，如具体的班次、工时、销售额）。给班次表和员工表都加上 location_id 字段，看似只是多一列，实际影响深远：它决定了系统能天然支持多门店经营，而不是每开一家店就复制一套表格。常见的复杂情形包括共享厨师池（同一名厨师轮值不同门店）、跨店借调（一家店忙时借用邻店员工）、总部老板巡看全部门店数据。处理方式通常靠三层权限：门店经理只能读写本部数据、区域经理可读写辖区内所有门店、品牌老板只读全部门店。若早期不加这一维度，后期迁移代价极高——所有历史班次都要重新归属门店，且真假难辨。

关键决策总结

自建排班应用的核心不在于技术难度，而在于把"你的排班到底怎么运转"这件事想清楚。数据模型决定了应用能撑多久：换班用记录而非编辑、工作站限制分配人选、工时自动计算——这三条如果一开始就做对，后面几乎不会遇到结构性问题。界面只需要两个：员工在手机上能看清自己的班次并挂出换班，经理在电脑上能看到红格空缺和审批队列。其余功能都是锦上添花。