ybuild / 场景

如何搭建一套掌控出品线的餐厅管理系统

餐厅的利润率是各行各业里最薄的之一：食材是最大的可控成本，而大多数经营者的存亡，就取决于它能不能落在健康的 28-35% 区间里。然而真正决定利润的那些数字——一道菜的成本是多少、冷藏库里还压着多少货、冷柜是不是整晚都稳在 41°F——却散落在一张张夹板纸、主厨的记忆、和员工群聊里。一套餐厅管理系统，把菜单、配方、库存和合规记录汇集到一处、让你能在出品线上直接运转，托管在 ybuild 上、通过你自己的域名对外提供服务。

痛点

食材成本在无声中失控：库存靠纸笔盘点（或者根本不盘），于是等到月末损益表结账，你才发现这个月一直跑在 38%——早已错过了在当期把它修正回来的时机。
备料单和温度记录都躺在夹板纸上，被咖啡渍浸花、被弄丢，直到卫生检查员开口要看最近 90 天的记录那一刻。
沽清单（86 list）、当日特餐、以及过敏原细节都装在主厨脑子里和一个群聊里，于是服务员会信心满满地给客人一个错误答案。
每一张供应商发票都是格式各异的 PDF，没有人把当初谈好的箱价和实际结算的金额核对一遍——这正是无人盯防的利润漏洞。

你能搭什么

菜单与配方成本核算

每一道菜品都关联到一份配方，配方里的每种食材都带着真实的包装规格和箱价。鸡肉的进价只需改一次，所有用到它的菜品的单盘成本和食材成本率就即时重算——于是你能在那些定价过低、分量过大的菜品悄悄吃掉你利润之前就把它们揪出来。

库存盘点与订货

一块适配手机的每周盘点界面，按存储区域组织——冷藏库、干货区、冷冻库。系统把你盘到的数量和常备量（par）逐一对比，交给你一份按供应商分组的缺口清单，直接变成你的采购单，而不是订货本上随手一划的猜数。

出品线与合规记录

备料单、报废与赠菜记录，以及冷藏库、热保温、两段式冷却的时间温度记录——每一条记录都带着员工签名缩写、时间戳，以及读数超标时强制填写的纠正措施，全部留存并可随时调出供检查。

数据模型

menu_items

id, name, category, price, station, allergens, is_86, recipe_id, is_active

ingredients

id, name, purchase_unit, pack_size, case_cost, recipe_unit, unit_conversion, par_level, on_hand_qty, supplier_id

recipe_lines

id, menu_item_id, ingredient_id, qty, unit

inventory_counts

id, count_date, storage_area, ingredient_id, counted_qty, counted_by

temp_logs

id, log_type, equipment, reading_f, recorded_at, staff_id, corrective_action

系统里的一天

开档：经理调出备料单——recipe_lines 加上昨天的销量，精确告诉出品线要备多少 mise（备料），这样没人会去多备那道一天只卖六碗的汤。
收货：收货界面把每一箱货和供应商约定的 case_cost 逐一核对，标记出少送或多送，并为这批货里的每种食材增加 on_hand_qty。
冷柜检查：每四小时一位厨师点开 temp_logs 界面，记录冷藏库读数；如果高于 41°F，应用会锁住保存，直到填入一条纠正措施。
服务中：服务员把三文鱼标记为沽清——menu_items.is_86 翻转，这道菜在每个档口的屏幕和面向客人的特餐牌上同时变灰。
冷却：炖菜离火之后，厨师启动一个冷却计时器；系统会在两小时时提示做 135->70°F 的检查，并在此后四小时提示做 70->41°F 的检查。
打烊：报废、赠菜、以及 POS 销售总额被登记，明天的备料量对照更新后的在手库存重新计算。
每周盘点：经理拿着手机逐个存储区域清点；应用把 counted_qty 和 par_level 对比，按供应商生成一张采购单。
月末：食材成本率按每道菜和整体汇总，在会计打开账本之前，就把哪些菜品定价过低或分量过大浮现出来。

AI 容易出错的地方

单位是头号陷阱。你按箱买鸡肉，按盎司分份，按个盘点冷藏库。粗糙的做法只存一个「数量」字段，你的食材成本核算就会悄无声息地算错——每种食材都需要一个采购单位、一个配方单位，以及两者之间的换算。
温度记录不只是一个数字。大多数州采纳的 FDA 食品法典（FDA Food Code）要求记录读数、时间戳、由谁测量、以及读数超标时的纠正措施——并且要求大约最近 90 天的记录可随时调出。绝不要让一条超标读数在没有后续处理的情况下就保存下来。
冷却是两段式的，不是一个勾选框：2 小时内从 135°F 降到 70°F，再用 4 小时从 70°F 降到 41°F。单一的「凉了没」开关过不了检查——把两个检查点都建模，各有各的计时和各自的合格/不合格判定。
过敏原不能是一段自由文本备注。芝麻在 2022 版食品法典中成为第九大主要过敏原；把过敏原作为每道菜上打好标签的字段来存储，好让服务员能即时筛选并作答，而不是一句话——那句话总有人忘了更新。
绝不要硬删除一道菜品或一种食材。删掉上个月的「本周鱼特餐」，它的销售和食材成本历史就会从你的报表里消失。用 is_active 做软删除，让 recipe_lines 和过往盘点保持完整，数字才诚实。

✓ 先做这些

带配方成本核算和实时食材成本率的菜品——这个单一数字会改变你的定价和分量决策。
针对你成本最高、走货最快的前 30 种食材的「每周盘点->常备量->供应商订货」闭环，而不是整个仓库。
带强制纠正措施的时间温度和报废记录，留存 90 天以上，卫生检查时能在几秒内调出。

— 先别做

刷卡处理和桌边支付——保留你现有的 POS，只导入它的每日总额；v1 不要重建支付。
工资、小费分账、以及劳动法排班计算——先从一张简单的班表做起，把工资交给你的服务商。
在线点餐和外卖平台菜单同步——先把内部运营做扎实，再去对接 DoorDash 和 Uber Eats。

常见问题

这会取代我的 POS 吗？

不会——继续用你的 POS 在桌边收款。这套系统与它并行：你把每日销售总额录进来（手工或简单导入），好让食材成本和库存能对照实际卖出的数据核对上。在 v1 里重建刷卡处理，是一场不值得打的仗。

它怎么计算食材成本率？

每道菜品关联到 recipe_lines，每一行指向一种带箱价和包装规格的食材。应用换算到配方单位，累加出单盘成本，再除以菜单售价。改一个箱价，所有用到那种食材的菜品都会重算。大多数全服务餐厅的目标大约在 28-35%。

这些温度记录真的能让卫生检查员满意吗？

这些记录会捕捉读数、设备、时间戳、员工签名缩写，以及超标数值的必填纠正措施，并保持至少 90 天可调出——这正是采纳 FDA 食品法典的辖区所看重的。务必和你当地卫生部门确认它想要的确切格式，因为各州会对这套示范法典做本地化调整。

我能用它经营不止一家门店吗？

可以。库存盘点、常备量和温度记录都是按门店隔离的，而菜单和配方是共享的，所以一次改价就会同时铺到所有门店。先从一家门店做起，把闭环跑通，再复制它。

不培训也能在出品线上用吗？

盘点和温度界面就是为一只湿手拿着的手机而造的——大按钮、一次一个读数、没有要翻找的菜单。因为整套系统托管在 ybuild 上、跑在你自己的域名下，员工只需在任意手机上打开一个收藏的网址；没有任何东西要安装或更新。

参考来源

FDA 食品法典（FDA Food Code） — 美国大多数州采纳的联邦示范法典，涵盖时间温度控制、冷却、过敏原和食品安全记录留存。
美国餐饮协会：FDA 更新其食品安全指南 — 行业协会对 2022 版食品法典更新的总结，包括把芝麻列为主要过敏原以及修订后的温度规定。
NetSuite：控制餐厅食材成本的 21 条策略 — 关于常备量、先进先出（FIFO）轮换和定期库存盘点以把食材成本控制在区间内的实用指导。

为你的生意搭这套系统

描述它，一次性上线到你自己的域名——托管、全栈、无需服务器。免费开始。

免费开始构建 →