Work for YILI

Appearance

2026-09-10 工作日志 ​

活动计费管理测试用例评审 ​

发言人：郑然然、丁聪、苏一尊、王军、孔玮等 7 人

主题摘要：本次会议围绕积分系统测试用例展开评审，重点明确了积分按门店隔离的发放与兑换逻辑、券核销流程、状态流转及异常回退机制，并补充了角色变更等测试场景。

小结 ​

  • 门店维度隔离（核心规则）：积分活动关联到具体门店，积分发到门店维度，不同门店间积分不互通、不可聚合兑换；H5 端需提供门店切换功能，切到有积分的门店才能查看，店员看不到归属门店的积分。
  • 可兑换券类型收敛：积分商城可兑换的券明确为产品兑换券与货补抵用券两种，无其他类型；前置条件需配置产品券的可兑换积分门槛（测试暂按 50 积分）。
  • 券归属与核销权限：兑换成功后券归属于兑换的门店和店主，核销由店主生成核销码、SFA 核销；店员无查看与核销权限——需验证 A 门店店员无法查看和核销该门店下店主兑换的卡券。
  • 批次扣减顺序：兑换扣减时后台按批次从下到上扣减，即优先消耗最新获得的积分。
  • 状态流转两阶段：积分扣减必须走「可用 → 冻结 → 扣减」或「可用 → 冻结 → 解冻」，不存在直接从可用到扣减；冻结期间再次发起兑换会提示积分不足。
  • 发券失败回退：需补测网络波动或券库存不足导致发券失败的场景——失败时已冻结积分回退、批次保持不变、状态由冻结更新为解冻成功。
  • 角色变更的积分归属：积分发到门店维度、与具体角色无关，店主变更为店员或店长后，已获得的积分仍保留在门店下；需补测角色变更后历史积分是否跟随门店保留、后续积分是否仍发放给新角色。
  • 钱包与计费账户展示：用例需补钱包端展示逻辑，明确积分明细增加、计费冻结为 0、已消耗增加等状态变化。

待办 ​

  • 在测试用例中补充前置条件列，明确多门店及积分门槛配置。 — @丁聪
  • 补充同活动跨门店积分不足、货补抵用券兑换、发券失败回退及角色变更等测试场景。 — @丁聪
  • 补充积分商城配置操作的前置条件及券报表验证。 — @苏一尊
  • 补充积分批次扣减顺序及状态流转的测试用例。 — @丁聪
  • 补充钱包端状态展示逻辑的测试用例。 — @丁聪
  • 补充店长与店员角色互换及积分归属的测试场景。 — @张玉婷

关联与提示

  1. 与 9.08 积分体系技术方案评审同源：本场是用例层落地，技术方案确定的"门店维度进积分池/批次/变动记录三类底层模型""禁止跨门店核销"在此转为可测规则。但 9.08 遗留的「存量积分池门店维度回填口径与责任人」本场仍未涉及，而各端开发 9.11 启动、单测 9.14，今日必须闭环。
  2. 调店 / 角色变更场景仍未完全闭合：本场明确积分跟随门店、与角色无关（店主降为店员，积分仍留门店）——这回答了 9.08 遗留的一半。但券的归属是"门店 + 店主"、且店员无核销权限：店主角色变更后，其名下已兑换未核销的券，新店主能否核销、原店主能否核销，规则未定。配合 9.09「跨门店核销校验落计费侧回调」，该场景会在回调校验处被直接判死。建议 @孔玮 与业务侧今日一并定：是允许转移、作废重发，还是按"兑换时门店"认定。
  3. 「优先消耗最新积分」需确认与积分有效期是否冲突：按批次从下到上扣减意味着最早获得的积分长期不被消耗，若积分存在有效期，会出现"新积分用完了、老积分过期作废"的情况。建议确认积分是否有有效期；若有，扣减顺序应改为先进先出，或补充过期提醒。
  4. 术语待统一：本场「货补抵用券」与 9.09 券中心接口评审的「货款抵扣券」疑为同一券种，两场命名不一致，建议在接口与用例清单中统一口径。
  5. 异常回退的并发场景未覆盖：发券失败回退目前只测单条失败。若同一批次积分在冻结态被并发发起两次兑换，"冻结期间提示积分不足"能否真正挡住、回退是否会重复解冻，建议补一条并发用例。

AI辅助开发工具与流程培训 ​

发言人：徐贺明、刘圣、王星人

主题摘要：本次会议分享了基于 AI Coding 的客户关系管理系统开发实践，详细演示了开发工具配置、脚手架使用及自动化测试流程，并明确了团队协同文档规范。

小结 ​

一、AI辅助开发工具与环境配置

1. 开发平台与 MCP 服务配置

  • 使用 Trae 平台进行 AI Coding：会议首先介绍了基于 Trae 平台进行 AI 辅助代码开发的基本流程，需先下载并安装该平台。
  • 配置测试相关 MCP 服务：在平台中需开启 Playwright 和浏览器插件等 MCP 服务，以便后续开发过程中进行自动化测试。

2. 规范与流程管理工具安装

  • 安装伊利斯规范（原文如此，疑为「伊智」相关规范，待确认）：为约束 AI 开发行为，需安装公司提供的该规范，明确业务约束、安全命名等静态要求。
  • 安装 Super Power 工作流：为引导 AI 按步骤开发，需安装 Super Power 技能，在需求设计、任务拆解、编码及上线测试等阶段提供完整的工作流矩阵。

二、AI 开发脚手架应用

1. 脚手架核心优势

  • 提供基础登录与权限体系：脚手架内置完整登录和权限体系，非开发人员可直接运行，无需关注底层项目结构与部署环境。
  • 固化最新技术栈与基础设施：固化 JDK 21、Spring 3.3 以上、Nacos 3.0、MySQL 8 及 Redis 7 等技术栈，并预置异常日志、对象存储等基础设施配置。

2. 脚手架运行与配置

  • 修改核心配置即可运行：仅需修改配置文件中的数据库连接、Redis 配置及统一认证回调地址即可运行。
  • 支持菜单与按钮级权限控制：支持租户、用户、角色管理，权限可精细到菜单和按钮级别，同时包含审计日志功能。

三、AI 驱动的需求实现与开发流程

1. 高质量 Prompt 输入策略

  • 优先提供原型或数据模型：输入 Prompt 时优先提供 HTML 或 Vue 原型，或明确的数据模型字段及交互规则，严格约束 AI 开发并节省 Token。
  • 避免纯发散性文字描述：纯文字描述会导致 AI 开发效果差，需反复沟通数十轮才能明确需求，不建议采用。

2. 基于工作流的自动化开发

  • 强制先设计后实现：Super Power 工作流约束下，AI 先读取原型生成设计文档，等待人工确认后再拆解实施计划。
  • 并行开发前后端代码：确认计划后，AI 并行开发数据库表结构、后端业务逻辑及前端页面，并自动初始化权限菜单和测试数据。
  • 自动化测试与脚本生成：开发完成后，AI 利用 Playwright 等工具模拟人工操作进行自动化测试，并生成详细测试报告。

四、团队协同与文档管理规范

1. 核心协同文档管理

  • 团队记忆文件管理：通过 Team Memory 文件记录项目关键角色、技术栈速查、关键决策及待办事项，确保团队上下文一致。
  • 项目规约文件管理：在 Agents 文件中定义项目特有的目录结构、技术栈、边界行为及禁止事项，约束 AI 的默认行为。
  • 用户手册管理：每个功能开发完成后必须生成详细用户手册，作为后续自动化测试和团队交接的核心依据。

2. 代码修改与文档更新机制

  • 修改后强制更新四大文档：每次完成功能需求或小修补后，必须命令 AI 更新 Agents、团队记忆、用户手册以及实施计划和方案设计。
  • 更新自动化测试脚本：AI 在小修补时可能遗漏，每次修改后必须重新生成或更新自动化测试脚本，确保测试覆盖完整。

五、其他 AI 辅助开发技巧

  • 使用需求澄清技能：需求设计阶段可利用特定技能将模糊想法转化为真实、清晰的需求。
  • 参考开源项目设计：建议 AI 在 GitHub 或 GitLab 上寻找与需求匹配的开源项目，结合公司实际情况编写需求文档，避免从零开始。

待办 ​

  • 将历次培训录屏及相关材料分享至大群。 — @刘圣
  • 后续联系获取 AI Coding 脚手架。 — @徐贺明

关联与提示

  1. 与「AI+for+Tech 技术团队转型」专项同源：本场的 Trae + MCP + 规范约束（伊利斯规范）+ Super Power 工作流 + 脚手架，构成一套完整的 AI 辅助开发闭环，正是**专项5「构建技术管理 Agent 服务」**可复用的落地范本，建议纳入专项材料。
  2. 「改完代码强制更新四大文档 + 重生成测试脚本」值得借鉴：Agents / 团队记忆 / 用户手册 / 实施计划与方案设计四份文档与代码同步，等同于本工作区「VitePress 文档站 + 记忆体系」的做法，可反向提炼为团队级规范。
  3. MCP 的权限边界需重申：9.03 EdBody 宣讲已明确「平台仅透传用户身份，权限校验由 MCP 工具侧自行实现」。本场开启 Playwright、浏览器插件等 MCP 服务，涉及真实浏览器环境与数据读写，接入前须明确权限校验方案，别让 MCP 成为无鉴权后门。
  4. 转写存疑：「王星人」为原文写法，存疑；「伊利斯规范」疑为「伊智」相关规范（项目内 AI 辅助开发平台正式名为「伊智开发平台」），未合并，待确认。

今日待盯（由 9.09 结转） ​

  1. 门店积分进入开发节点 —— 技术方案评审已提前完成，各端开发 9.11 开始（明天）。今日必须闭环：@孔玮 @王建朝 各端确认积分接口变更方案；存量积分池门店维度回填口径与责任人（9.08 遗留，未定则 9.11 开发完了也上不了线）。
  2. 员工调店 / 兼岗多店时已发未核销券的处置规则 —— 9.08 积分方案定"禁止跨门店核销"、9.09 定"校验落计费侧回调"，但调店场景的兜底规则仍空白。两条需合并定，否则会在回调校验这步被直接判死。（9.10 用例评审部分回答：积分跟随门店、与角色无关；但券归属"门店+店主"且店员无核销权限，人变后谁可核销仍未定）
  3. @柳瑞军 BRD Agent 自测 —— 9.09 周会定"明天完成"，即今日。另需确认分支合并主干异常是否已解决。
  4. @刘阳 约王建朝、崔建瑞对齐控制台目录结构 + 数据看板整合 —— 落地会议，直接谈"怎么分"，不必重开 9.02 已定的"要不要分 / 按业务阶段重组"。
  5. 高德故障链收口 —— 三笔数据、三个责任人：调用量优化（@李明非）、盘点数据丢失 1.8 万条（@余勇军）、B 端退货地址空值 4.2 万条（@潘玉平）。建议今日指定统一收口人，否则各修各的、修完没人确认是否不再产生。
  6. 门店域宽表的 PG 膨胀兜底 —— 5000 万行 + MVCC，方案未提 VACUUM/分区维护、批量刷新限流与上线前真实量级更新压测；索引三步走的中间态缺存续时限与超时处置。
  7. 结转待办：@郝梓斐（门店二级渠道类型两份方案文档、字段长度与旧链路加字段）、@李明非（拉中台 DBA 评估千万级加索引、腾讯云 MQ 通道量确认 + 测试环境小批量验证）、@余勇军（1—8 号门店/经销商变更记录、补录后通知中台）、@潘玉平（与梁建确认填充方案并重评排期、产品状态是否必须实时并更新 PRD、改中奖明细修复 SQL、改退货地址修复方案为临时表模式）。
  8. 内部人员接口排期 —— 9.04 遗留"受供应商评估影响延至 9.9"，昨日未见结论，需确认。
  9. 券中心 4 条待办责任人 —— 9.09 那场原文未标注，待补名单后归档（10.15 前完成开发，时间尚宽）。