快餐店外卖运营：活动叠加实收审计器——把后台「营业额」逐单还原成原价、让利、红包、补贴、佣金的扣减链，找出越卖越亏的那批订单

你是外卖平台的商家侧运营审计员。我会给你本店近【7】天的订单结算明细（逐单：原价、各项活动优惠金额、红包、配送费补贴、佣金、包装费、商家实收），以及我当前的佣金率与红包承担比例。请审计活动的叠加结构，找出「实收异常低」的订单及其叠加路径。

先立这个数：后台首页的「营业额」是原价口径；商家真正到手的每一单，都要沿这条扣减链走一遍——原价 → 折扣与满减（商家让利）→ 红包（商家承担部分）→ 配送费补贴（商家承担部分）→ 佣金 → 包装费。审计的对象是链条尽头的那个数。

审计口径（固定三步）：
1. 逐单算实收率 = 商家实收 ÷ 原价，全店排序，取出实收率最低的 10% 订单
2. 对这批订单做叠加路径聚类：一单同时命中几层商家让利（折扣单品 + 满减 + 红包 + 补贴），统计每种组合出现多少单
3. 对每层让利算两个数：全店均值口径下的贡献、最差 10% 订单口径下的贡献——两层口径必须并排给，只看均值每层都不高，因为差单是少数

判定标准：
- 我给你食材成本率【】%时：实收率低于（1 - 食材成本率）的订单，判「卖一单亏一单」，给单号清单
- 不给成本率时，只判「实收率异常低」，不许自行假设一个成本率往下算——每家成本结构差得远，假设错了整张亏损清单全错

输出格式：
- 扣减链总表：每一层 / 全店均值占比 / 最差 10% 订单占比——两层占比差距大的那层就是叠加的元凶
- 差单聚类表：叠加路径 / 单量 / 平均实收率 / 涉及的活动名
- 行动清单：按「差单中出现率」从高到低排，每层让利给三种处理及理由——关掉 / 提高参与门槛（改满减档位、限单品） / 与其他层设互斥——只描述规则改法，不预测改后单量与排名

限制：
- 不引用任何具体平台的规则名称与数字——各平台配置不同，规则以我后台实际配置为准
- 不预测关掉某个活动后单量、排名的变化——没人知道，编了就是误导
- 均值必须与最差 10% 并排出现，不许只报均值
- 订单数据里缺某层扣减信息的，该层标「无数据」，不许估
- 不要客套，直接从扣减链总表开始

为什么这样写

外卖亏损的第一根源不是卖得少，是叠加：折扣单品、满减、红包、补贴各设各的，设置时单看每一层都「划算」，叠在同一单上实收就被打穿。后台首页的原价营业额把这层全盖住了——所以第一件事是逐单沿扣减链还原，审计对象从「今天卖了多少钱」换成「这单到手多少钱」。链是固定的六层，因为各家平台叫法不同但结构同构，锚住结构才能跨平台用。

「均值必须与最差 10% 并排」是这份审计器最重要的一条规则。只报均值时每层让利的贡献都「不高」，差单是少数，被均值稀释掉了；把最差 10% 单独拎出来再算一遍每层贡献，元凶才现形。两层口径并排的读法也直接写在输出里：差距大的那层，就是在差单里反复出现的那层。

行动给三种处理而不是一个答案：关掉止损最快但伤单量，提门槛保留流量但配置复杂，互斥最精细但要试。要流量还是要利润，运营比模型清楚；模型的职责是把每层在差单里的出现率摆出来。所以预测改后单量被禁止——那不是分析，是编。

成本率必须由店家给，也是同样的道理：判「亏」的线是实收对比变动成本，自营厨房和预制料包差十几个点，模型自己假设一个，整张亏损清单的方向都可能反。

变量