Work for YILI

Appearance

2026-09-21 工作日志 ​

物码早会：项目进度同步与合同登记 ​

发言人：李亚洲、刘晓娜、邢健、吴菊、孙东栋等7人

本次会议同步了各项目测试排期与数据清洗进度，明确了合同费用登记要求，并安排了相关后续排查与确认工作。

小结 ​

1. 项目测试与排期同步

  • 取消业务UAT：因业务方需配合冷饮项目，取消业务UAT，由团队内部完成正常测试后直接上线。
  • 保障钱包展示正常：上线时间维持10月15日，需确保冷饮和热奶在钱包部分的展示正常。
  • 持续进行集成测试：各端需每日参与集成测试，测试与逆向需求将统一在修订版中更新排期。
  • 门店积分排期：门店积分项目的具体排期需在今天内完成并输出。

2. 数据清洗与监控进展

  • 门店与经销商关系比对：郑然需完成门店与经销商关系数据比对清单的沟通，并安排陈思查看。
  • 导购与门店历史数据清洗：零营销活动中心需完成导购与门店的历史数据清洗工作，晓娜需安排相关资源支持。
  • 排查序号9异常数据：营销助手需排查序号为9的异常数据，并在今天完成数据修复。
  • 关注920发版异常修复：今日主要跟进920发版后异常数据的修复情况。

3. 合同费用登记要求

  • 上午完成信息补全：各产品负责人需于今天上午在群内转发的表格中补全所有准备签署的合同信息，下午将由负责人统一检查。
  • 以当前版本为准：补全后的表格将作为最终依据，严禁遗漏，以避免后续费用出现混淆。
  • 今日完成费用增补：各团队需于今天完成费用增补登记，未登记的将视为项目费用已关闭。
  • 整体费用可能超支：根据昨日评估，整体项目费用可能存在超支风险，需尽快完成登记以核实。

待办 ​

1. 郑然

  • 完成门店与经销商关系数据比对清单的沟通，并安排陈思查看。
  • 完成导购与门店的历史数据清洗工作。

2. 刘晓娜

  • 输出门店积分项目的排期。
  • 安排资源支持数据清洗工作。

3. 王琪

  • 排查营销助手中序号为9的异常数据，并完成数据修复。

4. @所有人

  • 今天上午在群内转发的表格中补全所有准备签署的合同信息。
  • 今天完成各自项目的费用增补登记。

营销活动系统需求对齐研讨 ​

发言人：李明非、王建朝、张建利、马奇

本次会议主要对齐了营销活动系统的盘点任务与积分发放方案，明确了经销商维度数据传递逻辑，并确认了相关技术方案与系统菜单配置的后续推进安排。

小结 ​

1. 盘点任务与积分发放方案

  • 盘点任务无需拆分：盘点任务将在10月15日随正常版本上线，逆向需求等首期上线后再做处理。
  • 技术方案需重新评审：盘点任务的技术方案此前仅评审过半，且涉及数据库变更，需重新输出并同步至突击小队群。
  • 盘点任务与新活动模块关联：盘点任务在老营销活动模块中执行，执行后相关数据会推送给新活动模块进行命中等处理。
  • 积分发放与核销链路：新活动模块调用计费系统发放积分，总仓随后统一与卡券进行核对与核销。
  • 经销商维度数据传递：发放积分时，系统会将门店、店长及经销商等数据作为必传字段推送给计费系统，不影响现有接口交互逻辑。
  • 兑换逻辑由童超侧处理：当前活动侧无需额外开发，童超侧在获取积分时增加经销商字段，用户选择门店和经销商后再进行积分兑换。
  • 命中规则已支持经销商维度：活动命中规则中已包含经销商字段，只要前端传入相关数据，系统即可完成逻辑判断。

2. 系统配置与界面调整

  • SIP系统需增加菜单链接：业务人员登录的统一界面（SIP系统）需要增加一个链接至奶酪活动的菜单按钮。
  • 需与陈思确认格式：该链接的具体格式需由小娜联系陈思确认，开发人员按格式提供即可。
  • 活动创建支持经销商维度：在创建积分活动时，现有的活动管理模块已支持配置经销商维度，无需重新开发。
  • 积分与活动通过列表关联：积分活动界面支持从积分中心获取积分列表，通过活动列表与积分进行关联配置。

待办 ​

1. 马奇

  • 与娜老师确认盘点任务是否需要在10月15日上线，确认后同步结果。

2. 李明非

  • 重新输出盘点任务的技术方案并发在群里同步。
  • 根据确认的格式，提供SIP系统统一界面增加奶酪活动链接的配置。

3. @小娜

  • 联系小娜确认SIP系统统一界面增加奶酪活动链接的具体格式。

Agent接入YiliBuddy方案研讨 ​

发言人：刘振源、王建朝、刘阳、王帅龙、王磊等10人

主题摘要：本次会议围绕专项一和专项五共25个Agent接入YiliBuddy展开研讨，明确了高代码Agent通过统一鉴权与UI JSON规范接入的交互方案，并确定了后续试点改造与开发排期计划。

一、Agent接入方案与交互设计 ​

会议首先明确了将现有Agent能力接入YiliBuddy的整体技术路径与前端交互规范，重点解决高代码Agent的接入难点。

1. 接入路径与技术栈分类 ​

  • Dify与低代码Agent直接接入：对于基于Dify平台开发的Agent，可直接通过配置URL和Key完成接入，无需大量改造。
  • 高代码Agent需试点沉淀规范：针对Java和Python开发的高代码Agent，需先选取试点跑通通信协议，沉淀出标准范式后再进行批量接入。

2. 前端交互与表单规范 ​

  • 核心节点封装与右侧展示：高代码Agent的核心输入输出将封装为MCP或CLI工具接入，最终执行结果通过链接在对话流右侧区域展开，支持全屏操作与结果复核。
  • UI JSON规范收集用户输入：用户在调用工具前，系统会通过UI JSON规范自动渲染表单收集必填参数，支持文本框、下拉选、附件上传等组件。
  • 复杂前端交互暂保留原页面：对于包含大量复杂交互（如级联下拉）的高代码前端页面，建议通过自适应布局在右侧直接展示原页面，而非完全拆解为表单。

3. 鉴权与用户身份管理 ​

  • 统一依托OA身份进行互信：系统间的互信与用户身份确认，主要依托OA统一身份进行中间确认，通过OAuth Token换取可信用户身份，避免依赖对话中的文字信息。
  • YiliBuddy用户Token发放规划：YiliBuddy正规划直接发放用户Token给第三方系统，目前已在部分MCP场景中进行测试验证。

二、Skill Hub与数据采集机制 ​

针对用户侧技能发布及执行过程中的数据回传需求，会议明确了Skill Hub的发布机制与数据交互方式。

1. Skill Hub发布与审核机制 ​

  • 月底上线用户侧发布功能：本月底将上线Skill Hub用户侧发布功能，小团队内发布无需审核，大团队或全集团发布需平台管理员审核。

2. 执行结果回传机制 ​

  • 支持Markdown结果回传：Skill在执行过程中生成的Markdown结果，可通过配置对应的工具接口回传到业务管理系统。

三、当前系统现状与改造评估 ​

1. 一智开发平台现状 ​

  • Agent相互独立未串联：目前一智开发平台上的Agent均为独立运行，尚未串联成完整的工作流，且前后端各自鉴权。
  • 鉴权改造为关键卡点：接入YiliBuddy需与平台进行用户认证集成，统一一套鉴权方案是必须完成的改造点。

2. 改造工作量评估 ​

  • 表单集成与结果呈现改造量大：相较于登录鉴权，将所有前端表单转化为YiliBuddy内的录入表单，以及最终结果的标准化呈现，是工作量最大的两块改造。

四、后续推进计划与排期 ​

1. 试点场景跑通 ​

  • 优先跑通设备管理场景：建议先跑通设备管理场景，以此作为高代码Agent接入的参考案例，明确协议与规范。

2. 开发排期规划 ​

  • 需明确各Agent开发周期：方案确定后，需针对25个Agent制定具体的开发周期，并协助YiliBuddy开发团队共同完成接入工作。

五、待办事项 ​

  • 确认YiliBuddy直接发放用户Token的功能是否已上线，并跟进相关审批进度。 刘圣
  • 针对Java和Python开发的高代码Agent，选取试点场景跑通通信协议与接入规范。 刘振源 王建朝
  • 梳理当前25个Agent的技术栈，明确哪些基于Dify开发，哪些为高代码开发，以便分类接入。 刘阳
  • 针对25个Agent制定具体的开发周期排期，并协助YiliBuddy开发团队完成接入工作。 刘阳
  • 跟进设备管理场景的跑通情况，作为高代码Agent接入的参考范式。 刘振源

计费管理：提现与计费模块用例评审 ​

发言人：丁聪、薛梅、李强

主题摘要：本次会议主要对提现与计费模块的测试用例进行了评审，明确了批次拆分规则、提现拦截逻辑及PC端导出回归范围，并确认了计费流水与红包提现的集成链路。

一、主数据增量推送机制 ​

1. 多事业部与重复数据处理 ​

  • 兼容多事业部数据：当前数据本身已具备兼容多事业部的情况，系统需支持对接冷饮事业部等场景。
  • 基于Row ID顺序更新：主数据推送时，系统通过唯一的Row ID进行有序更新，后推送的数据会直接覆盖前序数据，不会产生重复数据。

2. 推送失败与重试机制 ​

  • 推送失败触发重试：主数据推送存在失败情况，系统支持重试机制，但通常在晚间发版期间推送量较少。
  • 重试不会产生重复数据：由于表内Row ID为唯一索引且更新有序，主数据重试推送时不会导致系统侧出现重复数据。

二、OpenAPI接口字段兼容 ​

1. 冷饮事业部字段补充 ​

  • 新活动计费规则同步：接口必须传入冷饮事业部字段，否则可能报错或导致文件隔离等默认处理异常。
  • 红包进账流水同步：未传事业部字段会提示资料缺失，传入后流水正常入库并展示；若本地缺失但主数据存在，系统会自动补全人员信息，否则置空但流水仍保留。

2. 查询与回调接口适配 ​

  • 列表与余额查询：红包进账流水列表查询、余额查询及发起余额接口均需传入事业部字段。
  • 提现回调接口：提现回调OpenAPI接口同样需要传入冷饮事业部资料。

三、红包提现规则与场景 ​

1. 提现金额与拆单限制 ​

  • 单笔提现下限0.3元：受微信提现规则限制，记账金额必须大于等于0.3元才能成功发起自动提现，否则提现失败。
  • 单笔大额红包暂不支持拆单：当前系统不支持单笔超过200元的红包自动拆单提现，需与业务侧沟通确认未来大额红包（如666、888元）的具体配置方案。
  • 合单提现支持拆分：若多笔自动提现失败后进行合单提现，且汇总金额超过200元，系统需支持将其拆分为多笔进行提现。

2. 提现失败与手动提现场景 ​

  • 自动提现失败：当记账金额小于0.3元或网络、用户环境问题导致自动提现失败时，金额会累加至余额中。
  • 手动提现流程：用户在余额满足0.3元后可发起手动提现，成功后余额相应扣减并生成手动提现记录；若手动提现仍不满足金额要求，则提现失败且余额不变。

3. 实名校验与钱包展示 ​

  • 无需实名校验：当前红包提现限额为200元以内，店主、店长、店员登录后可直接发起提现，无需进行微信实名校验。
  • 钱包H5展示规则：待提现列表按到账时间倒序展示，余额为零时不可一键提现；提现记录需展示金额、到账渠道、失败原因及发起时间，并支持分页与下拉刷新。

四、测试场景补充 ​

1. 提现批次状态校验 ​

  • 处理中批次限制发起：若系统中存在处理中的提现批次，用户不允许再次发起新的提现操作，需在测试用例中补充该场景。

2. 测试用例完善 ​

  • 补充提现失败场景：需在测试用例中明确补充自动提现失败的场景，涵盖单笔及多笔合单失败的情况。

五、待办事项 ​

  • 与业务侧沟通确认当前系统是否支持单笔超过200元的大额红包自动拆单提现。 赵敏
  • 在测试用例中补充自动提现失败（含单笔及多笔合单失败）的场景。 丁聪
  • 在测试用例中补充"存在处理中提现批次时不允许再次发起提现"的校验场景。 丁聪

专项5：工时评估 ​

首页统计数据口径优化 ​

优化升级首页统计数据的口径，使首页统计口径与统计分析页面保持一致。移除首页的静态数据，提升用户体验，减少用户误导。