2026-06-16 工作日志
SFA 系统发版与数据治理周会
发言人：李亚洲、刘晓娜、吴菊、龚明、蔡文博等 18 人
本次会议重点对齐了 7 月 2 日 SFA 灰度发版的关键节点与验收标准，敲定了 Redis 性能优化与 TTS 迁移方案，并针对 ERP 对账、扫码加锁性能及门店数据瘦身等治理任务明确了执行路径。
小结
1. 产品与数据治理进展
- 列表报表列控优化：计划于 6 月 25 日上线，其余功能按 7 月底排期正常推进。
- 神策埋点接入：已完成线上数据导出，今日将通过 Excel 进行初步分析并搭建看板，以验证 API 字段与业务维度的匹配度。
- TTS 语音迁移：新迁移方案已评审完毕，今日将制定明细计划并启动生产环境数据备份。
- 智慧门店数据一致性：已完成客户标记处理，需刘晓娜和建新确认历史存量垃圾数据的处理方案，避免门店人员关系数据异常影响业务。
- ERP 对账与调账：预计今明两天完成最终调研报告，计划在周四双周会上进行汇报，需数字办提供主导协同支持。
- 门店数据瘦身：针对库内约 800 万数据（有效仅 200 万）的冗余问题，需各端配合进行数据库瘦身，以提升整体性能。
2. 技术架构与性能优化
- Redis 性能优化方案确认：Redis 性能优化方案已确定，今日将在测试环境完成初始配置。鉴于 Nacos 作为核心组件的风险，决定不跟随 7 月 2 日业务发版，而是申请独立停机窗口进行切换，具体时间待定。
- 慢接口排查：已完成 6 月版本接口盘点，发现 1 个高优慢接口及 16 个业务接口问题，正在输出整体优化方案。
- 健康度监控：前端 B 传告警数据量较少，需持续观察；部分基础数据问题需长期监控并推动治理。
3. SFA 发版与验收标准
- 发版时间轴：确认 7 月 2 日为后端灰度发版日，7 月 4 日推全国；移动端发版时间需与数据团队对齐。
- 评审 Deadline：明确 6 月 30 日为上线评审截止日，严禁评审后补代码 Review 或测试报告。
- 扫码加锁性能测试：针对扫码出库加锁功能，需重点关注接口查询速度对扫码体验的影响，并要求进行前台实测（非仅看后台数据）。
- 并发场景验证：需测试短时间内同一人员扫同一码的极限场景，验证应用层状态机制是否能有效防止一码多出。
4. 遗留问题与需求对齐
- 签收功能范围：确认扫码记录签收功能归属 704 版本，而非 723 版本；关于"出货单展示签收"功能的排期，需吴菊与刘晓娜会后进一步确认。
- 多 OU 上线时间：针对营销活动中心与中台排期不一致的问题，需明确最终上线 Deadline（6 月 25 日或 7 月 2 日）。
- 查证明细表同步：决定放弃通过主数据兜底接口获取数据的方式，改为前端并传字段的方式解决数据同步延迟问题。
- 网关与连接异常：针对网关偶发异常及 Dubbo 连接超时导致的数据丢失问题，需进一步复现场景并定位根因。
待办
1. 产品与数据治理
- 李赵丹 更新表格中神策埋点及接口盘点的信息至 D 列，并移除高德地图相关已完结事项。
- 刘晓娜、建新 确认智慧门店历史存量垃圾数据的处理方案，并反馈给邢健。
- 邢健、陈思 拉会确认小智系统门店推送影响性评估方案。
- 陈祺 准备 ERP 对账调研报告 PPT，并在周四双周会前与吴菊、李亚洲预沟通。
2. 技术架构与性能
- 李亚洲、邱毅 梳理 Redis 优化涉及的前置测试配合方及具体工作。
- 李宝仟 完成扫码加锁方案的评审并确定上线排期。
- 刘晓娜 针对 SFA 市场走访发现的卡顿问题，今日输出分析结论。
- 刘晓娜 跟进 SFA 埋点对前端性能影响的测试结论。
3. 发版与排期
- 李亚洲 主导 ERP 对账涉及 DMS 系统改造的排期对齐，并跟进费用支出。
- 李亚洲 统筹门店数据库瘦身工作的排期与节奏。
- 刘晓娜 对齐多 OU 功能的上线 Deadline（6 月 25 日或 7 月 2 日）。
- 全体参会人员 更新日报中的今日待办，确保被点名的重点工作今日有结论。
简单退货功能技术实现与并发问题讨论会
本次会议主要围绕"简单退货"功能的技术实现、并发锁问题及性能瓶颈展开讨论，并明确了后续的优化方向。
小结
1. "简单退货"功能技术实现与并发问题
- 功能流程：会议详细梳理了"简单退货"的技术流程，包括参数校验、Redis 锁、出货单与出货码状态检查、组装退货数据以及最终的 MongoDB 数据写入等步骤。
- 并发锁问题：讨论了当前将 Redis 锁置于方法内部的实现方式存在风险。在高并发场景下，两个请求可能同时进入方法并绕过锁，导致数据不一致和重复操作的风险。
2. 性能瓶颈与解决方案探讨
- 性能瓶颈：当前方案使用 MongoDB 的分布式事务，由于其分片特性，导致事务性能不佳，尤其是在处理大批量数据时，容易因锁竞争和等待超时而报错。
- 解决方案：会议探讨了多种优化思路，包括：调整云平台 MongoDB 的锁等待超时参数；将耗时的写入操作（如批量保存流向信息）拆分，改为异步处理，以降低主流程的执行时间；设计通用的重试工具类，将事务逻辑剥离，当写入失败时记录详细信息并由独立任务进行重试。
待办
1. "简单退货"功能代码优化
- 张喜 将 Redis 锁的获取位置从前置的校验步骤移至方法外部，以确保并发场景下的数据一致性。
- 张喜 暂缓修改"补货权"相关的判断逻辑，待后续版本再进行优化，以避免引入风险。
2. 性能问题跟进与优化
- 张喜 联系云平台团队，咨询并尝试将 MongoDB 的锁等待超时时间调长，以缓解锁竞争问题。
- 宋洋 在完成压测并确认当前版本稳定性后，着手设计和实现一套通用的重试工具类，用于处理后续可能出现的写入失败问题。
小伊育儿智能助手功能与架构讨论会
会议讨论了"小伊育儿智能助手"的功能、架构迭代以及知识库构建与检索等方面的内容。
小结
1. 育儿助手功能介绍
- 核心场景与定位：育儿助手围绕婴幼儿喂养、健康等核心场景为家长解答问题，定位是做出差异化，成为更懂用户、贴近日常、有持续使用价值的产品，增强用户对品牌专业度和服务感的认知。
- 育儿问答：智能体结合宝宝档案、近期对话记录、长期记忆、内部知识库和必要的联网信息生成回答，宝宝档案可新建并输入重要信息，作为回答参考。
- 成长记录：针对新手妈妈观察宝宝、形成规律作息的诉求，设计了自然语言甚至语音输入的版本，让智能体自动记录，相比手动选择记录的 APP 更便捷。
- 奶粉成分对比：用户可上传两组奶粉成分的照片或截图，智能体识别营养成分表并生成客观对比结果，产品原则是不做品牌推荐，只帮助用户看懂信息。后续还将帮助缺乏奶粉营养成分常识的新手妈妈进行科普，按不同作用类型识别成分，辅助判断。
2. 架构设计迭代情况
- 旧版架构特点：旧版架构更像 AI 工作流，流程固定、稳定可控，能快速跑通能力，但关键判断由代码规则提前写死，智能感和自适应能力不足，面对复杂问题和任务类型变化时难灵活处理。
- 迭代版架构升级：迭代后更像 agent，模型更早参与，先做意图和风险判断，再做路由计划决定答案生成方式。加入 ReAct 执行链路，边做边看结果，如育儿问题先查知识库，判断资料是否足够，不够则决定是否联网补充，设置最多三轮动作步骤，既保留 agent 自主判断，又控制成本和避免失控。
- 迭代原因及优化：因旧版架构在处理复杂问题时存在局限性，所以进行迭代。此外，之前版本存在超时情况，复盘后对日志监控和版本进行了迭代优化。
3. 知识库构建与检索
- 知识库构建过程：构建了包含不同形式和格式的内部知识库，还购买了美国医学或育儿的 PDF 补充进知识库。对数据进行切分、清洗、分类，让大模型整理源数据信息，最后生成向量化数据存入本地向量知识库，本地生成的结果更好，会考虑宝宝档案里的月龄生成回答。
- 检索流程方法：结合上下文将问题改成更适合检索的形式，避免用户口语表达和知识库书面表达不一致导致搜不到结果。检索采用多路召回，包括向量检索和关键词检索的混合检索，检索到的结果用 RFF、RRF 算法模型融合，之后进入重排，复核候选片段能否回答问题，并叠加来源优先级——内部育儿知识和产品知识优先级高，外部美国 PDF 知识和联网搜索优先级低，指定质量高的网站优先检索，最后生成回答。
代码逻辑冲突与业务需求处理讨论会
会议讨论了代码逻辑冲突、需求文档完善、业务需求处理、数据清洗安排以及测试工作规划等相关事宜。
小结
1. 代码逻辑评估
- 逻辑冲突处理：当前逻辑与玉平盘点明细表取值优化逻辑冲突，需评估是否注释原逻辑。4 月 28 号玉平加的代码，因格致新需求，关联经销商为失效时也需展示，所以要注释该代码。
- 接口状态判断：接口未判断经销商及其 5 段的状态，只要存在就直接查询出来。4 月 28 日新增盘点逻辑，校验财务失效和体系业务失效状态，现打算去掉该逻辑。
2. 需求文档问题
- 文档展示要求：会议提出应提供需求背景分析材料，而不是直接展示代码，同时展示德式需求文档，说明需求变更后的影响范围和场景。
- 文档卡顿问题：德志的 PRD 文档于上周五（5.10）评审过，但打开卡顿加载不出来，需导出产品走查里面 5.7 的在线文档。
3. 业务需求处理
- 货权判断方案：业务需求要求货权经销商判断不做财务失效处理，因货权应在经销商财务失效前就已存在。需要明确货权判断是通用的还是每个报表独立的，要有相对的技术方案。确定当前提到的环节是要做的需求，需安排任务梳理系统中涉及货权经销商状态校验的业务逻辑，避免报表和业务代码执行逻辑不一致。
4. 数据清洗安排
- 清洗要求：德志要求查所有数据并重新清洗，上周传新老师表示超过 2000 万的数据不能直接洗，要确认不需要更新的字段，清洗完数据后手动执行拉取。
- 工时系统维护：讨论小志提工时评估系统的相关事宜，由说话人负责维护。同时询问小智的技术方案评审、代码 review 等工作是否正常进行，提醒注意备注历史数据清洗（从 1 月 1 号到今天）等情况。
5. 测试工作规划
- 报表排查测试：发言者昨天下午排查报表，只发现一处有特殊判断，需列出排查报表清单，标记处理情况和测试后发现的遗漏。
- 上线安排：今晚要上线酸奶产品，但各区域相关工作未开展，且酸奶有个重点品项。盘点添加完成后，需要测试报表逻辑。
智慧门店签收激励补发与数据治理讨论会
会议讨论了智慧门店签收激励补发方案、数据同步、费用校验、盘点明细逻辑、数据处理补数、代码评审及 PRD 回溯等问题。
小结
1. 签收激励补发方案
- 方案评估：
- 方案一：从日志提取触发激励但未获签收激励的码，与门店编码比对筛选，导入表中重新触发，有日志丢失风险。
- 方案二：全量码重放，拿出 6 月 12 号到 14 号凌晨的 256000293 条码数据，放触发签收基地表中触发，数据量大有风险。
- 方案三（推荐）：在方案二基础上全量搜索数据，与 699 个店员门店编码筛选，缩小数据量后触发，对系统压力小、精准度高。
- 执行步骤：先拿出 50 条或 10 条以内数据进行签发并检查数据正确性；数据正确后在 21 点到凌晨 2 点之间批量触发所有数据；触发完成后让罗宾进行数据校验和报表检查。
- 定位功能：机器和 Redis 有基于定位的功能，给定经纬度和 500 里范围可定位有效队列，数据实时调用接口，己方和计费部门都能查到。
- 报表更新：补发走正常接口，报表会更新，如消费者中奖明细表中的数据会补齐。
2. 数据同步问题
- 智慧门店数据：智慧门店此前出问题，部分门店数据未同步到主数据，已导出 Excel 表，后续需自行触发同步。
- 数据范围验证：需验证同步的数据范围，检查库里门店数据状态与同步数据是否一致，筛选出问题要标识反馈。
3. 费用与状态校验
- 费用核对：需核对活动里千川激励费用、签收激励发放来源，若用天马账户支出要与计费部门核对，上次提到让计费部门兜底。
- 状态校验：进行状态校验，确认扫码情况、活动费用和剩余码数量，包括总金额和初始码量。
4. 盘点明细逻辑
- 逻辑介绍：盘点明细表货权经销商销售五段逻辑入口在 CRS one C 项目监听 MQ，通过方法调 data RPC，入参有云上编码、事业部编码和 OU ID。
- 问题处理：查询经销商信息时未判断主数据状态，需查看 MySQL 表中 XML 部分 SQL 语句，调用 RPC 时也未对经销商主数据状态进行判断。
- 历史数据修复：询问是否修复历史数据，金玉萍之前 PRD 里写修复 2026 年 1 月 1 号之后的数据，会后和小娜老师等人确认。
5. 数据处理与补数
- Kafka 消息组装：在 CRS 中提供一个 controller 接口，盘点完后发消息到 CRS async，消费消息并进行数据组装，包含窜货规则判断等逻辑。
- 补数任务：有常态化定时补数任务，如经销商货权签收时间相关，补数是缺哪补哪，除非必要不走整个逻辑。
6. 代码评审与 PRD 回溯
- 代码评审：希望老师们帮忙评审代码，因建立老师在别的会，不行再约时间一起看，发言人曾和建老师私下看过源码。
- PRD 回溯：要求东东回溯玉平加罗毅的产品走查 PRD 5.7，查看当时版本里其他报表是否有类似逻辑诉求，若有则在群里同步并更新到文档，东东会翻文档并找玉婷。
图片上传与信息安全方案讨论会
会议讨论了图片上传、信息安全、存储方案、活动情况、报表导出等问题，并对相关解决方案进行了评估和探讨。
小结
1. 图片上传问题
- 资源缺失：704 需发布，但目前无资源开展上传工作。
- 草稿与图片：建草稿已完成，共读所需图片只有其他功能的环境照片示意图，可提供查看。
2. 图片信息安全
- 隐私问题：图片涉及员工姓名和 ID，可能涉及数据隐私，需判断是否为敏感信息。
- 信息确认：向金老师确认拍摄组件里有员工信息和姓名，语霖认同。
- 评估建议：建议找安全总监李恒评估信息是否敏感，明确评估后流程卡点。
3. 图片存储方案
- 非敏感信息存储：若图片非敏感信息，放公共读的公共桶，导报表带图片 COS 地址可直接访问。文件名可加 PM，括号里放文件 ID 名称。
- 敏感信息存储：若图片敏感，放自有读写桶，访问走鉴权。鉴权有时效，带有时间戳，链接过期需获取新链接。
4. 活动相关事宜
- 活动时间：红包活动从今天开始到 20 号，活动上线时间未确定。
- 活动改造：活动改造需评估安全性，采用链接方式请求并发量不大可直连系统，改造则需上传图片、改变业务链路。
5. 报表导出问题
- 导出需求：物码违规销售表需有图片导出，用于督办单扣款证据，用户可接受 URL 地址有时效性，最多 24 小时，过期需重新下载。
- 导出难题：查证明细表环境照片洗不到物码违规销售表；私有链接有时效性，鉴权信息会暴露。
6. 解决方案评估
- 存标识方案：存照片标识，但只能解决前端查单问题，无法解决报表导出和中台洗数据问题。
- 加密链接方案：前端页面设置查看权限，对图片链接加密后返给前台，但中台报表无相关数据。
- 方案评估与测试：将各方案成本、影响等内容写全，记录数据迁移事宜。估算加 bucket 解析和生成私有链接耗时，测试 COS 限流访问量。列出解决方案，写明优缺点，考虑是否保留以前配置内容。