2026-09-08 工作日志
物码早会：业务系统项目进度同步会
- 发言人：李亚洲、吴菊、刘晓娜、余建新、孙东栋等 9 人
- 主题摘要：本次会议同步了各业务系统的研发进度，重点明确了门店积分项目的排期节点，并对修订文档更新及高德地图调用异常等问题进行了跟进与安排。
小结
一、项目进度与计划同步
1. 各系统研发进展
- 报表与测试进度：移动端权限方案及数据口径将于今日确认开发；PC 端 P2 级报表需完成 SIT 测试用例编写；流向准确率测试今日收尾。
- 小智系统数据一致性：已完成导购与门店监控告警分析，确认为历史物理删除导致差异，将持续观察增量数据一致性。
- 云商系统告警处理：当前共 17 条告警，其中 13 条已有解决方案，1 条复现但异常行数较少，需关注高德地图出货地址类告警。
2. 高德地图调用异常排查
- 缓存优化方案已上线：针对盘点提交时高德地图解析次数耗尽的问题，扫码盘点加缓存的优化方案已于上周五上线，目前调用流量已显著下降。
- 后续沟通安排：需与教研团队沟通整体分布情况，以确认异常监控识别结果。
3. 门店积分项目排期对齐
- 整体里程碑节点：技术方案撰写与评审定于 9 月 10 日完成，各端开发于 9 月 11 日完成，单元测试于 9 月 14 日完成，集成测试于 9 月 15 日开始。
- 需求与测试评审安排：产品方案 PRD 上周已评审；计费侧今日将进行技术方案评审及测试用例评审，正向需求已对齐。
- 复杂数据需求对齐：涉及正向与逆向部分的复杂事后财务分摊汇总表等数据需求，需与各端及数据团队拉齐确认。
二、文档管理与后续跟进
1. 修订版文档更新要求
- 中午前完成内容更新：因当前文档内容较乱，要求各负责人今日中午前将各自负责的内容更新至修订版本。
- 下午重新发布：负责人检查并调整文档位置与顺序后，将于今日下午重新发布正式版本。
2. 监控告警问题登记
- 云商系统告警原因登记：针对云商系统监控发现的问题，需在今日将分析出的原因登记至问题清单中。
待办
- 今日中午前将各自负责的内容更新至修订版本。 — @全体人员
- 今日下午重新发布正式版本的修订文档。 — @李亚洲
- 与教研团队沟通高德地图整体分布情况。 — @余建新
- 今日将云商系统监控告警的分析原因登记至问题清单中。 — @邢健
- 今日完成移动端权限方案下的数据口径确认与开发。 — @孙东栋
- 今日完成 PC 端 P2 级报表的 SIT 测试用例编写。 — @孙东栋
- 今日完成流向准确率测试收尾工作。 — @孙东栋
- 本周完成两个系统之间门店与经销商关系数据的比对，并输出差异数据清单。 — @邢健
- 今日准备导购与经销商关系的差异数据清单。 — @邢健
- 今日进行计费侧的技术方案评审及测试用例评审。 — @计费团队
- 每日早会重点跟进门店积分项目从产品到技术到测试的进度。 — @亚洲（李亚洲）
- 与孔玮、建新（余建新）、陈祺对齐门店积分正向、逆向部分及复杂数据类需求。 — @小娜（刘晓娜）
- 上午重新梳理并确认门店积分主计划的时间节点。 — @李亚洲
关联与提示：
- 高德问题初步闭环（9.04 → 9.08）：本场确认"扫码盘点加缓存"优化方案已于上周五上线、调用流量显著下降，回应了 9.04「盘点落库高德逆地理调用优化」评审中"相同经纬度被反复请求、调用量大"的问题。但仍需注意：9.04 提的是两个问题——① 调用量过大 ✅ 已解；② 高并发下偶发失败导致盘点记录缺少地址 ❓ 本场未见提及。建议确认是否存在存量缺地址数据需要回补，以及高峰期失败时的兜底是否为"留空待异步补偿"。
- 门店积分排期落地：9.07 曾提"积分上线时间与 10.20 过近、需整合版本"，本场给出明确节点（技术方案评审 9.10 → 开发 9.11 → 单测 9.14 → 集成测试 9.15 起），并要求每日早会跟进。注意该节奏紧于常规，且复杂数据需求（事后财务分摊汇总表）尚未拉齐，需关注是否为压缩版排期。
- 告警链条延续：云商告警由 9.07 的"周末产品一致性告警"扩展至本场 17 条（13 条有方案）；其中高德地图出货地址类告警需与 9.04 的调用量优化关联看——调用量已降，但告警是否同步收敛待确认。
- 跨端部对齐未闭环：9.07 记录的"导购与经销商关系一致性处理"（@邢健）在本场落到"今日准备差异数据清单 + 本周完成两系统比对"，属同一任务推进。
积分体系技术方案评审
- 发言人：王军、王建朝、李强、贾继伟、蒋宜宏等 7 人
- 主题摘要：本次会议对积分体系技术方案进行了评审，重点确认了新增门店维度的数据权限设计、核心接口变更细节，并明确了后续推进与跨端确认计划。
小结
一、积分体系技术方案调整
1. 物理模型与数据权限设计
- 新增门店维度：积分池、积分批次、积分变动记录等底层物理模型均增加门店维度字段，以支持基于销售底座的门店级数据权限控制。
- 明细流水继承门店维度：积分账户变动明细表及积分兑换单据表均继承积分池的门店维度，用于后续结案报表处理及前端明细展示。
2. 核心业务流程与接口调整
- 跳转与桥接页面优化：跳转积分乐园小程序调用的 API 已调整；智慧门店集成跳转由原先的 postmessage 方案改为直接 allocate 桥接页面。
- 券核销门店一致性校验：接收券中心核销回调通知时，新增严格校验逻辑，要求券的核销门店、核销人员必须与发放门店、发放人员保持一致，禁止跨门店核销。
- 券列表展示逻辑调整：优惠券发放维度调整为"门店 + 人"，门店员工在券列表中只能看到发放给所在门店或本人在该门店的券，无法查看跨门店的券。
3. 接口字段与查询逻辑确认
- 积分兑换冻结接口必填门店编码：一阶段冻结积分接口中门店编码为必填项，系统需从指定的积分池中扣减并冻结积分。
- 积分余额查询支持双维度：账户汇总余额及流水列表接口支持按"人维度"或"人 + 门店维度"查询；其中 H5 端门店为必传，积分商城首页汇总可按人查询，兑换时按门店查询。
- 同步流水新增经销商字段：同步积分记账流水接口新增经销商编码与名称字段，用于结案报表及前端流水明细的科探文案展示。
- 明确经销商编码标准：针对新增的经销商字段，需与营销活动中心提前对齐，统一使用标准的客户编码，避免因团队人员变动导致对接偏差。
二、评审结论与后续计划
1. 评审结论
- 技术方案通过评审：评审组确认本次技术方案调整合理，底层模型与接口设计符合预期，同意按计划正常推进。
2. 后续推进计划
- 输出并同步会议纪要：会议结束后将整理会议纪要并发送至沟通群，供各方确认。
- 各端确认接口变更：涉及接口变更的各方需对本次调整方案进行确认，确保跨端协同无误。
待办
- 整理并发送本次会议的会议纪要至沟通群。 — @李强
- 各相关端对接口变更方案进行确认。 — @孔玮 @建朝（王建朝）
关联与提示：
- 排期提前：本场于 9.08 完成技术方案评审，早于今晨物码早会定的 9.10 节点，为后续开发（9.11）与单测（9.14）留出缓冲。
- 门店维度与既有规范一致：本场"门店维度必填、人员维度降级"的设计，与 8.31「数据权限与字段传输规范对齐会」确立的"以门店/仓库/位置 5 段为核心维度、人员 5 段降级非必填"为同一原则的延续应用，口径一致，无需重新论证。
- ⚠️ 两个方案未涉及但必须回答的问题：
- 存量数据如何处理：积分池、批次、变动记录三类模型新增门店维度，属底层物理模型变更。存量积分池无门店维度时如何回填？回填口径由谁定？若上线后再补，改造成本与风险远高于上线前。
- 人员调店场景：券核销要求"核销门店/人员必须与发放门店/人员一致"，若门店员工调店或兼岗多店，其名下已发放未核销的券如何处理？当前规则下可能直接失效，需明确业务边界与兜底（如允许转移或作废重发）。
- 经销商编码对齐意识值得肯定：主动提出与营销活动中心对齐标准客户编码、"避免因团队人员变动导致对接偏差"——这是把口头约定转成标准的正确做法，建议在接口变更清单里固化为字段级规范。
门店字段接收与数据补录方案评审
- 发言人：王建朝、郝梓斐、余勇军、李明非、张建利等 8 人
- 主题摘要：本次会议评审了门店二级渠道类型字段接收及索引方案，并讨论了因 SR 资源不足导致盘点数据丢失的补录方案，明确了后续验证与跨团队协同的具体计划。
小结
一、门店二级渠道类型字段接收方案
1. 字段接收与应用场景
- 新活动配置与抽奖校验：新活动创建时需按二级渠道类型约束筛选门店，抽奖环节需校验该字段。
- 老活动报表数据同步：新抽奖中奖后的报表数据需写入老营销活动底座，老活动主数据需同步接收该字段以支撑报表展示。
- 双项目方案补充：要求在基础底座与老营销活动两个项目下分别补充技术方案，明确描述字段的应用场景与影响范围。
2. 数据全量推送与索引添加
- 全量推送初始化：门店数据量达 1000 多万、无法指定更新，需全量推送以初始化新字段。
- 索引需谨慎评估：为避免加索引导致锁表或影响业务，须先全量清洗数据、再集中添加索引。
- 索引区分度待验证：二级渠道类型约 200 多种，加联合索引的区分度可能不足，需在测试或生产环境验证索引效率后再上线。
- 字段长度待确认：字段默认值为空，需与主数据团队确认字段长度，避免随意设置导致数据截断或存储浪费。
3. 数据链路与落库确认
- 旧活动链路同步：旧活动数据链路的中间表与最终落库表均需同步添加新字段，确保数据同步处理。
二、盘点数据丢失补录方案
1. 补录方案与执行路径
- 丢失原因：9 月 1 日起因 SR 资源不足，盘点数据查询失败、未写入报表。
- 初步方案：从日志文件下载完整消息体 → 写入新建 Mongo 表 → 定时任务读取并重新发送至消费 Topic。
- 优先方案：确认云平台支持消息队列导入后，优先采用直接导入 Excel 消息体，避免代码发版。
- 数据量：异常集中在 9 月 5 日，总计约 18000 多条；重新消费入库时系统有校验机制，不会重复入库。
2. 业务影响评估与验证要求
- 门店状态变更影响：补录时需重点评估 1 号至 8 号期间门店或经销商属性发生变更的记录，确认是否影响落户数据。
- 不影响扫码查证：补录数据走完串货逻辑后写入盘点明细表，不影响扫码查证明细及违规销售表的数据。
- MQ 通道限制：需向腾讯云确认批量导入消息体是否占用现有通道量，并在测试环境小批量验证可行性。
- 时效约束：日志保留 90 天，需在此期限内完成补录。
待办
- 在基础底座和老营销活动两个项目下补充技术方案，明确字段应用场景与影响范围。 — @郝梓斐
- 拉通中台 DBA（如钟阳、李斌）评估千万级数据量加索引的执行方案，避免锁表。 — @李明非
- 确认二级渠道类型字段的准确长度。 — @郝梓斐
- 在旧活动的数据链路中间表和最终落库表中同步添加新字段。 — @郝梓斐
- 向腾讯云确认 MQ 批量导入是否占用现有通道量，并在测试环境小批量验证导入方案可行性。 — @李明非
- 统计 1 号至 8 号期间门店或经销商发生变更的记录，评估其对补录数据的影响。 — @余勇军
- 数据补录完成后，通知中台团队重新抽取盘点数据。 — @余勇军
关联与提示：
- 与 9.07 二级渠道类型方案重评呼应：9.07「扫码错误记录与 H5 外网访问方案评审」中，二级渠道类型因"主数据文档基于液奶底座、实际为积分需求、跨冷饮/奶酪/液奶多事业部"而被推翻重写，本场是该需求的正式落地方案评审，且明确为夜奶事业部新活动场景，需在两份技术方案中写清归属与影响范围。
- ⚠️ 补录方案与 9.04「盘点签收故障修复」同源：均为"历史数据补写"，但方向相反——9.04 是状态覆盖待修正（3.9 万条失败置成功），本场是数据根本没写进去（9.1 起 SR 资源不足致 1.8 万条丢失）。两者都遵循"先堵口子再修数据"，但本场未明确 SR 资源问题是否已修复，若未修复，补录期间还会继续丢。
- ⚠️ 补录的隐藏前提未确认：按"1 号至 8 号门店/经销商属性变更记录"评估影响，说明补录数据会按当前属性重新计算落户。若期间属性已变更，补录结果可能与原始业务事实不符，需业务侧确认按哪个时点口径执行。
- 索引区分度问题值得单独论证：200 多种取值、1000 多万行数据，单列区分度约 1/50000；若为联合索引需确认前导列选择。建议让 DBA 给出实际执行计划与耗时评估，而非仅凭经验判断。