Work for YILI

Appearance

2026-08-20 工作日志 ​

项目管理系统推进会 ​

本次会议围绕项目管理系统推进展开，重点同步了移动端看板、PC端报表、积分运营及APM接入等议题进展，并明确了各项任务的下一步计划与负责人。

小结 ​

1. 移动端与PC端报表进展

  • 智慧门店看板暂缓：黄磊确认暂不做智慧门店看板，具体卡点与考量因素待进一步沟通后同步，该事项将在明日周会上进行共识对齐。
  • 小智看板明确推进：小智看板已纳入既定计划且BRD已通过，需关注后续调整并在周会汇报。
  • PC端P1级报表准备：本周完成用例邮件编写并与黄磊预约下周的UAT测试。
  • 生产流向报表评审：计划于下周开展PRD评审会议。
  • 其他PC端报表优化：相关优化内容将陆续更新至项目管理系统中跟踪。

2. 积分运营需求推进

  • 集成测试时间调整：SFA进入集成测试的时间调整为9月1日，计费与卡券模块调整为9月4日，整体对9月20日上线目标无影响。
  • 集中测试安排待定：暂不安排现场测试，待集成测试阶段视开发质量情况再决定是否安排集中测试，需提前沟通以防临时变动。
  • UI页面调整确认：智慧门店小程序首页与钱包页的UI存在调整，需尽快约业务方召开UI确认会。
    • 晓娜负责：确认自身准备工作并完成PRD评审，同时跟进计费侧进度。
    • 亚洲哥负责：确认业务侧UI输出是否就绪，以便协调双方时间开会。

3. APM接入与数据监控

  • APM接入初步定档827：因可能影响性能，已与供应商拉通对接，将于周五再次沟通评估潜在影响。
  • 数据一致性排查：邢健需在会后先行思考数据一致性问题。
  • 智慧门店店主监控告警：昨日出现告警，今日将分析问题原因。
  • 小智系统数据初始化：已完成接口数据初始化并重新对齐数据，确保无误，后续仅需做客户多OU数据的监控。
  • 主数据与小智系统梳理：周四需完成主数据和小智系统关于监控语句的梳理工作。
    • 陈思负责：协同供应商共同完成上述梳理任务。

AI黑客松挑战赛项目分享会 ​

本次黑客松AI挑战赛围绕知识解析工具、架构评审智能体及老系统BrowserUse能力建设三个项目展开，明确了各项目的技术架构、落地场景与后续演进方向，并针对业务价值、生产级验证及跨团队协同提出了优化建议。

小结 ​

1. 知识解析工具项目分享与点评

  • 业务痛点与定位：面向婴儿粉育儿师问答场景，解决非结构化图文视频素材依赖人工处理、效率低且难以持续的问题，定位为面向内部业务的自动化知识解析工具。
  • 流水线设计与实现：将素材处理拆为五步流程，采用双层双引擎并行架构保障质量稳定。
    • 图片解析：采用OCR提取文字坐标与置信度，结合版面分析模型识别阅读顺序，辅以大模型生成结构化信息。
    • 视频解析：通过抽帧去重、语音转写及画面理解三路融合，最终输出摘要、标签等六类结构化信息。
  • 效能提升与未来规划：日均处理量从人工的20条提升至50至150条，效率提升2.5至4.5倍，后续规划涵盖扩展格式、服务中台化、开放接口及质量迭代。
  • 刘洋老师点评建议：需进一步清晰数据处理的上下链路及最终端侧效果，并思考多元化文档处理后的知识积累与管理方式。
  • 尚总点评建议：应将该能力沉淀为通用基础能力，并评估产出速度与成本，结合AI团队整体方向进行积累。

2. 架构评审智能体项目分享与点评

  • 背景与目标：针对系统建设模式多样化导致评审内容差异大的问题，建立标准化、可追溯的架构预审机制，以提前暴露风险并沉淀评审方法论。
  • 产品方案与技术实现：一期以固定版本资料为任务边界，采用确定性六步处理管线而非多智能体自由规划，确保过程可控可解释。
  • 试点验证与升级规划：当前版本已跑通基础链路并在直播运营管理平台完成试点，后续需补齐评分汇总、证据定位及一致性检查等技术能力。
  • 贺明总点评建议：一期应先梳理日常评审中必须与非必须的项供AI筛选，二期再考虑受业务战略、时间窗口等因素影响的架构设计权衡点。
  • 尚总点评建议：需与技术管理协同探索，避免小范围开发，更多联合业务模块在真实场景中落地创造直接业务价值。

3. 老系统BrowserUse能力建设分享与点评

  • 接入路径对比与选型：对比MCP改造、传统RPA及其他通用Agent方案，选定复用存量页面且提供人机协同的BrowserUse模式，适用于缺乏智能化改造能力的老旧系统。
  • 安全隔离与技术创新：通过专属隔离浏览器、服务端硬边界控制及DOM与视觉混合识别，实现大模型对网页的安全操作。
    • 环境隔离：单次任务单用户单实例，凭证保护与账号身份强一致校验。
    • 执行边界：域名白名单控制，高风险动作强制执行阻断或转人工。
    • 视觉辅助：仅作为只读校验证据，不直接操作浏览器，利用DOM驱动字段引擎定位写入。
  • 业务价值与现状：使老旧系统无需改造即可快速接入Agent时代，已在测试环境验证OA内游外游与工作微博场景，即将在生产环境逐步开放。
  • 刘洋老师点评建议：需在复杂生产级页面上充分验证成功率，并锁定高价值核心场景以应对庞大的Token消耗问题。

4. 跨项目综合反馈与建议

  • AI产品经理技能演进：指出数字化时代的PM与生产级Agent PM存在根本性差异，后者需具备极强的架构能力，涵盖技术、数据及知识Skills认知。
  • 跨团队协同要求：技术人员不应在小范围闭门造车，需与生活中心等业务部门紧密协同，推动产品在真实业务场景中落地应用。

待办 ​

1. 移动端 / PC端报表

  • 黄磊需在明日周会上就"暂不做智慧门店看板"的决策进行共识对齐，并同步具体卡点与考量因素。 — @黄磊
  • 关注小智看板后续调整，并在周会汇报进展。 — （待定）
  • 本周完成 P1 级报表用例邮件编写，并与黄磊预约下周 UAT 测试。 — （待定）
  • 计划下周组织生产流向报表 PRD 评审会议。 — （待定）
  • 将其他 PC 端报表优化内容陆续更新至项目管理系统跟踪。 — （待定）

2. 积分运营需求

  • 晓娜需确认自身准备工作并完成 PRD 评审，同时跟进计费侧进度。 — @晓娜
  • 亚洲哥需确认业务侧 UI 输出是否就绪，以便协调双方时间召开 UI 确认会。 — @亚洲哥
  • 集成测试窗口：SFA 9/1、计费与卡券 9/4，需提前沟通集中测试安排以防临时变动。 — （待定）

3. APM接入与数据监控

  • 邢健需在会后先行思考数据一致性问题。 — @邢健
  • 今日分析智慧门店店主监控昨日告警的原因。 — （待定）
  • 陈思需协同供应商，在周四完成主数据与小智系统监控语句的梳理。 — @陈思
  • 周五与供应商再次沟通评估 APM 接入（定档 827）的潜在性能影响。 — （待定）

4. AI黑客松挑战赛项目分享会

  • 知识解析工具：明确数据处理上下链路与端侧最终效果，并设计多元化文档处理后的知识积累与管理机制；同步沉淀为通用基础能力，评估产出速度与成本。 — （知识解析工具团队）
  • 架构评审智能体：一期梳理日常评审"必须"与"非必须"项供AI筛选，二期再纳入架构设计权衡点；并与技术管理协同，联合业务模块在真实场景落地。 — （架构评审智能体团队）
  • 老系统BrowserUse：在复杂生产级页面充分验证操作成功率，锁定高价值核心场景以控制Token消耗；推进生产环境逐步开放。 — （BrowserUse能力团队）
  • 跨团队协同：技术人员避免小范围闭门造车，与生活中心等业务部门紧密协同，推动产品在真实业务场景中落地。 — （各AI项目负责人）

经销商MQ配置生效问题处理 ​

后补经销商 MQ 配置的图串（配置流程）导致服务先启用、后配置 Nacos，配置未生效，今日需重新发版。优雅停机优化调整为今日进行配置更新，配置更新后将随后续迭代发版自动升级。

小结 ​

1. 配置未生效根因

  • 经销商 MQ 配置为后补项，经图串（配置流程）写入，发布顺序出现偏差：服务先完成启用，Nacos 配置后写入，导致服务启动时未读取到该配置，配置未生效。

2. 处置措施

  • 重新发版：今日对经销商 MQ 配置相关服务重新发版，确保 Nacos 配置就绪后再启用服务，使配置正确生效。
  • 优雅停机优化改配置更新：将原本需发版的优雅停机优化，调整为今日通过 Nacos 配置更新完成；配置更新后会随后续迭代的发版自动升级，无需单独发版。

待办 ​

5. 经销商MQ配置重发版与配置更新

  • 今日完成经销商 MQ 配置相关服务重新发版，确保 Nacos 配置先于服务启用生效。 — （待定）
  • 今日完成优雅停机优化的 Nacos 配置更新，使后续迭代发版自动升级。 — （待定）

数据修复与业务逻辑调整评审会 ​

本次评审会聚焦数据修复与业务逻辑调整，明确了Sqv盘点明细表修复改用SQL执行，并确认了呼市暂存库数据异常修复方案及串货判断逻辑回退需求。

小结 ​

1. Sqv活动兑换积分异常数据修复

  • 明确采用SQL直接修复：针对806版本Data服务故障导致的35条产品信息为空问题，放弃原定定时任务方案，改为使用SQL脚本本地执行。
  • 核心考量与原则：因仅涉及35条少量数据且已停止新增异常，直接使用SQL能精准控制影响范围；后续若出现大规模丢数场景，应优先排查修复系统Bug而非依赖通用补数任务。

2. 盘点明细表经销商信息缺失修复

  • 明确修复逻辑与范围：针对底表OUID传错导致1328条盘点经销商信息为空的异常，需先修正底表暂存库OUID，再通过Mongo Shell清洗新老表数据并同步至中台。
  • 需补充背景与分类说明：会议认为当前方案将两种不同原因导致的数据缺失混为一谈，需在技术方案中补充背景原因、时间范围及两类数据的各自占比。
    • 呼市暂存库误传：小智系统传错OUID（实际应为740，误传为102）导致的数据缺失。
    • Data服务异常：RPC调用失败导致查询失败而引发的数据缺失（约60余条）。
  • 前端校验机制待优化：针对前端传入OUID与经销商关系不匹配即落库的问题，建议增加校验提示或阻断入库，避免产生无效脏数据。

3. 串货判断逻辑回退与查证接口改造

  • 还原串货判断主数据逻辑：将806版本新增的"门店关联经销商列表"用于串货判断的逻辑回退至上版，恢复从主数据获取列表进行比对，以解决前端选错经销商导致的流向异常误判。
  • 新增非必填距离字段：在查证接口新增非必填的"查证距离门店仓库的距离"字段，后续若前端传值则自动处理落表，不影响现有其他端功能。
  • 强化终端扫码交互反馈：针对品与所选经销商不匹配的情况，建议从产品侧推动上游终端直接提示用户选择错误，而非单纯依赖后端逻辑兜底。

待办 ​

6. 数据修复与业务逻辑调整

  • 今晚上线盘点明细表经销商信息修复脚本。 — @潘玉平
  • 补充盘点明细表修复方案中的背景原因、时间范围及两类异常数据的占比说明。 — @潘玉平
  • 评估并在接口层增加OUID与经销商关系的校验拦截机制。 — @张建利
  • 跟产品及上游沟通，要求终端在扫码时提示品与经销商不匹配的错误。 — @宋洋