---
---
2026-10-14 工作日志
计费管理：代码走查 & 上线方案评审
本次会议评审了多设备架构升级与积分系统上线方案，明确了数据库字段初始化、定时任务规范化及主数据导入等核心数据准备要求，并确认了发版顺序、代码评审重点及回滚策略。
小结
1. 需求确认与数据初始化
- 新增事业部字段处理：本次升级涉及多表新增事业部字段，脚本中已包含索引调整及历史数据初始化逻辑。
- 空值初始化规则：针对现有历史数据中该字段为空的情况，统一初始化为「椰奶」事业部编码（按事业部口径疑为「夜奶」，原文如此）。
- 门店角色字段处理：门店角色相关表的事业部字段同样需要进行初始化修复。
- 文档维护规范：本次上线涉及的资产文档需整合至统一的总文档中集中维护迭代，避免分散。
- 在途数据概念澄清：文档中的「在途数据」实指新增字段的历史数据初始化，并非业务在途概念，相关描述将直接修正。
2. 定时任务规范化
- 任务名称规范化：对存量定时任务的查询表（job_info）进行名称规范化处理，确保全量准确无误。
- 执行环境说明：该规范化脚本仅在 C 环境和 UAT 集成测试环境中执行预演验证。
- 数据备份保障：执行前需联系 DBA 备份相关表数据，确保具备回滚支持能力以防遗漏或丢失。
3. 主数据导入方案
- 存量数据处理：主数据基础数据通过线下导表方式提供，按接口文档规范直接导入数据库，确保与接口推送数据一致。
- 增量数据处理：以导表时间点为基准，向前推一小时获取增量数据进行同步推送。
- 测试预演机制：主数据提供方已提前提供八份表格数据，需在测试环境完成导入预演以排查细节问题。
- 生产导入逻辑：生产环境导入采用临时表中转策略，先校验临时表数据无误后再合并至正式表，防止冲突错误。
4. 发版计划与上线协同
- 发版项目拆分：本次上线共涉及五个项目包，前端两个后端三个，按版本顺序依次执行脚本。
- 网关停服协调：因涉及多设备架构升级，我方需先关闭网关入口停服，待恢复后通知营销活动侧重试失败的红包记账流水。
- 跨端依赖对齐：营销活动中心侧无强制先后依赖诉求，双方到点后可按各自节奏发版，但需提前沟通停服时间。
- 脚本附件处理：发版申请附件中仅填写文件名即可，无需粘贴文件详情，敏感参数信息不公开贴出。
5. 代码评审重点
- 核心业务聚焦：代码评审跳过常规流程，重点审查积分记账流水、积分池处理及积分兑换三大核心模块。
- 防重幂等设计：记账流水依靠上游生成的全局业务 ID 作为唯一索引实现防重；积分兑换使用内部生成的订单号做唯一锁校验。
- 异步消息处理：记账流水采用 MQ 消峰填谷异步方案，针对锁竞争失败设置约 3 分钟间隔重试，其他错误不重试。
- 积分兑换逻辑：兑换流程分为冻结与扣减两阶段，严格校验可用积分与批次失效时间（FIFO），生成变动记录与明细。
待办
1. 文档与配置修正
- 修改文档中将「在途数据」更正为「历史数据初始化」的描述。——贾继伟
- 调整 Excel 文件中涉及 SQL 部分的结尾列，并把继伟加上。——王军
- 将本次上线涉及的资产文档整合至统一的总文档中集中维护。——王军
- 整理并汇总 Nacos 参数配置信息至发版计划对应位置。——王军
- 上传微盘存放包含密钥的配置文件供上线使用。——王军
2. 数据备份与跨端协同
- 联系 DBA 宗阳老师备份相关表数据，确保上线具备回滚支持能力。——王军
- 沟通营销活动侧明飞团队，告知网关停服时间及后续重试要求。——王军
计费管理：积分池扣减与兑换逻辑
本次会议围绕积分池扣减与兑换逻辑展开，明确了幂等性处理、锁机制及微服务拆分规划，并敲定了发版申请、回滚方案补充及数据迁移优先级提升等后续行动。
小结
1. 幂等性与唯一性处理
- 积分池互斥锁防重：同一操作对同一积分池进行短时间连续请求时，通过获取互斥锁实现串行处理，第二次请求若未处理完则返回「正在处理中」，处理结束后再次请求则因外部订单号已存在而拦截。
- 外部订单号兜底校验：依赖上游业务组件及外部订单号做唯一性校验，内部不使用外部订单号建唯一索引以避免性能下降，仅用普通索引辅助查询。
- 失败场景明确区分：将锁竞争失败、回退之物等异常归为独立失败类型，避免与正常业务失败混淆。
2. 扣减与兑换流程设计
- 一阶段扣减确认：参数校验后按积分池加锁执行，成功则变更单据状态为已冻结、记录变动明细并将可用积分转为冻结积分；失败则解冻并回退至可用积分。
- 二阶段确认兑换：判断是否存在后按积分池加锁，状态变更为已兑换，将冻结积分转为已消费积分；兑换失败则将冻结积分回退至可用积分。
- 异常处理原则：尽量减少系统内重试机制，优先通过企微报警或异常任务交由上游或人工介入处理，避免因中间件 Bug 导致资金损失。
3. 分布式锁机制优化
- Redis 锁自动续期：当前使用 Redis 封装的短超时（5 秒）锁，竞争失败时强制续期（如 30 分钟）以应对网络抖动等异常。
- 替换为看门狗组件：计划后续引入现成的看门狗组件替代自定义续期逻辑，以降低开发与维护成本。
- 最终释放清理：在代码块的 finally 块中确保锁被正确清理释放。
4. 微服务拆分与分库规划
- 拆分背景与目标：当前核心业务全量集中在中心微服务导致压测压力大，需通过服务拆分与分库实现不同事业部在数据层与服务层的隔离。
- 拆分策略：采取渐进式演进，先拆出红包、积分、优惠券等大模块独立微服务，再根据流量负载进一步拆小。
- 红包微服务：面向消费者端，目前市场部有直接给消费者的需求。
- 积分微服务：后续主推方向，经销商激励预算将转成积分以提升量级。
- 优惠券微服务：随积分兑券需求增长而上升，需同步拆分。
- 特殊表处理：主数据基础表（如门店头表）不区分事业部，拆分时需特殊处理。
5. 发版与压测安排
- 发版窗口选择：今日下午 UAT 演示后提发版申请，审批通过后选择明日晚上作为发版窗口。
- 压测内容覆盖：严格包含四个内容。
- 奶路营销网络中心暂停上线：因多事业部架构升级代码无法拆分，本次上线不启用对应入口。
- 积分中需求：钱包 H 内的积分入口隐藏。
- 冷饮一期需求：智慧门店钱包部分不上线，但卡券部分会上线。
- 整体压测报告：压测结果将一并放入发版计划供评审。
6. 其他事项
- 数据迁移优先级提升：为避免明年各事业部量级上来后再分库导致数据迁移复杂度高，需提前与孔伟沟通将分库优先级往上放。
- 回滚方案补充：发版计划中的回滚方案缺失，需补充具体操作步骤以确保部署不成功时必须能回滚。
待办
1. 回滚方案与发版申请
- 今天下午 UAT 演示完后提发版申请，并补充回滚操作步骤。——王军
2. 发版准备
- 提前准备发版配置项，并在会中说明隐藏入口等特殊处理逻辑。——王军
一智平台：三类智能体上线分享会
本次会议分享了「一智平台」新上线的三类智能体，涵盖需求分析、PRD 设计与原型设计，明确了各智能体的目标用户、适用场景及操作流程，并收集了关于个性化知识注入的优化建议。
小结
1. 智能体上线背景
- 一期建设回顾：一智平台已完成技术管理 15 个智能体及技术服务 5 个智能体的上线。
- 本期上线内容：本次完成了技术服务剩余的 3 个智能体及服务平台的上线，并组织了两场分享会进行推广与试用。
2. 需求分析智能体
- 定位与目标用户：将业务想法或需求材料整理为结构化报告，服务于三类人员。
- 业务提出人：负责说清业务问题、目标及实际规则。
- 产品与分析人员：借助智能体检查需求完整性、消除歧义及矛盾。
- 评审与研发方：阅读核验后的报告以了解需求范围与决策事项。
- 核心应用场景：主要应用于两种典型场景。
- 从 0 到 1 生成：针对仅有初步想法的业务，逐步完善并输出完整分析报告。
- 现有文档审查：对已有需求文档进行规范性审查，识别语义缺失或不符合规范之处。
- 操作与功能流程：提供两种生成方式及完整的人工核验机制。
- 生成方式：支持通过文字描述直接生成，或导入现有材料进行分析补全。
- 人工核验：生成的每个模块内容均需人工勾选确认，支持调用内容助手优化文本。
- 冲突澄清：自动识别内容冲突或未明确项，需人工填写澄清描述后重新检查保存。
3. PRD 设计智能体
- 定位与核心价值：帮助产品经理将分散的需求材料整理成可编辑、可评审的 PRD 初稿，释放重复劳动时间。
- 功能模块与场景：系统分为「从 0 到 1」新建与「从 1 到 N」迭代两大模块，遵循不同的生成逻辑。
- 从 0 到 1 建设：适用于新建系统，提示词依赖行业经验补充模块供评审参考。
- 从 1 到 N 建设：适用于后续迭代，不强制要求发散性补充，缺失信息标记为待补充项。
- 工作台交互能力：基于规范目录生成章节，支持多模式的内容修改与输出。
- 辅助生成：支持 AI 全部生成或输入指令局部生成，右侧对话区同步展示待补充项。
- 内容编辑：支持原文档直接修改（带标注）或对特定段落进行 AI 改写。
- 预览与导出：支持单章预览与整体预览，生成完成后支持导出为完整 PRD 文档。
4. 原型设计智能体
- 定位与目标用户：自动生成页面原型底稿，提升沟通效率与设计效率，节省研发构思成本。
- 核心应用场景：主要应用于两类系统构建场景。
- 新建系统：根据需求描述自动推导视觉风格并生成原型清单。
- 已有系统迭代：上传现有页面截图，自动识别风格并生成对应原型。
- 操作流程与规范：提供标准化的五步至七步操作流程，强调数据脱敏。
- 资料准备：上传需求文档、功能清单或会议纪要等材料（严禁包含人员真实信息）。
- 风格选择：自动识别并推导视觉风格，支持手动调整色彩等偏好设置。
- 清单确认：先生成页面清单供用户选择、调整或删除，再进行详细生成。
- 实时交互：生成过程中支持与大模型对话交流，实时修正样式与细节。
5. 反馈与优化建议
- 个性化知识注入建议：与会者提出在 PRD 评估等迭代场景中，希望支持上传企业专属架构、方法及约束资产以提升生成质量。
- 后续优化方向：目前第一期已内置通用规范，后续将逐步优化并支持各系统的个性化知识注入。
- 资料分发与反馈渠道：会后统一发送会议视频、资料及入口指引，并提供问题记录表用于收集使用意见与优化建议。
- 平台命名待统一：本场分享的「一智平台」与既往记录中的「伊智开发平台 / 一智开发平台」为同一平台的不同写法，本记录按原文保留并括注，全站统一待专项处理。
待办
- 会后统一发送会议视频、资料及入口指引。（责任人待定）
- 提供问题记录表，持续收集使用意见与优化建议。（责任人待定）
关联与提示
- 前次待办闭环：10.13 记录「明天上午参加代码走查及建新方案评审会，重点评估冷饮项目是否受本次改动影响并进行回归测试（——全体成员）」已于今日代码走查中兑现，冷饮一期的取舍已明确为「智慧门店钱包部分不上线、卡券部分上线」；积分池幂等与锁机制的评审结论也可作为 10.13 SR 数据丢失问题的参照实现（记账流水用上游全局业务 ID 做唯一索引防重）。
- 同根因链新增切面：10.13 已立项「建立 MQ 消息发送失败的兜底机制（企微告警或每日巡检表）——张喜」，本次会议进一步将异常处理原则定为「尽量减少系统内重试，优先企微报警或异常任务交由上游/人工介入」，两条互为印证；记账流水当前仍保留「锁竞争失败约 3 分钟间隔重试」，需与 10.13 MQ 限流重试三次失败的教训对齐口径——重试只做有限次且必须有告警兜底。今日下午券中心评审同样采用「推送复用通用异步能力 + 失败重试三次 + 人工补推定时任务」，属同一兜底模式，三处可合并为一条统一的重试与告警规范。
券中心：积分需求接口升级评审
发言人：杨建、王建朝；主题：本次会议评审了券中金积分需求 v2 接口升级方案，明确了今晚的上线计划与数据库结构调整，并确认了批量核销、推送机制及代码逻辑，最终评审通过。
小结
1. 上线部署计划
- 今晚 20:00 执行升级：计划今晚 20:00 进行系统升级，届时停服网关约 20 分钟，以完成数据库表结构更改；需重新申请今晚的发布工单并交由建南老师协助审批；本次上线需在 15 号上班前完成。
- 上线前置准备已就绪：数据库初始化值、配置、后端代码分支检查，以及 nacos 和 X job 的配置均已提前完成；生产环境的参数、签名密钥及生产地址已提供给计费中心、积分商城和智慧门店。
- 不影响现有 v1 版本：本次升级仅新增 v2 接口，v1 接口未做改动且已做独立切割，不影响对接方现有功能。
- 对接方上线时间错开：计费中心和智慧门店等对接方计划在明天晚上上线，本次升级不会对其造成影响。
2. 数据库表结构变更
- 调整非空约束：将货补券等原有非空字段调整为可空，以兼容积分需求中大量可空参数的场景。
- 新增可控字段：为支持入库需求新增部分可控字段，不影响 v1 版本的更新。
- 清理无用索引：对比测试库后清理部分无用索引，以优化表结构。
- 中台抽取待确认（未闭环）：王建朝提问测试中心的数据库表是否被中台抽取，若有表变更而中台未抽取到数据则会有问题；杨建回复目前好像没有，若有则后续确认。
3. 接口核心逻辑评审
- 新增游标字段：查询列表和统计接口在 v1 基础上增加游标字段，主要提供给计费中心使用。
- 支持按门店分组查询：新增按门店编码分组查询接口，供智慧门店查询各门店的券量数据。
- 核销码支持批量生成：获取核销码接口支持传入多个券码批量生成二维码，但限定只能传入同一种券类型；生成时将数据初始化到缓存以提升查询速度，若重新生成包含交集的券码，原有交集的码将失效。
- 支持一码多券批量核销：核销接口支持针对一个二维码下的多张券批量核销，并按货补券、代金券等类型区分处理。
- 新增核销状态查询接口：用于查询二维码的核销状态，目前主要供计费和营销助手轮询使用。
- 发券支持产品数量入参：自制券发券接口新增产品数量入参，以支持一张券对应多张产品的积分兑换需求。
- 复用通用推送能力：核销推送复用原有通用异步推送能力，记录请求与响应参数；新增人工补推定时任务，针对推送失败的情况工具会重试三次，若仍失败可通过人工触发定时任务进行补推。
4. 代码逻辑与校验答疑
- 王建朝（提问）：批量券的类型限制是在client 端实现的吗？后端这边有做校验吗？
- 杨建（回答）：入参时只能传一种类型，但后端目前可能没有校验到，担心加逻辑会影响生码响应速度。
- 王建朝（提问）：只要前端代码不写 bug 就没有问题，可以接受吗？
- 杨建（回答）：可以，因为返回列表已经限定了类型，除非通过非正规方式绕过。
- 评审结论：上述答疑为风险口头确认（券类型校验依赖前端、后端未做校验），未形成强制校验动作，会议整体评审通过。
待办
- 将本次评审涉及的 Excel 表链接发送给王建朝。——杨建
- 重新申请今晚的发布工单，并交由建南老师协助审批。——杨建
- 确认测试中心的数据库表是否被中台抽取。——杨建
营销活动中心：盘点任务创建与发布代码评审
发言人：余勇军、张建利、宋洋、王建朝；主题：本次会议对盘点任务系统的创建、校验与发布逻辑进行了代码评审，重点讨论了 RPC 校验性能、重复校验机制及并发锁优化，并明确了多项代码修改与产品对齐要求。
小结
1. 门店与产品校验逻辑
- 分批 RPC 校验机制：系统支持上传几万个门店编码，通过分批（每次 2000 个）进行 RPC 调用校验，以避免单次查询耗时过长导致用户体验下降。
- 内存比对与性能风险：校验逻辑为查询经销商下的门店列表，并在内存中进行比对，评审指出在大数据量下可能存在匹配时间过长的问题，建议在线上环境进行实际测试。
- 产品范围为必填项：系统会根据产品编码通过 RPC 调用查询产品，并获取经销商下的所有产品进行有效性校验。
2. 重复任务与时间交叉校验
- 时间交叉判断：系统会查询同一时间区间内是否存在门店与经销商范围重复的盘点任务，若存在交叉则提示冲突，不允许创建重复任务。
- 空列表初始化冗余：代码中存在先初始化空数组再重新赋值的冗余操作，评审建议直接赋值，无需额外初始化。
- 禁用 QueryWrapper：针对时间交叉校验的查询逻辑，评审明确要求必须摒弃 QueryWrapper，统一改为直接编写 SQL 语句。
- 去除全包名：代码中使用的集合交集方法存在全包名，建议去除以提升代码简洁度。
3. 任务保存与并发控制
- 多子表配置：盘点任务主表关联 7 张子表，用于存储经销商、渠道、门店类型、销售五段、门店范围及产品范围等配置参数。
- 先删后增更新策略：在修改任务时，系统会先删除原有的子表数据，再执行新增操作。
- 状态前置校验：任务仅在「草稿」状态下允许编辑、修改和发布，非草稿状态（如运行中、已发布）将直接拦截操作。
- 并发锁风险预警：由于新增与修改任务共用同一个保存方法，会导致锁的冲突概率升高，可能引发用户在保存时系统长时间转圈的问题。
- 删除操作私有化：为防止误删非草稿状态的任务数据，评审建议将删除子表数据的方法改为 private 并增加状态校验。
4. 业务场景与产品对齐
- 任务强制性与集中性：盘点任务通常由总部强制要求，可能集中在月底或月初同时开展，与向外发钱的活动在并发量和业务场景上存在显著差异。
- 锁机制对用户的影响：针对并发锁可能导致系统响应变慢的问题，评审要求整理实现方案及锁机制对用户的影响，并与产品经理对齐，明确向用户的解释话术。
待办
1. 性能验证
- 在线上环境测试门店编码校验的执行时间，以验证内存比对性能。——余勇军
2. 代码修改
- 优化门店编码校验代码，避免使用 substring 进行索引处理，改为放入 list 中最后再 join。
- 将时间交叉校验的查询逻辑从 QueryWrapper 改为直接编写 SQL 语句。
- 去除代码中集合交集方法的全包名。
- 去除代码中无用的空列表初始化操作。
- 将删除子表数据的方法改为 private，并在修改时增加草稿状态校验，防止误删非草稿任务数据。
3. 产品对齐
- 整理并发锁的实现方案及对用户的影响，并与产品经理对齐解释话术。
关联与提示
- 同根因链新增切面（与今日计费管理记录并读）：本次「新增与修改共用同一保存方法 → 锁冲突升高 → 用户长时间转圈」，与今日上午积分池评审的「Redis 5 秒短锁 + 竞争失败强制续期 30 分钟 + finally 释放」是同一类并发风险在两个系统的不同表现。盘点任务集中在月底月初并发量骤增，属于可预见的峰值场景，锁粒度与等待时长应按峰值而非日常量设计；两处的锁处理策略建议一并review 后定统一口径。
- 风险项待验证：门店编码校验采用「查经销商门店列表 + 内存比对」，本次已明确需在线上环境实测执行时间；该逻辑与 10.13 盘点压测评审中「状态更新接口因同门店同时段仅一个进行中任务、无法造数压测，只能改代码 Review」属同一批数据约束，若后续月度峰值前未拿到实测数据，只能靠线上兜底。