2026-07-13 工作日志
签收功能数据与项目进展同步会
本次会议同步了签收功能数据、各角色使用情况及项目进展，并重点讨论了数据一致性、性能监控及遗留问题。
小结
1. 签收功能数据分析
- "待签收"功能上线一周，数据占比已达 13%，增长迅速。
- 日常开单（扫码出库）功能主要面向渠道 2 级分类中的 SDR，当前占比为 1.74%。
2. 各角色使用情况
- 店员和店长的数据呈现持续增长趋势，特别是店长参与人数从 1 月的 600 多人增长至 6 月的近 2000 人。
- 导购督导的数据增长相对平缓，已基本覆盖大部分业务场景。
3. 项目进展与问题跟进
- APM 监控: APM 系统已上线，将对慢接口进行监控。同时，APM 合同已启动，以便提前介入。
- 扫码效率: 计划本周完成扫码速度优化方案的评审和开发。
- 资金账户图片处理: 计划本周完成评审和开发，将去掉与 COS 平台的交互，改为直接与银联接口交互。
- iOS 图像识别崩溃: 已定位到与 SDK 集成有关的问题，将通过灰度测试包进行优化。
- 鸿运中心数据比对: 当前有 23 个主题域存在数据差异，正在优先处理影响业务的 10-11 个。其余批量差异数据将在后续进行分析。
- 健康度规则监控: 已分析并定位了 7 月 6 日和 7 月 7 日告警的 19 条健康规则问题，部分问题已明确责任方。
- 遗留问题: 会上通报了多项新发现的遗留问题，如"一键转移"导致出货地址为空、"西二八"仓库编码重复、产品追溯码与批次不唯一等。
4. 版本规划
- 7 月底版本: 后端发货时间为 8 月 6 日，SIV 灰度为 8 月 7 日，全国推广为 8 月 8 日。
- 需求进度: 李亚洲将发布修订版需求表，供各端现场确认。
待办
1. 数据一致性问题
- 邢健需在今天下午组织会议，同步鸿运中心数据比对的详细清单及本周计划。
- 李亚洲将提供所有已分析完的数据差异清单，供各端共同评估影响。
2. 性能与稳定性优化
- 李赵丹需在本周内完成 iOS 图像识别崩溃问题的灰度测试包并推送。
- 任铭需在分析完扫码速度优化后的数据后，将结果挂载到相应文档上。
3. 健康度规则问题跟进
- 孙东栋需在今天内将健康度规则监控中发现的问题的责任方明确并分配。
4. 版本需求发布
- 李亚洲需在会上发布修订版需求表。
5. TTS 改造费用确认
- 陈祺需与卢仁霄再次沟通，确认 TTS 改造项目的专项费用出处。
数字科技中心黑客松 AI 挑战赛激励方案宣讲
本次会议发布了数字科技中心黑客松 AI 挑战赛激励方案，明确了全员参与、先到先得的申报机制，制定了基于业务价值与创新性的评审标准，并强调了数据安全与知识沉淀要求。
小结
1. 赛事机制与参与规则
- 参与范围与形式: 赛事面向数字科技中心全员开放，支持个人或 2~5 人组队申报，鼓励跨职能组队合作。严格要求参赛项目必须基于团队自身技术能力实现，严禁借助外部供应商的技术能力进行开发。项目展示不设限，支持视频、PPT、文档等多种形式。
- 申报与评审安排: 采用企业微信 SaaS 在线文档进行申报，遵循"先到先得"原则。固定每周二进行项目展示与评审，每个项目汇报时间为 5~10 分钟，由王总担任主评审。
- 工具使用规范: 允许使用内部 AI 平台（如 E party、Coding、Trip）及低代码/自动化工具；若使用外部工具，必须严格遵守数据脱敏与安全要求。
2. 激励体系与评审标准
- 评审维度与权重: "业务价值与完成效果"占比最高（50%），其次是"技术创新性"（25%）和"知识沉淀"（25%）。设立金奖、银奖、铜奖及参与奖四个等级。
- 奖金分配与升级机制: 团队项目奖金由队长根据成员贡献度进行分配。新增"奖项升级"机制，参赛者可选择放弃当前奖项，在后续评审中继续冲击更高奖项。严禁同一项目重复申报。
3. 合规要求与后续规划
- 数据安全底线: 严禁上传涉密资料、经营数据及战略方案至外部 AI 工具；使用内部工具时需按密级要求进行脱敏处理。将对所有申报材料进行合规性审查。
- 成果沉淀与推广: 所有参赛案例将作为部门内部能力资产进行沉淀，优秀案例将在后续工作中进行复用与推广。对于大规模推广应用的优秀案例，将给予额外激励。
待办
- 加入报名台账群组，并开始进行案例申报。—— 全体参会人员
门店信息上报接口技术调整评审会
本次会议主要讨论了门店信息上报接口的技术调整，明确了门店、经销商等字段的传递规范，并确定了相关接口的改造方案。
小结
1. 接口字段传递规范调整
- 门店五段码: 各端上报门店信息时，需将"扫码人"的五段码作为门店的五段码进行传递，而非"扫码电"的五段码。
- 门店与经销商信息: 前端需传递门店名称、经销商名称、门店关联经销商集合（如有多个则传多个）、门店等级等信息。对于名称字段，若有则传递，若无则不传递。
- 新增字段: 新增的"渠道类型"、"渠道级别"、"门店经纬度"等字段需在相关接口中进行传递。
2. 后端校验逻辑调整
- 必填字段处理: 后端将不再对"扫码人五段码"进行严格校验，若前端未传递则视为有效，以兼容部分场景。
- 数据源切换: 后端将不再主动查询主数据校验门店、经销商等关系，而是信任前端传递的数据，将数据源切换为前端提供的数据。
3. 新增接口字段要求
- 盘点与查证接口: 在新增的盘点和查证接口中，需传递门店关联经销商集合、门店经纬度等字段。
新活动签收激励数据回补与物码查询接口取值逻辑变更评审会
本次会议评审了新活动签收激励数据回补方案与物码查询接口取值逻辑变更方案，并讨论了相关技术细节、风险及后续优化方向。
小结
1. 新活动签收激励数据回补方案
- 背景与目标: 为解决新活动签收激励数据缺失的问题，需将激励信息回补至 B 端出货明细表中。
- 技术方案: 初版方案采用定时任务每日同步，从 MongoDB 的签收激励记录中提取数据，通过追溯码匹配并更新 B 端出货明细表中相应字段。
- 讨论与优化: 会议讨论认为，原定时任务方案存在数据一致性风险（如任务失败、网络异常），且新老活动数据链路均为异步，建议采用 MQ（消息队列）实现异步更新，并辅以定时任务作为兜底机制，以保证数据最终一致性。
- 风险与依赖: 方案上线需等待新活动模块正式上线并产生数据后方可执行，以确保数据源的准确性。
2. 物码查询接口取值逻辑变更
- 背景与目标: 为修正"出货数量"和"签收数量"的取值逻辑，使其更准确地反映实际业务情况。
- 技术方案: 修改接口逻辑，不再直接返回数值，而是通过产品信息分别获取"出货数量"和"成功签收数量+失败签收数量"，并将其组合为"应签收数量"。
- 讨论与优化: 会议指出，将数值类型（int）改为字符串（string）以支持"100件"等带单位的展示，存在风险。建议评估新增独立字段的可行性，以更好地分离数据模型和展示逻辑。
3. B 端出货报表 Bug 修复
- 问题: 经排查，发现 B 端出货报表存在 Bug，导致"自主签收"类型的出货次数未被正确累加。
- 结论: 该问题已定位并紧急修复，将通过打补丁的方式发布。
待办
1. 新活动签收激励数据回补方案
- 方案需从定时任务模式优化为 MQ 驱动的异步模式，并设计相应的兜底机制。—— 潘玉平
- 与相关方（如张喜、明飞）确认新活动模块的具体上线时间，以便规划数据回补的执行时机。—— 潘玉平
- 在方案文档中补充对系统性能影响的评估，并完善数据回补失败后的告警与人工干预机制。—— 潘玉平
2. 物码查询接口取值逻辑变更
- 评估将"出货数量"和"签收数量"字段从 int 类型改为 string 类型的风险，并与前端同学确认最终展示格式。—— 潘玉平
- 与各相关前端团队沟通，确保各方了解接口返回字段的变化及其对前端展示的影响。—— 潘玉平
3. Bug 修复与流程规范
- 尽快发布修复"自主签收"出货次数未累加问题的紧急补丁。—— 张喜
- 将本次会议讨论的所有技术方案、Bug 修复等事项，在 Codebuddy 上建立并维护对应的记录，以规范后续的开发流程。—— 张喜
面试纪要：数据迁移方案与技术栈交流
本次会议主要围绕数据迁移方案、技术栈应用及个人开发流程进行了深入交流。
小结
1. 数据迁移方案与实践
- 背景与目标: 为配合系统切换，需将千万级的历史数据从 SQL Server 迁移至 MongoDB 系统，涉及码的层级转换、流向生成及明文码加密等业务逻辑。
- 技术实现: 方案采用"还原-抽取-转换-导入"的模式。为提升性能，已将原先的同步方案优化为异步任务处理，并通过分批处理（如每批 5 万条）和分组处理等方式降低数据库交互压力。
- 挑战与应对: 初期因并发线程池设置不当导致速度过慢，现已优化为动态控制线程数量；同时，针对数据量大的分页查询，通过业务分组等方式规避了"分页拖累"的风险。
2. 技术栈应用
- Cortex: 用于解决微服务架构下的分布式事务一致性问题，确保跨服务操作的数据最终一致。
- Netty: 在一个医疗数据采集项目中，基于 TCP 协议和 PCB 协议构建了数据采集网关，因其高性能和轻量级特性被选用。
3. 开发流程与方法论
- lsg 分享了其个人的开发流程：从需求拆解、与产品经理确认、功能设计、技术选型、开发、自测到 UAT 上线的完整闭环。