Work for YILI

Appearance

2026-06-08 工作日志 ​

项目早会 ​

本次会议为项目早会，同步了各模块的最新进展，明确了后续工作重点，并对 6.11 版本的上线评审进行了部署。

小结 ​

1. 产品与功能进展

  • 活动中心产品走查：第一阶段走查已于 6 月 11 日和 6 月 25 日完成，后续将根据问题优先级进行优化。
  • 前端产品走查：6.11 版本将上线提示与优化、登录页及接口优化等功能，后续的出货、退货、盘点等功能将延后至 7 月初上线。
  • 智慧门店：本周将完成相关功能测试并上线，同时进行主数据和智慧门店的数据清洗工作。

2. 性能优化

  • 接口性能：将针对上周梳理出的慢接口，本周输出接口层面的优化项和上线计划。
  • 小智系统：扫码拍照的性能优化方案已定，计划于 7 月 2 号上线。
  • APM 接入：整体上线时间已推迟至 7 月底。

3. 数据治理与迁移

  • 数据迁移：本周将完成拆库后的数据迁移及验证工作。
  • 数据一致性：针对经销商 ID 等 ID 的映射关系，将在今天输出方案并组织决策。
  • 数据清洗：智慧门店将进行存量数据清洗，小智系统已完成主题域清洗并需确认数据同步方案。

4. 技术与遗留问题

  • 报表梳理：信誉度盘点项目进度正常，已完成 80%，剩余字段梳理将在今天内完成。
  • 遗留问题：共 17 个线上问题正在处理中，除一个需重点监控外，其余均有排期。门店同步时差一小时的问题已有方案并预计给出初步排期。

5. 6.11 版本上线评审

  • 各项目组需确保相关人员参会，特别是各系统负责人需亲自参与，不能依赖供应商。
  • 各项目组需提前梳理好 6.11 版本涉及的协同事项，确保版本顺利发布。

待办 ​

1. 数据治理

  • 李超 完成声码模块优化方案的人天评估并反馈给事业部。
  • 李超 完成数据迁移及验证工作。
  • 陈祺 确认并输出 ID 映射关系的最终方案。
  • 邢健 确认并输出门店数据同步的监控规则。

2. 问题跟进

  • 陈祺 确认并解决 TTS 与 ERP 订单差异明细的问题。
  • 李宝仟 确认并解决门店同步时差一小时问题的初步排期。
  • 赵薇 组织对 APM 周报中问题的内部对齐，区分需求、优化与系统问题。

3. 版本发布

  • 李亚洲 梳理 6.11 版本涉及的协同事项，并组织上线评审。
  • 赵薇 组织对市场走访结论的沟通，确认后续版本的上线时间。

4. 其他事项

  • 李亚洲 组织"扫码加锁"控制需求的移动端看板 PRD 评审。
  • 刘晓娜 确定补数据任务的具体排期。

面试记录 ​

候选人：李志民

整体沟通能力尚可，技术思维也不错，对问题能比较全面地从技术视角进行分析。

敏捷创新项目成果汇报会 ​

本次会议为敏捷创新项目成果汇报会，共展示了 18 个项目，涵盖 AI 赋能、数据安全、研发效率、运营提效等多个领域。

小结 ​

1. 数据与 AI 应用

  • 数据追溯与预警管理：通过两个月的建设，实现了对战略落地和项目管理数据的追溯、预警和闭环管理，预计每年可节约 500 小时重复劳动，并大幅提升风险项目和合规率。
  • 三方检测报告智能识别：利用图像识别和大语言模型，实现了对液态奶事业部三方报告单的智能识别与数据回填，替代了人工录入，效率提升显著，录入差错率降至零。
  • 核心数据保险箱：构建了物理隔离、不可篡改的核心数据保险箱，通过 Lgap 架构和 AI 工具 Cypher Sense，实现了数据防篡改、防病毒，并简化了备份流程，显著降低了存储成本。

2. AI 赋能与流程优化

  • AI 视频会议升级：选定私有化部署方案，旨在替换现有腾讯会议，以实现数据安全可控、AI 能力（如智能纪要、实时翻译）集成，并对接自有的千问大模型。
  • AI 赋能原奶对账结算：成功将 AI 工作流集成到私有云系统，实现了 XML 发票到 PDF 格式的转换、AI 前置核验和智能匹配，全年预计节约 4200 多小时工时，提升处理效率 80%。
  • AI 驱动的资源设备管理：基于 IoT 平台和 AI 算法，搭建了预测性维护体系，通过传感器实时监测设备状态，提前预警故障，并创建了"大师"AI 智能体进行健康问诊和知识问答。

3. 研发与运营提效

  • AI 全流程辅助开发：展示了 AI 在产品设计、开发、测试等全流程中的辅助应用，如"AI 全链路辅助供应商现场审核移动项目"和"AI 赋能党建平台建设"，均实现了自研交付和效率提升。
  • AI 重构研发设计系统：成功运用 AI Coding 重构了乳品研发设计系统，验证了"绩效团队+AI"的新模式，大幅缩短了开发周期和成本。
  • AI 赋能直播运营：打造了 AI 直播运营管理平台，为直播运营提供全链路数字化支持，覆盖五大事业部近 300 个直播间，累计营收破亿。

4. 智能化运营与数据分析

  • AI 智能标签：利用客服语音和企微对话数据，通过 AI 模型沉淀消费者标签，应用于精准运营，如识别竞品购买者、推荐羊奶粉等。
  • 液氮门店智慧运营：为业务代表提供确定性的进店任务和预警信息，如"7 天未拜访"、"陈列不达标"等，以数据驱动门店运营。
  • 内容运营智能体：打造了内容运营智能体，旨在通过 AI 能力提升短视频内容的洞察、创意和生产效率，以应对内容缺口和转化不足的挑战。

待办 ​

1. AI 视频会议升级项目

  • 王伟 项目已进入招标阶段，需加快与厂商的功能优化和系统对接工作。

2. 私有云 AI 工作流赋能项目

  • 孙正平 需进一步了解私有化模型的 Token 消耗成本。

3. AI Coding 赋能敏捷化项目

  • 张弛 需跟进长图生成 Skill 的优化方案，以解决当前大模型对图文识别不准的问题。

营销助手图片展示问题讨论会 ​

本次会议主要讨论了营销助手图片无法展示的技术问题，并确定了临时解决方案及后续的长期优化方向。

小结 ​

1. 营销助手图片展示问题

  • 营销助手上传的图片存储在私有 COS 桶中，导致前端无法直接访问和展示。
  • 方案一（由营销助手直接返回图片链接）改动较大，需后端接口调整。
  • 方案二（将 COS 文件夹改为公有读）技术上可行，但存在数据安全风险。

2. 解决方案与技术细节

  • 临时方案：采用方案二，将 COS 指定文件夹设置为公有读。为规避安全风险，前端将通过 Nginx 反向代理访问，不直接暴露 COS 域名。
  • 数据展示：为解决报表中缺少图片字段的问题，将在查询和导出时，通过临时方案从 MongoDB 中拉取图片链接并展示。
  • 长期方案：未来需将图片信息直接存入主键表（sr 表），并支持在用户上传图片后实时更新，以提升性能和数据一致性。

待办 ​

1. COS 权限配置

  • 粱健 需联系运维团队，将 COS 指定文件夹的权限改为"公有读"。

2. 技术方案文档完善

  • 粱健 需补充和完善临时方案的技术文档，明确从 MongoDB 查询图片信息并返回给前端的详细流程。

3. 长期方案设计

  • 粱健 需设计长期方案，明确将图片信息存入 sr 表的具体实现方式，并准备后续的开发排期。

老活动系统消费顺序问题讨论会 ​

本次会议主要讨论了老活动系统中因消费顺序导致的数据展示问题，并探讨了相应的技术解决方案。

小结 ​

1. 消费者中奖明细表活动名称显示问题

  • 问题现象：当一个消费者中奖码同时命中 C 端和 B 端（或售卖激励）活动时，由于消息消费的顺序不确定，导致中奖明细表中展示的活动名称不一致。例如，系统可能错误地将 C 端活动的中奖记录展示为 B 端活动的名称。
  • 问题根源：当前的数据写入逻辑未区分不同活动，而是根据消息到达的先后顺序写入，导致数据不一致。

2. 技术解决方案探讨

  • 方案一（增加字段）：在"消费者中奖明细表"中增加独立的 B 端活动名称和 C 端活动名称字段，将活动信息拆分。此方案改动相对较大，且涉及历史数据处理。
  • 方案二（保证消息顺序）：修改消息生产逻辑，在向 Kafka 发送消息时，根据中奖码进行哈希运算，确保同一中奖码的所有相关消息被发送到同一个 Kafka 分区。这样可以保证消费端按顺序处理，从根本上解决名称错乱问题。此方案被认为改动最小。

3. 老活动系统现状与风险

  • 系统现状：当前线上存在约 20-24 个老活动，由于缺乏熟悉其代码和架构的人员，且新活动系统尚未完全上线，导致老活动系统存在大量线上问题，处理效率低下。
  • 潜在风险：邱毅提出，老活动系统中存在的一系列问题（如数据缺失、字段错误）很可能在新活动系统中复现，因为新旧系统在底层服务上可能存在耦合。

待办 ​

1. 解决消费者中奖明细表活动名称错乱问题

  • 宋洋 采用"保证消息顺序"的方案，修改消息生产逻辑，通过按中奖码哈希分片 Kafka 消息，确保同一订单下的消息消费顺序正确。
  • 宋洋 消费端也需要相应修改，以配合新的哈希分片策略进行消费。

2. 启动老活动系统技术链路梳理

  • 邱毅 鉴于老活动系统存在较多历史问题且新系统尚未完全替代，需启动类似"避难活动"的技术链路梳理工作。
  • 邱毅 本次梳理需将新旧活动系统的设计整合，全面排查潜在的风险和隐患。

上线发版检查清单说明会 ​

本次会议介绍了上线发版的检查清单及检查标准，旨在通过事后检查确保各环节工作落实到位。

小结 ​

1. 上线发版检查清单说明

  • 目的：本次检查旨在倒逼各团队落实自身职责，检查清单中的大部分项目将通过团队提供的证明材料进行逻辑性核对，而非由检查方代替完成具体工作。
  • 模板要求：各团队需使用提供的模板，填写本次发版对应的需求（简要描述）、方案文档链接，并由产品经理准备。

2. 系统测试检查标准

  • 测试用例与结果匹配：需提供测试用例清单和测试结果清单，确保两者内容完全对应，数量一致。
  • 测试结论：上线发版前，所有测试用例的测试结果必须为"通过"，不应存在未通过或无结论的情况。
  • 用户测试：若涉及用户测试，必须提供有用户签字的测试报告截图作为证明。

3. 用户培训检查标准

  • 培训材料：需提供培训操作手册、培训材料等相关文档。
  • 培训记录：需提供培训记录，如签到表、培训截图或录屏等。
  • 考试记录：若设置了考试，需提供考试记录及达标情况的证明。

待办 ​

1. 准备上线发版检查清单

  • 各团队需使用模板，填写本次发版对应的需求和方案文档链接，并由产品经理准备。