2026-05-23 工作日志
项目早会
本次早会对产品优化、数据治理、遗留问题及528版本上线等事项进行了同步，明确了各项工作的进展、风险和后续安排。
小结
1. 产品优化与性能
- 营销活动中心：611上线及经销商电子围栏取值逻辑优化项目进度正常。
- 前端性能优化：SIV登录和扫码场景优化已排期；智慧门店将在5月29日完成第一版上线；小智侧拍照功能性能优化将在5月27日完成数据分析。
- A/B测试：神策基座接入开发正常；APM接入手机端页面的计划因厂商暂不具备能力而推迟至6月底。
2. 数据治理与一致性
- 主数据与智慧门店：数据一致性问题按计划推进，将在5月29号给出解决方案。
- ERP与云商数据：主数据与云商间的数据一致性问题，需在5月25号前完成产品数据调整。
- 定时任务梳理：将对线上常交任务运行失败导致的数据丢失问题进行专项治理，本周内完成现有定时任务的现状分析。
3. 健康度与平台优化
- 健康度配置：营销活动中心健康度配置共需21项，本周将逐步完成各端的对齐配置。
- 平台优化：将持续推进聆讯云平台的优化工作。
4. 遗留问题与需求
- 528版本上线：会议重点讨论了5月28日版本的上线内容，要求各端确认是否存在遗漏或延期风险。
- 消费者中奖明细表：针对此问题将启动专项治理，但当前仍需优先保障B端出货与盘点等核心业务的稳定。
- 需求跟进：业代签收UI调整将在周三前完成并组织最终评审。
待办
1. 528版本上线准备
- 各端需在今日10:30前完成528版本上线内容的检查清单填写，以便下午进行评审。@吴菊 @邱毅 @孙东栋 @刘晓娜 @任铭 @王琪 @张建利 @李志磊 @余建新
- 各端需在今日内确认并更新528版本上线内容的最终排期。@余建新 @吴菊
2. 技术方案与问题跟进
- 完成B端出货报表字段的技术实现逻辑处理，并于明天或后天给出结论。@张建利
- 完成现有定时任务的现状分析，梳理任务列表及其涉及的数据。@张建利
- 完成拍照功能性能优化的开发及测试。@王琪
- 完成经销商人员接收逻辑的梳理，并准备明天的解决方案沟通。@邢健
- 完成SIV登录和扫码场景优化的排期并补充到文档中。@李赵丹 @王琪
活动模块技术架构梳理会议
本次会议旨在全面梳理现有活动模块的技术架构，分析其数据同步的实时性问题，并为后续的优化升级提供依据。
小结
1. 现有活动模块技术问题盘点
会议的核心目标是梳理现有活动模块的技术逻辑，特别是数据同步的实时性问题。
- 当前存在的主要问题是，部分关键操作（如提现、中奖）的结果并非实时同步，而是通过定时任务拉取，这给业务带来了困扰。
- 为从根本上解决问题，需要梳理清楚活动模块与各上游下游系统的对接关系，明确哪些是实时同步、哪些是异步，并分析异步场景下的超时处理机制。
2. 新旧活动模块对比与升级规划
- 本次梳理的目的之一是评估即将上线的新活动模块，看其是否能解决老版本存在的问题，从而实现一次性优化。
- 新旧模块在技术实现上存在差异，例如新模块未采用老版本中的"light flow"工作流组件。
待办
1. 现有活动模块技术架构梳理
- 李明非负责整理现有活动模块的上下游系统对接关系，明确各环节的同步方式（实时/异步）、耗时及超时兜底方案。
- 李明非需在当天下午两点左右完成初步梳理。
2. 新旧模块技术差异分析
- 王建朝将根据李明非提供的梳理清单，重点分析老版本中因"light flow"工作流组件引发的高并发问题，并评估其在新版本中的影响。
经销商电子围栏数据替换方案讨论
本次会议讨论了将经销商电子围栏数据替换为行政区划数据的技术方案，并明确了在实施前需解决的数据使用规则、影响范围及兼容性等问题。
小结
1. 数据替换方案与潜在风险
- 背景：计划将经销商电子围栏的应用数据源，从现有的行政区划数据表，替换为经销商的电子围栏数据。
- 初步方案：计划保持现有接口的返回参数不变，以实现前端无感知的平滑过渡。
- 主要风险：替换后，街道（street）字段将存储完整的中文地址，其长度可能超过现有数据库字段（如VARCHAR(4000)）的限制，存在数据存储溢出的风险。
2. 数据使用规则与影响范围
- 核心问题：新的电子围栏数据结构更精细，包含了品牌（brands）、渠道（channel）、OU等维度，而旧的行政区划数据并未如此细分。
- 关键疑问：当前的PRD文档过于笼统，未能明确下游各业务场景（如不同报表、详情页）如何使用这些精细化数据。例如：
- 同一个经销商的不同品牌，其电子围栏范围是否应被区分对待？
- 报表等前端应用应如何处理这些新增的、更复杂的字段？
3. 数据一致性与验证方法
- 数据一致性：需要确认新的电子围栏数据与旧的行政区划数据在逻辑上是否保持一致，尤其是在省、市、区等编码层面是否存在差异。
- 验证方法：为确保数据迁移的准确性，不能仅通过抽样验证，必须采用全量关联查询的方式，对新旧数据表进行交叉核对，确保所有数据都能正确映射。
待办
1. 明确数据使用规则与影响范围
- 韩冬冬需组织与产品经理及业务方沟通，梳理并确认电子围栏数据在各业务场景下的具体使用逻辑，特别是关于品牌、渠道等维度的处理方式，并将结论固化到PRD文档中。
2. 数据兼容性与迁移验证
- 韩冬冬需与主数据团队确认，确保电子围栏数据中的省市区编码与现有系统保持一致，避免因编码不统一导致数据匹配错误。
- 韩冬冬需编写SQL脚本，对新旧两套数据进行全量关联核对，确保数据迁移的完整性与准确性。
3. 技术方案评审
- 待上述问题全部明确并形成文档后，再组织技术方案的正式评审。
528版本发布计划与协同会议
本次会议主要围绕528版本的测试进展、发布计划及协同方案展开讨论，明确了各系统在发版前需完成的准备工作。
小结
1. 营销活动中心528版本
- 新增内容：在B端出货场景增加出货距离配置规则；在自主签收场景中，将扫码即提交，取消本地缓存；将门店名称等信息作为必填字段进行传递。
- 测试进展：整体测试进度正常，其中B端出货规则距离控制的测试已完成86%，计划于今日内完成。
2. SFA系统528版本
- 新增内容：在扫码出货时增加门店半径规则校验；为支持智慧门店扫码签收，优化了收货码的域名规则；修复了盘点时切换门店导致经销商信息丢失的Bug。
3. 智慧门店与小智系统528版本
- 新增内容：在扫码签收场景，由前端传递签收距离信息；在自主签收场景，实现扫码即提交；为支持新域名收货码，将门店信息拼接到URL中。
4. 主数据治理
- 调整内容：为确保数据一致性，将对下游系统（智慧门店、小智）的客户数据推送范围进行限制，仅推送"液态奶事业部"的102ou范围内的数据。
- 数据处理：主数据侧将过滤无效数据进行推送，下游系统需在发版后完成存量数据的清洗和标记工作。
5. 发布计划与协同
- 核心争议：会议重点讨论了本次发版的发布方案，主要争议在于"不停机协同发版"与"停机发版"的优劣。
- 结论倾向：考虑到本次发版涉及多个相互依赖的系统（如SFA、智慧门店、小智、主数据），为规避因版本不一致导致的线上问题，会议倾向于采用"停机发版"的方案，确保各端同步上线。
待办
1. 发布计划与协同
- 各端需尽快确定最终的发布顺序和详细计划，特别是涉及"停机发版"时的服务发版顺序。@张建利 @徐贺明 @孙传熙 @李赵丹 @邢健 @任铭 @王琪
- 需要细化各系统内部的服务发版顺序、DDL操作和配置修改清单，以确保回滚方案的完整性。@张建利 @徐贺明 @孙传熙 @李赵丹 @邢健 @任铭 @王琪
2. 测试与文档
- 各系统需在发布前，完成并提供最新的测试报告。@郑然然 @李赵丹 @邢健 @王琪
- 需要提供测试通过版本的封版截图，作为发布依据。@张建利 @李赵丹 @邢健 @王琪
3. 数据处理
- 主数据侧需在5月26日发版后，推动下游系统完成存量数据的清洗和标记工作。@邢健 @任铭 @王琪 @李赵丹
4. 发布评审与考核
- 本次发版将进行正式的上线评审，未按要求完成材料准备的同学将被纳入考核。@赵薇
即时零售商业模式讨论
本次会议深入探讨了即时零售的商业模式、核心驱动因素及主要参与者，并分析了其对乳制品品类的影响。
小结
1. 即时零售商业模式与分类
- 核心模式：骑手在30分钟至1小时内将商品配送到家，主要分为O to O（平台类）和前置仓两种模式。
- O to O模式：平台（如美团闪购、京东秒送）负责订单分发和配送，货权归属线下门店或仓，平台仅为服务提供者。
- 前置仓模式：商品由前置仓持有并开具发票，目前主要代表有小象超市、普普超市和叮咚买菜。
2. 即时零售的驱动因素与发展现状
- 历史背景：起源于餐饮外卖，为盘活骑手资源而拓展至商超、药店等品类。
- 发展契机：2020-2022年疫情催化了即时零售的爆发，消费者购物习惯发生改变。
- 当前趋势：整体销售增速放缓，但消费习惯已养成。核心驱动力为"犯懒"、"临时需求"和"即时满足"，尤其适合冷饮、乳制品等高频次购买的商品。
3. 主要平台与渠道分析
- 京东：其"京东到家"业务整合了自营（京东超市）、七鲜超市和京东秒送等多个运营主体，消费者在同一个App内可能因会员身份或活动不同而看到不同的价格和商品。
- 抖音：采用"先有媒介，再有渠道"的模式，通过短视频和直播获取流量，其小时达、次日达等功能与即时零售概念相似。
- 硬折扣：一种无价格浮动的零售模式，依赖自有品牌和极致供应链降低成本，代表企业有盒马、快乐蜂、奥乐齐等。
4. 数据与合作机会探讨
- 数据分析：平台提供了如"智慧分销"等功能，可用于分析产品铺货情况、反向挖掘高需求品类和空白网点，为产品上翻和市场拓展提供数据支持。
- 合作潜力：会议认为，未来数科与各平台在数据共享、SaaS工具、渠道协同等方面存在大量合作机会。
待办
1. 数据后台访问权限
- 北京诺德1702将会后为需要访问平台后台数据的同学开通账号。
528版本代码走查会
本次会议评审了扫码签收、门店距离校验、拆箱标识及盘点作弊等功能的代码，明确了各模块的逻辑、风险及优化点。
小结
1. 扫码机签收接口
- 新增扫码接口，支持根据码类型（二维码、唯一码、无码）进行查询。
- 接口包含防重提交逻辑，通过Redis实现，超时时间为2秒。
- 采用兜底策略，若查询不到经销商的OU，则默认为102。
2. 门店距离校验
- 核心逻辑为根据门店编码匹配距离校验规则，并校验实际距离是否符合规则。
- 匹配规则支持多级（如5段、4段等），采用优先匹配长规则的策略，并有兜底逻辑。
- 门店信息的有效性校验需注意区分"门店与经销商的供货状态"和"门店在事业部的在营状态"。
3. 必填字段校验逻辑
- 明确了用户、门店、经销商名称等字段在必填场景下的处理逻辑：优先通过系统查询获取信息，若查询不到则使用前端传入的兜底信息。
- 此逻辑在串货校验等场景下，需确保使用"原始门店信息"，以避免因信息不全导致误判。
4. 拆箱标识校验
- 在扫码签收等场景中，会校验传入的拆箱标识（flag），若为"拆箱"，则需进行相应处理。
5. 盘点作弊功能
- 新增了盘点距离等必填字段，并移除了原有的有效性校验，由上游控制数据准确性。
- 采用高德API解析经纬度并获取地址信息，若解析失败需记录日志并考虑补偿方案。
6. 日志与异常处理
- 会议中发现部分日志为排查问题临时添加，内容冗余，建议在系统稳定后进行清理或改为debug级别。
- 当前异常处理较为分散，建议后续统一设计异常码及处理逻辑。
待办
1. 门店状态字段确认
- 张喜需确认门店信息查询中使用的status字段具体代表"门店与经销商的供货状态"还是"门店在事业部的在营状态"。@张喜
2. 代码优化与完善
- 张喜需将代码中硬编码的"102"替换为可配置的静态变量，并添加注释说明。@张喜
- 梁健需优化日志，减少不必要的JSON序列化，避免性能开销。@梁健
- 梁健需与产品侧确认，当高德API解析地址失败时，应记录日志并补偿，还是直接返回空值。@梁健
- 梁健需与产品侧对齐，当门店/用户/经销商信息查询不到时，使用兜底信息的具体策略。@梁健
3. 文档与记录
- 张喜会后需将本次评审的详细记录、问题及结论更新至Wiki。@张喜