Work for YILI

Appearance

2026-06-24 工作日志 ​

每日站会 ​

本次会议同步了各项目模块的最新进展，重点讨论了性能优化、数据问题及遗留问题的解决方案，并明确了后续的排期和待办事项。

小结 ​

1. 各项目模块进展同步

  • 活动中心：相关列空分组需求已完成测试，待业务 UT 通过后安排评审上线
  • 前端走查：所有开发工作已结束，今日进入测试阶段
  • 数据走查：今日将进行数据对齐，本周内完成现状梳理
  • 性能优化：主数据门店接口优化及后端埋点数据优化的版本统一至 7 月 2 日发布
  • App 问题：针对用户反馈的页面加载慢问题已建立专项群跟进；针对 6 月 22 日发现的 400 余次 App 崩溃问题，已上线云端日志采集体系进行定向分析
  • 智慧门店：昨天已分析差异数据问题原因，今日将进行数据比对、推送及功能开发；昨日完成的接口优化将今晚发版上线
  • 云商：昨天已修复产品数据告警问题，今日将排查门店与经销商关系一致性告警问题
  • 高德地图：含连接超时问题已调整参数不再报错，将持续观察；原定 7 月 4 日发布的两个问题，将随后端 7 月 2 日的版本一同上线

2. 遗留问题与历史问题

  • 加锁技术方案：当前的技术方案存在风险，将与李赵丹会后再次对齐
  • 盘点数据重复：此前被标记为无法清理的历史问题，因涉及业务发放工资，需重新启动清理流程。已初步确定方案，将由刘晓娜团队细化后评审

3. 测试与排期

  • 各项目按计划推进内部测试，预计在两天内完成
  • 各项目需统一上线时间，跟随版本发布，避免零散上线

待办 ​

1. 项目排期与计划更新

  • 各项目需统一上线时间，跟随版本发布 —— 陈思
  • 更新里程碑计划，将"小智系统上线"等事项的完成时间与版本对齐 —— 陈思

2. 技术方案与问题跟进

  • 针对加锁技术方案存在的风险，会后需再次对齐 —— 李赵丹、刘晓娜
  • 细化盘点数据重复的历史问题解决方案，并组织评审 —— 刘晓娜
  • 持续跟进 App 崩溃问题的日志分析 —— 李赵丹
  • 持续观察高德地图接口调用超时问题 —— 张建利

3. 发布与评审

  • 完成"小智系统"接口优化功能的发版上线 —— 邢健
  • 组织智慧门店系统功能开发的评审会议 —— 邢健
  • 完成数据走查的现状梳理工作 —— 任铭

PRD 需求评审会（盘点及提交、扫码签收） ​

本次会议主要评审了盘点及提交、扫码签收等相关需求，明确了各端的方案细节和技术实现。

小结 ​

1. 盘点及提交需求

  • 背景：解决因扫码盘点数据缓存导致已售产品被逆向记录的问题
  • 方案：前端扫码后直接提交，取消本地缓存；后端提供新接口进行校验，如产品是否过期、是否当日已盘、是否为大众团购出货等
  • 环境照片：手动录入和 OCR 方式需支持上传环境照片，但具体为必传还是选传需进一步明确

2. 各端技术方案

  • 小智端：扫码后直接盘点，简化交互；将为 OCR 和手动录入功能增加配置开关；盘点记录将不再区分"有效"和"作弊"数量
  • 智慧门店端：扫码后直接提交，取消本地缓存；需增加人员和门店范围的前置校验；将新增时间上报日志功能
  • SFA 端：扫码后直接提交，取消本地缓存；将为 OCR 和手动录入功能增加配置开关；盘点记录将不再区分"有效"和"作弊"数量

3. 待签收及一键签收功能

  • 背景：SFA 生成出货单后，需支持门店人员在智慧门店中查看并签收
  • 方案：在首页增加待签收订单的浮层提示；点击后进入列表页，可查看订单详情并进行签收；签收时需校验门店距离
  • 关于是否支持"一键签收"多个订单，需进一步调研门店的实际出货频次数据

待办 ​

1. 技术方案与文档

  • 小智端需明确环境照片的上传规则（必传/选传），并更新 PRD 文档 —— 陈燕冰
  • 小智端需将扫码盘点相关的操作纳入时间上报日志体系 —— 陈燕冰
  • 各端需统一将相关需求文档合并至同一版本（零五版） —— 陈思

2. 数据调研与需求确认

  • SFA 需提供近期门店的出货单量数据，以评估"一键签收"功能的必要性 —— 任铭
  • 需与 UI 设计师确认首页待签收订单浮层的视觉样式，确保其突出醒目 —— 任铭
  • 需与业务方确认，盘点时是否需要无感知地同步签收操作 —— 陈燕冰

报表字段注释梳理会 ​

本次会议主要对多个业务报表的字段进行了梳理和注释，并讨论了如何在报表中展示这些注释。

小结 ​

1. 报表字段梳理与注释

  • 会议对"查证明细表"、"B 端出货明细表"、"盘点明细表"、"消费者中奖明细表"、"流向异常明细表"、"异常退货明细表"、"作弊明细表"等报表的字段进行了逐项梳理，明确了各字段的来源、含义和计算逻辑
  • 对于"是否重码"、"扫码类型"、"流向分类"、"追溯状态"、"扫码范围"、"流向异常判定规则"等关键字段，明确了其具体的判断依据和业务逻辑

2. 报表注释展示方案

  • 初步方案是在报表页面的字段旁增加一个"小叹号"图标，点击后弹出注释内容
  • 下载报表时，应同时提供包含所有字段注释的说明文件（如 Sheet2），并与数据文件（如 Sheet1）一同下载

待办 ​

1. 字段注释完善

  • 补充"是否重码"字段的历史背景和停止产生重码的具体时间 —— 吴南林
  • 补充"退货类型"、"签收类型"、"扫码方式"等字段的所有枚举值 —— 吴南林
  • 确认"是否为补充经销商"、"物流候补货件"等字段的具体业务含义 —— 吴南林

2. 报表展示方案设计

  • 设计并提供报表注释的 UI 方案，包括点击"小叹号"弹出注释的交互原型，并将其整合进 PRD 文档 —— 吴南林

3. 技术方案确认

  • 与技术团队确认，关于字段注释的展示方案（如采用配置化管理），需在技术方案中明确实现路径 —— 吴南林

奶酪项目接口规范与数据对接方案对齐会 ​

发言人：孔玮、粱健、李明非、金策、宋洋等 9 人

会议明确了奶酪项目接口文档需在本周五前完成最终版定稿，确认了首期不接入扫码机盘点功能，并针对数据底座对接方案进行了重新评估，要求拉通技术监理进行最终决策。

一、接口规范与文档对齐 ​

1. 接口差异与兼容性评估

  • 字段与枚举值变更：奶酪接口在字段命名上进行了规范化重构，删除了部分冗余字段，并将枚举值改为字符串类型以增强容错性，导致无法直接复用液奶接口
  • 盘点逻辑调整：奶酪盘点接口改为单码（Passcode）上传模式，移除了批量上传逻辑，且不再支持作弊码的上传与拦截，仅处理有效盘点数据
  • 扫码工具限制：鉴于液奶侧仅保留"营销助手"工具，奶酪侧暂定沿用该枚举值，不再支持其他扫码工具类型

2. 文档定版与开发约束

  • 最终版交付节点：鉴于当前接口文档被定义为"临时版"，存在变更风险，双方确认需在本周五（本周内）输出经技术监理评审通过的最终版接口文档
  • 开发风险控制：明确要求接口文档定版后严禁随意变更，若因接口变更导致开发返工，需提前报备风险并可能导致项目延期

二、业务范围与功能裁剪 ​

1. 首期功能边界界定

  • 扫码机盘点功能裁剪：明确奶酪事业部首期版本不承接液奶侧的"扫码机盘点"功能需求，该功能暂不纳入本期开发范围
  • PRD 基线确认：确认本期开发严格依据已评审通过的奶酪事业部 PRD 进行，排除液奶事业部新增的、未在 PRD 中明确的需求

2. 数据对接范围确认

  • OU（组织单元）数据范围：确认目前仅需接入业务侧指定的单一 OU 数据，暂不接入其他 OU 数据，避免数据冗余
  • 主数据同步状态：确认奶酪数据尚未推送至底座，需与杜婷确认具体推送状态及 OU 编码

三、数据对接架构方案博弈 ​

1. 技术侧方案主张

  • 统一数据源诉求：技术侧（李明非、宋洋）主张所有子系统（如活动中心、积分商城等）统一从底座获取数据，以解决各子系统独立对接主数据导致的数据不一致问题
  • 方案变更回溯：技术侧指出，此前"直连主数据"的方案已被技术负责人（邱雨）否决，因此计划改回"通过底座中转"的方案

2. 业务侧质疑与评估

  • 架构合理性质疑：业务侧（孔玮）质疑增加底座层中转的意义，认为此举并未解决主数据同步延迟的根本问题，反而增加了架构复杂度
  • 最终决策机制：鉴于双方对方案存在分歧，决定由业务侧拉通技术总监（娜姐）及技术监理（邱雨）进行最终决策，以确定是维持"直连主数据"还是采用"底座中转"方案

待办 ​

  • 整理并提供经技术监理评审通过的最终版接口文档 —— @马奇 @宋洋
  • 确认奶酪数据推送状态及 OU 编码，并在对接群中同步 —— @李明非
  • 拉通技术总监（娜姐）及技术监理（邱雨）确认数据对接方案（直连主数据 vs 底座中转） —— @孔玮
  • 将本次会议待办事项汇总并同步至群内 —— @马奇

技术评审 - MAC 盘点明细表重复数据修复（导出时去重临时方案） ​

项目负责人：营销活动中心
评审时间：2026/06/24
参与评审人：王建朝、刘晓娜、宋洋、梁健、陈祺、邱毅、孙传熙、马奇
评审结果：✅ 有条件通过（按评审意见补充风险说明，并同步业务侧预期）

小结 ​

1. 技术方案背景

盘点明细表存在重复数据，月底财务需据此数据结案。因底层数据清洗方案耗时较长，本月无法及时完成，业务方要求在"下载导出"时先支持按唯一标识去重，确保导出文件中每条盘点码仅出现一次，满足当月结案使用。

2. 决议事项

  • 代码改造：在 Report 服务盘点报表导出流程中，增加基于 take_date_day + trace_code 的 HashMap 去重校验，使用 it.unimi.dsi.fastutil 中的 Object2LongOpenHashMap 降低内存占用（200万 UUID 约 190M）。去重 Map 声明在方法体内，方法结束前主动置 null 便于 GC 回收；不改变原有排序及精确查询逻辑。
  • 业务对齐：已与业务方（刘晓娜确认）达成共识——导出数据条数与页面列表不一致属预期行为（重复已被过滤），盘点次数字段本次暂不准确，仅用于月底结案判断"是否被盘过"，不关注具体盘点次数；需提前告知业务侧并做好答疑准备。(责任人：刘晓娜/宋洋)
  • 风险关注与监控：上线后密切监控 Report 服务 Pod 内存、GC 及导出成功率，防范并发导出导致 OOM 影响同 Pod 其他报表导。
  • 后续规划：本次仅为临时应急方案，底层重复数据清洗及页面查询去重（终极方案）另行排期评审实施，不在本次范围内。

3. 评审提出的风险点与要求

  • 导出一致性：须按排序取首条去重，保证同条件多次导出结果稳定（已确认可实现）。
  • 内存风险：Report 服务共享 Pod，并发大量导出可能存在 OOM 风险——已要求方法内局部变量 + 主动置空，主动释放内存占用；上线后监控内存指标。
  • 可导条数差异：如列表查1万条导出可能仅数千条，业务侧已知晓并接受，需做好答疑说明。
  • 盘点次数字段：本次导出不修正盘点次数，业务方确认不影响结案使用。

4. 方案地址

https://yldc.coding.yili.com/p/sip-mac/wiki/44683

待办 ​

1. 风险说明与业务对齐

  • 补充技术方案中的风险说明部分，明确内存占用、导出条数差异等预期行为 —— 刘晓娜、建新
  • 提前告知业务侧导出去重逻辑及预期差异，做好答疑准备 —— 刘晓娜、宋洋

2. 上线监控与后续规划

  • 上线后密切监控 Report 服务 Pod 内存、GC 及导出成功率 —— 刘晓娜、建新
  • 底层重复数据清洗及页面查询去重（终极方案）另行排期评审实施 —— 刘晓娜、建新