2026-08-17 工作日志
项目进展同步与数据一致性跟进会
本次会议同步了各项目进展，重点讨论了数据一致性、线上问题及需求澄清，并明确了后续的跟进事项。
小结
1. 各项目进展同步
- 业务需求：移动端智慧门店端的出货场景因需求流程未对齐而暂停，本周将先进行测试。PC 端的其他需求正在按计划推进 UAT。
- 门店积分运营：逆向邮件已发出，等待业务侧确认后再推进；正向开发按计划进行。
- 营销助手：827 后端发版及 829 全国上线工作正常推进。
2. 数据一致性问题
- 门店与经销商关系：将在本周下半周与人民团队对齐门店及历史数据差异。
- 客户数据：P0 级问题将在 8 月 18 日发版上线解决。
- 产品状态：存在产品状态在变更和报表中不一致的情况，需尽快明确解决方案和排期。
- 数据库连接池：打满问题需有明确的解决方案和时间节点。
3. 线上问题与需求澄清
- 调拨码状态：本周新增的调拨码状态不支持问题，将由前后端协同协查。
- 需求流程：移动端智慧门店端的需求流程未对齐问题，需尽快组织澄清。
待办
1. 移动端智慧门店端需求
- 需与宝仟对齐需求，并与黄磊约时间进行需求澄清。 — @孙东栋
2. 数据一致性问题跟进
- 针对产品状态不一致、数据库连接池打满等问题，需在今日内组织会议，明确解决方案和排期。 — @吴菊 @余建新 @建新 @小娜
- 协同处理调拨码状态不支持的问题。 — @建新 @小娜
3. 门店积分逆向需求
- 技术侧需向业务侧反馈实时计算和批量跑批两种方案带来的技术难点和改造压力。 — @建新 @孔北
4. 日常事项
- 将已完成的事项从当前日会记录中移除，以精简内容。
营销活动中心功能与物码营销技术方案会
会议讨论了营销活动中心的活动创建流程、物码营销红包发放及智慧门店前端功能，并明确了相关技术方案与数据治理问题。
小结
1. 营销活动中心功能
- 活动创建与配置：介绍了活动创建的全流程，包括基本信息（如总金额）、活动范围（支持按销售五段、经销商、门店、产品等多维度筛选）、激励规则（支持首扫、N 次、大额红包等）、活动限制（如扫码位置、数量限制）及预警设置。
- 活动类型：明确了本期将支持三种活动类型：针对门店的红包活动、针对门店的卡券活动、集五福活动。一个活动内可配置多种激励规则，且支持在单个大活动中通过投放策略进行精细化管理。
2. 物码营销与智慧门店
- 前端功能：智慧门店首页将提供"开箱扫码"和"物码活动"两个入口。用户扫码后，若命中活动则跳转至 H5 页面获取激励。
- 红包发放：中奖红包将自动提现至用户微信钱包，无需手动操作。若因微信问题导致提现失败，系统会记录异常，但营销天网的发放状态仍为成功。
3. 技术方案与数据治理
- 码的激活：讨论了码的激活方案，倾向于采用"升码器激活"而非"产线扫码激活"，以确保 9 月 30 日上线时的稳定性。
- 扫码兜底：为应对二维码无法识别的情况，前端需支持条码识别和手动输入码信息的功能。
- 门店数据：会议深入探讨了门店信息（特别是店主手机号）的多系统管理问题，指出当前存在数据源不统一的风险，需进行数据治理。
待办
1. 需求与方案确认
- 会后将会议纪要及 PRD 文档邮件发送给相关方。 — @北京诺德1706
- 将组织周三的专项会议，对 PRD 进行评审。 — @北京诺德1706
- 将组织周四的数据治理经验分享会。 — @北京诺德1706
- 将组织周五的需求封板会议。 — @北京诺德1706
2. 技术与数据治理
- 需与严总确认 TTS 端的码激活方案，明确采用"升码器激活"。 — @李超
- 需提供 400-500 张不同光照和角度下的实物图片，用于防翻拍算法模型的训练。 — @北京诺德1706
- 需组织专项会议，讨论并明确店老板手机号的变更流程与管控逻辑。 — @北京诺德1706
3. 测试与试点
- 需制定详细的测试与试点计划，确保 9 月 30 日上线后能有实际业务场景进行验证。 — @北京诺德1706
4. 项目沟通
- 与 @吴菊 将建立双向邮件确认机制，确保项目信息同步。 — @北京诺德1706
积分池模式与销售五段数据权限讨论会
会议主要讨论了积分体系因采用"积分池"模式导致无法关联销售五段数据权限的问题，并探讨了相关的技术挑战与业务需求。
小结
1. 积分体系的技术挑战
- 积分体系采用"积分池"模式，将积分与人维度绑定，导致业务数据中不再包含门店信息，无法直接关联销售五段。
- 当前的数据权限方案依赖于销售五段进行数据筛选，若在积分体系中实现此功能，会导致因多对多关系和左连续匹配带来的巨大性能问题。
2. 积分体系的业务逻辑与现状
- 积分体系的底层数据（如记账流水）保留了门店信息，但聚合后的"积分池"和"积分账户"等核心数据表中已无此信息。
- 积分的增减、兑换等核心业务逻辑均在"积分池"内进行，其设计初衷是为了优化终端用户的查询效率和简化业务流程。
3. 数据权限缺失带来的问题
- 积分兑换、积分流水等管理后台页面无法按销售五段进行筛选和展示，导致数据无法按区域进行有效管理和分析。
- 业务方尚未明确数据权限的具体使用场景和使用者是谁，导致需求不清晰。
待办
1. 明确数据权限需求
- 需要与业务方进一步沟通，明确数据权限的具体使用场景、使用者以及期望达成的管理目标。 — @孔玮
2. 探讨替代技术方案
- 需由郭老师牵头，与数据组老师共同探讨可行的技术方案，例如能否从门店人员维度找到一种策略来关联唯一的销售五段，以规避多对多关系带来的性能问题。 — @郭老师
数据修复方案与线上问题排查及安全整改会
会议主要讨论了数据修复方案、线上问题排查及安全风险整改。
小结
1. 数据修复方案
- 针对 806 版本因 data 服务 CPU 占用过高导致的数据异常，设计了三个定时任务进行修复：
- 修复货源及经销商信息：通过时间分片和分页查询，利用 RPC 调用获取缺失的经销商及五联信息，并通过 Stream Load 高效更新。
- 修复产品信息：逻辑与修复货源信息类似，通过 RPC 调用获取产品信息并更新。
- 修复出货及签收地址：利用高德地图 API 将经纬度转换为省市区街道信息。为避免高德 API 的 QPS 限制和重复调用，增加了 Redis 缓存和限流处理。
2. 线上问题排查与修复
- 盘点返点识别结果异常：修复 8 月 6 日后识别结果为"作弊"的数据，将其状态统一修改为"通过"。
- 营销助手环境照片 URL 缺失斜杠：修复因 URL 缺少"/"导致图片无法打开的问题，涉及 SR 库和 MongoDB 中的约 50 万条数据。
- 消息消费导致数组序列化为字符串：排查到因 MQ 消费时将数组对象错误序列化为字符串，导致数据异常。已通过代码层面的判断和手动转换进行修复，并提供了数据修正脚本。
3. 安全风险整改
- 底座项目存在独立登录页：发现基础底座项目存在一个独立的登录页面，该页面的用户名和密码与统一认证中心一致，存在严重的弱密码风险。此问题将被修复，所有登录必须通过统一认证中心。
待办
1. 数据修复与问题排查
- 需先将所有异常数据导出并分析其根本原因，区分是由 data 服务异常、业务逻辑问题（如经销商失效）还是其他原因导致，再制定针对性的修复方案。 — @潘玉平
- 在修复营销助手 URL 问题时，需采用"临时表"方式进行，先将异常数据导出至临时表进行验证和修复，确保操作安全后再回写至源表。 — @余勇军
- 需将 MQ 消费导致数组序列化为字符串的 Bug 修复代码及数据修正脚本提交上线。 — @粱健
2. 方案文档更新
- 需将本次会议讨论的所有问题及修复方案整理到技术文档中，特别是要梳理清楚不同类型异常数据的处理逻辑。 — @潘玉平
- 需将营销助手 URL 修复方案更新至技术文档。 — @余勇军
- 需将 MQ 消费 Bug 的修复方案补充到技术文档。 — @粱健
3. 安全风险跟进
- 负责底座项目的独立登录页改造，移除该页面，确保所有登录均通过统一认证中心进行。 — @李明非
- 负责组织各系统进行一次全面的弱密码风险排查。 — @王建朝