外卖门店经营透视官（文件版）

把平台下载文件变成一条可审计的经营证据链：

文件清单 -> 数据覆盖 -> 平台内结果 -> 主链路 -> 具体订单/商品/评价/巡检对象 -> 证据等级 -> 动作

本 Skill 只处理文件。不要尝试寻找、配置或调用 MCP，也不要因为文件名相似就假定字段同义。

四项交付硬闸口

以下任一项不满足时，不得写“完整诊断”“根因已找到”或直接给经营动作：

平台独立闭环且结论全中文：美团、淘宝闪购、京东分别完成结果、同期、主链路、业务对象、证据等级和动作。跨平台只能并排概览，不能合并客单、转化率、补贴强度或原因。经营稿不得出现脚本字段名、代码状态或英文平台内部名。
异常完整下钻：达到阈值的营业收入、有效单、实收客单、曝光、转化、订单金额客单或结算到手率，必须继续读取当前文件中对应平台的订单、商品、评价、巡检/成长任务或专项报表，直到解释主要差额，或穷尽文件后写清“已确认层级 + 最小缺失文件/字段 + 下一步核查动作”。
范围语义优先于门店数量：单店、点名多店、省市区域和全局门店都使用同一条链路：数据边界 -> 范围结果 -> 门店贡献 -> 主链路 -> 业务对象 -> 证据等级 -> 动作或最小缺口。全局和明确省市区域先汇总范围，再将差额拆到门店；用户点名多家门店时，默认把每家店当成独立分析范围，分别跑完整链路，最后仅并排比较。不得仅因为出现多家门店就把它们合计分析；只有用户明确说“这些门店合计/作为一个整体”时才建立临时门店组。
默认只交付文字版：最终结果直接写在对话正文，内容较长时可以另附 .md Markdown 文件。不得主动生成或附带 HTML、网页、仪表盘、可视化站点或富媒体分析报告；不得为了“展示效果”把同一结论再转成 HTML。编译产生的 JSON 仅用于内部校验，不是运营交付物。只有用户在当前请求中明确指定 HTML 时，才允许改变格式。

文件入口

收到 ZIP、XLSX、CSV 或文件夹时，先读 references/file-contract.md。不要先打开单个表就写结论。

1. 盘点而不展开明细

使用捆绑的表格 Python 运行：

python3 scripts/inspect_report_files.py \
  --source meituan=<美团文件或目录> \
  --source eleme=<淘宝闪购文件或目录> \
  --source jd=<京东文件或目录> \
  --output <临时目录>/inventory.json

先确认：压缩包路径安全、文件可读、平台归属、报表类型、工作表、行列数、日期范围、空表和完全重复文件。文件名只用于候选分类；最终以列头、粒度和平台归属确认。

2. 标准化到独立临时目录

python3 scripts/normalize_report_files.py \
  --source meituan=<美团文件或目录> \
  --source eleme=<淘宝闪购文件或目录> \
  --source jd=<京东文件或目录> \
  --include store \
  --output-dir <新的临时目录>

先用门店日报定位目标门店或异常门店。选定平台门店 ID 后，再在新的目录运行完整标准化，并用 --store-filter meituan=<ID>、--store-filter eleme=<ID> 或 --store-filter jd=<ID> 只保留要下钻的门店；多个门店重复该参数。这样历史明细再大，也不需要把全品牌全部订单和商品一次载入分析上下文。

标准化输出保留来源文件、工作表、来源行、文件哈希和候选主键。相同候选键且标准化业务字段完全一致的重叠行会自动去重，并在 manifest.json 和保留行的 duplicate_sources 留审计记录；同键字段冲突仍保留为诊断阻塞项。空表、门店 ID 缺失和未知订单状态不得补值。用户明确要求全品牌逐店诊断时，仍先用门店日报全量扫描，再按异常门店分批标准化明细。

不要把标准化中间文件作为默认商用交付，也不要在报告中展示顾客名称、完整评价原文、地址或订单号。

3. 选择分析范围、平台、门店和目标日

先读 references/analysis-scopes.md，按语义而不是门店数量把请求标成以下一种范围：

single_store：一个明确门店；门店贡献层只确认该店就是范围差额对象。
named_stores：用户点名两家或以上门店；每家独立分析，最后并排比较，禁止生成点名门店合计业绩和统一根因。
regional_scope：用户关注某省、某市、大区或其它明确地域整体；先完成区域结果和区域内门店贡献分解。
all_stores：当前文件盘点出的全量门店；纳入数必须与各平台文件盘点门店数闭合，再定位异常门店。
store_group：仅当用户明确要求“这些店合计、作为一个整体”时使用，不得从一串门店名称自动推断。

路由优先级：出现“全部、全品牌、全国、所有门店、整体大盘”走 all_stores；出现明确省市/大区整体走 regional_scope；点名一家走 single_store；点名多家走 named_stores。只有明确的合计意图才能覆盖点名多店默认拆开规则。

范围不同不产生多套诊断方法。区域/全局只多做一次“范围差额 -> 门店贡献”的定位；点名多店则对每家分别复用单店主链路与明细下钻。

每个平台先从门店日报定位平台门店 ID；不能只用同名门店跨表或跨平台猜测身份。目标日默认取用户要求的截止日；用户未指定时，取门店日报中最新且覆盖完整的业务日。

生成两组比较输入：

python3 scripts/build_file_analysis_inputs.py \
  --normalized-dir <标准化目录> \
  --platform <meituan|taobao|jd> \
  --store-id <平台门店ID> \
  --target-date <YYYY-MM-DD> \
  --output-dir <新的分析目录>

只有平台口径或订单对账已经确认“优惠前总额/营业额”是结算前订单金额时，才增加 --confirm-settlement-candidate。不能仅凭列名自动确认。

4. 按准备状态路由

comparison_inputs_ready：分别运行 ledger_same_weekday_input.json 和 ledger_weekly_trend_input.json，再结合 14 天日序列判断时间形态。
single_day_or_partial_profile_only：只交付已提供日期的单日结构体检、文件可补能力和缺失日期清单；不能写趋势、持续性、同比原因或经营动作。
同日同门店多行、候选主键冲突或门店 ID 映射异常：先解决重叠导出、版本或粒度，不能直接求和。

当结构化输入齐全时运行：

python3 scripts/build_diagnostic_ledger.py --input <ledger_input.json> --output <ledger_output.json>

同一平台必须同时运行同星期比较和双周趋势。只运行其中一组不能形成最终原因结论。

两份账本完成后编译时间形态、营业状态和停业损失：

python3 scripts/compile_store_diagnosis.py \
  --readiness <分析目录>/readiness.json \
  --same-weekday <分析目录>/ledger_same_weekday_output.json \
  --weekly-trend <分析目录>/ledger_weekly_trend_output.json \
  --output <分析目录>/store_diagnosis.json

用户要求“单店昨天”时，额外读取 references/single-store-yesterday.md 确定昨天口径和目标日明细边界；它不能替代或改变统一分析链路。

任何范围的成稿都不得另写临时汇总脚本替代标准流水线。每家已纳入门店先生成上述平台分析目录。单店、省市区域、全局或用户明确要求合并的门店组使用 --analysis-dir；同一平台有多家门店时重复传入：

python3 scripts/compile_scope_report.py \
  --scope-type <single_store|regional_scope|all_stores|store_group> \
  --analysis-dir meituan=<美团分析目录> \
  --analysis-dir taobao=<淘宝闪购分析目录> \
  --analysis-dir jd=<京东分析目录> \
  --scope-display-name=<门店、门店组或全品牌展示名> \
  --output-dir=<新的报告目录>

点名多家门店时改用门店键绑定各平台目录，保证每家独立成稿：

python3 scripts/compile_scope_report.py \
  --scope-type named_stores \
  --store-analysis A店:meituan=<A店美团分析目录> \
  --store-analysis A店:taobao=<A店淘宝闪购分析目录> \
  --store-analysis B店:meituan=<B店美团分析目录> \
  --store-analysis B店:jd=<B店京东分析目录> \
  --scope-display-name="A店和B店" \
  --output-dir=<新的报告目录>

all_stores 还必须按平台传入盘点门店数，例如 --expected-store-count meituan=80；编译器发现纳入门店数不闭合时必须停止。named_stores 顶层一旦出现合计平台结果，发布校验必须失败。单店旧编译器只保留向后兼容，不再作为新报告的正式入口。

发布前必须运行：

python3 scripts/validate_scope_report.py \
  --report-json <报告目录>/scope_report.json \
  --report-markdown <报告目录>/scope_report.md \
  --output <报告目录>/validation.json

只有 publish_allowed=true 才能交付报告。校验器失败时回到数据边界、口径或下钻证据，不得绕过。

最终只交付校验后的对话文字或 scope_report.md。不要交付内部 JSON，也不要继续调用网页、前端、Dashboard、HTML 生成或托管工具。

诊断边界

具体门店默认读取目标日 D 往前连续 14 个自然日：

主对比：D vs D-7
趋势对比：D-6…D vs D-13…D-7

完整日期、缺失日、聚合和输出规则见 references/time-comparison.md。

文件覆盖按“平台 × 门店 × 日期 × 数据对象”分别判断：

门店日报缺失某日：不补 0，不用相邻日替代。
订单/商品/评价只有单日：可以解释当日结构，不能解释 14 天趋势。
同一对象混入多个导出版本：先按文件哈希、导出时间和候选主键判断；冲突未解决前不聚合。
京东订单文件没有订单状态时，不把全部订单行当有效订单；京东缺评价和巡检文件时只写能力缺口。

从结果层选择主问题

先在当前经营范围计算商家实收、有效订单和商家实收客单。省市区域、全局或明确合并门店组必须把商家实收差额完整分解到门店，区分同向缺口门店和反向抵消门店；贡献合计必须回到范围差额。点名多店不建立合计范围，每家分别执行下面的结果拆解与主链路，完成后才做门店间比较。单店把门店贡献记录为恒等层。

先检查门店营业状态。目标日无营业、周期内部分停业、无效门店或异常关店时，优先进入营业供给分支，不解释低分母下的进店率和下单率。

营业状态可比时再计算：

实收 = 有效单 × 实收客单
有效单影响 =（本期有效单 - 对比期有效单）× 对比期实收客单
客单影响 = 本期有效单 ×（本期实收客单 - 对比期实收客单）

两项之和必须回到实收变化；回不去时保留未解释差额并检查门店范围、退款、四舍五入和有效单口径。

有效单影响更大：进入 曝光 -> 进店转化率 -> 下单转化率。
客单影响更大：进入 结算前订单金额客单 -> 结算到手率。
两项都异常：影响更大者为主问题，另一项单独建次问题。
结果稳定：只做结果总结，不为完整性强行罗列模块。
有效单为 0 时，实收客单“不适用”，不是缺失也不是 0；结果与停业损失仍可判断，但不得计算单均经济、客单链路或低分母漏斗。

涉及字段映射、计算和阈值时读 references/metrics-and-ledger.md。

异常下钻

读取 references/branch-playbooks.md 中命中的分支，不一次展开所有模块：

价格带、活动、渠道、客群、取消、退款、履约：读 references/order-diagnostics.md。
商品贡献、菜单、价格、售罄、商品漏斗：读 references/product-diagnostics.md。
评分、差评、回复、申诉、服务主题：读 references/review-diagnostics.md。

订单与商品分支已有完整 14 天且有效单规则明确时，可运行：

python3 scripts/build_detail_diagnostics.py --input <detail_input.json> --output <detail_output.json>

订单、活动、渠道、客群和商品是重叠视角。不同视角的贡献不能相加；商品“带来订单数”也不能跨商品求和当门店订单数。

证据等级与停止条件

落点：差额集中在某渠道、活动、商品、价格带或履约对象；不能写“导致”。
候选原因：方向和时间吻合，但缺配置、动作台账或对照。
已验证原因：业务对象、链路指标和结果差额同对象闭合，且两组同期与 14 天时间形态支持。
动作就绪：已验证原因，并且动作对象、成本风险和影响范围明确。

停止条件只有两个：找到能解释主要差额的已验证对象；或订单、商品、评价、巡店/成长任务和当前专项文件都已按命中分支检查，仍只能给出已证明层级、最小文件缺口和一个具体核查动作。

编译输出

成稿前读 references/reporting.md。单店、省市区域和全局整体固定采用：

数据边界 -> 范围结果概览 -> 门店贡献定位 -> 分平台诊断 -> 动作与最小缺口

多平台按“美团 → 淘宝闪购 → 京东”组织，每个平台分别写：

数据边界 -> 结果 -> 两组同期与14天形态 -> 主链路 -> 具体业务对象 -> 证据等级 -> 动作或最小缺口

全文使用中文业务名称。技术字段映射只能放在独立附录；普通运营稿不展示脚本名、JSON 字段、文件哈希或候选键。没有完整 14 天时，标题必须写“单日结构体检”或“文件数据盘点”，不能写“深度经营诊断”。