菜单分区要有第二张图：每道菜怎样占用后厨

顾客菜单按凉菜、主食或招牌等品类排版，只解决“顾客怎样找到菜”；后厨需要另一张生产图，回答每道菜经过哪些备料、冷藏、烹饪、组装和出餐节点，以及同时占用哪些人员、设备与空间。两张图以唯一菜品码连接，但要分别验证查找体验与生产承载，不能用前台分类直接推定后厨负荷。

WebstaurantStore的菜单设计文章讨论菜品组织、版式和顾客阅读。[1]它能支持前台信息架构，却不提供本店订单组合、工序节拍或设备能力。菜单重排后的购买变化也只能在上线后用实际订单观察，历史订单模拟仅用于检查假设组合能否被承载。

建立菜品主数据，而不是只改栏目标题

每道菜保存唯一菜品码、顾客名称、前台分区、规格、可选项、停售条件、备料卡、过敏原或食品信息接口、厨房票据名称、工序版本和生效日期。纸质菜单、线上入口、收银、备料卡和培训材料都引用同一版本号。

前台分区可以改变，菜品码与工序关系不应悄悄改变。若“招牌菜”同时属于“主食”，渠道可展示多个入口，但后厨仍接收同一个菜品码，避免重复建档或两套配方。

一道菜的完整演示映射

以下全部为演示，不是门店真实工艺或产能：菜品D101在顾客菜单“热食”分区，订单进入后先从冷藏节点R1领取预处理物料，在工位P1完成称量与组装准备，再到烹饪节点C1执行批准程序，最后在出餐节点E1核对。订单票据、备料卡和培训都显示D101及同一版本。

菜品码	前台分区	备料与冷藏	烹饪/加工	组装出餐	待验证负荷
D101	热食	R1、P1	C1	E1	各节点占用时间、并发、切换
D202	小吃	P1	C1	E1	与D101共享P1、C1、E1
D303	蒸点	R2	C3	E2	蒸制批次与等待

现场实施时，节点代码再绑定实际资产号、工位和程序版本；只有确实参与该工序且有任务记录的设备才进入映射，不用产品名称或网页参数充当产能证据。

历史基线先描述事实

选定可比时段，按菜品码统计历史订单组合、到达时点、取消、停售、厨房票据、完成时点、返工和设备或工位占用记录。基线要保留日期、班次、人员、菜单版本和异常，不只给日均销量。

历史数据说明旧菜单下发生过什么，不能证明新排版会让顾客怎样购买。若历史记录缺少工序或资产号，只能标为缺口，不能用设备额定功率换算节拍。

用三种情境检查承载条件

基准情境重放历史订单及实际到达顺序，验证模型能否大致复现已知排队和节点占用。保守情境假设新分区没有改变购买组合，只改变展示；它用于检查系统映射，不宣称销量变化。高峰情境则由运营方明确假设，例如D101与D202在同一时间窗占比上升，同时D303保持历史上界；假设来源、幅度和理由写在表头。

模拟逐单经过备料、烹饪和出餐节点，记录共享节点排队、设备并发、批次等待、人员跨区和停售触发。它只能暴露“在这些假设下可能超载”，不能证明新排版必然造成该订单组合。

给出一个可复算的纯假设窗口：C1只有一个同等机位，D101占用4分钟，D202占用3分钟，清场已包含在各自时长；12:00到D101、12:01到D202、12:02再到D101，按先到先服务分别在12:00、12:04、12:07开始，等待0、3、5分钟。若菜单展示变化后的情境只把12:01那单改成D101，其余到达、人员和节点不变，则三单在12:00、12:04、12:08开始，等待变为0、3、6分钟，C1在12:00—12:12连续占用。变化只说明这个假设组合令第三单多等1分钟；不是销量预测，也不证明真实门店需要添机。

若要比较更激进组合，再增加情境而不是偷偷改基线。每次只改变明确变量，保留前一结果，避免菜单、人员、设备和工序同时变化后无法归因。

顾客任务与生产任务分别测试

顾客侧用典型任务测试能否找到菜品、理解规格与可选项、发现停售或限制，不测后厨产能。后厨侧用模拟票据、空容器或批准的冷态任务验证票据能否对应菜品码、备料卡和工序，不把员工记忆当作系统映射。

上线后的实际订单才可用于观察查找与购买是否变化。比较需考虑日期、活动、价格、库存和渠道，同时保留未能控制的条件，不把排版与销量相关直接写成因果。

设备负荷必须来自记录

设备网页功率只说明额定电气字段，不能折算出单份时间、批量能力或并发上限。负荷表需要现场任务记录、当前程序、批量、装卸、清洁切换、人员和失败样。没有记录的节点写“待验证”，不因关联某型号就填一个理论产量。

共享工位尤其要算组合占用：D101与D202分别能完成，不代表同时进入P1仍能承载。统计排队分布和极端情形，安全、食品与设备限制优先于缩短等待。

从订单组合计算节点占用

情境表不只写“高峰一百单”，而要列每个时间窗内D101、D202、D303各有多少单、每单或每批经过哪个节点、是否可以并行、切换需要什么动作。相同总单量可能形成完全不同的瓶颈：D101集中会压C1；按本演示映射，D101与D202同时上升会共同占用P1、C1和E1，哪一处先形成瓶颈要由各节点的现场时长与并发规则判断。

任务时长使用现场观察分布，而不是只取最快一次。装载、等待、程序、卸载、清洁、补料和异常停顿分别记录；多人协作与自然历时也分开。若某工序按批次运行，模型需要写明成批规则与未满批等待，不能把每份时间简单相加。

演示结果可写“假设高峰组合下，P1待处理队列持续增长”，但不能写“菜单重排导致P1超载”，因为购买组合仍是假设。验证路径是先小范围上线、观察真实组合，再更新情境与人员设备安排。

失败样比平均值更能说明边界

平均等待没有变化，仍可能出现某类订单长期滞留、票据被错分、共享设备切换失败或员工为赶单绕过食品控制。模拟和试运行都保留最大等待、返工、停售、设备报警、跨区和未完成订单，并回到具体菜品码与节点。

一次异常不能自动归因于菜单，但也不能被大量顺利订单平均掉。团队先区分数据、映射、工序、人员、设备和外部事件，再决定改菜单分区、限制选项、改变备料或调整生产线。

菜品变体需要独立映射

加料、去料、规格、辣度或套餐替换可能改变工序与节点，不能一律继承标准菜。每个会改变设备、批次、食品信息或组装的选项建立变体码或明确规则，测试票据是否把差异传到后厨。

如果前台允许一个选项而后厨没有批准工序，先关闭该选项，不让员工现场创造路径。停售时同步顾客入口、收银和备料，避免只有后厨知道。

上线观察与停止条件

上线前预设观察窗口、负责人和停止条件，例如票据映射错误、共享节点队列持续增长、设备或食品限制被触发、员工必须绕过标准动作。达到条件时暂停受影响菜品或回到经核实版本，不需要等整日结束。

观察记录按订单与节点保存，说明活动、缺货、人员和设备异常。几天数据可以发现问题线索，不能自动外推全年；季节、促销或渠道变化后需要重新评估。

发布用一张变更矩阵

矩阵逐菜列旧分区、新分区、菜品码、POS名称、厨房票据、备料卡、工序版本、培训材料、渠道和责任人。所有受影响对象通过后才安排生效；未完成的渠道临时停售或维持经批准旧版，不允许前台先卖、后厨后补。

上线设回退条件，但回退前要确认旧菜品、价格、配方、库存与食品条件仍有效，不能默认恢复已停售项目。失败记录进入下一版变更，不用口头说明覆盖版本差异。

最终交付应同时包含顾客分区图、逐菜工序图、历史基线、明示假设的情境结果和全渠道版本矩阵。这样菜单设计才不会只在页面上清楚，却把拥堵留给后厨。

参考资料

• WebstaurantStore：菜单设计指南