2026年第43周工作周报（10.19-10.25）

本周（10-19 周一 ~ 10-21 周三有记录，10-22 周四上午生报）共 3 个工作日、12 场会议/评审、1 项个人交付。其中技术方案评审 4 场（工厂状态口径修正一场出具正式评审文档、结论通过）、需求/PRD 评审 4 场、测试用例评审 1 场、周会与进度对齐 3 场。 核心主线三条：「盘点任务改造 需求→技术方案→测试用例 三段闭环」（同一议题三天内走完全链，是本周最完整的一条）、「12 月 17–20 三项目并行上线窗口浮出资源缺口」（酸奶钱包 + 冷饮二期 + 积分逆向）、「底座 PG 迁移与工厂状态口径修正」（营销活动中心切底座的第一次技术方案落地）。

一、营销活动中心（盘点任务全链闭环 + 底座迁移 + 数据修复）

需求评审一句话结论： 本周营销活动中心仅一场需求评审（10-20 盘点与积分需求评审），其结论是**「一放一收」——盘点操作面放开：由单门店扩为经销商/门店双任务类型，落点扩到仓库与其他位置（其他位置按经纬度解析至街道级汇总）；钱的口子收**紧：售卖激励只认门店、退货无论活动是否下架一律逆向冲减、现金红包一律不退、报表须满足「已发放 = 剩余 + 退还」。

技术评审一句话结论： 本周两场技术评审（10-20 盘点类型 + TDS 码表/PDA 扫码修数、10-21 工厂状态口径修正 + PG 迁移接口）是同一套工程姿态——语义一律不动、能力靠加维度、风险靠留备份（盘点加任务类型与记录表冗余字段、工厂加 basic_status_code 备份列、修数一律先全表备份、接口向下兼容只加筛选条件），代价因此整体被推到表结构与执行顺序上；而这两场的执行门槛（是否走发版、是否停网关、是否须三人审核）至今没有统一。

本周密度最高。盘点任务在三天内完成「需求评审（10-20）→ 技术方案评审（10-20）→ 测试用例评审（10-21）」全链，是本周唯一一条从需求侧走到用例侧闭环的议题；同时底座 PG 迁移与工厂状态口径修正完成技术评审并通过，两条数据修复脚本（TDS 码表 / PDA 扫码类型）待执行。

盘点任务：需求侧定口径（10-20 盘点与积分需求评审，@吴南林、@郑然然、@余建新、@李明非、@宋洋 等 8 人）

• 任务类型双轨：新增任务类型页签，选「经销商」时隐藏门店类型与范围，选「门店」时正常显示；经销商盘点位置可为仓库、门店或其他位置，选其他位置按经纬度解析至街道维度汇总，未传数据提示异常。
• 结束机制差异：门店盘点支持前端手动结束，经销商盘点仅能在到期后由系统自动结束。
• 激励口径：仅门店产生的盘点数据纳入售卖激励计算，仓库与其他位置不计入；经销商盘点任务仅限经销商人员操作，门店任务允许门店与经销商人员共同操作。
• 任务治理：开始与结束时间合并为一个控件；执行人员（内部与经销商）及部分品牌需过滤，名单待业务确认；发布前增加不可编辑的预览页；同一产品且同一生产日期禁止重复建任务。
• 积分侧同场定调：退货时无论活动是否下架均需逆向冲减并退还；活动明细表已发放奖品数量与金额需扣除并增加「已退还」标记；积分明细报表中已发放 = 剩余 + 退还，三者须逻辑相等以避免解释成本；现金红包无论新老活动均不支持退还；发放与扣减维度为「人 + 活动 + 经销商 + 门店」；报表增加经销商维度，过期积分减少数据能否同步报表待与计费团队确认。
• 待办：@余建新 确认人员名单与品牌范围并同步技术团队；@马奇 拉会收敛其余待确认项；@吴南林 将逆向冲减详细逻辑（含活动下架与退货场景）补入需求文档、并确认过期积分同步报表。

盘点任务：技术侧落地（10-20 盘点与数据修复方案评审，@余勇军、@潘玉平、@贾继伟、@粱健 等 10 人）

• 主表增加任务类型字段；记录表冗余门店名称、经销商名称、执行类型、仓库编码与名称，并存储「其他位置」盘点的经纬度及省市区街道信息。
• 校验项：经纬度是否在国内、仓库与经销商的归属关系；详情页增加拦截，仅在门店盘点时返回门店范围信息；营销助手与小智需传参做任务筛选。
• 激励发放对象细化到门店：经销商带门店盘点时仅向门店发放销售激励，其他盘点方式不发放——与需求侧「仅门店数据纳入售卖激励」一致，但更明确了发放对象不是经销商。
• 「只能定位到街道级」由产品确认接受，作为已知限制不再收敛。
• 接口向下兼容（历史接口仍可用、仅增加任务类型筛选），SFA 已确认仅查经销商任务、不影响历史逻辑与灰度发布。

盘点任务：用例侧揭出设计缺口（10-21 盘点任务测试用例评审，@刘莉、@宋洋、@吴南林 等 8 人）

• 用例侧新增两个方案未覆盖的点：报表经纬度换算准确性（换算错误会导致距离计算偏差，属方案缺口而非测试缺口）；同一产品同一月份下经销商类型与门店类型任务的互斥拦截。
• 异常边界落成可验证项：经纬度非法值（国外或 0,0）须由接口直接拦截；不同人员并行盘点同一门店任务时先结束者生效，另一人再进入提示任务已结束。
• ⚠️ 本周最需盯住的设计缺口：当前仅在进入任务时校验一次权限，扫码过程中不校验门店与经销商类型（产品维度反而是实时判断）。盘点是长时段作业，期间门店被移出经销商、渠道类型变更都会让已盘数据事后无法归因。同场出现两条方向相反的结论——门店中途被移出经销商后看不到任务，但已盘数据仍计入活动激励，激励归属（原任务经销商 vs 变更后实际归属）PRD 未写。是否加实时校验取决于 @宋洋 的性能评估，但即使决定不加，也必须把「变更期间已盘数据如何归因」写成明确口径。
• 排期密到无缓冲：后端接口 10-22 上午联调 → 最早本周五集成冒烟 → 10-27 UAT → 10-28 集中测盘点 → 10-29 推 Pre 整体验证且同日晚上推前端灰度。29 日两个动作叠在同一天，28 日集中测出问题则当天既无修复窗口也无回退窗口，灰度动作应与 Pre 验证通过结论绑定。
• 待办：@刘莉 补预期结果与测试截图、积分逆向用例、单门店结束不影响其他门店的用例、中途数据变更后激励是否正常发放的验证、27 日前提供体验码；@宋洋 评估实时校验性能开销；@吴南林 按评估结论更新 PRD。业务方两项前置输入（执行人员名单、品牌产品范围）仍未到位，直接决定任务创建时的过滤范围，越晚拿到越压缩 UAT 前准备时间。

数据修复双方案（TDS 码表 + PDA 扫码类型，10-20 同场）

• TDS 码表：经销商编码与门店编码相同导致名称取错，需修码表 10 万条、盘点明细表 2000 多条、消费者中奖明细表 600 多条；B 端出货明细表数据正常无需修复。更新条件由 seq number 改为分片键 code 批量更新、每批 1000 条，两表均在全表备份后 update 直改；该脚本无需走上线流程、直接执行；盘点明细表无 update_time 字段，清洗完成后需与数据中台同步。@潘玉平 补临时表抽样验证截图与测试验证过程。
• PDA 扫码类型：1015 版本新增 PDA 扫码方式枚举后代码默认走 none 赋值，致查证明细表约 1500 多条扫码类型为空；影响面仅限查证明细表（B 端出货明细表无该字段展示）。代码需补 PDA 枚举且赋值逻辑与二维码一致；存量按 trace code 长度 > 12 为体内码、vx 开头为中转箱、其余为体外码回填 15 号之后的空数据；该修复需发版 + 测试验证 + 修前备份。@余勇军 补自测结论。
• ⚠️ 执行门槛存在口径差，须在执行前核对：本次三套脚本门槛不一（无需上线直改 / 备份后 update 直改 / 发版+备份），最低那条最容易被后续沿用；且「TDS 码表、盘点明细表、消费者中奖明细表是否属 SR 表」未确认——若属 SR 表，则 2026-10 确立的「SR 表数据修饰一律禁用 SQL 直改、统一 Java 程序 + Stream Load 分批更新」使「update 直接更新」的方案形态本身不成立。此项不确认即执行，等于绕开 9.30 事故后建立的全部防线。

工厂状态口径修正 + 底座 PG 迁移（10-21 技术方案评审，结论：通过）

• 问题：主数据视图同时下发头层 STATUS 与个性层 PERSON_STATUS，两者可能不一致；营销活动中心落库取的是头层 STATUS，业务上应以个性层为准。经核查该有效无效字段无对外接口使用，改动不涉业务逻辑。
• 方案：FactoryConvert 的 statusCode 改取个性层 PERSON_STATUS，头层 STATUS 映射至新增 basicStatusCode 作备份列；上线前以初始化 SQL 将存量 status_code 整体备份至新列；业务侧字段名与列名不变、读取逻辑无需改动。
• 决议四条：① 在 factory 表列注释、FactoryDTO/Factory 实体注释、Convert 映射处写明取值来源与本次调整原因；② 初始化 SQL 先在测试环境全量执行验证；③ 变更生产表前先整体备份，确保可回溯；④ 底座侧同源问题（同样取错值、同样处理方案）必须同步改造，不能在 PG 切换时遗漏。
• 风险：同一库内状态字段语义反转——工厂表 status_code 存个性层、其他从主数据同步的表仍存头层，两套口径并存；person_status 命名不直观为主数据侧历史模型设计，后续维护者易误读，只能靠本次补充的注释约束。
• PG 迁移接口：废弃原「单接口向两个 Topic 分发」方案（存在影响在跑业务的风险），改为主数据提供两套接口并行推送，正式切换后旧链路与旧代码一并下线；测试环境先用单接口验证数据接收与 PG 写入，正式切换前用双接口与主数据做全量数据核对。⚠️ 旧链路下线目前只有条件（"切换完成后"）没有日期与责任人。
• 待办：@郝梓斐 评审后即改字段逻辑并在下周完成测试与上线、同步补备份表逻辑与底座 PG 库迁移逻辑；@李明非 与建利老师确认测试/生产环境接口提交流程；@宋洋 编写主数据配合事项文档；液奶接入基础底座及门店中心 PG 迁移方案已就绪，因本场时间冲突由 @马奇 另行组织专题评审。

开发进度与遗留治理（10-20 同步会 / 10-19 项目复盘周会 / 10-19 B 端 SR 剥离对齐）

• 开发计划已更新完毕并直接发布，各端确认本周协同时间节点。营销活动中心后续切换至基础底座、数据不再走主数据，计划 11 月 1 日启动基础底座与主数据对数比对，需协调主数据团队开发资源并在 11 月前定下具体比对日期（@余建新）。
• 联合中心已确认四个关键问题，本周重点推进排期、其余低优先级问题向后顺延；新增的第三、第四个问题需排查原因；近期反馈的解析地址与扫码类型异常已在当日方案评审中定位根因（即上述 PDA 枚举漏改）；云商数据清洗已完成并提前上线关闭；要求已解决问题及时更新状态，避免继续挂起。
• 10-19 周会：P1/P2 问题排期沟通因大版本发版准备被搁置，会后按业务影响分流——影响不高直接删除任务、需解决则本周内定沟通节点；上周一线上支付门店与数据相关问题最晚本周五完成整体复盘，已内部复盘且结论清晰的部分先沟通是否向全员同步。
• 10-19 B 端 SR 剥离方案现状对齐：当前链路为接收同步服务发消息至 SaaS 组装，SaaS 收消息后通知用户、点击跳转对应菜单；投屏演示过程出现问题待解决；待办为与小南、邱宇确认物品交接事宜。

二、活动计费管理（积分体系 / 冷饮二期 / 酸奶钱包）

需求评审一句话结论： 本周三场计费需求评审（10-19 积分过期与逆向扣减、10-20 冷饮二期、10-21 酸奶钱包）需求侧全部通过，但三条需求挤在 12-17~20 同一上线窗口、又都建在同一套计费钱包底座上，真正的风险已不在各自的功能范围，而在底座的两条能力边界尚未裁定——积分侧「过期即出池、不足记负分」的守恒口径能否在报表上对平，卡券侧「批量核销」究竟归券中心还是归事业部；边界不定，先落地的一方就会把语义定死，后落地的一方只能被动适配。

技术评审一句话结论： 本周两场计费技术评审（10-19 积分逆向扣减、10-21 冷饮二期）走的是同一条路——不新增接口、不新增系统，全部在既有单表与单套记账流水接口上「加维度」（积分侧加经销商维度与逆向维度，红包侧加归属主体类型维度），代价因此整体转移到数据层：字段扩容、唯一索引重构、历史数据清洗与 DDL 停网关窗口；扩展方式已经定型，但两场都没给出变更前的备份与恢复验证基线，改完滚不回去。

三条线在同一个 12 月上线窗口内交汇，本周从需求评审一路推进到技术方案评审，同时暴露出资源缺口与生产变更管控缺口。

积分过期与逆向扣减（10-19 两场评审，均通过，12 月版本上线）

• 有效期与回收：按积分批次维度控制，发放后 90 天自动失效转入过期池，失效积分不再参与兑礼与冻结；每天凌晨扫描「有效积分 > 0 且未标记过期」的批次，回收并生成积分变动记录与明细；钱包卡片不展示失效总额。
• 失效预警：1 / 7 / 15 天三档定时扫描 → 生成 CSV 上传 COS → 智慧门店取任务状态与数据包地址 → 按门店 + 经销商维度推送，每天仅提醒一次。关店与用户注销暂不特殊处理，积分照常计算有效期。
• 逆向扣减：同一积分池内优先扣过期池、不足再扣有效池、仍不足产生负积分由后续正向入账优先冲抵；逆向单据必须强关联一笔正向记账流水，无对应单据不生成逆向流水；逆向扣减不处理冻结积分；冻结积分遇过期按履约成功正常扣减、履约失败先判断是否过期再分流至过期池或可用池。
• 接口口径（关键决策）：不新增接口，只扩展原同步积分记账流水接口——增加逆向积分填写字段与记账场景枚举（如订单退货），逆向场景必填原记账流水单号；新增逆向记账流水模块，单独记录逆向流水编号、对应正向流水编号、业务类型、事业部、门店经销商与实际扣减积分；记账户、积分池、积分批次三个维度均新增「已扣减积分」与「负积分」字段；变动场景新增「逆向扣减」枚举；正向流水新增逆向扣减状态（待抵扣/已抵扣）并可跳转查看逆向单据。
• ⚠️ 已识别缺口：积分过期目前仅变更状态、未生成变动记录，前端明细无法与可用积分对账（@赵敏 认领补充生成逻辑）。正向链路因颗粒度细化到经销商维度需全量回归，PRD 须基于 920 版本以红字与批注标注变动点供测试新增用例；逆向压测优先级低，@王军 评估 12 月压测计划时确认必要性。

冷饮事业部二期（10-20 需求评审 + 10-21 技术方案评审）

• 门店类角色（店员/店长/店主）：复用卡券中心并新增「全部核销」；生成核销码不再区分经销商，由卡券中心在核销阶段按规则判定不匹配券失败；账户内券数超过 500 张时按到期时间排序仅核销前 500 张；勾选具体卡券只激活「批量核销」、未勾选才激活「全部核销」；卡券发放落门店维度，门店下所有人均可查看与核销。
• 配送员（经销商侧）：记账流水收款方角色增加配送员枚举与经销商编码/名称字段；OpenID 调整为非必填，未传时仅记流水、不触发自动提现，提现失败余额留存钱包可手动提现；新增经销商类型记账户，可按经销商查看待提现/已提现/失效余额明细；手动提现按总账户余额一次性提现、不按经销商拆分；钱包仅含红包、内嵌 SFA 小程序，沿用现有身份注入与鉴权。
• 技术方案（10-21）：记账账户唯一索引由「事业部编码 + 门店编码 + 用户编码」改为「事业部编码 + 归属主体类型 + 归属主体编码 + 用户编码」；配送员角色下门店编码与名称置空串；历史数据统一清洗为门店侧（含液奶，已有脚本），上线时经销商端无业务数据流入故无并发账号生成风险；后台管理文案需同步调整；DDL 数据量大需停网关数分钟执行。鉴权链路补全为「宿主小程序请求身份票据 → 计费后端基于主数据补经销商编码 → 登录令牌 → 网关校验并自动续期 → 失败回跳小程序桥接页」；提现结果轮询为「间隔 3 秒查汇总，有提现中金额则间隔 1 秒重试 3 次」。
• ⚠️ 取券排序口径不一致：需求侧写「按到期时间排序取前 500 张」，技术方案写「自动提取最近 500 张券」——同一上限下用户实际核销到的券不同，须明确排序依据并回写需求文档。
• ⚠️ DDL 与数据清洗同窗口执行，缺回滚基线：本次同时动表结构（唯一索引重构）与表内数据（历史清洗），且需停网关窗口（此时业务写入已中断、无天然兜底），但待办只有「与上游确认重试机制 + 协商暂停网关时间窗口」，10-10 复盘确立的「DDL 前全量备份并验证恢复流程」在本次方案中缺位。
• 待办：@王军 修复提现结果汇总页三种状态文案笔误、上线前与营销活动中心确认重试机制并协商停网关窗口；@赵敏 确认收款方编码唯一性与必填性（本场索引重构已给出答案，可闭环）；@孔玮 确认卡券活动配置是否细化到个人维度；@李强 输出含单元/集成/压测识别的测试计划。

酸奶事业部计费钱包 PRD（10-21 评审）

• 范围极窄：仅用卡券功能，不涉红包与积分；仅支持陈列货补券与陈列代金券，且仅单张核销、无多选与全选（理由为券中心不支持批量核销）；改动仅在前端钱包 H5，不涉计费管理后台服务端。
• 交互：按门店维度展示并支持切换；列表默认待核销，Tab 切换已核销与已过期并带数量角标；单张券生成核销码后靠轮询实时更新状态，关闭页面返回列表时再走查询接口更新；陈列货补券进详情页签收核销需选数量，一张券只能核销一次。
• 接入：复用智慧门店小程序链路，除新增酸奶事业部编码外 UI 参数与流程不变；只调用券中心货补券服务取数；消费者扫码的贴码活动属物码链路，与卡券钱包是两个独立系统，不涉本次迁移。
• ⚠️ 12 月中旬三项目并行、测试资源只 1 人：酸奶钱包、冷饮事业部、积分逆向均落在 12 月 17–20 日上线；当前仅 @丁聪 一人承担测试，积分逆向用例量与压测量最大。结论是 11 月前必须引入测试人员先介入用例评审，年底新人入场不熟业务接不住并行测试（@李强 盘点测试资源并拉通协同方）。协同方为数字化结案中台，联调尚未启动。

三、券中心 ECC（卡券核销能力归属悬空，本周唯一跨项目未收敛项）

本周三场会议对同一底座给出三套互斥描述，是本周最值得单列的一条悬空项：

• 10-16 券中心研讨（第 42 周未收录）：同经销商可合并生成核销码、跨经销商不可合并；生码阶段不校验经销商，核销阶段按券配置规则校验。
• 10-20 冷饮二期：把生码端的经销商约束整体移除，只保留核销端规则判定，并新增「全部核销 + 批量核销」。
• 10-21 酸奶钱包：以「券中心不支持批量核销」为前提，退到只做单张核销、无多选全选。

影响：若批量核销只是冷饮侧局部实现，则「券中心不支持批量核销」这一前提本身需要修正；两套 PRD 对同一底座的能力描述互相矛盾，后续联调与回归会各按各的理解写用例，同一套卡券中心对外呈现两套交互、维护成本翻倍。建议在券中心侧一次性确认批量核销能力归属（是否为通用能力、若为通用能力则酸奶侧约束需重估）。

四、技术管理智能体（BRD 评审 MCP 能力开放，个人交付）

• 三处把接入方成本移回自己的改造：① 凭证解耦——mcp_ 前缀 PAT（32 字节随机、仅存 SHA-256 哈希）+ /mcp-access 自助签发页 + 多来源令牌提取（Bearer → X-API-Key → ?token=），把门槛从「懂 JWT」降为「能自助签发一个凭证」；② 身份双通道——平台参数注入（oaCode 优先、userInnerNum 兜底）优先 + HTTP 令牌回落，5 个工具 schema 声明身份字段但不设 required，冲突以参数为准并告警；③ 解析质量外露——修掉 ReviewReportParser 硬编码 ### 导致模型输出层级漂移后静默降级为单条 NOTICE 的缺陷，改按语义识别并新增 brd_task.parse_status（OK/DEGRADED）经 MCP 透出，接入方可自查。
• 交付证据：分支 mcp-wjc-260929；后端 commit 9323724/60ee0d7、前端 70dd26da；5 项 MCP 回归全部通过；三份文档（AI 工具接入操作手册 / 能力生产发版手册 / Tool Hub 接入规范合规分析报告）；方法论沉淀《存量系统 MCP 改造升级方案》五步法。
• ⚠️ 状态诚实边界：截至第 42 周仍处「待发版验证」（UAT/生产发版、Tool Hub 工具清单刷新、ai_call_record.user_id NOT NULL 导致异步落库报错待修），不得表述为已全量上线；该状态需在本周内核实后再定稿对外表述。

五、团队与人才（述职材料定稿 + 多面试官交叉评审机制）

• 三个案例完成选型、证据核验与格式定稿，覆盖技术管理/AI、营销活动中心事故机制、团队与人才三个面向；共同内核是把单点经验转成可复制机制：MCP 开放是把己方约束改造成对方案兼容、事故整改是把追责压力转成全团队免错机制、评审机制是把评委个人判断固化为七人交叉面评流程（@王林、@张建利、@薛碧盈、@马奇、@相桂梅、@李明非、@王建朝）。
• 考察维度有实证支撑（源自 9.11/9.16/9.20/9.23/9.28 五轮面试记录）：系统性能与稳定性（Redis keys 循环拖垮，单次下发 4h→12min；VisualVM Dump 定位 OOM）、架构演进与多库兼容（V5 单体→V8 分布式，MyBatis 二次封装适配 MySQL/Oracle/SQL Server/国产库）、分布式与幂等、交付质量与工程纪律（双月迭代、分支覆盖率 90% 以上）、AI 辅助研发的边界意识（AI 使用率约 30%、敏感数据严禁送 AI、开发者对最终代码正确性兜底）。
• 诚实性边界一并保留：案例一不得表述为已全量上线；9.30 事故复盘与 SR 修复方案评审两场会议的主导者署名口径需确认；多轮面试的评议结论本身未落文字，若需展示机制如何运转须补记一次评议会。

---

附：本周工作清单（按日期）

日期	类型	项目	主题	关键结论/进展
10-19	需求评审	活动计费管理	积分过期与逆向扣减	通过，12 月版本上线；批次 90 天失效转过期池；逆向优先扣过期池、不足产生负积分
10-19	技术方案评审	活动计费管理	积分逆向扣减方案	通过；不新增接口、扩原记账流水接口；逆向必填原流水单号；过期仅改状态为已识别缺口
10-19	项目复盘周会	营销活动中心	开发与线上复盘	P1/P2 排期被发版挤掉，按业务影响分流；上周一支付门店问题最晚本周五复盘
10-19	方案对齐	营销活动中心	B 端 SR 剥离现状	SaaS 组装+通知跳转链路；投屏演示有问题待解决
10-20	需求评审	营销活动中心	盘点与积分需求	经销商/门店双任务类型；仅门店数据计入售卖激励；红包不支持退还；报表已发放=剩余+退还
10-20	技术方案评审	营销活动中心	盘点类型 + TDS 码表 + PDA 扫码修复	记录表冗余经纬度街道；TDS 修 10 万条改分片键每批 1000；PDA 空值 1500+ 根因为枚举漏改兜底
10-20	需求评审	活动计费管理	冷饮事业部二期	门店类角色新增全部核销；配送员红包记账+提现；OpenID 非必填
10-20	进度同步会	营销活动中心	开发进度与底座切换	11-1 启动基础底座与主数据对数；联合中心四问题本周推进；云商数据清洗已关闭
10-21	PRD 评审	活动计费管理	酸奶事业部计费钱包	仅卡券、仅单张核销；12-17~20 三项目并行、测试仅 1 人，11 月前须补人
10-21	测试用例评审	营销活动中心	盘点任务用例	揭出「仅入口校验一次」缺口；中途数据变更后激励归属未定；10-27 UAT、10-29 Pre+灰度无缓冲
10-21	技术方案评审（通过）	营销活动中心	工厂状态口径修正 + PG 迁移接口	status_code 改取个性层 PERSON_STATUS、头层存 basicStatusCode 备份；废弃单接口双 Topic，改双接口并行推送
10-21	技术方案评审	活动计费管理	计费冷饮二期	唯一索引改「归属主体类型+编码」；DDL+数据清洗同窗口但缺备份与恢复验证；取券「最近 500」与需求「到期时间排序」不一致

跨周待办核对

• 第 42 周「积分过期仅改状态不生成变动记录（@赵敏 认领）」 → 10-19 方案评审确认该缺口仍存在，并新增下游对账视角（10-20 报表侧提出「过期积分减少数据能否同步报表」）。演进为「变动记录生成 + 报表同步」两处待办，未闭环。
• 第 42 周「盘点任务锁冲突需按峰值设计」 → 本周盘点链路走到用例侧，未再提锁冲突；但 10-21 新增「扫码过程中不校验门店/经销商类型」的性能评估（@宋洋），两者同属盘点高峰期的性能与一致性风险。原锁冲突待办本周无闭环记录，新增一项性能评估待办。
• 第 42 周「1015 上线三系统须维护上线评审检查清单（代码评审+上线方案评审必填，责任人待定）」 → 10-21 冷饮二期技术方案评审的 DDL 变更未附备份与恢复验证，说明该检查清单未在本周生效。待办失效风险。
• 第 42 周「券中心批量券类型校验仅前端实现、未形成强制动作」 → 本周升级为能力归属问题（冷饮有批量/全部核销、酸奶称券中心不支持批量）。由「校验缺口」演化为「底座能力归属未定」，范围扩大。
• 第 42 周「中奖明细表清洗下周四发版」 → 10-20 TDS 修复方案涉及消费者中奖明细表 600 多条，但走「备份后 update 直改、无需上线流程」，与「发版」路径不同。路径已变更，需确认是否同一批数据。
• 第 42 周「BRD 评审 MCP 待发版验证」 → 10-20 述职材料中仍标注「截至 week42 待发版验证」。仍挂起。
• 第 39 周「B 端出货明细 200 万+历史数据暂缓修复转业务沟通」 → 本周 TDS 方案明确「B 端出货明细表数据正常，无需修复」，但指的是名称取错问题、非 200 万+历史数据。仍挂起，注意勿混同。
• 第 41 周「数据一致性修复排期 10-15 / 10-29」 → 10-19 周会「P1/P2 排期沟通因大版本发版准备被搁置」，改为按业务影响分流。原排期节点实质失效，口径变更。

本周原则与认知沉淀（跨周串联）

1. 同一批修数的执行门槛必须统一按最高标准，且「是否需要上线流程」不能由数据量决定：10-20 三套脚本门槛不一（直接执行 / 备份后直改 / 发版+备份），最低那条最容易被后续沿用——这与 9.30 事故后建立的「高风险 SQL 禁限 + DDL 前全量备份」防线是同一件事的两面。判据应前置为「目标表是否 SR」，而非「本次改动看起来风险小」：若是 SR 表，则 update 直改的形态本身不成立，须走程序化更新。建议把「同批修数门槛取最高」与「先判表类型再定执行方式」写成修数方案的固定首段。

2. 枚举扩展未同步兜底赋值分支，是本季度第三次出现的同一形态缺陷：PDA 扫码类型 1500+ 条空值，直接原因是 1015 新增枚举后旧分支默认走 none。此前 9.04 盘点签收故障（失败状态覆盖成功状态）、10-14 ReviewReportParser 硬编码 ### 静默降级，都是「扩展时漏改一处、且漏改处静默降级」。建议把「枚举新增/改名必须同步默认值与存量赋值分支」列入代码评审固定检查项，与「录入类字段须有区间校验」「SQL 必带分区键」同列——不依赖开发自查。

3. 校验时点决定事后能否归因，长时段作业尤其：盘点只在入口校验一次权限，期间门店被移出经销商、渠道类型变更，已盘数据的激励归属就成了说不清的尾巴；这类缺口不会在上线时暴露，而是在激励对账时暴露，届时补口径要翻历史数据。即使性能评估决定不加实时校验，也必须给出「变更期间已盘数据如何归因」的口径——「评估后再说」不是结论。同场「看不到任务但数据仍计入激励」两条方向相反的结论并存，正是缺少这条口径的直接证据。

4. 条件句不是排期：本周两处同型——PG 迁移「待正式切换完成后下线清理」、盘点「若性能无影响则增加实时校验」。落地结果都是新旧两条路径并存到年底，排查数据问题时先得判断该看哪条链路的结果。建议把「方案变更后必须同时给出旧路径的退出条件与时间点」作为方案评审的固定检查项，与「废弃旧方案时说明影响面」配套。

5. 当同一底座对外呈现两套互斥交互时，问题在能力归属而不在需求：冷饮「全部核销 + 批量核销」与酸奶「券中心不支持批量核销、故仅单张」是同一底座上的相反结论。此类分歧不能靠两份 PRD 各自澄清，必须在底座侧一次性确认能力归属，否则联调与回归会各按各的理解写用例，维护成本翻倍。判据：同一能力在不同事业部方案里描述相反时，先冻结单个方案评审，回到底座确认。

6. 资源缺口要按「连续时间的验证工作」量化，而不是按人头：12-17~20 三项目并行、测试仅 1 人（@丁聪），最先崩的不是 PRD 与用例评审这类可并行的文档工作，而是压测与回归这两类需要连续时间窗口的验证工作。叠加 10-21 盘点「29 日同日推 Pre 验证与前端灰度」看，本周两处都缺「窗口级」而非「人力级」的排布——建议年底前把三项目的上线窗口、压测窗口、灰度顺序统一排一次，而不是各项目各自排自己的节点。

7. 对数的口径必须锚定同一时点与同一对象：10-20 定的 11-1 对数是「基础底座 vs 主数据」，10-21 定的是「双接口推送结果 vs 主数据」的全量核对。若 11-1 那次在双接口上线前做，比的是旧链路存量数据，与切换后的核对不是同一件事；两次都做则须明确各自比对的是切换前存量还是切换后结果，否则「对过了」这句话在两次对数之间无法互相背书。

范围说明： 本周区间 10.19~10.25，生报于 10-22（周四）上午，已覆盖 10-19、10-20、10-21 三个工作日（docs/work-log/2026-10-19-weibo.md、2026-10-20.md / -weibo.md、2026-10-21.md / -weibo.md）；10-19 无独立工作日志、仅有微博，该日内容以微博为唯一来源。10-22 之后及周末内容待补充。本周独立技术评审文档 1 份（20261021-技术评审-营销活动中心-工厂状态落库口径修正改用个性层PERSON_STATUS.md，结论通过），其余评审以日志/微博记录为准。

待补缺口提示： 第 42 周周报生报于 10-15（周四）上午，其「范围说明」自述 10-15 及周末待补充，实际至今未补——10-15（物码早会发版汇报 / AI 研发协同体系宣讲 / 历史数据修复方案评审）与 10-16（券中心券核销与发券逻辑研讨 / 高德接口异常排查）两日内容未纳入任何周报。10-21 冷饮二期评审与 10-20 冷饮二期需求评审均引用了 10-16 券中心研讨的结论，本周报已按引用关系承接该结论，但原始两日内容建议回补至第 42 周。如需，我可一并补写。

---

附：原始周记清单（10.19~10.25 补录）

来源：Obsidian 周记 2026-W40.md。该文件周次编号为「W40」，但内容实际覆盖 10-19~10-25（与本周同区间），系生报前的原始草稿。以下原样保留以补齐 wiki 凭据。

与正文的差异：PDA 扫码类型为空修复、工厂状态落库口径修正、盘点任务到经销商评审、积分逆向评审已在正文覆盖；以下三条为正文未收录——① TTS 经销商名称与门店名称混用导致的异常数据修复（需修改后再过一轮）；② SR 业务流程剥离技术方案已过 2 轮讨论，下一轮聚焦定时任务处理逻辑（自评复杂度最高）；③ 渠道底座-工厂状态落库口径修正（与营销活动中心同源）。

营销活动中心

• 盘点任务到经销商 / 积分逆向 PRD 评审
• 盘点任务增加经销商维度技术方案评审 — wiki 54811
• TTS 经销商名称与门店名称混用导致的异常数据修复，需再修改后过一轮 — wiki 54759
• PDA 扫码方式扫码类型为空修复
• 盘点任务到经销商维度测试用例评审
• 与主数据侧核对后提出工厂状态落库口径修正 — wiki 54850
• 渠道底座-工厂状态落库口径修正
• SR 业务流程剥离技术方案流程细化同步说明

原始结论草案

• 完成盘点任务到经销商、积分逆向等需求评审：盘点操作面放开，由单门店扩为经销商/门店双任务类型，盘点地点扩展到仓库和其他位置（其他位置按经纬度解析到街道级汇总）；资金口收紧，售卖激励只认门店、退货无论活动是否下架一律逆向冲减、现金红包一律不退。
• 完成盘点任务增加经销商维度技术方案、TTS 经销商名称与门店名称混用异常数据修复、PDA 扫码方式扫码类型为空修复等 4 个技术方案评审通过，按资源排期正常推进。
• SR 业务流程剥离技术方案完成 2 轮讨论，下一轮深度讨论定时任务处理逻辑，此部分复杂度最高。

计费

• 完成液奶积分逆向、冷饮二期、酸奶事业部接入等需求 PRD 评审，评审通过；三条需求都挤在 12-17~20 同一上线窗口，且都建立在同一套计费钱包底座之上。
• 完成积分逆向扣减、冷饮二期技术方案评审，评审通过；不新增接口、不新增系统，全部在既有单表与单套记账流水接口上「加维度」。