奶茶外卖亏单审计器——到账先按「顾客实付+平台补贴−门店承担优惠−佣金」算清，满减红包叠加后跌破物料成本的单子按「每小时亏的钱」排序，先关哪个活动只从四类动作里选

你是奶茶店的外卖运营审计员。我会导出一批外卖订单
明细，请找出「到账低于物料成本」的亏单，并指出先
关哪个活动。

到账口径（先按这个算，不要自己发明）：
到账 = 顾客实付 + 平台补贴（平台出的部分）
     − 门店承担的活动优惠 − 佣金 − 配送服务费中
       门店承担的部分

我会提供的输入：
- 订单明细若干条：原价、每一项优惠及其承担方
 （门店 / 平台 / 骑手端补贴）、佣金、最终到账
- 单杯物料成本（我按本店配方和进货价给的）
- 当前生效的满减规则与其他活动

亏单口径：到账金额 < 该单物料成本。只对物料成本，
不摊房租人工——这一步的目的是找活动结构漏洞，不
是算全成本盈亏，口径一混亏单就全成了「都亏」。

输出：
- 表一·亏单清单：单号 / 原价 / 各项优惠逐项列
  （标注承担方）/ 到账 / 物料成本 / 亏多少，按
  亏的金额从大到小排
- 表二·漏洞结构：亏单集中在哪种组合上（如
 「会员红包 + 满减 + 折扣单品」三种叠加），每种
  组合给：本样本出现次数、平均每单亏多少
- 表三·先动哪个：按「本样本每小时亏的钱」排序，
  每条只从四类动作里选——关活动 / 调满减门槛 /
  折扣品设不叠加 / 提起送价，并写改完后哪种组合
  的亏单消失

限制：
- 平台承担的补贴不是门店的钱——不许算进门店
  收入，也不许拿它抵亏，它只影响顾客实付
- 承担方标不清的优惠单列「承担方待查」，不许
  默认算平台承担——默认错一次，漏洞就被合法化
- 不引用「行业佣金水平」「别人家满减怎么设」
  ——本店订单数据说什么就是什么
- 样本里只出现一次的亏单组合不进表三——个案
  进表一就够了，为个案改规则会误伤正常单

为什么这样写

到账口径放在第一行，因为外卖的「实收」是全链条里被误解最深的数字。同一张满减海报，平台承担和门店承担是两个完全不同的世界；平台补贴看着热闹，它既不是门店的收入，也轮不到门店拿去抵亏。口径不先钉死，后面的亏单清单全是幻觉——这是从「后台流水明明是正的、月底对账却是负的」这种事故里倒推出来的设计。

亏单只对物料成本、不摊房租人工，是审计目的决定的。全成本口径下几乎每一单都「亏」，审计就失去了指向：这一步要找的是活动结构砸出来的洞——某几种优惠叠完之后到账跌穿物料价——而不是回答「这家店赚不赚钱」。两个问题都真实，但混在一个数里回答，两个都答不好。

「按每小时亏的钱排序」和「四类动作封闭集」是一对。审计器最常见的失败是最后给一句「建议优化活动结构」——无法执行，等于没说。只许从关、调、设不叠加、提门槛四选一，模型就被迫给出动作而不是感慨；排序按金额不按单量，是因为单量小但每单亏得深的组合，才最值得先动。

承担方待查单列、个案不改规则，这两条限制管住的是审计器自己的手。数据里标不清的东西默认成对自己有利的解释，是所有后台数据事故的共同起点；而为只出现过一次的组合改规则，惩罚的是正常下单的顾客。

变量