我在食堂管理这个圈子里泡了好几年见过太多管理员被“下周吃什么”这件事逼到失眠。别小看这一句话背后牵扯采购、库存、成本、营养、口味、季节、剩余食材、员工反馈哪一环断了线第二天食堂就可能开天窗或者被员工在群里点名批评。今年年初开始我试着把AI接进食堂管理流程让大模型根据历史数据、当前库存和营养需求自动编排一周菜单再联动生成采购清单。跑了三个多月原本每周要花两三个小时排餐的管理员现在基本只干一件事在AI给的草稿上做加减法、拍板发布。这篇文章就记录一下我是怎么从一个被AI编出一堆“梦里才有的菜名”气到摔键盘的人变成一个敢把“下周吃什么”交给AI出初稿的人。1. 先弄明白食堂排餐为什么是块硬骨头1.1 一张菜单背后至少五条约束线很多人觉得食堂菜单就是“今天吃鸡还是吃鱼”真上手排一次才知道每次编下周菜单都是一次多目标决策而且不是单日决策是一整周五天连在一起做规划。单看某一天可能怎么排都合理但放到一周维度问题全来了。第一是营养线。员工餐不是下馆子天天红烧肉、炸鸡排员工是吃得开心但营养结构一塌糊涂长期下来身体扛不住食堂也会被吐槽“不健康”。所以一周菜单里蛋白质、蔬菜、碳水、豆制品要有基本比例煎炸类不能太多。第二是成本线。企业食堂都有餐标比如人均15元或者20元不是说不能超但每周总体必须拉平。有的菜毛利低、有的菜毛利高得交叉着来不然财务月底一看报表食堂运营就是“赔本赚吆喝”。第三是库存线。冷库里还有三十斤鸡腿、十几斤土豆下周菜单就得尽量把这些先消化掉不然一边压库存一边买新货损耗只会越来越大。这个约束最折磨人因为库存不是一成不变的每天进货、每天消耗排菜单的人得心里时刻装着账。第四是口味线。众口难调还不是最难的最难的是“重复”。周二刚吃过红烧肉周四再上就有人拍照发圈“食堂是不是只会做这个”所以排菜单天然要带“近期不重复”的隐性规则。第五是合规线。食堂要考虑过敏原标注、特殊忌口、清真餐或素食需求还要按食安要求留样和菜谱存档。这些如果全靠管理员脑子记迟早出问题。人工排餐的问题恰恰在于一个人要在很短时间里同时照顾这五条线而且每周都要做一次。第一次排可能还行连续排三个月脑子里的约束不打架才怪。换人接手的时候更头疼经验全在上一任的脑子里带不走、留不下。1.2 AI真正替代的不是管理员是“反复试错”我接触过很多想做食堂数字化的甲方一开始都说要上“智能推荐”后来发现大家真正缺的其实是一套能快速生成候选方案的工具。AI进食堂之后它干的最核心的一件事不是替管理员做决定而是先把“试错”的成本压到几乎为零。以前管理员想验证“这样排成本会不会超”得自己拿计算器或Excel一点一点试现在AI可以两分钟给出五套菜单每套都标注预计成本、营养数据、消耗库存量管理员只需要从中挑一套、改几个菜而不是从零开始排。这就像以前写周报你得自己从空白文档开始敲现在AI给你一份带批注的草稿你改改就能用。管理员省下来的精力可以花在真正需要经验判断的事情上比如供应商临时缺货怎么换菜、哪个窗口阿姨做糖醋口味更稳。所以我一直跟客户强调别把AI当成“做决定的领导”把它当成“干活特别快、但偶尔会犯傻的实习生”。它负责算、负责记、负责给方案管理员负责把关、掌眼、背锅。这样定位项目落地会顺利得多。2. 方案选型为什么我用“大模型规则校验”2.1 传统推荐系统为什么不够用刚开始有人建议我用传统推荐算法说历史销售数据都有跑个协同过滤就能知道员工爱吃什么。这个思路没毛病但真落地会发现一个问题推荐系统只能从已有菜单里“选”不能从无到有“编”。食堂排餐最大的工作量不是“从200道菜里挑5道”而是“怎么让挑出来的5道菜在成本、营养、库存上相互配合”。比如AI要安排周一主荤推荐系统根据历史热度给一个“红烧肉”但红烧肉的食材成本偏高、周四已经安排了糖醋排骨这两道菜都是大荤放在一周里就显得油腻。这些问题推荐系统不太会管。生成式大模型厉害的地方在于它能理解一堆约束条件然后像人一样用自然语言把一周菜单“写”出来。它甚至能写出来“考虑到周二有土豆炖鸡块周三主食换成粗粮更均衡”这种带逻辑的说明。所以最终我选了“生成式AI出草案”的路线。但纯大模型也不行它太能“编”了。测试阶段它给我生成过“凉拌爆炒腰花”“巧克力炒饭”这种让人眼前一黑的菜名一看就是脱离了菜品库的自由发挥。到那时候我明白一个道理AI负责聪明规则负责把关。大模型输出草稿程序再拿草稿去数据库里做校验成本超了打回、库存不够打回、营养不达标打回几轮下来才能给人看。2.2 数据先结构化不然AI只是在给你编故事AI排餐质量高不高七分在数据三分在模型。我踩过的最大一个坑就是一开始直接把一张Excel菜谱表丢给大模型以为它能“理解全部”。结果它真就把“鱼香肉丝”当三个字处理了完全不知道这道菜要用多少肉、多少配料、成本是多少。后来我把菜品相关的数据全部结构化了最核心的几类表包括表名关键字段用途菜品基础表菜品ID、名称、分类、口味标签、是否时令限定AI可选范围菜谱原料表菜品ID、原料ID、用量、损耗系数算采购量和营养素原料信息表原料ID、名称、单位、单价、当前库存算成本和采购历史售卖表日期、菜品ID、售卖份数、剩余份数算受欢迎度营养参考表菜品ID、热量、蛋白质、脂肪、钠、膳食纤维营养达标校验禁忌标签表菜品ID、过敏原、清真、素食、辣度保障安全合规这里最花时间的是“菜谱原料表”。一道土豆炖鸡块得拆成土豆、鸡腿肉、胡萝卜、葱姜蒜、生抽、老抽每样多少克。拆完以后程序才能干两件事一件是根据每日就餐人数算出食材总需求另一件是根据原料表的营养成分换算出一份菜的实际营养值。这个工作确实枯燥但必须做。不做结构化后面所有和成本、库存、营养相关的功能都立不起来。我通常建议客户先盘自己最常做的八十道菜把数据录进系统够周转三周不重复就能先跑起来。2.3 技术栈怎么选便宜、快速、能落地我们最终的技术方案非常朴素大模型API加一个Python定时任务再加一个共享表格当审批界面。没有专门训练模型也没买GPU服务器。具体流程是每周五下午四点定时脚本自动把库存表、历史销售表、预算参数汇总成一段Prompt调用大模型API生成五套下周菜单草案程序拿到草案后逐条去数据库里校验成本和库存把不合格的菜品标红并附上原因随后结果推到企业微信或者共享表格管理员在手机上就能审核修改点一下发布系统再自动拆解食材需求生成采购清单。这套方案有两个好处。第一是便宜API调用一次的成本几毛钱一周跑几次一年下来也就几百块比请人开发一套推荐系统划算得多。第二是灵活后续想加约束条件比如“每周三必须有粗粮”“不吃辣的员工比例高就少放辣椒”改程序里的一段文案就行不用动整个架构。我给很多小体量食堂做方案时都劝他们别一上来就上什么“智慧食堂中央控制系统”。先把最简单的AI排餐闭环跑通让管理员感受到省事后面再加硬件设备、营养大屏、刷脸取餐都是顺理成章的事。3. 核心实现让AI真正当好“食堂管家”3.1 把食堂规矩写进提示词大模型不会天然懂你食堂的潜规则得把规矩一条条写进提示词里。我经过几轮调优现在用的Prompt框架大致长这样你是一名有十五年经验的机关食堂营养师兼管理员。 现在需要你帮我制定下周5个工作日的午餐菜单。 硬性要求 1. 只能从提供的菜品库中选择不得编造不存在的菜名。 2. 优先消耗当前库存食材库存不足的食材自动进入采购建议。 3. 一周内同一道菜不重复汤和主食除外。 4. 每日人均食材成本控制在15元以内一周总成本浮动不超过5%。 5. 午餐结构必须包含1个主荤、1个副荤/蛋类、1个素菜、1个汤、1份主食。 6. 每周深色蔬菜出现不少于3次豆制品出现不少于2次。 7. 上周已出现的菜品见历史菜单本周不再安排。 8. 注意过敏原和忌口标签标注每道菜的辣度。 输入信息 - 当前库存xxx - 菜品库xxx - 历史售卖情况xxx - 上周菜单xxx - 本周预估就餐人数xxx 输出格式请用Markdown表格输出周一至周五每天一行包含主荤、副荤、素菜、汤、主食并附一段50字以内的安排理由。这段提示词里最关键的是“只能从提供的菜品库中选择”。加了这一句之后AI再也没给我编出过“凉拌爆炒腰花”那种鬼东西因为它知道自己的选择边界在哪里。这就像一个实习生进公司你得先告诉他能用哪些报销科目他才不会拿一张“海底捞”发票去报销差旅费。还需要注意一点大模型对“成本”的感知是模糊的。它不知道土豆多少钱一斤、鸡腿肉多少钱一斤所以我允许它出草稿但最终的“成本超不超”必须交给程序用具体单价去算。模型拍脑袋规则来把关这个分工不能乱。3.2 一周菜单生成实例AI给的草稿长这样拿我们跑过的一次真实参数举例。当时系统库存里有土豆30斤、胡萝卜18斤、鸡腿肉25斤、豆腐15斤上周菜单里已经出现过红烧肉和大白菜本周预估每天400人就餐人均餐标15元。AI给的第一套草稿大概是这样的星期主荤副荤/蛋类素菜汤主食周一土豆炖鸡块青椒炒蛋清炒西兰花紫菜蛋花汤米饭周二麻婆豆腐香菇肉片手撕包菜冬瓜汤二米饭周三胡萝卜烧肉蒜苗炒香干清炒油麦菜番茄蛋汤米饭周四青椒鸡丝番茄炒蛋醋溜土豆丝黄瓜汤杂粮饭周五红烧狮子头白菜豆腐清炒莴笋酸辣汤米饭这版草稿一看就是“能用的”不是瞎编。土豆和胡萝卜被分散在周一周三周四三道菜里正好消化库存豆腐出现了两次豆制品指标轻松达标红烧肉和大白菜没出现避开了重复。整体荤素搭配也说得过去。但程序校验时发现一个实际问题麻婆豆腐按每份150克豆腐算400份需要60公斤豆腐当前库存只有15公斤供应商本周只能供给40公斤缺口5公斤。程序标红后管理员做了个小改动——周二换成“鸡蛋炒木耳”把豆腐需求降到周五的白菜豆腐那一道菜。这样改完成本、库存、营养全部通过。我把这类操作叫作“AI出题、人工改卷”效率高且不容易翻车。真正好的落地状态是AI草稿大部分能直接用管理员只需要在关键位置微调而不是从头推翻重来。3.3 采购清单不是AI嘴一张就完事要算法联动菜单定稿之后下一步就是生成采购清单。这一步很多人以为可以让AI直接写我试过不靠谱。AI一句“建议采购土豆50斤、胡萝卜20斤”既不知道库存扣减也不管包装规格客服拿着单子买回来不是多就是少。正确的做法是菜单确认后程序自动按“菜谱原料表”把每个菜拆成原料需求再按就餐份数汇总最后减去当前库存、乘上一个损耗系数得出净采购量。简单逻辑就像这样需求 {} for 菜品 in 本周菜单: 份数 预估人次[菜品.星期] for 原料, 每份用量 in 菜谱原料表[菜品]: 需求[原料] 每份用量 * 份数 实际采购 {} for 原料, 总需求 in 需求.items(): 考虑损耗 总需求 * (1 损耗系数) 净需求 考虑损耗 - 当前库存[原料] if 净需求 0: 实际采购[原料] ceil(净需求 / 包装规格) * 包装规格我习惯把损耗系数设在12%到15%之间因为土豆削皮、青菜去根、肉切配缩水这些损耗看起来不大但累计下来很吓人定低了采购单就会不够用。包装规格为什么要向上取整因为食材采购不是按克买的土豆一箱40斤、西红柿一件30斤你算出“31.7斤土豆”不可能只买半箱。这套逻辑跑下来采购单基本不用人工改。供应商周一早上收到的单子和冷库实际缺的东西严丝合缝。有一周我们甚至把剩菜率从之前的18%降到了9%左右管理员自己都吓了一跳。3.4 别急着全自动先跑一个月的“人机协作”项目上线第一个月我压着管理员不让他把“审核”这步关掉必须每单都人工看过再发。当时有人嫌麻烦“AI都排好了我直接公布不行吗”我说不行因为现在跑的是“人机磨合期”还没到“放手期”。磨合期的核心任务是记录人工改动。比如AI这周配了西兰花管理员把它换成菠菜我们就在后台记一条“西兰花被替换”的日志。日志跑了一个月统计出来规律本地员工普遍不爱吃苦瓜但AI每隔几天就安排一次成本偏高的牛肉类菜品管理员每周都会替换成鸡肉或鸭肉。这些规律后来都被我写回提示词变成了显式约束。现在我的建议是“AI出初稿、人工终审”这个模式至少保留三个月。等管理员或者老板完全信任了再把终审放宽成抽审。全自动不是不能做但出一次错AI就会被扣上“还是不行”的帽子那后面推行什么都会受阻。4. 落地之后踩过的坑问题排查与避坑实录4.1 问题速查表这些情况我都遇过整个过程中我把最典型的几个问题整理成了一张速查表方便后面在其他食堂复制经验现象可能原因排查与解决AI生成了一些根本不存在的菜名提示词没限定菜品库范围在提示词明确“只能从提供的菜品库中选择”并把菜品库作为白名单传入采购清单算出来总是不对原料用量单位不统一或者损耗系数偏低统一换算到克和千克按两周实际盘点校准损耗系数员工反馈菜单重复、没新鲜感缺少“最近14天不重复”约束把历史菜单传进Prompt并增加“近两周已出现菜品禁用”规则一周成本经常超预算只设了人均上限没限制单日波动改为单日和一周双重约束单日偏差超过10%时自动重新生成AI回复格式偶尔乱掉模型输出不稳定程序解析失败约定JSON输出格式并做异常重试失败超过3次自动切到上一次可用的菜单模板管理员不敢用担心AI背锅没有人工审批环节保留终审环节系统记录每条人工改动生成“人机协作”日志这张表里的问题我基本都踩了一遍尤其第一行。最开始我把“菜品库”作为隐含信息没有在提示词里强调AI就开始天马行空。后来把所有菜品名显式列在输入里情况立刻好转。解决办法不复杂但经历一次才知道关键在哪儿。4.2 几个值得写进项目文档的注意点除了问题速查表还有三件事我想重点提醒。第一禁忌信息必须用标签不能用“AI理解”。过敏原、清真餐、素食、忌口这些不能指望大模型靠常识判断必须在菜品库里给每道菜打上结构化标签。比如“肉末茄子”看起来是素菜但里面如果放了肉末就不能打“素食”标签。程序校验的时候宁可误杀不可放过。这跟食品安全一样是底线问题。第二不要太迷信AI的营养计算能力。不同菜谱用的油量差别很大同样是番茄炒蛋有的师傅放20克油有的放50克营养数据差得远了。我给客户的建议是先抓大放小把热量、蛋白质、脂肪这些主要指标管起来钠和膳食纤维可以后续再精细化。第三模型不是越大越好。我在技术选型时对比过几个主流大模型发现对于“生成菜单”这种任务效果差别并没有想象中那么大。反而是提示词和数据质量对结果的影响更明显。一个小的轻量模型配上精调过的Prompt、干净的数据表往往比一个大模型裸跑更稳定。我个人在实际操作中最深的体会是AI进食堂最大的障碍从来不是技术而是信任。管理员怕它瞎排、采购怕它算错、老板怕它超成本每个人的担忧都合理。但只要你把规则一条条写清楚、把数据一点点做干净、给人留足审批权AI真的会成为食堂里那个最不想抢功劳、却一直在背后默默干活的实习生。它不懂本地人的口味不懂你食堂的锅够不够用但它能让你从“下周吃什么”的焦虑里彻底松一口气。