2026-05-13 工作日志
项目进度同步会
本次会议同步了体验优化、数据治理、TWW系统改造等项目进展，并明确了多项待办事项。
小结
1. 体验优化
- 提示语优化：已完成四个场景的文案梳理，将最终确定文案。
- 报表优化：已与业务侧确认，将分两部分进行，筛选条件和交互将与中台统一风格，列控报表的文档修改已完成。
- 定位服务：定位服务已于昨日上线，可进行验证。
2. 数据治理
- 智慧门店数据一致性：客户差异问题已确认方案和排期；店主店长店员差异问题已输出清单，将与主数据侧沟通解决方案；已建立自动化监控机制。
- 主数据与小智数据：已识别到数据同步报文中存在非数据异常的错误信息，将通过对接群同步给各端排查。
- 批次号问题：针对分仓拆箱可能导致批次号不唯一的问题，已明确TTS侧将在528版本上线相关改造。
3. TWW系统改造与订单差异
- TWW系统改造：为解决OU问题，初步排期在月底，将尽快与各方确认最终排期。
- 云商多次签收：已定位问题原因为历史的手动签收功能，将与高超经理沟通解决方案。
4. 技术专项
- 全局埋点：已完成开发，将启动梳理自定义埋点需求。
- APM监控：明确了后续工作，需产品侧先明确核心业务模块和页面，再由技术侧进行性能分析。
- 微服务架构：微服务注册组件的NFS存储将进行技术验证，验证通过后考虑迁移至本地盘。
5. 遗留问题与风险
- 528版本上线：针对扫码加锁功能，需关注其对前端操作性能的影响。
- B端出货规则控制：因涉及新增接口，存在压测风险，需线下讨论应对策略。
待办
1. 体验优化
- 完成提示语优化的最终文案定稿。@李赵丹
- 完成报表优化相关文档的修改并确认整体排期。@余建新
- 补充"手机号、经纬度、经销商出货时间"这三个缺失数据的方案并确认排期。@余建新
- 拆分自助开单和日常签收的两个版本。@余建新
2. 数据治理
- 推动智慧门店与主数据侧的数据一致性问题进行深度剖析。@邢健
- 协调各端产品经理跟进小智与TTS系统的接口报错问题。@邢健
3. TWW系统改造
- 与李超经理及TTS侧确认TWW系统改造的最终排期。@陈祺
4. 订单差异与签收问题
- 在周四与高超经理沟通云商多次签收问题的具体解决方案。@陈祺
- 在今天内与高超经理沟通并敲定528版本加锁功能的最终排期。@刘晓娜
5. 技术专项
- 补充泳道图梳理的技术相关内容。@张建利
- 完成微服务NFS存储迁移的技术验证，并在验证通过后制定生产环境迁移排期。@邱毅
6. 遗留问题跟进
- 评估"B端出货明细表"增加实时产品状态的需求合理性。@余建新
- 评估"扫码签收自动带入出货门店"功能方案的必要性，并与业务侧确认。@任铭
- 评估"扫码加锁"功能对前端性能的影响。@余建新
- 完成"扫码加锁"功能的内部BRD评审。@孙东栋
- 协调PM管理系统账号以便录入潜在需求。@王轩春
"扫码即签收"功能压测方案讨论
本次会议主要讨论了"扫码即签收"功能的压测方案，明确了压测范围、目标、时间计划及相关负责人。
小结
1. "扫码即签收"功能压测方案
- 压测范围：明确需对"扫码即签收"接口和"距离判断"接口进行压测。
- 压测目标：
- "扫码即签收"接口需达到 748 TPS（每秒处理748次请求），响应时间P95小于 500毫秒
- "距离判断"接口需评估其性能并确保在整体链路中响应时间可控
- 压测时间：
- "扫码即签收"接口的压测计划于 5月15日 启动
- "距离判断"接口的压测计划将根据环境准备情况另行安排
2. 压测环境与数据准备
- 环境：需要将压测环境资源扩容至与生产环境一致的规格。
- 数据：
- "扫码即签收"接口的压测将使用由测试人员准备的大量测试数据
- "距离判断"接口的压测将使用由后端提供的、包含有效5段组合ID的真实数据
3. 文档规范
为确保各团队对需求理解一致，后续所有相关文档需从PRD中摘录并标准化接口编码、地址等信息。
待办
1. "扫码即签收"功能压测
- 张喜负责准备压测所需的真实数据（包含有效的5段组合ID），并提供给测试人员。
- 吕杰负责准备压测数据并编写压测方案，于 5月15日 启动压测。
- 张喜负责在 5月14日 或更早时间提出工单，将压测环境资源扩容至生产环境规格。
2. "距离判断"接口压测
- 吕杰负责准备压测所需的真实数据（包含有效的5段组合ID），并提供给测试人员。
3. 文档与报告
- 郑然然负责提供压测方案的模板。
- 吕杰负责在压测结束后，将压测报告和压测方案一同整理并输出。
4. 其他
- 吕杰负责在压测结束后，与相关人员核对环境配置是否正确。
- 吕杰负责在压测结束后，组织相关人员对压测结果进行评审并对齐。
AI训练营复盘
本次会议为AI训练营的复盘，回顾了学员的成长历程，分析了项目中的优秀实践与待改进之处，并解答了学员提出的50个问题。
小结
1. 训练营回顾与学员成长
- 初期状态：学员初期倾向于直接将AI生成的答案进行格式修改后提交，缺乏对AI输出准确性的判断能力。
- 成长过程：通过四次网课、线下实操和独立开发，学员们逐步掌握了AI原生的思维方式，能够主动思考一个场景是否适合用AI解决，并具备了设计Agent架构的能力。
- 最终状态：学员已能独立完成复杂的Agent搭建（如15-20个节点），并能主动排查问题，形成了从"看"到"做"再到"独立思考"的能力跃迁。
2. 项目优秀实践与待改进之处
- 准确性：优秀的案例通过拆解场景边界、设计多分支路径（如文件格式错误、知识库未命中等）来提升准确性。同时，优化知识库分块策略和为高频问题维护标准答案也是提升准确性的有效方法。
- 稳定性：通过为大模型和工具节点设置重试机制与异常分支、使用轻量模型压缩多轮对话历史等方式来提升稳定性。
- 速度与成本：通过使用轻量模型处理非核心任务（如意图识别）、为不同任务链路设置匹配的模型和动态调整token上限等方式，在保证速度的同时有效控制成本。
- 可控性与合规性：优秀的案例体现了良好的版本管理和清晰的节点命名习惯，便于后期维护。同时，通过平台级敏感词过滤和提示词中的软约束来确保合规。
3. 学员问题解答
会议对学员提交的50个问题进行了分类整理，并基于"密塔AI"等高质量信息源，结合团队经验给出了详尽的解答。
- 核心问题：重点讨论了上下文传递的挑战，提出了最小信息原则、Supervisor架构、分布式记忆等多种管理策略。
- 通用方法论：强调了将复杂业务拆解为SOP、参考社区模板、使用控制变量法排查Prompt或模型问题等通用方法。
待办
1. 填写问题问卷
- 鼓励尚未填写问卷的学员补充自己的疑问，以便团队持续优化后续的学习内容。@HNU
数据修复任务讨论会
本次会议主要讨论了三项数据修复任务，明确了修复方案和优先级。
小结
1. 数据修复任务
- 任务一：修复日常开单与自主签收数据，需补充收货人和签收人的手机号信息。由于数据加密导致无法直接查询，需通过编写代码进行解密补充。
- 任务二：补充签收人的经纬度数据。由于签收人无此信息，导致在补收货人出货地址时数据为空。
- 任务三：补充经销商的签收时间。因系统与TDS存在约5分钟的数据同步延迟，导致部分已出货的订单在B端出货明细表中缺少签收时间。
2. 数据同步延迟问题分析
会议深入探讨了数据同步延迟的根本原因：TDS更新签收时间后，需经过"云商"再到"GPS"系统，导致数据链路较长。 王建朝指出，即使数据中台直接读取"中间表"，也无法从根本上解决因业务流程异步导致的5分钟延迟问题。
待办
1. 数据修复方案排期
- 张喜需在会后尽快确认并提供三项数据修复任务的具体方案及完成排期。
2. 数据修复任务执行
- 优先级最高：先处理"经销商签收时间"的缺失问题，通过定时任务每日补充。
- 次优先：处理"日常开单"与"自主签收"数据的手机号补充问题，可采用已评审过的方案先行执行。
MongoDB货权经销商名称缺失数据修复方案讨论
本次会议主要讨论了MongoDB基础码表中"货权经销商"名称为空的历史数据问题，并确定了通过SQL脚本进行修复的技术方案。
小结
1. 问题背景与目标
- 问题：MongoDB基础码表code_info中存在约73万条数据，其"货权经销商"字段仅有编码而无名称，导致"新鲜度盘点"等报表出现数据异常。
- 目标：修复该数据质量问题，确保盘点报表中的经销商名称正确显示。
2. 解决方案与技术讨论
- 核心思路：将数据修复过程拆分为两个步骤，以降低对MongoDB的压力。
- 第一步：在MySQL的SR临时表中，将缺失的"货权经销商"名称进行补齐。
- 第二步：使用SQL脚本，基于第一步中已补齐数据的SR临时表，直接更新MongoDB中的code_info主数据表。
- 实现方式：经讨论，确认可以通过编写SQL脚本来实现数据更新，无需编写复杂的代码，可由韩冬冬会后完成。
3. 明确后续需求
- 数据范围：需要明确需要修复数据的具体时间范围，以便精准地从SR表中筛选数据。
- StarRocks表优化：会议中发现用于数据抽取的StarRocks表缺少时间戳字段，这是一个模型设计缺陷，需要后续跟进修复。
待办
1. 明确数据修复范围
- 韩冬冬需与徐彤老师沟通，明确需要修复数据的精确时间范围（如起止时间戳），以便后续筛选。
2. 修复StarRocks表结构
- 韩冬冬需与徐彤老师沟通，推动在StarRocks的盘点明细表中增加时间戳字段，以支持后续的数据抽取和更新。
3. 编写并评审SQL脚本
- 韩冬冬需使用Circle工具编写SQL脚本，用于从SR临时表更新MongoDB中的code_info表。
- 韩冬冬编写完成后，需同步给马奇，以便组织相关人员进行快速评审。