餐饮业利润薄、决策碎。某个供应商把一种食材涨了价；某位厨师出品稍微大方了一点；一次促销把销量推向了毛利更低的菜；某家门店订多了、最后倒掉。每件事都不大，加在一起却决定了一家店赚不赚钱。
老板通常是从月度损益表上发现问题的。那时原因已经过去几周，散落在成千上万笔交易里，而报表只告诉你食材成本率变了，不告诉你为什么。五家门店各有习惯，“哪家店、哪道菜、哪种食材、哪个供应商？”这个问题，会计可能要查好几天。
餐饮集团的数字孪生是什么
对餐饮集团来说，数字孪生不是一个三维厨房，而是一个能运行的经营模型：每一笔销售连着实际出品的配方，每个配方连着食材，每种食材连着采购、供应商和现有库存。因为这些关联是明确的，模型既能把一个数字追溯回原因，也能向前推演一次变化——换供应商、涨价、改菜单——在你拍板之前先看结果。
我们做了什么
我们的餐饮数字孪生建模了一家虚构的悉尼五店餐饮集团：90 天可复现且已对账的种子交易、60 道菜、120 种带配方的食材、15 家有价格历史的供应商。
- 与界面独立的计算引擎。 门店损益、菜品指标、配方成本和永续加权平均库存都从基础数量算出，并由测试精确对账到分。
- 食材孪生。 任何一种食材，都能看到它做成了哪些菜、这些菜的收入、按明确规则分摊给它的利润，以及它本身的成本。旗舰案例我们写在《一公斤大米赚了多少钱？》里。
- What-if 与事件模拟。 改一个供应商价格、一个出品分量或销售结构，或模拟一次突发事件，所有受影响的数字都由同一个模型重算。
- 预测驱动的补货。 建议采购单来自预测，经过审批，并留下审计记录。
- 引导演示。 九个步骤，从一家门店的毛利异常出发，追到原因——本地大米供应商和超配方用量——最后生成一张已审批的采购单，并验证它对库存的影响。
- 英文与简体中文，因为很多集团的后厨和总部本来就用不止一种语言。
它能帮老板回答的问题
- 这周哪家店的毛利变了？哪些菜、哪些食材能解释它？
- 原因是供应商价格、出品超量、损耗，还是销售结构？
- 某个供应商涨价若干，每家店的毛利会怎样？
- 该改配方、改菜价，还是换供应商？
- 每家店这周该订多少？谁批准的？
- 把食材成本诚实分摊之后，哪些菜真的值得留在菜单上？
会带来哪些改变
以前： 月结之后发现食材成本上升，解释它要开一次会。采购靠主厨的记忆。和供应商谈判时，并不知道一次涨价对整个集团意味着什么。门店之间只比总数。
以后： 异常在发生的时候就被标出来，并追溯到具体门店、菜品、食材和供应商。供应商涨价，在接受之前就算清了对每家店的影响。订货量由预测建议，审批有记录。店长和总部看的是同一套数字。菜单决策看每道菜的贡献，而不只是销量。
在你的集团里怎么落地
不需要新硬件，孪生用的是你已经在跑的系统：
- 诊断。 导出几个月的 POS 销售、配方卡（表格也行）、供应商发票或价目表、盘点和损耗记录。我们检查它们怎么关联、缺口在哪里——配方往往是最薄弱的一环。
- 基于你数据的原型。 用你的数据替换种子生成器，与你的账目对账，然后在你自己的门店上展示第一批异常和 what-if。
- 联网孪生。 定时接入 POS、财务和供应商数据，保持模型最新，采购审批也搬进孪生的流程里。
无论找哪家供应商，都值得问：
- 系统能不能和我的账对平到分？测试能不能给我看？
- 把利润分摊给食材时，规则是不是明确的、能不能由我改？
- 预测和 what-if 是不是与损益用同一个模型算的，而不是另一张表格？
- 每一次审批和修改是否都有记录？
诚实地说局限
演示中的集团、门店、菜品、供应商和每一笔交易都是虚构的种子数据，没有连接任何 POS、财务或供应商系统。把利润分摊给食材是一种规则选择（按成本、按数量或均分），不是客观事实——孪生的做法是把规则摆在明处，而不是藏起来。演示里的预测基于合成历史，不代表任何真实需求。
去看看
- 在线孪生：restaurant.octopustwin.com
- 案例研究：餐饮数字孪生
- 想看看你自己的门店？联系我们。
