Work for YILI

Appearance

2026-09-04 工作日志 ​

总裁办创新元活动 FED 学习通知 ​

  • 来源：总裁办
  • 主题摘要：聚焦"高品质的产品体验、有温度的服务体验、能共鸣的情感体验"三大体验提升，总裁办开展创新元活动，专题制作了 FED 学习专题（学习时长 64 分钟），请全员 9 月 21 日前完成学习。

小结 ​

一、活动背景与目标

  • 三大体验导向：围绕产品体验、服务体验、情感体验三条主线，集中提升全员的"体验"意识与能力。
  • 总裁办主导：以创新元活动为载体，推出体系化学习专题，作为后续业务牵引和考核的依据之一。

二、学习安排

待办 ​

  • 9 月 21 日前完成《创新元 · 三大体验提升》FED 学习专题，并记录完成时间与积分。 — @语霖

液奶物码早会（元宝会议助手实时转写·09:09 起） ​

  • 发言人：李亚洲（主持）、邢健、余建新、刘晓娜（晓娜）、陈思、建新（待确认全名）、"小智晓娜"（产品/人名不清，原文如此）
  • 主题摘要：围绕本周项目计划更新与门店积分周末发布、9/10 月发版节奏合并、智慧门店告警治理与数据监控、以及高德解析服务故障复盘等事项进行对齐；多项动作要求本周内给出更新与责任闭环。

小结 ​

一、项目计划与发版节奏

  • 本周计划更新：李亚洲要求团队 周五前（即 9.4 当日内）更新项目计划，重点调整门店积分计划，并敲定周末整体发布节奏。
  • 发版合并评估：安排专人重点评估 9、10 月发版计划，目标减少发版次数；评估完成后在群内同步结论（成员指定尚未明确）。

二、智慧门店与数据治理

  • 店主告警处理：邢健同步智慧门店整体推进正常，但店主告警需安排资源排查；"小智晓娜"正在分析告警并计划输出接口改造排期。
  • 数据监控进度：李亚洲与余建新、刘晓娜对齐进度，确认部分问题已解决；李亚洲同时跟进最新数据监控内容是否由"建新"（待确认全名）填写。
  • 历史数据兜底：国外经纬度异常定位为智慧门店未校验距离所致，系历史遗留边界数据问题，仍需人工兜底排查。

三、外部依赖与旧接口下线

  • 内部人员接口：陈思指出该接口排期因供应商工作量评估受阻，预计延至 9 月 9 日；李亚洲要求及时更新计划，避免供应商节奏反向拖累整体排期。
  • 营销活动中心：邢健汇报已完成方案评审，今日将确认排期并下线旧接口。

四、第三方服务故障复盘

  • 高德解析服务失败（昨日）：李亚洲要求刘晓娜排查数据并评估影响范围，承诺稍后给具体故障恢复时间——当前卡点在缺精确时间节点，先以影响面排查为先。

待办 ​

  • 周五前更新项目计划，重点调整门店积分计划并敲定周末整体发布。 — @门店积分计划对接人
  • 评估 9、10 月发版合并方案，完成后群内同步。 — @（待指派专人）
  • 智慧门店店主告警分析，输出接口改造排期。 — @（小智）晓娜
  • 更新内部人员接口排期（受供应商评估影响），预计 9.9 给出新节点。 — @陈思
  • 营销活动中心今日内确认排期并下线旧接口。 — @邢健
  • 跟进数据监控最新内容填写与更新。 — @建新（待确认全名）
  • 排查高德解析服务失败的影响范围并给出恢复时间。 — @刘晓娜
  • 排查国外经纬度异常（智慧门店未校验距离，历史遗留边界数据）。 — @刘晓娜 / 智慧门店团队

冷饮事业部活动测试用例评审 ​

  • 发言人：苏一尊、郑然然、李明非、赵化龙、王珍瑜等 9 人
  • 主题摘要：本次评审围绕冷饮事业部活动测试用例展开，明确了模板配置、激励规则、活动限制及跨端集成逻辑，并针对叠加奖品、概率测算及活动限制组合场景的测试用例提出了补充与重构要求。

小结 ​

一、活动模板与基础配置

1. 事业部与活动层级确认

  • 事业部配置确认：通用模板中事业部字段需明确选择为冷饮事业部，后续总部、区域等配置需根据实际业务需求进行选择。
  • 活动层级与优先级确认：当前活动层级在活动创建环节配置，系统未做特定限制，但需向业务方明确活动层级与中奖优先级直接相关，需确认冷饮业务实际使用的层级范围。

2. 核心触发规则配置

  • 触发对象与级别：操作人员限定为店长和店员，误码级别统一配置为 1 级，且需包含内码营销状态为已激活的条件。
  • TPM 编码属性：冷饮事业部活动的 TPM 编码未与系统打通，仅作为活动标识的文本字段，业务方可直接填写。

二、激励规则与奖品发放

1. 特殊激励与普通激励逻辑

  • 优先级判定：系统优先判断是否满足"周期内第 N 次扫码"的特殊激励条件，满足则发放特殊激励；不满足时才触发普通激励。
  • 特殊激励叠加机制：特殊激励（如周期内第 N 次扫码）支持配置叠加奖品，需先中主奖品（如现金红包）后才能触发叠加奖品的发放。

2. 叠加奖品功能限制

  • 普通激励不支持叠加：当前需求仅特殊激励支持叠加奖品，普通激励无此需求，需通过前端逻辑控制普通激励不展示叠加配置按钮。
  • 冷饮事业部功能隔离：为避免数科在配置模板时误配，开发需在代码中增加事业部判断逻辑，隐藏冷饮事业部的普通激励叠加入口。

3. 中奖概率与金额计算

  • 概率独立配置：特殊激励与普通激励的中奖概率相互独立，系统仅限制单条规则概率不超过 100%，不强制要求总和为 100%。
  • 概率交叉验证：测试需覆盖非 100% 概率场景，验证当主奖品与叠加奖品概率均小于 100% 时，整体中奖概率是否为两者相乘关系。

三、活动限制与预警机制

1. 门店维度限制规则

  • 扫码次数与金额限制：活动限制支持按门店维度控制单日/单期扫码中奖次数，以及控制全体门店的单日发放总金额上限。
  • 限制条件组合校验：多条限制条件之间无优先级，系统会依次校验，只要有一条不满足即停止发放激励；测试需补充多条件组合及互斥场景。

2. 预警与预算控制

  • 预算与码量控制：活动需同时控制预算总金额与活动码量，任一达到上限即停止发放。
  • 预警机制：系统支持日程预警与已发放金额预警，需补充验证预警时间不能大于活动开始时间等异常场景。

四、跨端集成与钱包展示

1. 智慧门店与计费集成

  • 防作弊接口调用：开箱扫码流程中，智慧门店仅调用防作弊接口，随后拼接 URL 跳转至计费 H5 页面。
  • 钱包明细展示：计费 H5 页面需展示激励明细，包括激励类型（如开箱激励）和金额流水，需验证多笔红包的汇总与展示兼容性。

2. 提现功能验证

  • 提现动作补充：本次激励对象仅为店主，测试用例中需补充店主提现动作的验证场景。

待办 ​

  • 确认冷饮事业部活动层级的具体使用范围，并向业务方说明层级与中奖优先级的关系。 — @赵化龙
  • 评估并实现前端逻辑，隐藏冷饮事业部的普通激励叠加奖品配置按钮。 — @李明非
  • 补充特殊激励与普通激励的概率交叉验证、码量/金额超发场景及多条件组合限制的测试用例。 — @苏一尊
  • 单独拉取并重新验证预警机制及活动过程中的预算/码量修改场景。 — @苏一尊
  • 补充钱包明细展示（激励类型、金额流水）及店主提现动作的集成测试用例。 — @丁聪
  • 与刘莉梳理测试用例设计思路，并与冉冉（疑为郑然然，原文如此）、雪梅达成共识后，重新组织内部用例评审。 — @苏一尊

关联：本场属冷饮事业部活动落地环节，与 9.02「冷饮 H5 活动页面技术方案对齐会」为同一需求链路——H5 由营销活动中心提供、智慧门店小程序嵌入（下周三二次评审，安全方案待 @李明非 补齐）；本场"智慧门店仅调防作弊接口 + 跳转计费 H5"正是该方案的集成落地形态。

盘点签收故障修复方案评审 ​

  • 发言人：潘玉平、张喜、王建朝、贾继伟、李明非等 7 人
  • 主题摘要：本次会议针对盘点查账签收失败及数据覆盖问题，明确了代码堵漏方案与数据修复脚本，并确认了上线节奏及高德相关遗留问题的后续安排。

小结 ​

一、重复签收问题原因与堵漏方案

1. 故障原因定位

  • 并发导致数据覆盖：在盘点查账签收场景下，前链路写入 Mongo 是实时的，而异步写入报表较慢，并发时两条数据均查询不到报表状态，导致重复签收消息覆盖，且存在失败状态覆盖成功状态的风险。

2. 代码堵漏方案

  • 拦截重复签收消息：在发送异步消息写入报表前增加判断逻辑，若为重复签收则直接拦截、不再发送消息，从源头堵住报表重复签收的口子。

二、历史数据修复方案

1. 修复范围与数据量

  • 修复特定失败数据：针对 806 版本至今产生的数据，修复对象为签收类型 = 查账签收 / 盘点签收，且签收状态 = 失败、失败原因 = 重复签收的数据，预计涉及 39000 多条。

2. 修复逻辑与执行计划

  • 状态变更逻辑：将失败状态变更为成功状态，清空失败原因，并将更新时间置为当前时间。
  • 先堵漏后修复：计划今晚先上线堵漏代码，观察 1-2 小时确认无新增重复数据后，再执行数据修复与收口操作。

3. 修复脚本优化要求

  • 增加创建时间条件：为提升 SQL 执行效率并利用分区键，修复脚本的查询条件中必须补充"> 最小创建时间"的条件（如 19 号零点）。
  • 备份与修复条件一致：备份表与修复数据的 SQL 语句中 WHERE 条件必须严格保持一致，确保备份数据与修复数据完全匹配。

三、其他遗留问题

1. 高德数据问题

  • 接口调用量过大：高德接口因调用量过大导致昨日宕机，需修改相关 Job 逻辑；因今日时间紧张，推迟至下周一处理。

2. 业务同步

  • 群内同步修复进展：数据修复完成后，需在群内同步进展，并向业务方进行同步说明。

待办 ​

  • 修改数据修复方案，在 SQL 条件中增加创建时间限制，并确保备份与修复的查询条件一致。 — @潘玉平
  • 今晚先上线堵漏代码，观察确认无新增重复数据后，再执行数据修复与收口操作。 — @潘玉平
  • 数据修复完成后，在群内同步进展并向业务方说明。 — @余建新
  • 下周一处理高德接口调用量过大导致宕机的数据修复问题。 — @李明非

关联与提示：本场的"先堵漏、观察、再修数"是本周第二条同类原则——与 9.01「电子围栏清洗方案」（幂等脚本 + 执行完毕立即下线 Controller 入口）同源，均属临时数据脚本必须先堵口子再修历史、且条件必须可回溯。另注意：高德接口昨日宕机与本日液奶物码早会中"高德解析服务失败"为同一事件，早会侧排查影响范围（@刘晓娜），本场定的是 Job 逻辑改造（@李明非，下周一），两条线需对齐口径、避免重复排查。

技术方案评审：盘点落库高德逆地理调用优化 ​

  • 评审对象：FreshnessSignReceiptServiceImpl（盘点即签收）落库逻辑中的高德逆地理编码调用
  • 发言人：（待补充）
  • 主题摘要：盘点即签收落库时需调用高德逆地理接口将经纬度解析为格式化地址并写入 freshnessAddress / otherLocaInfo 字段；盘点业务高峰期暴露调用量过大与接口偶发失败两类问题，需优化调用策略与失败兜底。

小结 ​

一、现状：盘点落库链路中的高德逆地理调用

  • 调用位置：盘点即签收（FreshnessSignReceiptServiceImpl）落库时调用高德逆地理接口。
  • 调用目的：将上报的经纬度解析为格式化地址。
  • 落库字段：解析结果写入 freshnessAddress / otherLocaInfo 字段。

二、高峰期暴露的两个问题

1. 高德调用量过大

  • 重复请求同一坐标：同一门店 / 仓库在盘点高峰期会被大量扫码，相同经纬度的高德逆解析被反复请求，给高德接口造成压力。

2. 高德返回失败导致地址缺失

  • 高峰并发下偶发失败：高德接口在高峰并发下偶发失败，导致地址解析不到，盘点记录缺少地址。

待办 ​

  • （待补充：本场评审的方案结论、优化措施与责任人未见记录，需会后补齐）

关联：本场即当日「盘点签收故障修复方案评审」中"高德接口调用量过大导致昨日宕机、需修改相关 Job 逻辑、推迟至下周一（@李明非）"的具体方案议题，与液奶物码早会"高德解析服务失败、排查影响范围（@刘晓娜）"为同一根因链条的三个切面：影响面排查（刘晓娜）→ 调用量优化（本场）→ 存量数据修复（李明非，下周一）。

待补充项说明：本条记录目前仅含问题背景，优化方案（缓存/降级/补偿策略）、评审结论与责任人尚缺，待补齐后完善本节点。