外卖自动化三大流程业务逻辑总览

覆盖外卖日报更新、门店营业状态检查、商品异常检查。以下内容按当前本地脚本和定时任务整理,运行时不依赖影刀/ShadowBot。

先看这里:业务负责人确认清单

这些点最容易导致“系统没错,但业务口径错了”。建议业务负责人逐条确认。

Review First
1. 日报日期范围是否固定为 5 天? 当前规则:结束日期=昨天,开始日期=昨天往前 4 天。请确认是否所有平台、所有报表都按这个日期口径。
2. 日报是否必须 14 份齐全才继续? 当前规则:数据下载包必须刚好 14 份有效报表,否则不分发、不刷新、不上传。请确认是否允许缺某个平台时先上传其他平台。
3. 营业状态里“饿了么已打烊”是否算正常? 当前脚本把饿了么“已打烊”也视为正常状态。这个是关键业务口径,需要明确是否只在某些时段正常。
4. 营业状态是否只反馈异常门店? 当前逻辑:正常门店不写飞书,只有异常门店才上传。请确认是否需要每天保留全量门店状态快照。
5. 菜品“已下架/已售罄”是否全部算异常? 当前逻辑:只要进入已下架或已售罄列表,就生成异常记录。若存在允许下架、允许售罄、季节性停卖,需要建立白名单。
6. 商品异常是否允许每天重复记录? 当前商品异常上传是创建记录,不按唯一键去重。若同一菜品上午和下午都异常,会形成两条检查记录。请确认这是否符合追踪需求。
7. 京东商品异常是否接受“全部门店”口径? 当前京东商品异常按“全部门店”检查,不逐店输出。若业务需要定位到具体京东门店,需要进一步拆分口径。
8. 美团可检查门店数以页面可见为准 当前美团会发现页面下拉里的门店,并与配置门店取交集。若某店不在页面下拉中,不会强行反馈,避免误报。
建议审核方式:业务负责人先确认上面 8 个口径,再看下面三个流程图。只要这些标准没问题,自动化反馈的结果才有业务意义。

一、外卖日报更新流程

每天 08:00 执行,从四个平台下载 14 份报表,清洗合并后上传飞书多维表。

automation-2 · 08:00

业务目标

替代影刀日报链路,实现“下载报表 -> 验空 -> 分发 -> 清洗合并 -> 刷新 Excel -> 飞书同步 -> 清理源文件”。

日期规则

结束日期为昨天,开始日期为昨天往前 4 天,共连续 5 天。也可通过 WAIMAI_START / WAIMAI_END 临时覆盖。

完整性门槛

数据下载包 必须刚好 14 份已验证非空报表;不齐、多出、空表、HTML 登录页都会失败停止。

执行脚本

pipeline\run_daily_pipeline.ps1

1. 前置清理清空日数据存档处旧临时文件;数据下载包旧文件移入本次日志备份。
2. 打开 Chrome/CDP复制并复用 Chrome 登录态,启动 9222 调试端口。
3. 下载 14 份报表饿了么 5、京东 4、美团 4、小匠人 1。
4. 验空与完整性Excel/CSV 逐文件校验;只有有效文件进入数据下载包。
5. 分发与标准化按平台/栏目分发到日数据存档处,补齐 workbook 所需字段。
6. 刷新并上传刷新日更 workbook,调用飞书 API 同步 6 张日更表。
平台报表关键业务规则
饿了么 / 淘宝闪购门店下载、订单下载、商品下载、评价下载、商家成长进入数据下载/报表下载;设置 5 天日期;全选字段;下载管理中取文件;空表最多重试 3 次。
京东到家 / 京东秒送门店、订单、商品、订单评价门店/订单/商品需要生成后去下载列表二次点击下载;订单评价走旧版评价管理,选择订单评价,导出后直接下载。
美团外卖门店、订单、商品、评价设置日期、全选字段、下载数据;弹窗点击前往下载;下载列表刷新到“下载”后取文件。
小匠人 / 渠道成本分析渠道成本分析确认左侧为 6.14 渠道成本分析,设置同一日期范围,直接导出。

飞书同步逻辑

  • 刷新 外卖数据日更表(日).xlsx
  • 调用 upload_excel_new.py
  • 唯一键 新增/更新。
  • 当前日报配置 cover=false,正常日更不删除历史记录。

成功后清理

  • 飞书上传成功后,清空本次分发进日数据存档处的源文件。
  • Chrome 成功时关闭;失败时保留浏览器用于人工排查。
  • 日志写入 out\pipeline_时间戳

需要业务确认的日报口径

  • 5 天日期范围是否始终适用于所有报表。
  • 14 份报表是否是硬门槛,缺一份是否必须整流程失败。
  • 飞书日报按唯一键新增/更新,不删除历史旧记录,这是否符合数据治理要求。
  • 成功上传后删除日数据存档处本次源文件,是否满足审计留痕要求。

二、门店营业状态检查流程

一天多次检查三大平台门店营业状态,发现异常门店后截图并写入飞书。

10:40 / 15:00 / 17:00 / 21:20

业务目标

发现门店未按预期营业、休息、暂停、下线等状态,形成飞书异常记录,方便运营追踪。

执行脚本

pipeline\run_store_status_check.ps1
run_store_status_check.mjs

输出位置

out\store_status\run_时间戳\summary.json 和异常截图。

飞书脚本

upload_shop_status.py

1. 启动登录态浏览器复用 Chrome 资料目录和 9222 CDP。
2. 打开平台页面美团门店管理、京东门店设置、饿了么品牌账号页面。
3. 关闭安全弹窗只点关闭、我知道了、取消、以后再说等无风险按钮。
4. 读取门店状态抓取门店名、状态、所在页信息;京东支持翻页读取。
5. 判定异常非正常状态生成异常;异常门店截图。
6. 飞书写入异常门店、状态、检查时间、截图上传到多维表。
平台读取方式当前正常判定
美团进入门店管理,状态筛选置为全部并查询,解析门店列表。营业中正常营业
京东进入门店设置列表,读取表格营业状态,自动翻页。营业中正常营业
饿了么打开门店切换器,从门店列表解析门店名称和状态。营业中正常营业;脚本当前也把饿了么 已打烊 视为正常状态。
如果出现登录过期、验证码、滑块、人机验证、短信验证、安全授权或无法判断的弹窗,流程停止并报告截图路径,不自动绕过。

需要业务确认的营业状态口径

  • 美团、京东只有 营业中 / 正常营业 视为正常,是否足够。
  • 饿了么 已打烊 当前视为正常,是否应按检查时段区分。
  • 是否需要飞书记录全量门店状态,还是只记录异常门店。
  • 检查时点 10:40、15:00、17:00、21:20 是否覆盖业务需要。

三、菜品异常检查流程

每天两次检查商品“已下架”和“已售罄”,记录异常菜品、截图并上传飞书。

10:32 / 17:01

业务目标

替代影刀商品异常检查,发现各平台门店中不该下架或售罄的菜品,形成飞书问题记录。

执行脚本

pipeline\run_product_abnormal_check.ps1
run_product_abnormal_check.mjs

配置来源

product_abnormal_config.json 维护平台 URL、登录前缀和门店清单。

飞书脚本

upload_bad_product.py

1. 打开平台美团、京东、饿了么,复用登录态。
2. 切换门店美团/饿了么按门店逐家切换;京东按全部门店检查。
3. 进入商品列表进入商品管理里的商品列表或商家商品管理。
4. 检查已下架点击已下架,收集菜品名,逐项截图。
5. 检查已售罄点击已售罄,收集菜品名,逐项截图。
6. 上传飞书平台、门店、问题概述、问题类型、截图写入多维表。
平台检查范围关键细节
美团当前可发现的美团门店;配置门店与页面门店交集。切店后校验当前门店名;菜品名优先读取商品卡片 title / input value,避免把“单点不送”等标签当菜名。
京东全部门店。进入商家商品管理,抓取已下架商品;京东当前不逐店切换。
饿了么配置中的 18 家门店。必须先从连锁总账号切到具体门店,再进入 商品管理 -> 商品列表;不能停在菜单模板或连锁商品库。

记录内容

  • 平台:美团 / 京东 / 饿了么。
  • 门店名称。
  • 检查时间。
  • 问题概述:菜品名 + 下架/售罄。
  • 问题类型:商品上下架异常。
  • 异常截图。

验证结果口径

  • 每个平台生成 summary.json
  • 记录每个门店的下架数、售罄数和上传结果。
  • 任一门店检查失败或上传失败,平台状态为 partial_failed
  • 成功后 Chrome 自动关闭;失败时保留现场。

需要业务确认的菜品异常口径

  • 所有 已下架已售罄 是否都算异常。
  • 是否需要白名单:例如季节性菜品、临时停售、只套餐售卖、门店主动售罄。
  • 同一菜品上午、下午重复异常是否要重复写入,还是只保留最新状态。
  • 京东当前是全部门店口径,不逐店拆分,是否可接受。
  • 美团门店数以页面实际可发现门店为准,缺失门店是否需要单独告警。

四、三套流程共用规则

这些是跨流程的稳定性、风控、日志和人工介入规则。

Common Rules
浏览器策略使用 Chrome 复制资料目录 + CDP 端口;不依赖影刀运行环境。
弹窗策略只关闭明确安全的公告、活动、引导、通知类弹窗。
人工介入验证码、滑块、短信、安全授权、登录失败、无法判断弹窗,停止并截图报告。
日志位置所有运行日志、summary、截图都写在 workspace 的 out 目录,不再堆桌面截图。
飞书方式通过本地 Python API 脚本写入飞书多维表,不走浏览器 UI 手工上传。
收尾成功关闭浏览器;失败保留浏览器现场,方便截图和人工继续。
流程定时任务主命令成功标志
外卖日报更新每天 08:00powershell -File .\pipeline\run_daily_pipeline.ps114 份报表齐全,workbook 刷新成功,飞书上传成功,临时源文件清理完成。
营业状态检查10:40、15:00、17:00、21:20powershell -File .\pipeline\run_store_status_check.ps1三平台门店状态读取成功,异常门店截图和飞书写入成功。
菜品异常检查10:32、17:01powershell -File .\pipeline\run_product_abnormal_check.ps1三平台商品异常读取成功,异常菜品截图和飞书写入成功。
当前三套流程的定位:下载/检查由 Codex 本地脚本执行,结果通过本机现有飞书 API 脚本写入多维表;影刀只作为历史参考,不作为运行依赖。