Work for YILI

Appearance

2026-07-17 工作日志 ​

查证签收、盘点签收距离判断需求确认（与亚洲电话沟通） ​

昨天关于查证签收、盘点签收距离判断的问题与亚洲做了电话沟通，确认需求如下。

小结 ​

1. 门店距离筛选限制需求

  • 查证签收、盘点签收场景，门店选择仅支持选择 500 米范围内门店。
  • 盘点场景：前端现有距离限制，需复核确认是否生效、阈值是否为 500 米。
  • 查证场景：前端新增 500 米门店距离筛选限制，中台不单独为该场景做配置页面。原因如下：
    1. 距离判断依赖当前操作人实时定位，定位坐标、门店坐标均在前端获取、计算测距，校验逻辑天然跑在前端，无需跨前后台传参、调接口做距离运算，业务链路更通顺。
    2. 距离限制为固定统一业务规则，无分角色、分渠道、分门店差异化调整需求，不存在运营后台灵活配置的场景，无需中台提供配置页面。
    3. 仅用于门店选择拦截提示，属于操作层交互限制，不影响底层核心数据存储，不属于全局通用业务参数，无需中台统一管理。

2. 签收判断逻辑（与前期需求评审保持一致）

  • 完成盘点 / 查证操作后产生的签收数据，不再沿用原有签收校验规则，统一执行新逻辑（详见 PRD）。

项目进展早会 ​

本次早会对齐了各项目进展，重点讨论了历史数据修复、性能表现及后续监控计划。

小结 ​

1. 历史数据修复

  • 昨天已与业务方确认，历史数据需要进行修复。
  • 数据修复方案已同步，技术侧正在评估具体的修复方法。

2. 性能表现与监控

  • 对 7 月 2 日发布以来的性能进行了梳理，剔除报表类接口后，P99 延迟均小于 600 毫秒，整体表现良好。
  • “盘点结果上传”接口因请求量大导致 P99 延迟较高，后续将通过网格扫码机盘点功能进行优化。
  • 将持续监控两周，若无异常则可结束此专项。

3. 项目进展

  • “收签收和出货数据”功能已于昨日上线，待 TTS 完全上线后才算解决。
  • “营销活动中心”对数工作原定 7 月 17 日完成，将延期至下周五。

待办 ​

  1. 历史数据修复：技术侧需评估并制定历史数据修复的具体方案。——余建新
  2. 性能监控：需持续监控系统性能两周，确保无异常情况。——李宝仟
  3. 数据验证：会后需联系“东”监控并验证修改后的数据是否达到预期效果。——李宝仟
  4. 方案同步：将与各前端团队同步“邮箱查证 + 距离控制”的相关方案。——李宝仟

项目进展与风险回顾会（门店积分运营方案推进） ​

本次会议回顾了项目进展与风险，并重点讨论了门店积分运营方案的延期风险及后续推进策略。

小结 ​

1. 项目进展回顾

  • 签收链路优化：版本二开发进展顺利，预计 8 月 6 日上线，将包含查证即签收、扫码盘点即签收等功能。
  • PDA AI 翻拍：已进入测试阶段，计划随 8 月 6 日版本一同上线。
  • 卡券功能：在经典和安慕希小程序的弹窗界面优化正在进行中，由市场部主导。
  • 门店积分运营：方案目前处于调研阶段，预计下周四或周五将组织业务侧进行 PRD 评审。

2. 问题与风险沟通

  • 问题解决：本周共新增 20 个问题，已解决 12 个；另有 8 个正在处理中。
  • 重点项目风险：门店积分运营方案因 PRD 尚未最终确定，导致无法给出确切的上线排期，存在无法按时（8 月中旬）上线的风险。
  • 系统异常：B 端出货及司机配送扫码出库时出现数据不一致等问题，原因已定位，相关修复将在 8 月初版本中发布。

3. 新国标保质期切换

  • 各工厂的新旧版包材切换排期已初步明确，将随旧版包材的消化进度进行同步。

待办 ​

  1. 新国标保质期切换：蔡志刚需将最新的切换排期和要求同步给项目组。
  2. 门店积分运营方案：刘晓娜需在下周组织业务侧对门店积分运营方案进行 PRD 评审，并根据评审结果给出明确的上线排期。
  3. 销售部数字化规划：销售部需提前准备相关资料，以便在 20 日的销售部数字化规划研讨会上进行有效讨论。
  4. 项目管理问题跟进：张乐对项目经理尚志伟提出了批评，要求其反思工作态度和质量，并立即推进门店积分运营方案的测试工作。

新活动签收激励回补B端出货明细表技术方案评审 ​

本次会议讨论了新活动签收激励回补 B 端出货明细表的技术方案，明确了数据回补流程、StarRocks 更新方式及历史数据修复方案。

小结 ​

1. 新活动签收激励数据回补方案

  • 背景：新活动签收激励的数据需要回补到 B 端出货明细表中，但签收激励的触发时间可能早于 B 端出货数据写入 StarRocks 的时间。
  • 方案：采用“中转”方案。将新活动签收激励的业务数据暂存至 MongoDB 集合中，待数据稳定后再通过定时任务将数据批量回补至 StarRocks。

2. StarRocks 数据更新机制

  • 更新方式：明确将采用 Stream Load 方式进行数据回补，以支持对 StarRocks 表中特定字段的部分更新，避免了单条更新的性能问题。
  • 字段变更：B 端出货明细表将增加字段以支持新活动的积分、卡券等多种奖励类型。

3. 历史数据修复方案

  • 问题：上次数据修复时未处理数据重码问题，导致修复错误。
  • 方案：在本次修复中，通过为数据增加序列号作为唯一键，避免重码问题。将通过比对领奖时间等信息，筛选并修正历史错误数据。

待办 ​

  1. StarRocks 表结构与枚举值补充：潘玉平需在方案文档中补充新增字段的详细说明，特别是各类奖励（如红包、积分、卡券）的枚举值及其对应含义。
  2. 历史数据修复：孙世文需执行历史数据修复脚本，利用唯一键解决数据重码问题，并修正已存在的错误数据。