Work for YILI

Appearance

2026-07-22 工作日志 ​

各模块开发联调进展与测试推进策略讨论会 ​

本次会议主要讨论了各模块的开发联调进展，明确了扫码机盘点等功能因开发未完成而无法进入测试，并商讨了后续的测试推进策略。

小结 ​

1. 各模块开发进展与测试阻塞问题

  • 扫码机盘点：接口联调仍在进行中，尚未完成，因此不具备进入测试的条件。
  • 智慧门店：开发工作尚未完成，预计下周才可进行单元自测，因此无法进入集成测试。
  • 销售团队中心：开发无问题，可进入测试。
  • 营销活动中心：开发无问题，可进入测试。

2. 测试推进策略

  • 当前因"扫码机盘点"和"智慧门店"两个核心模块未完成开发，导致整体项目无法按计划进入测试。
  • 讨论认为，为确保测试的顺利进行，需要确保至少有两个核心模块（如 SFA 和小智）的状态为"可测试"，才能启动集成测试。

待办 ​

1. 各模块状态确认

  • 陈思需再次确认"小智"模块是否存在问题。
  • 李宝仟需跟进"扫码机盘点"接口的联调进展。
  • 李宝仟需催促"智慧门店"项目组了解其开发延迟的具体原因。

智慧门店扫码查证GPS定位飘移风险识别 ​

在测试用例评审过程中，识别到智慧门店在扫码查证时，会根据用户定位匹配一个最近的门店，并将其作为用户的当前门店传给营销活动中心。该方案依赖用户 GPS 定位的准确性，存在模糊定位下定位飘移的潜在风险。

小结 ​

1. 风险机理

  • 智慧门店扫码查证时，根据用户 GPS 定位匹配最近门店，并将该门店作为"当前门店"传给营销活动中心。
  • 方案依赖用户 GPS 定位准确性；手机 GPS 含精确定位与模糊定位等方式，模糊定位下用户 GPS 可能飘移至数公里以外。

2. 影响与后果

  • 若实际在 A 门店（如诺德物美）扫码，但定位飘到 B 区域（如首经贸），系统会将 B 周边门店传给营销活动中心。
  • 导致营销活动中心在执行查证及签收时出现异常签收，并出现退货并异常自主签收的情况。
  • 产生与实际业务不匹配的数据，增加运营/运维工作，需营销活动中心进行数据修复。

3. 后续建议

  • 需评估 GPS 飘移应对方案（如定位精度校验、门店匹配兜底、异常签收拦截），并指定责任人与跟进计划。（待补充）

查证签收与盘点签收详细用例评审会 ​

本次会议评审了查证签收与盘点签收的详细用例，明确了不同场景下的业务逻辑、异常处理及 UI 表现。

小结 ​

1. 查证签收与盘点签收核心逻辑

  • 货权一致性：货权经销商与查证/盘点经销商不一致时，产生异常签收或退货记录；一致时为正常签收。
  • 门店一致性：门店与查证/盘点门店不一致时，产生退货记录；一致时为正常签收或异常签收。
  • 签收激励：仅对正常签收（如自主签收）发放激励，异常签收（如查证异常签收）不发放激励。

2. 特殊场景处理

  • 多经销商门店：智慧门店扫码查证时传回关联的所有经销商，后端按电子围栏、品相等信息匹配货权，匹配则视为一致，不匹配则视为不一致。
  • 距离校验：智慧门店查证或盘点需在 500 米范围内，超过 500 米无法调用接口并进行操作。
  • 作弊与 OCR：作弊场景记录作弊明细，不影响正常盘点或签收流程；OCR 盘点与扫码盘点为同步接口，可并行处理。

3. UI 表现问题

  • 异常签收状态提示：收货码签收时，若同一箱内存在多种异常签收（如查证签收、盘点签收、查证异常签收等），前端 UI 统一提示"已签收"，无法区分具体异常类型。

待办 ​

1. 多经销商门店处理逻辑

  • 宋洋需在 PRD 中明确：智慧门店传回多个经销商时，后端如何匹配与取值。——宋洋

2. 异常签收 UI 表现优化

  • 任铭更新 PRD，备注收货码签收多种异常时前端统一显示"已签收"。——任铭
  • 张玉婷同步更新三方测试用例，将 UI 表现描述为"已签收"。——张玉婷
  • 任铭协调各方，推动前端 UI 文案修改。——任铭

3. 门店距离校验逻辑确认

  • 梁岩会后再次确认门店距离校验的具体逻辑，并将结论同步给刘莉。——梁岩

4. 测试用例完善

  • 刘莉补充"未出已签"在仓库查证时因门店不一致生成退货记录的场景。——刘莉
  • 刘莉补充"未出已签"在门店查证时因门店不一致生成退货记录的场景。——刘莉
  • 刘莉补充 OCR 盘点的相关测试用例。——刘莉

5. 开发联调与测试

  • 张喜负责跟进开发联调和单元测试的进度。——张喜

智能体平台建设规划周会 ​

本次会议为项目首次周会，同步了智能体平台建设的整体规划，并对各模块的周进展及风险进行了同步。

小结 ​

1. 智能体平台建设规划

  • 第一阶段（7-8 月）：完成各模块智能体的搭建。
  • 第二阶段（9 月）：完成智能体与统一开发平台的整合。
  • 第三阶段（10 月）：落地功能统计看板及 MCP 试点功能。

2. 开发流程与规范

  • 周会安排：各项目组需在周二或周三完成周计划并给出结论，以便于沟通协同。
  • 版本发布：平台将实行每月月底发版制。
  • 代码管理：高代码部分的代码分支由平台侧统一创建和管理。
  • AI 工具使用：为保证数据安全，建议各团队优先使用公司提供的 AI 工具（如 AI Defi），而非第三方工具。

3. 各模块进展同步

  • 智能体开发：王建朝的 Agent 开发进度约 90%；刘曌阳因任务紧张，本周暂未开始。
  • 云平台成本计算：陈强已完成成本计算逻辑的梳理，正在完善中。
  • 系统巡检 Agent：杨华峰已完成指标采集需求和方案，正在进行指标制定和报告生成。
  • 磁盘管理 Agent：白晨凡已完成磁盘扫描、采集及预警功能的开发，整体进度正常。
  • 运维知识库 Agent：温浩已完成需求整理，本周将进行 PRD 的整理工作。
  • 数据库调优 Agent：施少华已完成初步方案沟通，本周正在进行服务器采集模块的开发。
  • AI 平台对接：崔建瑞已完成 AI 编码和知识库的初步对接，大模型网关对接因资源申请问题，预计明天可测试通过。

待办 ​

1. AI 模型资源需求上报

  • 高代码开发的同学需在今天或明天下班前，将各 Agent 所需的大模型资源（模型名称、选型原因等）维护到指定文档，以便平台侧统一申请开通。——崔建瑞

2. 各模块周报更新

  • 刘曌阳需将个人工作计划的"完成情况"和"预计完成时间"字段更新。——刘曌阳
  • 张世杰需将 AI Defi 集成到技术管理平台的计划更新至文档中。——张世杰
  • 李兴南需将云平台 Agent 的进度同步更新至文档。——李兴南
  • 温浩需将运维知识库 Agent 的 PRD 整理进度更新至文档。——温浩

3. 技术方案沟通

  • 郭崇岭关于"自动备份恢复 Agent"采用 AI 生成脚本并部署在服务器上执行的方案，需会后与徐俊凯进一步沟通确认。——郭崇岭
  • 施少华关于"数据库调优 Agent"在服务器上采集信息并生成报告的方案，需会后与徐俊凯进行沟通。——施少华

消费者中奖明细表活动信息拆分与数据修复需求讨论会 ​

本次会议讨论了消费者中奖明细表的活动信息拆分与数据修复需求，明确了不同场景的修复方案、数据量评估以及后续的优化方向。

小结 ​

1. 消费者中奖明细表数据修复需求

  • 背景：由于历史原因，原"活动信息"字段同时包含了 B 端和 C 端信息，现需将其拆分为独立的 B 端和 C 端活动信息。
  • 范围：本次修复范围为 2025 年 1 月 1 日至今的数据，总量约 2500 万条。

2. 数据修复方案与分类

  • C 端活动：数据无需清洗，因其已正确存储在新增的 C 端字段中。
  • B 端活动：需将原存储在 C 端字段中的 B 端信息，回填至新增的 B 端活动信息字段。
  • BC 一体化活动：需从售卖激励表中查询并补充 B 端活动信息；若无，则降级为 C 端活动。
  • 全国活动：需根据品牌 code（如 002、470）进行区分，将"草原酸奶"等品牌的数据按其具体活动类型进行拆分。

3. 方案优化与执行计划

  • 数据量优化：提出可与业务方沟通，将"经典""安慕希"等品牌的全国活动统一归为"经典活动"，以减少约 1200 万条数据的修复量。
  • 执行策略：采用分批处理（如每批 1000 条）的方式，并通过游标分页实现，以控制对线上服务的影响。
  • 验证方案：计划通过导出处理后的数据进行抽样检查，核对数据量和关键字段（如活动名称、类型）的准确性。

待办 ​

1. 业务范围确认

  • 与业务方（德智、陈娜）沟通，确认是否可以将"经典""安慕希"等品牌的全国活动统一归为"经典活动"，以减少数据修复量。——李明非

2. 技术方案更新

  • 更新技术方案文档，确保其包含最新的字段变更说明。——孙世文

3. 生产环境验证方案补充

  • 在方案文档中补充生产环境的数据处理验证方案。——李明非

4. 执行效率评估

  • 在生产环境先执行少量数据（如 100 条），验证处理效率和准确性，以便评估整体处理耗时。——李明非

BRD Agent 功能开发与优化（个人交付） ​

完成的功能与优化 ​

1. BRD 数据权限控制 ✅

  • 提取公共权限校验方法 getTaskAndCheckPermission(taskId)，校验任务存在且属于当前用户。
  • 列表查询强制添加 created_by = 当前用户 条件，移除管理员全量查看权限；所有单任务接口（状态/进度/详情/评审项/删除）均增加权限校验。
  • 越权访问返回 null/空列表并记录 warn 日志；前端移除"提交人"筛选框及相关代码。
  • 涉及文件：后端 BrdReviewServiceImpl.java、前端 BrdList.vue；提交 5739339、081d1362。

2. 文档反向同步更新（V1.1 版本） ✅

  • 按实际代码实现更新三份文档并按日期生成新版本（原文件保留）：业务需求文档、技术方案文档、系统功能设计（HTML）。
  • 主要更新：标记 Phase 1 MVP 核心流程 100% 完成；新增企业微信机器人通知（WeChatWorkNotifier，markdown_v2）、数据权限控制章节、列表查询性能优化（字段裁剪 + 复合索引）；更正实际技术栈（Arco Design Vue 非 Element UI、OkHttp、BrdDbInitializer 自动建表）；同步 API 契约与目录结构。

3. 文件上传类型筛选 ✅

  • 前端 accept 限定 .docx/.pdf/.md/.txt，文件选择对话框仅显示此四类；移除对 .doc（POI XWPFDocument 不支持旧版格式，原代码会运行时报错）。
  • 前后端双重校验，统一错误提示"仅支持 docx/pdf/md/txt"；步骤条描述补全 txt。
  • 涉及文件：前端 BrdUploadStep.vue/BrdReview.vue、后端 BrdFileServiceImpl.java/DocParser.java/BrdFileController.java；提交 a0cf664、58cb98bf。

4. 服务安全重启机制 ✅

  • 固化安全规则：重启前用 lsof -ti:端口 获取进程列表，逐个检查命令行，仅 kill 含 tech-management/tech-agent（后端 Java）或 vue-cli-service（前端 Node）的进程。
  • 禁止 pkill -f java/pkill -f node 等模糊匹配；保留微信开发者工具、腾讯会议、TRAE IDE 等进程不受影响；端口未释放时等待重试。

5. Git 版本管理 ✅

  • 规范提交并保持工作区干净；今日提交：5739339（权限控制）、081d1362（移除提交人筛选框）、a0cf664（上传类型限制）、58cb98bf（前端类型筛选）。

小结 ​

  • 今日 BRD Agent 完成数据权限控制、文档反向同步（V1.1）、上传类型筛选、服务安全重启机制、Git 规范管理五项交付，Phase 1 MVP 核心流程已 100% 完成。
  • 技术纪律提升：权限最小化（越权返回空 + warn 日志）、前后端双重校验、服务重启精确进程识别避免误杀其他应用，体现"安全与规范前置"的工程素养。