2026-09-14 工作日志
物码早会：主计划进度同步与发版评审
发言人：李亚洲、吴菊、王建朝、孙东栋、刘晓娜等 11 人
主题摘要：本次会议同步了各业务线主计划进度，重点讨论了 RPC 服务故障的 SOP 机制，并明确了 9 月 18 日上线评审及 10 月 15 日双事业部切换的关键时间节点。
小结
- SaaS 报表集成完成：建新负责的 SaaS 报表加字段集成已完成，计划 9 月 16 日统一发布。
- 移动端与生产流向：移动端进度正常；PC 端 P2 级本周继续沟通；生产流向须于今日（9.14）完成 UAT 测试。
- 门店积分测试安排：进度正常，9 月 15 日进入机测；因临近双节，测试先采用远程方式进行。
- 门店开发环境已启动：门店开发团队周末加班推进，环境已正常启动，可配合营销活动中心做部分集成。
- 门店与经销商数据比对：供应商今日需输出门店与经销商关系数据的差异比对结果，并交由对应负责人对接。
- 导购与门店关系治理：营销活动中心本周重点治理导购与门店的关系数据；此前导购与经销商的关系数据差异已达标处理。
- 告警概况（9.11—9.14）：共 13 条告警，其中 4 条为常态化监控、1 条需中台调整规则、另 3 条需继续做异常分析。
- 报表类监控排期：重复签收订单差异明细表 9.16 解决；查证明细表扫码机号预算编码为空 9.17 解决；B 端出货明细表经销商财务失效无断维控 9.20 解决。
- 高德地址异常收敛：因高德问题导致的 B 端出货表地址类为空数据已大幅减少，目前仅剩 20 条，今日继续定向分析排查。
- RPC 故障根因更正：报错核心并非调用层问题，而是 Data 数据库因连接数满导致服务本身不可用，需更正此前"RPC 调用异常"的错误描述。
- 影响范围未识别完全：故障虽已快速解决，但数据中台后续监控仍发现部分数据需补充，说明初期影响范围识别不完整。
- 异常处理 SOP 机制：后续需完善 SOP——不仅要在故障发生时恢复系统稳定，还要主动排查影响范围并修复数据，避免等待业务反馈。
- 常态化登记：要求每日在企微群内对问题进行整理登记，已解决的也要记录，以便后续分析并实现闭环管理。
- 上线评审时间：因 9 月 20 日为周日、周六休息，9.20 发版的上线评审初步定于 9 月 18 日，明日早会确认最终时间。
- 统一发版窗口：针对分散在 9.15、9.17、9.20 的发版计划，需评估是否统一合并至 9 月 20 日；若属日常小 bug 修复且方案无争议，可走快速评审流程。
- 10.15 双事业部切换排期：两个事业部同时切换，整体排期紧密、无缓冲期，各环节必须严格卡死时间节点；9 月 15 日集成节点不可动摇。
待办
- 供应商今日输出门店与经销商关系数据的差异比对结果，并交由对应负责人对接。 — （原文未标注责任人）
- 对 B 端出货表地址类为空剩余的 20 条做定向分析排查（今日）。 — （原文未标注责任人）
- 更正 RPC 故障原因描述：由"RPC 调用异常"改为"Data 数据库连接数满导致服务不可用"，并更新至故障表。 — （原文未标注；按 9.11「RPC 问题沟通」该条挂 @马奇，转写口径为 @李明非 重写）
- 完善异常排查与数据修复 SOP，并落实每日企微群问题登记（已解决的也登记）。 — （原文未标注；按 9.11 会议由 @李明非 牵头）
- 生产流向今日完成 UAT 测试。 — （原文未标注责任人）
- 确认 9 月 18 日上线评审的最终时间（明日早会确认）。 — （原文未标注责任人）
- 评估 9.15 / 9.17 / 9.20 三次发版是否合并至 9.20，并明确"快速评审流程"的适用判定。 — （原文未标注责任人）
- 按排期解决三条报表类监控问题：9.16 重复签收订单差异明细表、9.17 查证明细表扫码机号预算编码为空、9.20 B 端出货明细表经销商财务失效无断维控。 — （原文未标注责任人）
- 对 9.11—9.14 告警中仍需继续异常分析的 3 条出具结论。 — （原文未标注责任人）
关联与提示
- RPC 根因在三天内被推翻了一次，值得警惕：9.11 那场刚把原因从"RPC 调用异常"细到"806 发版期间 data 服务异常、被 catch 后中断赋值"，今天又改成"Data 数据库连接数满导致服务不可用"。说明 9.11 那版仍停在中间层，没挖到根。建议故障表按三层结构填写：调用现象（RPC 报错）→ 服务状态（data 服务不可用）→ 根因（DB 连接池打满）；并且必须再追一句"连接数为何被打满、是否已做扩容或限流"——否则修完照打不误。这条正好是 9.11 刚沉淀的原则第 10 条的实操检验：不用技术大类词还不够，停在服务名也不够。
- "初期影响范围未识别完全"是 9.11 SOP 第二步的活证据：故障当次恢复很快，但残留数据是靠数据中台后续监控补发现的——和王建朝 9.11 讲的"不能等中台告诉你"完全对上。建议把 SOP 第二步固化成可交付清单：受影响业务线 / 涉及表与数据量 / 修复 SQL 的时间范围与分区键 / 回滚兜底。
- 每日企微群登记是台账的轻量版，但企微群不可检索、不可统计。建议群内只做提醒、结论必须同步落一张在线台账（9.11 王建朝已要求 @李明非 出这张表）。否则三个月后回看，只剩一堆翻不到底的聊天记录，"每日登记"就白做了。
- 高德故障链终于接近收口：B 端出货表地址类为空从 9.09 的 4.2 万条降到今天仅剩 20 条。但仍需注意两件事——① 统一收口人仍未出现（9.08 起提了四次，三个切面仍各管各的）；② 剩下 20 条要"定向分析排查"，如果最终以"业务上允许为空"结案，务必记录原因与判据，不要只是把监控规则调掉（延续此前"阈值/规则调整必须留痕"的口径）。
- 发版合并到 9.20 有两个隐患：9.20 是周日，且 9.20 距离 10.15 双事业部切换只剩不到一个月、切换又无缓冲期。把三次发版压到周日一天，一旦出问题既没有工作日应急资源，也没有回滚余量。另外"方案无争议可走快速评审"里的"无争议"谁判定、怎么判定没定义——快速通道很容易变成默认路径，建议明确到"仅限≤N 行改动且不涉及数据结构与对外接口"。
- 9.15 集成节点"不可动摇"，但节点完成的判定标准没定义。今天同时说门店积分 9.15 进机测且先远程进行（双节临近）。门店积分涉及发券、核销、积分扣减与跨门店规则，远程机测能否覆盖真实门店场景存疑；而 10.15 切换无缓冲，9.15 一旦虚过就没有退路。建议把 9.15 的"集成完成"定义为可验收清单（哪几个接口、哪几条主链路跑通、哪些用例通过率达标算完成），而不是一个状态词。
- 数据治理是一条接力的线：9.11 早会提到导购与经销商关系 119 条差异做整然/失效/达标处理，今天说这部分"已达标处理"，本周转向导购与门店关系治理，同时供应商今日输出门店与经销商关系差异比对。三者在做三种不同的关系对，建议确认是否同一批基础数据的不同关系维度，避免各治理各的、口径互相对不上。
- 9.11 早会那三条 RPC 待办应就地合并：当时拆成"排查 RPC 调用异常是否导致产品编码/名称缺失"挂三个人。本场已给出确定根因（Data 库连接满），那三条应关闭并归入本场的 SOP + 台账待办，避免重复排查。
- 转写存疑（原文保留）："经销商财务失效无断维控"语义不明，疑为"经销商财务维度失效 / 未维护"类表述；"远程方式"机测的具体范围未说明。本场原文未给任何待办责任人，上表责任人系我按 9.11「RPC 问题沟通」的挂靠关系补注，请以实际分工为准。
计费中心钱包需求工作量评估
主题摘要：完成计费中心钱包需求的工作量评估，核减 77 人天。
小结
- 完成计费中心钱包需求的工作量评估，核减 77 人天。
待办
- （本项无新增待办）
关联与提示
- 建议把核减的"基准线"留痕：本次只记录了"核减 77 人天"这个结果，未记录原评估值与核减后的终值。建议在主计划或需求文档里补上「原评估 / 核减后 / 核减项清单」，否则 77 人天这个数字三个月后会变成无法复查的孤立结论。
- 核减项需回流到排期：77 人天对应的需求范围、被砍掉或合并的功能点，应同步到 9.14 早会提到的主计划与 9.20 发版窗口，避免出现"人天减了但排期没动"的口径错位。
平台菜单整合方案研讨
发言人：刘阳、贾云飞、王建朝、崔建瑞、柳瑞军
主题摘要：本次会议围绕项目管理平台与 AI 开发平台的菜单整合展开讨论，明确了以项目管理平台为主入口的整合方向，并初步规划了前端 UI 风格统一、菜单分类及首页展示的后续改造方案。
小结
- 平台定位差异：AI 开发平台偏向单点能力（如 BRD 生成、PRD 评审），主要面向产品经理等特定环节人员；项目管理平台偏向全流程代办，主要面向研发及项目管理人员。
- 主入口方向已定：最终目标是将 AI 开发平台的能力整合进项目管理平台，用户从项目管理平台进入即可直接调用底层 Agent 能力，避免在不同系统间复制粘贴内容。
- 短期渐进式整合：因两平台底层架构差异较大、短期内难以完全融合，决定先在前端 UI 与菜单目录层面整合，后续再逐步推进架构层面的统一。
- iframe 方案被否：若用 iframe 直接嵌入，会导致操作区域变窄、当前页刷新跳转不便于两边进度对照，体验较差，故不采用。
- 统一前端 UI 风格：决定先统一两平台前端 UI 风格与基座，将 AI 开发平台页面风格向项目管理平台靠拢，降低视觉割裂感。
- 菜单按业务分类：菜单目录初步规划为「评审类 / 建设类 / 项目管理类」三大板块，将问答类等非开发相关功能单独归类管理。
- 增加一级分类入口：为避免菜单层级过深，计划在菜单最外层增加一层分类选择，进入后选择模块再进入具体功能，方便快速定位。
- 首页以任务代办为核心：首页展示应以用户近期任务代办为主，而非直接展示全局评估数据，确保进入系统能快速处理手头工作。
- 首页增加项目概览指标：计划在首页顶部增加项目概览的小指标卡片，方便用户快速了解整体项目情况。
- 按角色控制菜单可见性：系统需支持基于用户角色与权限控制菜单显示隐藏，确保不同角色（内部员工、外部供应商）只看到相关功能模块。
待办
- 参考一智开发平台（即「伊智开发平台」的会议转写异写，与正文"AI 开发平台"同指）已有的整合方案，推进项目管理平台与 AI 开发平台的菜单融合性改造。 — @刘阳
- 在系统首页顶部增加项目概览的小指标卡片，并将核心展示内容调整为近期任务代办。 — @贾云飞
关联与提示
- 平台命名口径需统一（已知风险）：本场正文用"AI 开发平台"、待办用"一智开发平台"，二者实为同一平台。按既有约定，"一智 / 一致 / 意志开发平台"是"伊智开发平台"（原"AI 辅助开发平台"正式名）的会议转写异写。建议在正式文档与待办里统一为正名，避免与"项目管理平台"混淆。
- 本场部分回答了"四平台关系"待厘清项：MEMORY 中长期挂着一个未决项——伊智 / AI 辅助开发 / WorkBody / EdBody 四平台关系未在一处说清。本场明确了"AI 开发平台能力整合进项目管理平台、以项目管理平台为主入口"，等于先给 AI 开发平台落了位；但 WorkBody 与 EdBody 的定位边界仍未在本场厘清，建议专项里继续收口，否则"主入口 + 两个智能体平台"仍会制造用户困惑。
- 待办缺截止时间：两条待办都只挂了责任人、没有交付时间。刘阳的菜单融合改造、贾云飞的首页改造都涉及前端排期，建议补一个里程碑（如挂到 9.20 发版窗口或单独周排期），否则容易一直"推进中"无闭环。
- "问答类等非开发相关功能单独归类"是分类缺口的信号：目前菜单分"评审 / 建设 / 项目管理"三类，但已承认存在"问答类"等不属于这三类的功能。建议同步定义"其他 / 工具类"兜底分类，避免后续新能力无处安放、又堆回主菜单。
- 外部供应商可见性要联动数据安全分级：按角色控制菜单可见性、区分内部员工与外部供应商，方向正确且与 9.11 规范的"最小权限 / 默认拒绝"一致；但外部供应商若能看到调用模型的 AI 能力入口，需同步校验其可见功能是否触碰 L3/L4 私有化数据边界（9.11 规范：L3/L4 必须私有化、绝密严禁建设）。建议权限方案把"角色 — 可见模块 — 数据分级"三列一起定。
- 渐进式整合的可行性判断：先统一 UI 风格、后统一架构，是架构差异大时的务实选择；但需警惕"UI 统一了、底层仍是两套"带来的长期维护成本——同一功能在两套架构上各改一遍。建议在推进菜单融合的同时，明确架构层统一的技术预案与触发条件（如某能力日活超阈值即启动架构合并）。
活动计费管理技术方案评审：冷饮事业部红包接入方案评审
发言人：王军、贾继伟、王建朝、蒋宜宏、李强
主题摘要：本次会议评审了计费中心冷饮事业部接入红包系统的技术方案，重点讨论了营销活动与记账流水同步、红包自动提现机制、账期规则与回调补偿、对账模块，并明确了底层数据表（已达 2000 万+）分库分表优化的后续规划。
小结
- 营销活动兼容冷饮字段：在现有营销活动管理模块增加兼容处理，接收并同步冷饮事业部的设备字段，无需改造主流程。
- 记账流水 MQ 异步落库：同步逻辑保持 MQ 异步落库以削峰填谷；同步过程中从缓存读取产品数据，减少直接查库压力。
- 门店类角色自动提现：本次接入新增门店类角色自动提现，消费者与门店提现逻辑均兼容；提现失败回退"待提现"，门店员工可在钱包 H5 手动一键提现。
- 提现状态流转：状态由下游营销天网反馈流转（未发起支付 / 提现中 / 成功 / 失败）；对"未发起支付 / 提现中"设定时任务补偿重试并轮询最终支付结果。
- 失败回退闭环：下游返回错误时，提现单置"失败"、记账流水回退待提现、提现支付记录同步标记失败。
- 账期规则关闭：冷饮事业部配置关闭账期规则，红包进账流水账期属性为"有效"、到期日期设为较大日期（即实际不设账期冻结）。
- 提现成功 MQ 异步回调：成功后通过 MQ 异步回调上游营销活动管理模块（冷饮）；回调失败累加通知次数，定时任务筛选"回调次数 ≤30 次且结束时间 ≤6 小时"的任务补偿；连续失败 3 次或超 6 小时转人工介入。
- 对账双触发 + 防重：定时任务在活动到期后自动触发，或由 B 端在自动对账失败后手动触发；系统防重生成，新任务将主表对账标记"进行中"并累加对账次数。
- 汇总优先、明细兜底：第二阶段定时任务（每 5 分钟）先汇总对账（本地 vs 上游汇总），不一致再进明细对账（遍历流水与原数据表，对比金额 / 出资方式，异常或单边缺失入对账结果表）。
- 记账单对账联动提现单：记账单对账成功后，自动在提现单对账主体表插入数据，触发后续提现单对账流程。
- 复用现有表模型：仅部分明细表补充事业部字段区分；所有对外接口及 Web 端入口均需增加事业部字段以实现按事业部数据切片。
- 千万级数据量预警：线上记账流水表、提现记录及明细表已达 2000 多万，存在性能瓶颈风险；业务代码层已预留分库分表支持，后续需排期底层分库分表优化。
待办
- 更新方案文档，补充事业部字段的相关说明与标注。 — @王军
- 补充冷饮事业部回调通知的令牌获取时间（修改为 24 小时）。 — @王军
- 删除方案中已取消的微信支付失败错误场景描述。 — @王军
- 输出底层数据库分库分表优化技术方案，并规划到后续项目排期。 — @王军
关联与提示
- 分库分表是本次最该挂时间的待办：线上核心三表已达 **2000 万+**且明确"存在性能瓶颈风险"，而方案只说"业务代码层已预留、后续排期"。"预留了接口、没排期"是典型技术债前置——冷饮是新接入事业部，数据量还会更快膨胀，叠加 9.14 早会提的 9.20 发版 / 10.15 双事业部切换（无缓冲），等爆了再排期就来不及。建议把王军那条"输出分库分表方案"直接挂到可验收里程碑（如 9.20 后第一周出方案、Q4 落地），不要停在"后续"。
- 回调补偿的两条触发条件不是一回事，建议写清：方案同时有"回调次数 ≤30 次且结束时间 ≤6 小时"的补偿筛选上限，和"连续失败 3 次或超 6 小时转人工"的硬触发。前者是定时任务捞哪些单子来重试，后者是人接手的边界，两个维度别混。另"连续失败 3 次"若按每 5 分钟轮询，约 15 分钟就转人工，那 30 次 / 6 小时的补偿窗口基本用不上——需确认"连续失败"的计数口径（是否跨任务周期重置）。
- 关闭账期 = 失去防逆向缓冲，需联动退款链路：冷饮"关闭账期规则"意味着红包进账立即有效、可被提现。要确认：一旦用户退款 / 退货，已提现红包如何追回？账期本就是防套现 / 防逆向的缓冲。这与 9.11「RPC 问题沟通」定的"退款按原汇率退、混合支付分开退"、以及积分退款的逆向逻辑是同一类问题，建议把"红包无账期 + 提现逆向"作为一个闭环专项确认，别让账期一关就把漏洞打开了。
- 事业部字段不能只靠字段、要在代码层隔离：方案要求"所有接口 + Web 端加事业部字段做数据切片"，但按 MEMORY 已沉淀原则第 6 条"功能隔离靠代码不靠规范"——事业部区分不能依赖配置人员填对字段，否则一个事业部的请求能读到另一个事业部数据。建议明确"事业部字段是否参与数据权限隔离判断"，尤其红包 / 提现涉及资金。
- 状态机覆盖关系待确认：自动提现失败会"回退待提现"，但定时任务又对"未发起支付 / 提现中"做补偿重试——"待提现"到底是被自动重试覆盖、还是只由门店手动触发？若两者都能动，存在并发双提风险。建议把状态机画全：待提现 / 未发起支付 / 提现中 / 成功 / 失败各自的进入与退出条件，堵住并发口子。
- 与今日第二节"计费中心钱包需求核减 77 人天"是同一系统：本场是钱包（红包 / 提现）的技术设计落地，第二节是工作量评估。建议把分库分表方案、事业部字段改造这类评估时可能未含的增量，回流核对——核减 77 人天后排期是否已含本场的表改造与分库分表工作量，避免"人天减了、实际工作量没减"的口径错位（同第二节提示 2）。
营销活动中心技术方案评审：Scan Detail 数据丢失回补与 SR 治理
发言人：（原文未列，评审方为营销活动中心技术团队）
主题摘要：本场评审了因 SR（Stream Routing Load）服务升级重启导致 9 月 7 日—11 日丢失约 3 万条扫码查证明细表（Scan Detail）数据的故障原因、数据回补方案，以及后续的监控告警与架构重构治理。
小结
- 故障时间线：9 月 7 日 SR 服务升级重启，Stream Routing Load 异常中断；9 月 11 日服务重启恢复；9.7—9.11 共丢失约 3 万条数据。
- 故障现象：消息正常消费但未落库，主要影响扫码查证明细表（Scan Detail）。
- 根因初步推测：SR 重启时主库与 Kafka 等中间件状态不一致，待进一步取证（属现象级描述，未定位到具体服务 / 脚本 / 代码分支）。
- 业务影响分级：Scan Detail 供前端与中台展示，需回补；B 端出货表、异常流向表仅字段缺失、业务未使用，暂不回补。
- 回补逻辑：以经销商名称为关联键，从 SR 临时表回补 Scan Detail，使用
NOT EXISTS防重复插入；分批执行——先验证 9 月 7 日 13 条数据，通过后再执行剩余。 - 一致性保障：临时字典表保证经销商名称 + 编码唯一，防止笛卡尔积造成数据膨胀；回补起始时间 9 月 7 日 23:58:47，按天拉取数据。
- 监控治理：对接学通，新增 Stream Routing Load 异常停止告警，解决本次故障无告警的问题。
- 架构优化：10 月输出 SR 存储与同步重构方案，评估存储 / 同步方式替换，解决资源、写入、同步稳定性瓶颈。
待办
- 执行 Scan Detail 数据回补：先验证 9 月 7 日 13 条，通过后再分批回补剩余约 3 万条。 — （原文未标注责任人）
- 对接学通，新增 Stream Routing Load 异常停止告警。 — （原文未标注责任人）
- 10 月输出 SR 存储与同步重构方案，评估存储 / 同步方式替换。 — （原文未标注责任人）
关联与提示
- "消息正常消费但未落库"是消费确认与落库非原子导致的同类缺陷：消费位点已前进但落库失败，本质和 9.11「RPC 问题沟通」那次"catch 后字段没设置就发 MQ、流程中断但上游已确认"是同一类形态——异常被吞、流程断在中间、上游不知情。建议把"落库成功之后再 ack"写成 SR 重构的硬约束，否则重构只换存储不换范式，照样丢。
- 根因"待取证"按 MEMORY 原则第 10 条仍不达标：初步推测"主库与 Kafka 状态不一致"是现象级，没落到具体服务、哪个重启脚本、Kafka 哪个 topic、状态不一致的具体表现（offset？partition？主从延迟？）。回补执行前务必把取证结论补进故障表。另本次最初并非靠告警发现（第三项的"新增告警"已自证是监控盲区），应写进复盘作为告警覆盖缺口证据——这正好印证 9.11 王建朝"不能等中台监控驱动修复"的口径。
- 回补关联键用"经销商名称"有匹配风险：方案自己承认要用字典表防"名称 + 编码"笛卡尔积，说明名称本身不可靠（重名 / 变更 / 不规范）。建议回补关联键优先用经销商编码，名称仅作辅助校验；
NOT EXISTS判定必须基于业务主键而非整行，否则分批边界（同一经销商跨天）会漏插或错插；9 月 7 日那 13 条灰度验证要显式覆盖名称异常、跨天分批边界等高风险场景，不能只验证"能跑通"。- "B 端出货表 / 异常流向表暂不回补"需留痕、别变永久隐患：本场称其"业务未使用"，但 9.14 早会显示 B 端出货明细表并非完全闲置（有"经销商财务失效无断维控 9.20 解决"排期、且高德地址异常也在此表）。须确认缺失字段不影响 9.20 那条排期，否则"暂不"会悄悄变成"永不"。
- 三项动作要登入 9.11 统一问题台账、落实 SOP 闭环：9.11 王建朝要求所有问题进同一张台账（发现来源 / 影响范围 / 根因 / 责任人 / 排期 / 关联待办）。本场的回补、告警、SR 重构是 SOP 第二步（识别影响范围 + 修复）的落地，但本场没提台账——别又散落，建议直接挂到那张表里。
- 9.7 升级到 9.11 恢复间隔 4 天无人发现，指向发布缺"升级后数据写通校验"：SR 升级重启后若做一次写通校验，当天就能发现 Load 中断。建议把"服务重启 / 升级后必须做一次数据写通与消费位点校验"纳入发布 checklist（呼应 MEMORY 原则：临时脚本上线前全量测试、评审材料没写等于没评审）。
提现对账方案评审
发言人：王军、王建朝、贾继伟、孔玮
主题摘要：本次会议评审了提现单对账方案，明确了两阶段对账机制与表结构，确认了主数据更新逻辑，并针对门店自动提现的参数传递问题安排了后续确认工作。
小结
- 适用品牌范围：提现单对账仅支持营销天网品牌（数字化金融也支持），不支持经销商。
- 核心表结构（4 张）：提现单对账任务表、对账元数据表、对账明细表、提现对账主体表，分别记录任务、拉取的元数据及异常明细。
- 一阶段：定时任务触发：遍历状态已结束且超过两天的营销天网活动，生成对账任务并更新主表进度。
- 前四次自动 + 人工兜底：每个营销天网活动前四次对账由系统自动触发，若前四次均失败则停止自动触发；B 端管理人员可手动重新发起作为兜底。
- 二阶段：汇总优先、明细兜底：先调用营销天网汇总接口与本地对比；不一致则通过游标分页拉取明细元数据逐单比对，识别单边缺失或明细差异。
- 对账结束清理元数据：对账任务完成后，清空当前活动对账主体下的原数据以释放线上数据库内存。
- 账期规则配置：需在红包记账流水账期规则表中为"人运事业部"配置账期规则，且计费冷饮的规则状态设为关闭。
- 主数据异步落库：主数据含销售区域、门店等五类基础数据，经 MQ 批量推送异步落库，通过主数据 ID 更新。
- 人员数据按主数据 ID 全局更新：不区分事业部，通过全局唯一主数据 ID更新，使用时再结合事业部及状态筛选。
- 状态变更依赖主数据推送：人员跨事业部调动导致状态失效时，主数据中心推送最新状态，系统据此做白名单等权限管控。
- 门店自动提现参数待确认：王建朝问门店自动提现的 open_id / app_id 是否具备，王军答功能支持且参数非空必填、已具备；孔玮追问新营销活动模块（无历史沟通记录）上游能否满足该条件，王军需会后与营销主管确认。
- 对接范围确认：计费冷饮本期仅涉及智慧门店，不涉及小智。
待办
- 确认门店端自动提现功能中，上游系统是否能提供 open_id 和 app_id 等非空必填参数。 — @王军
- 调整并完善方案中涉及的细节内容，并将接口确认结果发出。 — @王军
关联与提示
- 本场与「冷饮红包接入」是同一条对账链路的上下游：上一节（冷饮红包接入）明确"记账单对账成功后自动插入提现单对账主体表、触发提现单对账"——本场正是那个提现单对账的落地（4 张表、两阶段汇总→明细、防重标记进行中）。两节应合并理解为"记账单对账 + 提现单对账"全链路，但两条待办都挂 @王军且都缺统一排期，建议合并跟踪，别各跟各的。
- "前四次自动全失败即停止、仅人工兜底"需确认恢复路径：若根因是上游接口间歇性超时，第 5 次可能成功，但"停止自动"意味着永久不自动重试、只能靠人记得手动。建议明确：停止后是否允许"活动级"重新开启自动，或定时任务对"已停止但活动仍在进行"的活动做周期探活，否则会静默漏对账。
- "对账后清空元数据"与差异复核 / 审计矛盾：二阶段结束即清空对账主体下原数据。可一旦出现单边缺失 / 明细差异，清空后后续复核、财务审计都无原始拉取数据可查。建议区分结局：存在差异的不清空、或清空前归档到冷存 / 历史表——呼应 MEMORY 原则第 11 条（可回溯）与 9.11 规范（日志留存内 3 月 / 外 6 月）。
- 门店自动提现的 open_id / app_id"上游是否具备"是阻断性风险：王军说"自动提现要求这些参数非空必填"，但孔玮指出新营销活动模块无历史沟通、上游能否满足未知。这意味着若上游不满足，门店自动提现将整体无法上线——而这正是上一节（冷饮红包接入）"新增门店类角色自动提现"的前置阻塞项。建议 9.20 发版前必须给结论，否则冷饮红包的"门店自动提现"功能悬空，直接冲击 9.14 早会"9.15 集成节点不可动摇"。
- 主数据"全局更新不区分事业部 + 使用侧按事业部筛选"需强制三要素校验：主数据层不隔离事业部、隔离发生在使用侧。风险在于使用侧"事业部 + 状态"筛选若有遗漏，会出现人运 / 冷饮 / 其他事业部共享同一主数据 ID 但权限管控错位。建议明确"主数据 ID + 事业部 + 状态"三要素在使用侧的强制校验，尤其白名单权限（本场提到依赖状态做白名单管控）。
- 人运有账期、冷饮关账期，坐实了上一节的风险点：本场确认"计费冷饮规则状态设为关闭"，正好印证上一节"关闭账期 = 失去防逆向缓冲"的判断——两套账期并存时，退款 / 逆向逻辑必须分别处理（有账期 vs 无账期回退路径不同）。建议把"红包无账期 + 提现逆向"闭环专项在本场一并挂账。另"仅智慧门店、不含小智"需确认小智提现对账是否走另一套，避免两线口径不一。
数据修复方案评审
发言人：潘玉平、王建朝、粱健、贾继伟、张喜等 10 人
主题摘要：本次会议重点评审了系统出货历史数据修复、盘点明细表字段新增及签收距离修复方案，明确了执行细节与风险，并针对查证地址修复提出了补充评估要求。
小结
- 系统出货历史数据修复（586 万条一次性更新）：针对 8 月 6 日至 9 月 11 日期间"仅签收未出货"的盘点与查证场景，通过 SQL 将出货单与签收单匹配的数据一次性更新为系统出货；该操作仅涉及单列更新，预计影响较小、无需复杂脚本。
- 执行排期与注意事项：因数据量大，计划于 9 月 16 日发版当晚 22:00 或 24:00（低峰期）执行；需与朱老师确认大批量更新对 SR 数据库的具体影响，并评估分批次执行以避免系统压力。
- 盘点明细表新增"签收类型"字段：在签收门店名称后新增签收类型字段，展示最后一次出货的签收记录类型，前端展示与导出效果保持一致。
- 该字段无需重复评审：仅新增查询字段、逻辑简单、已在测试环境验证通过，测试报告出具后直接上线，不走复杂评审流程。
- 签收距离修复（时间范围界定）：仅修复 8 月 6 日至 8 月 14 日数据，排除 3 月 27 日（tag 表重构前）及异常签收类型，共计约 13700 条码。
- 签收距离按签收单批量修复：通过 SQL 根据签收单获取签收距离，仅更新"签收距离 + 更新时间"两字段；修复前需先备份数据。
- 执行速率与留痕要求：需评估并控制执行速率、避免全表扫描影响库性能；因技术方案文档大小受限，完整 SQL 脚本须上传网盘并附链接确保可追溯。
- 查证地址修复暂缓：涉及串货、违规销售等复杂业务逻辑，不能直接修表，需先梳理修复后对业务的具体影响范围；需与产品及业务方对齐影响与结论，并将评估结论补充至技术方案开头后方可推进。
待办
- 与朱老师确认大批量数据更新对 SR 的影响，并评估分批次执行方案。 — @粱健
- 明天完成 SOP 的审核并给出反馈。 — @王建朝
- 与产品及业务方对齐查证地址修复的业务影响范围，并将结论补充至技术方案开头。 — @潘玉平
关联与提示
- 586 万条一次性 SQL 更新是高危操作，必须逐字对照 MEMORY 原则第 11 条"先堵后修 + 备份表与修复语句 WHERE 逐字一致"：本场只说"预计影响较小、仅更新单列"，但 586 万行量级 + 16 号发版当晚执行，必须补三件事——① 备份表 WHERE 与修复 SQL WHERE 逐字一致（否则无法回滚，这是 9.04 盘点签收修复评审的血泪教训）；② 是否已先上堵漏代码确认 8.6–9.11 期间无新增同类脏数据（先堵后修，别边漏边修）；③ 分批执行的具体上限与频率评估。
- "仅签收未出货"范围的界定 SQL 要慎重：本场用"出货单与签收单匹配"反推"仅签收未出货"。需明确匹配关联键与边界条件，避免把"真正未出货"和"已出货但状态未同步"两类数据混改。另注意：9.14 早会 Scan Detail 回补是另一张表（查证明细），与本次出货/签收主数据修复是两件事，别在排期里并成一条。
- "无需重复评审 + 直接上线"与 9.11 刚发布的规范有张力：9.11 规范要求"评测必须 100% 覆盖六维度 + 业务用户验收"。签收类型虽是简单查询字段，仍建议至少留测试报告归档而非彻底跳过；它直接挂生产表的前端与导出，导出口径错会流到下游报表（呼应 9.14 早会"查证明细表扫码机号字段为空 9.17 解决"那类排期）。
- 13700 条码签收距离修复的"控制速率避免全表扫描"要把关：只更新两列是对的，但 SQL 若 WHERE/索引不当仍会全表扫描拖垮库。呼应 MEMORY 临时脚本原则"必须幂等、上线前全量测试（含并发）、执行完毕立即下线"——建议修复 SQL 附带执行计划（EXPLAIN）确认走索引。
- 查证地址修复"暂缓"是正确的，但必须防长期挂起：涉及串货/违规销售，直接修表会掩盖真实业务问题，本场要求"先评估业务影响、补充至方案开头"与 9.11 SOP "识别影响范围"一致。但暂缓 ≠ 不修，潘玉平这条待办要设责任人 + 截止，否则易无限期晾着，而查证地址恰是 9.14 早会"高德地址异常仅剩 20 条"那条的源头之一。
- 三条待办都缺硬里程碑、且彼此有时序依赖：只有王建朝 SOP 审核有相对时间（"明天"=9.15），粱健的 SR 影响确认、潘玉平的查证地址评估均无日期。尤其 586 万修复定在 9.16，粱健的确认必须早于 9.16；且本场"确认大批量更新对 SR 影响"与今早会 RPC 根因"Data 数据库连接数满"是同一库——在连接本就吃紧的库上跑 586 万更新可能再次打满连接，建议粱健确认时一并评估连接数余量与限流。
- 名字存疑（原文保留）：待办责任人"粱健"（米字旁），与早前日志中出现的"梁健"（木字旁）疑似同一人异写，本场按用户原文保留；若确为同一人建议后续统一。