2026-09-04 工作日报

一、今日工作总结

1、模块TOP大事

• 盘点签收故障修复方案定稿：3.9 万条历史数据"先堵漏、观察、再修数"，今晚上线堵漏代码：根因是并发下的数据覆盖——前链路写 Mongo 是实时的、异步写报表较慢，并发时两条数据都查不到报表状态，导致重复签收消息互相覆盖，且存在失败状态覆盖成功状态的风险。堵漏方案为在发送异步消息写入报表前增加判断，重复签收直接拦截、不再发消息。历史数据修复范围为 806 版本至今、签收类型（查账/盘点签收）+ 状态失败 + 失败原因=重复签收，约 39000 多条，修复逻辑为置成功 + 清空失败原因 + 更新时间置当前。执行顺序明确为今晚先上堵漏代码 → 观察 1-2 小时确认无新增重复 → 再执行修数与收口。脚本两条硬要求：SQL 必须带"> 最小创建时间"条件以命中分区键；备份表与修复语句的 WHERE 条件必须严格一致。
• 高德调用问题一天内三次出现，方案评审启动但结论未定：盘点即签收（FreshnessSignReceiptServiceImpl）落库时同步调用高德逆地理接口，将经纬度解析为格式化地址写入 freshnessAddress / otherLocaInfo。高峰期暴露两类问题——同门店/仓库大量扫码导致相同经纬度被反复请求、调用量过大；高峰并发下高德偶发失败导致盘点记录缺地址。该议题与早会"高德解析服务故障排查"（@刘晓娜）、下午"高德接口调用量过大致昨日宕机、Job 逻辑改造推迟下周一"（@李明非）构成同一根因链条的三个切面。⚠️ 本场评审仅记录问题背景，优化方案、评审结论与责任人尚缺，待会后补齐。
• 冷饮事业部活动测试用例评审：叠加奖品仅特殊激励支持，冷饮需代码层功能隔离：明确特殊激励优先于普通激励——先判"周期内第 N 次扫码"，满足发特殊激励，否则发普通激励；叠加奖品仅特殊激励支持，且需先中主奖品才触发叠加。为避免数科配置模板时误配，开发需在代码层按事业部判断隐藏冷饮的普通激励叠加入口（@李明非）。概率方面特殊与普通激励相互独立、单条 ≤100%、不要求总和=100%。跨端集成形态明确：智慧门店仅调防作弊接口，拼 URL 跳计费 H5，H5 展示激励明细与金额流水，激励对象仅店主需补提现用例。
• 9.3 技术方案评审邮件 4 封全部定稿，并沉淀为可复用 skill：完成《Job 表新增 sub_type 字段》《销售区域与行政区域关系、经销商经营围栏状态校验》《盘点明细报表仓库名称兜底》《码流向解析顺序问题修复》四封评审邮件，项目统一归属营销活动中心。同步优化 tech-review-email skill：动态参数每次询问收集（禁止沿用上封默认值）、内容精简（背景 1-2 句、要点只留整体流程、代码级细节不写）、决议改待办式、新增「风险提示」小节、结果与决议一致性自检。

2、重点/基础工作

• 液奶物码早会（09:09）：要求周五前（即今日）更新项目计划，重点调整门店积分计划并敲定周末整体发布节奏；安排专人评估 9、10 月发版合并方案以减少发版次数。智慧门店整体推进正常，但店主告警需安排资源排查（@晓娜 分析并输出接口改造排期）；数据监控部分问题已解决；国外经纬度异常定位为智慧门店未校验距离所致，系历史遗留边界数据，仍需人工兜底。外部依赖方面，内部人员接口因供应商工作量评估受阻延至 9 月 9 日；营销活动中心已完成方案评审、今日确认排期并下线旧接口。
• 盘点签收故障修复评审：除堵漏与修数外，明确数据修复完成后需在群内同步进展并向业务方说明（@余建新）。
• 冷饮用例评审补充规则：触发对象限店长/店员、误码级别统一 1 级、须含"内码营销状态=已激活"条件；冷饮 TPM 编码未与系统打通，仅为文本标识、业务方自填；活动限制多条件无优先级、依次校验、任一不满足即停发；预算与码量任一触顶即停；需补"预警时间 > 活动开始时间"等异常场景用例。
• 总裁办创新元 FED 学习通知：围绕"产品体验、服务体验、情感体验"三大主线，学习专题约 64 分钟，9 月 21 日前完成（17learning 平台）。
• 架构原则沉淀：将「数据修复的顺序与可回溯」「功能隔离靠代码不靠规范」「并发写入的状态一致性」三条写入长期记忆，供后续同类评审直接引用。

3、每日总结&思考

【外部依赖】高德今天出现了三次，分散在三场会里，没有一场把它当成"一件事"在处理。早会说"解析服务失败、排查影响范围"（@刘晓娜），下午签收评审说"调用量过大致昨日宕机、改 Job 逻辑、下周一"（@李明非），傍晚的方案评审才终于定位到具体代码位置——盘点落库时同步调用逆地理接口，相同经纬度被反复请求。三次描述的是同一个故障，但因为分散在不同会议、不同责任人，没人把它串成一条线。建议指定一个统一收口人，否则大概率演变成：刘晓娜报完影响面、李明非改完 Job，但没人确认"改完是否真的不再触发"。外部依赖的管理成本，往往不在故障本身，而在没人负责闭环。

【技术判断】这场高德优化如果只做一件事，应该做缓存，而不是限流。经纬度到地址的映射是稳定的，同一门店/仓库高峰期重复扫码，重复请求的坐标几乎是同一批——这类"相同输入、稳定输出、高频重复"的调用，缓存命中率会非常高，能削掉绝大部分调用量。限流则不同，它是把压力转换成失败，问题没消失，只是换了个表现形式。但要注意：缓存只解决问题①（调用量大），解决不了问题②（偶发失败导致缺地址）——缓存命中率高不等于不会失败。问题②要靠异步补偿：落库时先记经纬度、地址字段留空并标记待解析，由补偿任务重试填充。更进一步说，同步调用外部接口写库本身就是设计问题：高德一抖，盘点记录就缺地址，严重时会拖垮落库链路。正确姿势是解耦 + 补偿 + 超时熔断三层都要有。评审时建议把两个问题分开看，别指望一个方案盖两个洞。

【数据修复】"先堵漏、观察、再修数"这个顺序是对的，但可以再硬一点。现在的表述是"观察 1-2 小时确认无新增重复数据"——建议把判据写死：观察期内新增重复签收数必须为 0，并明确观察窗口的具体时间段与核对方式（查哪张表、按什么条件）。3.9 万条状态一旦改错，回滚成本远高于多等两小时。另外那条"备份表与修复语句的 WHERE 条件必须逐字一致"值得单独强调：这不是洁癖，是能不能回滚的分界线——条件不一致的备份等于没有备份。

【流程资产】今天最有长期价值的事，可能不是哪场评审，而是把 4 封评审邮件的写法收敛成了 skill。用户在原邮件上反复做的精细化修改（去掉代码级细节、决议改待办式、结果与决议一致性自检）说明一件事：评审邮件的读者要的是结论和动作，不是技术细节。这个偏好一旦固化成模板，后面每一封评审邮件都省一次来回。这跟我们做智能体是同一个道理——把个人反复做的判断规则显性化，就是资产。专项 5 的验收标准也应该是这个：沉淀了多少可被他人复用的规则，而不是做了几个 Agent。

【一个隐患】冷饮用例这边已经在测"跳转计费 H5 + 钱包明细展示"了，但 9.02 那场定的安全方案（公网暴露 + Token 鉴权 + 防刷）还没出，下周三才二次评审。如果安全方案有变动（比如鉴权方式改变、URL 拼接方式调整），跨端用例要跟着返工。建议让 @苏一尊 等安全方案定了再冻结跨端集成用例。

二、周末及下周一（09-07）工作计划

1、模块TOP大事

• 今晚上线堵漏代码并观察（今晚～周末）：上线后按明确的判据观察 1-2 小时（新增重复签收数必须为 0，明确核对的表与条件），确认后执行 3.9 万条数据修复与收口；修复完成后群内同步并向业务方说明。
• 门店积分周末发布：按今日要求更新项目计划、敲定发布节奏，跟踪发布结果。
• 下周一：高德存量数据修复与 Job 逻辑改造（@李明非）：与调用量优化方案合并推进，明确统一收口人，避免影响面排查、调用优化、存量修复三条线各做各的。
• 下周一：补齐盘点落库高德逆地理调用优化的方案结论：明确缓存策略、异步补偿机制、超时熔断，以及责任人。

2、重点/基础工作

• 9、10 月发版合并评估：指定专人，评估完成后群内同步结论。
• 智慧门店店主告警：推进接口改造排期输出（@晓娜）；持续跟进数据监控内容更新。
• 内部人员接口排期：9 月 9 日新节点跟踪（@陈思），关注供应商评估是否再次拖累整体排期。
• 国外经纬度异常人工兜底：历史遗留边界数据，需人工排查（@刘晓娜 / 智慧门店团队）。
• 冷饮用例补充：概率交叉验证、多条件组合限制、预警与预算/码量修改、钱包明细与提现用例（@苏一尊 @丁聪）。
• week36 周报收口：9.4～9.6 内容并入，完成本周周报。
• FED 学习专题：9 月 21 日前完成，可安排在周末。

三、待办事项（责任人）

来源	待办事项	责任人	时限
盘点签收故障修复评审	修改数据修复方案，SQL 条件增加创建时间限制，确保备份与修复条件一致	@潘玉平	今晚前
盘点签收故障修复评审	今晚先上线堵漏代码，观察确认无新增重复数据后再执行修数与收口	@潘玉平	今晚
盘点签收故障修复评审	数据修复完成后在群内同步进展并向业务方说明	@余建新	修复后
盘点签收故障修复评审	下周一处理高德接口调用量过大导致宕机的数据修复与 Job 改造	@李明非	9.7
高德逆地理调用优化评审	补齐优化方案结论（缓存/补偿/熔断）、评审结论与责任人	待定	待定
冷饮事业部活动用例评审	确认冷饮活动层级使用范围，向业务方说明层级与中奖优先级的关系	@赵化龙	待定
冷饮事业部活动用例评审	评估并实现前端逻辑，隐藏冷饮事业部普通激励叠加奖品配置按钮	@李明非	待定
冷饮事业部活动用例评审	补充概率交叉验证、码量/金额超发、多条件组合限制用例	@苏一尊	待定
冷饮事业部活动用例评审	单独重验预警机制及活动过程中预算/码量修改场景	@苏一尊	待定
冷饮事业部活动用例评审	补充钱包明细展示与店主提现动作的集成测试用例	@丁聪	待定
冷饮事业部活动用例评审	与刘莉梳理用例设计思路，与冉冉（疑为郑然然）、雪梅达成共识后重组织内评	@苏一尊	待定
液奶物码早会	更新项目计划（重点门店积分）并敲定周末发布节奏	@门店积分计划对接人	今日
液奶物码早会	评估 9、10 月发版合并方案并群内同步	@（待指派专人）	待定
液奶物码早会	智慧门店店主告警分析，输出接口改造排期	@（小智）晓娜	待定
液奶物码早会	更新内部人员接口排期（供应商评估受阻）	@陈思	9.9
液奶物码早会	营销活动中心确认排期并下线旧接口	@邢健	今日
液奶物码早会	排查高德解析服务失败影响范围并给出恢复时间	@刘晓娜	待定
液奶物码早会	排查国外经纬度异常（智慧门店未校验距离，历史遗留数据）	@刘晓娜 / 智慧门店团队	待定
FED 学习通知	完成《创新元 · 三大体验提升》学习专题并记录完成时间与积分	@语霖	9.21

说明：高德相关事项分散在三场会议（影响面排查 / 调用量优化 / 存量修复），建议指定统一收口人，避免三条线各做各的、无人确认闭环。