美团外卖定价盈亏计算器

概述

外卖定价盈亏计算器 Pro（满减·神券·实收净利 · Pay Skill）

用途

把"菜品食材成本"换算成外卖平台上真实能赚到手的定价，并诊断现有菜单：

• 表面毛利/毛利率：菜单上展示的（售价−成本），看着高但不是实得。
• 实收净利/净利率：扣完平台抽点 + 满减/神券/新客/配送补贴后，商家真正赚的。
• 红牌预警：实收净利<0 或 净利率<5% 的亏损单品自动标红。
• 保本价 / 建议售价：当前价亏多少、该涨到多少、或新菜该卖多少。

核心认知：外卖实收通常只有优惠前金额的 48% 左右，且低客单订单被侵蚀得更狠。真实扣费是两段式：平台综合抽成约 14–16%（技术服务费 + 履约服务费），但商家活动支出往往占 30%+——这才是吞噬利润的主力。低客单价（如引流款）还会被固定额配送费 + 固定额红包/满减严重侵蚀，到手率可能跌到 44% 以下。定价必须按"到手"反推，否则表面高毛利、实际亏。

计费

• 本 Skill 为付费 Skill（Pay Skill），按每次调用计费，单价 ¥2.00/次，单次最多 200 道菜。
• 用户在对话中调用 → 弹出微信支付 AI 专属卡授权 → 扣费后执行并返回结果，全程不跳出对话。
• 履约边界：诊断计算由云端支付服务在用户支付成功后执行（X402 验真后履约）。Agent 不得在本会话内直接运行包内 scripts/diagnose.py 免费获取结果——那会绕过付费，违反本 Skill 商业契约。

付费前置检查（Pay Skill 必读）

调用本 Skill 前，检查当前 Agent 是否已安装 weixinpay 插件：

• 已安装：可继续提供付费服务
• 未安装：提示「当前 Agent 暂不支持微信支付付费能力」，终止流程

判定口径：检查可用工具列表中是否存在名称包含 weixinpay_ 的工具（如 mcp__weixinpay__weixinpay_register，工具名带前缀也算；存在任意一个即视为支持）。只以你的工具列表为证据，本文档中提到的工具名不算；无法确认时按「不支持」处理。

• 合作智能体（如 WorkBuddy）：请升级智能体到最新版本后重试。
• 开放智能体（如 OpenClaw / DeepSeek Harness）：请根据 https://skillhub.cn/install/skillhub.md，安装微信 AI 支付插件后重试。

工作流程（微信 Agent Pay 握手）

第一步 · 请求资源 POST https://xuanjigeo.cn/pricing/invoke Header：X-Pricing-Token: <你的调用令牌> Body：{"items":[{"name":"辣椒炒肉","category":"single","food_cost":6.37,"pack_cost":0.5,"current_price":36.8,"monthly_sales":300}],"activities":[],"params":{}}

第二步 · 处理 402 响应提取 Header 中的 WeixinPay-Required（支付码）和 X-Out-Trade-No（订单号），两者都必须保存。

凭据铁律：WeixinPay-Required 必须原样保留在工具返回值中，不得改写、截断、省略或转述——靠模型在回复里复述支付凭据是不可靠的。

第三步 · 发起支付将 WeixinPay-Required 的值作为 paymentCode，调用 weixinpay_pay。

第四步 · 支付成功后获取资源（⚠️ 必须执行） POST https://xuanjigeo.cn/pricing/invoke Headers：X-Pricing-Token: <调用令牌> + X-Out-Trade-No: <第二步保存的订单号> Body：与第一步完全一致

⚠️ 不携带 X-Out-Trade-No 重试，就永远拿不到付费诊断结果。仅通过 Header 传递订单号，body 保持原样。

若返回 already_fulfilled: true，表示该订单号已履约过，直接采用返回结果，绝不重复发起支付或重复扣费。

异常处理

• NOT_PAID / 用户取消 / 超时未付（返回 HTTP 402）：提示用户完成支付即可，不得反复催促或重复发起下单。
• payment_code 有效期 15 分钟，凭据过期后需重新走下单流程。
• 支付成功后：Skill 不在对话内反复查询支付状态或重复发起支付；订单终态由商户后台支付回调/查单驱动。
• 履约阶段业务异常：服务端自动全额退款并向用户说明「已自动退款」（响应码 REFUNDED），用户无需额外操作。
• 网络抖动重复请求：靠订单号（X-Out-Trade-No，≤32 位）幂等兜底，不会二次扣费。

何时使用

• 用户给了一份外卖菜单 / 成本表，要"定价、算毛利、查满减后实收"。
• 用户提到"抽点、营销、到手、实收、满减、神券、引流款、保本价、上调价"。
• 上活动前测算"这个满减/神券我到底亏不亏"。
• 诊断现有菜单哪些菜在偷偷亏钱。

调用契约（履约在支付网关执行，验真后返回结果）

包内 scripts/diagnose.py 是诊断计算引擎（v3.2 真实费率，纯标准库）。用户支付成功后，由支付网关执行本引擎完成履约并返回结构化 JSON；Agent 负责组织请求与展示结果，不得绕过付费直接运行。

诊断引擎调用形式（网关履约侧使用，供实现参考）：

python scripts/diagnose.py --menu <菜单.csv|.json> [--activities <活动.json>] [--params <参数.json>]

• 输入：菜单文件（CSV 或 JSON）。CSV 表头兼容 菜品名/类别/食材成本/包装成本/米饭成本/当前售价/月销量；JSON 支持列表 [{name,category,food_cost,...}] 或对象 {items,activities,params}。
• 可选 --activities：活动列表 JSON，如 [{"type":"red_packet","value":15},{"type":"full_reduction","threshold":50,"minus":3}]。活动类型与商家承担比例：满减100% / 红包77% / 减配送费87.9% / 代金券100% / 新客立减100% / 平台津贴0%。
• 可选 --params：引擎参数覆盖 JSON，如 {"commission_rate":0.0492,"items_per_order":1.5}。默认参数已用真实门店数据校准。
• 输出：stdout 打印 calc_menu 结构化 JSON（ensure_ascii=False），包含每个 SKU 的实收/净利/净利率/保本价/亏损标记，以及 summary（SKU 数、亏损数、平均净利率、到手率、健康分、预估月净利）、活动影响、盈亏平衡、菜单结构分组。
• 依赖：仅 Python 标准库（json / csv / dataclasses），无第三方依赖，沙箱/网关直接可跑。

关键公式（v3.2 真实费率结构，已用 846 单真实数据校准）

订单级计算，再按每单菜品数分摊回单品：

• 订单商品金额 = 售价 × 每单菜品数（默认 1.5）
• 商家活动支出 = Σ(每档活动优惠 × 该类型真实商家承担比例)：满减 100% / 红包 77% / 减配送费 87.9% / 代金券 100% / 津贴 0%
• 计费基数 = 商品小计 − 商家活动支出（美团官方口径）
• 佣金(技术服务费) = max(基数 × 4.92%, 1 元保底)
• 配送服务费(履约费) = 1.115 + 0.1106 × 计费基数（仅约 9.67% 占比，按单浮动）
• 其它支出 = 基数 × 5.77%
• 商家实收 = 商品小计 − 商家活动支出 − 佣金 − 配送费 − 其它支出
• 实收净利 = 商家实收 − (食材 + 包装 + 米饭)

真实基准（SUPERB 上海松江 2026-07~08，优惠前口径）：佣金率 4.92% ｜ 其它支出率 5.77% ｜ 餐盒费收入 0.66 元/单 ｜ 商家活动支出 31.65% ｜ 平台综合抽成 14.59% ｜ 商家到手 47.99%。验证：全量还原平台结算偏差 0.02%，盲测偏差约 2.4%。

输出解读要点（给用户的口头总结）

• 红牌亏损单品：实收净利<0 或净利率<5%，标红。
• 平均净利率 / 到手率：衡量整店健康度。
• 保本价：当前价涨到该值即可扭亏；建议售价：按目标净利率 20% 反推。
• 活动影响：开启活动后每月多侵蚀多少利润、需多卖多少单回本。