初始发布: 21 个 skills (Claude Code / Codex / DSH)

2026-08-14 01:51:44 +08:00
commit ea0857bedb
129 changed files with 35566 additions and 0 deletions
@@ -0,0 +1,69 @@
+# 营收 / 出品分析打法（5月固化）
+
+## 三类分析 + 对应脚本
+
+| 用户诉求 | 脚本 | 产出 |
+|---|---|---|
+| N月营收分析（无预制表时） | `build_analysis.py <目录> <YYYY-MM>` | 营收分析xlsx(13 sheets) + `_analysis_summary.json` |
+| 各部门收入起伏根因（MoM） | `dept_deepdive.py <本月目录> <上月目录>` | `_deepdive_<部门>.json`（总览/二级分类/班次/SKU涨跌含分类验真）|
+| 菜单/出品 卖最差 | `menu_onsale_ranking.py <月度目录>` | 各部门在架SKU升序榜 |
+
+`_analysis_summary.json` 的 `employees` 字段 = 12(13)人 (部门业绩/班次业绩/部门×班次业绩) 三元组，直接写 V2 cols 19/20/21。
+
+## 🔴 必守口径（5月踩坑总结）
+
+1. **统一分类器重算两月**：做 MoM 对比时，4月也要用同一分类器重算，**不要拿4月预制xlsx对比5月自算**（分类器漂移会造出假象，如"西湖咖啡-21%"实为持平）。`dept_deepdive.py` 已对两月用同一分类器。
+
+2. **幽灵汇总行**：POS「订单明细」末尾有一行 `订单来源/订单号/营业日期 全='--'` 的汇总行，金额=所有真实行之和，会让订单级字段翻倍2x。必须 `if str(订单号).strip()=='--': continue`（build_analysis 已修）。
+
+3. **dish级 vs 订单级**：部门收入用「菜品明细」逐菜累加 `菜品收入（元）`（dish级）；订单级列受联台重复污染，勿用。
+
+4. **酒头/畅饮票=精酿**：`1-10酒头3小时畅饮票` 等"酒头/畅饮"SKU 是扎啤生啤，归精酿（非调酒）。
+
+5. **部门×班次交叉**：营收xlsx不自带，需 build_analysis 用菜品名匹配（≈95%）+ 按部门合计比例校正。滨江厨房团队(刘/叶/尹)班次=0、中班=0、前厅部门=0。
+
+6. **菜单"在架"口径**：菜品库导出**无「售卖状态」字段**（在售/下架混在一起）。用"当月有售(≥1件)"作在架代理 → 下架季节菜自动排除。代价：漏掉"在架但真没人点"的极少数款。要100%精确需用户重导菜品库勾「售卖状态=售卖中」。
+   - 5月实测：西湖菜品库100款厨房菜→仅45在售；滨江138→45。**菜单严重冗余，大量下架菜没从系统清理**。
+
+## 🟢 质量要求：跑完必做对抗式复核
+
+每次营收分析跑完，**用 Workflow 起多个 agent 独立重算 + 对抗验证**（部门POS/班次/团购/交叉/环比 各一路）。5月正是靠这个抓出 2 个真bug（幽灵行翻倍、酒头误归）。验真手法：每个涨跌SKU比对 `cat_apr` vs `cat_may`，一致=真实业务变化，不一致=重归类伪变动需剔除（`cat='-'` 表示该月无此SKU=新上/下架，属真实，非伪变动）。
+
+## 输出去向
+
+- 营收分析 13 sheets：总览/部门收入/团购→部门归口/班次营收/部门x班次/品类(一级,二级)/每日营收×2/支付方式/12员工业绩/深度分析/改进建议/部门起伏根因
+- 出品分析：可加 sheet「西湖/滨江 餐食卖最差(在架)」「出品优化建议(该砍清单)」
+- 报告 md：`大梦N月各部门营收起伏深度报告.md`、`大梦N月_菜单精简与出品优化建议.md`
+
+## 已知业务结论（5月，供下月对比基线）
+
+- 双店本质夜间酒馆：晚班占 81-85%，20-23点占 57-61% 营收。
+- 西湖=精酿+调酒双驱动酒吧店；滨江=精酿单极社区店。
+- 白班餐食弱：西湖周末/节假日强(3.3x工作日)、滨江平(1.9x)、工作日白天日均仅¥160-190。
+- 会员质量：西湖健康(会员客单>非会员)；滨江会员"次卡化"(纯咖啡会员单17%→33%，客单跌破非会员)。
+- 断货可恢复≈¥13.9k/月（健力士黑啤两店同步断供最易救）。
+
+---
+
+## 🆕 伪菜品库法（6月起·解决新品归类）
+
+**问题**：菜品库是某个月导出的静态快照，次月新上的 SKU（尤其精酿新酒款）不在库中 → 落到 `dept_by_name` 关键词兜底 → 归类不可靠。手敲关键词还有宽词误伤风险（"菜"/"面"/"饭"）。
+
+**解法**：用当月「菜品销售明细」导出反推菜品库。该文件 sheet「已销售」**表头在第 3 行**，含字段：
+`出品部门 | 营业日期 | 菜品名称 | 菜品大类 | 菜品小类 | 订单编号 | 销售数量 | 销售额 | 菜品优惠 | 菜品收入 | ...`
+
+取 `菜品名称 → 菜品大类/菜品小类`，同名多类时取出现次数最多的那组，输出成 `菜品编码（SPUID） | 菜品名称 | 基础分类` 三列即可被 `load_menu()` 读取。
+
+**注意**：
+- 同名多类是正常现象（如"深烘拿铁"既有 `咖啡/经典` 也有 `经典咖啡`），取众数即可，6月滨江有 11 个这类 SKU。
+- 大类值会随店而异：滨江有 `肉肉肉/无咖无醇/瓶罐精酿`，西湖有 `软饮/brunch轻食简餐/纯饮`，`dept_of_category()` 里两店分支已覆盖。
+- `美团团购套餐` 类 SKU 在 POS 侧**菜品收入为 0**（核销记 0、钱在平台侧归口），`is_teamgou_shell()` 会跳过，不会重复。
+
+## 🔍 团购/收银重复性审查（每月建议做一次）
+
+老板会问"班次业绩是不是把团购和收银的重复算了"。审查三步：
+1. **支付方式汇总**（店内订单明细→支付明细 sheet）：确认支付方式列表里**没有**"美团团购券"之类的平台支付方式。6月滨江只有 微信/支付宝/会员卡/代金券/现金。
+2. **壳单实付**：含 `美团团购套餐` 大类 SKU 的订单，其全渠道「顾客实付」应为 **0**（6月实测 3 笔全 0）→ 只算了平台一边 ✓
+3. **代金券**：POS 侧计入顾客实付，平台归口时 `teamgou_dept_split()` 返回 None 明确跳过 → 只算了收银一边 ✓
+
+**易误判**：会有一批订单「菜品收入=0 但有实付」（6月滨江 86 笔 5,455.60）——那是 **「会员卡-卡余额消费」**（储值卡买单，POS 记全额优惠、钱走卡余额），**与团购无关**。5月同样机制（21,667/207笔），环比可比，不要当成 bug。