Work for YILI

Appearance

2026-06-17 工作日志 ​

项目早会 ​

本次会议同步了各项目进展，重点讨论了数据迁移、性能压测、功能联调及遗留问题，并明确了后续的工作计划。

小结 ​

1. 版本规划与数据迁移

  • 7 月 2 日版本将包含主数据及部分优化内容，其余内容按原计划推进。
  • 门店人员数据已完成待清洗问题的确认，主数据侧将进行数据清洗并推送。
  • 智慧门店侧将进行内部人员优化方案设计及历史门店数据清洗。

2. 性能与技术问题

  • 全局埋点接入后，压测报告显示内存消耗较高，但对整体性能和加载时效无影响。
  • 网关问题因无法在测试环境复现，正在尝试搭建本地环境进行排查。
  • 大包连接超时问题已完成技术方案评审并修改，将进行新一轮评审。

3. 测试与联调

  • 智慧门店的"一键转发"功能因分享链接问题存在阻塞，将进行联调。
  • "待签收"和"分享签收"功能将在今日进行联调。
  • 今日测试将集中在 508 会议室进行。

4. 遗留问题与风险

  • 补发奖励功能已通过技术方案评审并完成少量数据校验，将按计划部署。
  • 新发现的"B 端出货明细表"数据量差异问题，已由孙东栋进行排查。

待办 ​

1. 自定义埋点功能

  • 李赵丹 需在 7 月 30 版本前梳理并输出自定义埋点的初步范围。

2. 数据与系统优化

  • 邢健 需完成门店与经销商关系数据的逻辑优化开发，并与主数据进行联调测试。
  • 张建利 需梳理并统一调整活动中心所有微服务的连接配置。

3. 测试与问题跟进

  • 任铭 需在今日内完成"一键转发"功能的单元测试。
  • 李亚洲 需跟进"B 端出货明细表"数据量差异问题，并给出回复。
  • 李亚洲 需与业务方沟通"安卓端非上架应用转发次数限制"的功能必要性。

4. 功能部署

  • 刘晓娜 需在今日完成对 699 家异常门店的补发奖励数据筛选与部署。

营销助手门店查询 Bug 修复评审（技术方案评审） ​

发言人：张喜、王建朝、马奇、张建利、贾继伟

本次会议评审了营销助手门店查询因特殊字符过滤导致的编码匹配失效 Bug，确认了拆分处理逻辑的修复方案，并针对前端交互体验与后端性能优化提出了改进建议。

小结 ​

1. Bug 根因分析与修复方案

  • 故障根因定位：
    • 特殊字符处理逻辑缺陷：此前为兼容门店名称中的特殊字符（如括号），后端使用了 MongoDB 函数对输入参数进行统一过滤，导致传入的纯数字门店编码被误处理，从而无法进行精确匹配。
    • 业务场景掩盖问题：由于用户习惯主要使用门店名称进行模糊搜索，极少使用编码精确匹配，导致该 Bug 在线上环境潜伏较久，直至近期内部测试才被发现。
  • 修复方案确认：
    • 逻辑拆分策略：采纳张喜提出的方案，将查询逻辑拆解。门店编码（Shop ID）采用精确匹配（等于查询），门店名称采用模糊匹配并使用函数包装以兼容特殊字符，避免相互干扰。
    • 测试环境验证：确认测试环境已在 5 月份完成修复且验证通过，目前仅生产环境因未发版存在代码不一致问题。

2. 交互体验与性能优化建议

  • 前端交互改进建议：
    • 输入框功能解耦：建议前端将输入框改为仅支持门店名称模糊搜索，避免用户输入难以记忆的纯数字编码，提升易用性。
    • 下拉列表优化：建议前端在输入关键词后，通过下拉列表展示匹配结果供用户选择，并将选中的固定门店 ID 传给后端，而非直接透传模糊关键词。
  • 后端性能与限制：
    • 查询性能现状：目前接口因数据量不大且增加了经销商和时间范围限制，暂未出现明显性能问题，但需关注未来数据增长后的性能瓶颈。
    • 时间范围强限制：目前后端未对时间范围做强制限制，主要依赖前端控制。若后续出现性能问题，后端将增加强限制逻辑。

待办 ​

1. Bug 修复

  • 张喜 修复生产环境 Bug 并发布上线。

2. 前端交互优化

  • 张喜 将前端交互优化建议（取消编码匹配、增加下拉列表）反馈给产品经理（德智/小娜）。

积分商城系统功能与架构讨论会 ​

会议讨论了积分商城及相关系统的功能、数据对接、架构设计等问题，并对后续工作进行了安排与规划。

小结 ​

1. 系统功能介绍

  • 业务支撑功能：计费中心支撑活动的红包提现和发放；卡券支撑活动发券场景；积分中心作为活动的一种玩法和激励方式，支撑各种活动的激励类型，发积分，配置活动时可选择积分类型和触发条件；风控中心是活动的风控营销模块。
  • SAAS 产品定位：SAAS 私有化产品定位为积分运营工具，支撑小智导购任务激励、小拓陈列活动检核、营销活动中心物码相关活动等场景，不同场景下人员完成任务可获积分并进行兑换。

2. 数据对接问题

  • 基础数据来源：小拓系统后端涉及的销售区域、门店、经销商等基础数据，由主数据实时推送，但门店数据可能有几小时间隔。未来计划升级基础数据对接方式，直接对接基础底座的数据，或与营销活动中心对接同样的基础数据。
  • 数据推送问题：主数据推送多个系统存在时差，新系统增加会加重基础数据推送延迟问题。使用营销活动中心数据存在进度匹配问题，基础数据按需推送需考虑传输回溯业务问题。
  • 数据安全问题：去年因数据安全需搭建技术体系，可采取加密和哈希手段，明确敏感数据存储的数据库，但无法识别数据流转情况。数据库有独立实例，需处理数据关联关系，使用同一密钥进行加密和解密。

3. 积分商城功能

  • 商城管理：包括商城基础地址设置，用于与各端交互，以及小智、小拓人员、门店人员的商城装修，可根据前端 UI 设计进行。
  • 活动管理：商城可添加活动，添加活动需约定积分类型，类似专款专用，还需明确兑换活动的范围、时间范围、清零规则和兑换方式。
  • 积分兑换：自定义品可维护实物或类似京东 E 卡的券，设置品的信息、库存和最多兑换量，选品扣减积分后弹出填地址页面，由业务人员线下发货。对接京东需维护京东的币及兑换限制，兑换、发货和物流信息可在京东页面查看。

4. 系统架构设计

  • 积分商城架构：使用人群包括经销商人员、导购督导和门店人员，有后台管理系统、小程序，以及与第三方对接的 API 等访问层。
  • 网关与服务：统一网关进行认证和路由转发，主要业务服务有积分商城主服务，用于积分兑换、活动创建和维护。
  • 接入方式：积分商城接入银行活动中心的方式与卡券中心相同，都是接入权限底座，通过底座网关转发，跳转到积分商城的积分明细、活动管理等功能。

5. 工作安排与规划

  • 系统迁移：5 月 26 号完成迁移方案，先将 MySQL 剥离出来，后续数据处理上，以前的数据保留，新发生的数据单独拎出，历史数据单独存储，保留积分活动页面入口及跳转链接。
  • 功能扩充：目前积分系统只支撑燕奶活动，冷饮提出需求，要扩充系统以接上冷饮需求，将夜奶积分与小拓共用的基础数据剥离出来独立，后续重点讨论数据对接方式。
  • 专项会议：拉专项会讨论营销活动中心未来接多事业部情况下底层数据库的建设问题，安排节后宋洋休假回来一起落实此事。
  • 营销活动周中心：确认营销活动周中心是模块升级，升级内容嵌在营销活动中心里，替换活动模块，未来冷饮奶酪入口统一，不同事业部和角色看到的内容不同。

B 端出货规则单据冻结报表评审 ​

本次会议主要评审了 B 端出货规则单据冻结报表的新增功能，明确了其查询、导出及权限控制等需求。

小结 ​

1. 报表功能评审

  • 新增"冻结单据报表"菜单及页面，支持通过多种查询条件（如精准/模糊查询）筛选数据，并具备导出下载功能。
  • 报表的可见范围由系统管理员通过角色或人员进行分配，用户仅能看到其组织架构内被授权的数据。

待办 ​

1. 权限控制验证

  • 秦丽娜 需验证报表的权限控制逻辑，确保仅被授权的用户才能查看，并且其查看范围仅限于其组织架构内。