Work for YILI

Appearance

2026-10-20 工作日志 ​

述职材料：个人案例素材梳理（个人交付） ​

今日集中完成个人述职三个案例的选型、证据核验与格式定稿，覆盖技术管理/AI、营销活动中心事故机制、团队与人才三个面向。

完成的内容与优化 ​

1. 案例一：BRD 评审 MCP 能力开放（我与人共赢） ✅

  • 切入点：把自研的 BRD 评审能力以 MCP 形式开放给 Tool Hub、WorkBuddy 等 AI 工具。共赢的杠杆不在「开放」这个动作，而在三处把接入方的成本移回自己：
    • 凭证解耦：mcp_ 前缀 PAT（32 字节随机、仅存 SHA-256 哈希）+ /mcp-access 自助签发页；多来源令牌提取（Bearer → X-API-Key → ?token=），PAT 优先、回落 JWT，解决「小白用户拿不到 JWT、AI 工具难配置」的前提。
    • 身份双通道：平台参数注入（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 工具接入 BRD 评审 MCP 操作手册 / MCP 能力生产发版手册 / BRD-MCP-ToolHub 接入规范合规分析报告）。
  • 方法论沉淀：《存量系统 MCP 改造升级方案》五步法（能力盘点→工具设计→身份鉴权→结果错误分层→接入验收），供其他存量系统复用。

2. 案例二：9.30 B 端出货明细表 4.9 亿条数据误清空事故的机制整改 ✅

  • 根因三层：insert overwrite + SR 分区匹配未命中直接覆盖／数据量大耗时过长改用 overwrite 未评估风险／团队对 SR 小众数据库机制掌握不足且无运维经验。
  • 恢复时间线：9.30 10:00 执行 → 10:10 发现并联系项目经理协调中台与技术监理 → 10:20 线上会议 → 10:50 定方案由中台回推至临时表 → 次日 5:00 半年内 2.8 亿条恢复完毕 → 当晚 2.1 亿条历史数据补齐，4.9 亿条当日全量恢复。
  • 整改机制（共赢载体）：批量修复类 SQL 须张喜/李明非/王建朝三人审核后方可上会，禁止个人直接上会；SR 表数据修饰一律禁用 SQL 直改，统一 Java 程序 + Stream Load 分批更新；上线评审表固定增加 SR 操作、新老接口兼容、SFA/PDA/App 版本兼容三项检查；insert overwrite/delete 从技术视角禁限或走特殊审批；DDL 前全量备份并验证恢复流程，渠道域备份情况全盘查漏；建立 UAT/PET 生产数据回灌机制；重大节前严禁发版与需求变更的封版红线；重点人员学 SR 机制并考核；长期推动 SR 替换云端 PaaS（Doris/ClickHouse）+ 业务解耦。
  • 共赢表述内核：把一次事故的追责压力转成全团队共享的免错机制——开发拿到可复制的修复路线与文档标准，测试与运维侧风险从个人经验转清单化管控，机制反向解放 DBA 不必手写高危 SQL。
  • 文档规范同步确立：方案先出伪代码级大流程框架，建表 SQL/统计语句/Stream Load 指令作附录，核心 SQL 须附业务逻辑依据、测试环境空跑结论与执行计划截图证明分区命中。

3. 案例三：多面试官交叉的技术评审机制（以人为中心） ✅

  • 考察维度实证（源自 9.11 / 9.16 / 9.20 / 9.23 / 9.28 五轮面试记录）：系统性能与稳定性（Redis keys 循环拖垮，单次下发 4h→12min；VisualVM Dump 定位 OOM）／架构演进与多库兼容（V5 单体→V8 分布式，MyBatis 二次封装适配 MySQL/Oracle/SQL Server/国产库）／分布式与幂等（分布式锁与分布式事务、统一认证/工作流/MQ/实时流推送）／交付质量与工程纪律（双月迭代、分支覆盖率 90% 以上）／AI 辅助研发的边界意识（AI 使用率约 30%，敏感数据严禁送 AI，开发者对最终代码正确性兜底）／底层原理与表达。
  • 机制侧实证：面试官固定编组交叉面评（王林、张建利、薛碧盈、马奇、相桂梅、李明非、王建朝）；对外结论统一由人事与候选人联系，评委不各自承诺；9.28 单场三连（明安振 通过 / 高志 不通过 / 冯陈龙 通过），9.16 单周并行 4 场并全部进入待评议。

4. 案例格式定稿 ✅

  • 述职体单段结构确定：「在【项目】中，我把【切入点】作为切入点，全面梳理【对象】，从【维度】等多维度开展排查 → 针对排查出的隐患，结合业务实际制定分阶段整改方案，明确目标、责任主体及时间节点 → 通过技术指导与协同推动完成优化升级 → 筑牢【意义】」。

小结 ​

  • 三个案例的共同内核是把个人/单点经验转成可复制的机制，与「我与人共赢」的主线一致：MCP 开放是把己方约束改造成对方案兼容；事故整改是把追责压力转成全团队免错机制；评审机制是把评委个人判断固化为交叉面评流程。述职表述上以机制承载能力，而非以能力包装机制。
  • 同时保留诚实性边界：案例一截至 week42（截至 10-17）仍处「待发版验证」，不得表述为已全量上线；案例二相关会议记录未署发言人，归属表述对外前需确认；案例三多轮面试的评议结论本身未落文字，若需展示机制如何运转需补记一次评议会。

待办 ​

1. 述职材料收尾确认

  • 确认 BRD 评审 MCP 能力当前发版状态（UAT/生产发版、Tool Hub 清单刷新、ai_call_record.user_id 落库报错修复进展），核实后再决定述职中的「已落地」表述。——责任人待定
  • 与相关方确认 9.30 事故复盘与 SR 修复方案评审两场会议的主导者署名口径。——责任人待定
  • 向薛碧盈确认多轮面试的实际评议流程，必要时补记一次评议会以补全「机制如何运转」环节。——责任人待定

2. 沉淀与推广

  • 将三个案例的述职体定稿整理为可复用模板，纳入个人述职材料库。——责任人待定
  • 推动《存量系统 MCP 改造升级方案》五步法在其他存量系统团队中复用。——责任人待定

盘点与积分需求评审 ​

发言人：吴南林、郑然然、余建新、李明非、宋洋等 8 人；主题：本次会议围绕盘点任务与积分商城的优化需求展开评审，明确了经销商与门店盘点逻辑、积分逆向冲减规则及报表展示维度，并梳理了多项待确认事项。

小结 ​

1. 盘点任务创建与人员过滤

  • 时间控件合并：盘点任务创建时，将开始时间和结束时间合并至一个控件内完成选择。
  • 人员与品牌过滤：需对执行人员（内部与经销商人员）及部分品牌进行过滤，具体过滤名单待与业务方确认后补充。
  • 增加任务预览功能：盘点任务发布前增加预览按钮，点击后弹出不可编辑的预览界面供业务方核对。

2. 经销商与门店盘点逻辑

  • 任务类型切换：盘点页面新增任务类型页签，选择「经销商」时隐藏门店类型和范围，选择「门店」时正常显示。
  • 盘点位置与数据汇总：经销商盘点位置可为仓库、门店或其他位置；若选择其他位置，系统将根据经纬度解析至街道维度进行数据汇总，未传数据将提示异常。
  • 任务结束机制差异：门店盘点支持前端手动结束；经销商盘点仅能在到达结束日期后由系统自动结束。
  • 激励计算规则：仅在门店产生的盘点数据会纳入活动的售卖激励计算，仓库或其他位置的盘点数据不计入。
  • 盘点人员角色限制：经销商盘点任务仅限经销商人员操作，前端界面仅展示产品范围；门店盘点任务则允许门店和经销商人员操作。
  • 任务防重校验：系统已具备校验机制，同一产品且同一生产日期不允许创建重复的盘点任务。

3. 积分商城兑换产品券与首页展示

  • 增加适用产品字段：在兑换产品券的界面、商城列表及产品详情中，需显示该券关联的适用产品字段。
  • 首页门店与积分联动：从首页进入商城显示全部门店积分汇总，从钱包进入则带入默认门店；门店筛选项切换时需联动更新下方积分卡片的值。

4. 积分逆向冲减与发放逻辑

  • 逆向冲减规则：门店发生退货时，无论活动是否下架，均需将已发放的积分为门店进行逆向冲减并退还。
  • 活动明细数据更新：退货后，活动明细表中已发放奖品数量及金额需扣除已扣减的积分，且需增加「已退还」标记。
  • 报表数据一致性：积分明细报表中，已发放、剩余与退还的数量需保持逻辑相等，避免增加解释成本。
  • 红包无退还机制：新活动的积分支持逆向退还，但现金红包无论新老活动均不支持退还。
  • 积分发放与扣减维度：积分的发放与扣减均由计费系统处理，维度为「人 + 活动 + 经销商 + 门店」。

5. 积分明细报表展示维度与数据同步

  • 增加经销商维度：积分明细报表需增加经销商维度，以便按门店和经销商查看积分数据。
  • 过期积分同步确认：需与计费团队确认过期积分的减少数据能否同步至报表，以保障可用积分展示的准确性。

待办 ​

1. 盘点任务需求确认

  • 与业务方确认盘点任务中需过滤的具体人员名单及品牌范围，并将确认结果同步给技术团队。——@余建新
  • 拉会确认盘点任务相关的其他待确认事项。——@马奇

2. 积分逆向冲减与报表口径

  • 将积分逆向冲减的详细逻辑（含活动下架及退货场景）补充完善至需求文档中，并与相关人员对齐。——@吴南林
  • 与计费团队确认过期积分的减少数据能否同步至积分明细报表。——@吴南林

关联与提示

  1. 同根因切面（与 10-19 积分体系评审定调并读）：10-19 已把「积分过期仅改状态、不生成变动记录」列为已识别缺口，并由 @赵敏 认领补充生成逻辑；本次评审从报表侧提出「过期积分的减少数据能否同步至报表」，本质是同一缺口的下游闭环——若计费侧变动记录不补齐，报表的「已发放 = 剩余 + 退还」等式与可用积分展示都无法对账，本次待办（@吴南林 与计费团队确认）正是该缺口的对账侧入口。
  2. 同根因切面（10-19 定调的逆向扣减规则未覆盖「活动下架」场景）：10-19 口径为「同积分池内优先扣过期池、不足再扣有效池、不足产生负积分，逆向扣减不处理冻结积分，且逆向单据必须强关联一笔正向流水」，本次明确「门店退货时无论活动是否下架均需逆向冲减并退还」，是在原规则外补齐下架活动这一分支。需注意其与现金红包的差异——红包不退还，意味着同一笔退货在积分与红包两条线上报表口径不对称，需在需求文档中显式区分，否则报表的「退还」列会被理解为全品类适用。

营销活动中心开发进度同步会 ​

发言人：李亚洲、邢健、余建新、孙东栋；主题：本次会议同步了营销活动中心的开发进度，确认了联合中心需处理的关键问题，并明确了 11 月基础底座与主数据的对数排期及遗留问题的排查安排。

小结 ​

1. 整体开发计划与进度同步

  • 计划正式发布：会议确认开发计划已更新完毕，后续将直接发布，各端已确认本周协同的具体时间节点。
  • 确认四个关键问题：联合中心昨日沟通确认了四个需处理的问题，本周将重点推进这四个问题的处理排期，其他优先级较低的问题将向后顺延。

2. 基础底座与主数据对数安排

  • 数据链路切换背景：营销活动中心后续将切换至基础底座，数据将不再走主数据，而是直接走基础底座。
  • 11 月启动对数：计划于 11 月 1 日启动基础底座与主数据的对数比对工作。
  • 协调主数据开发资源：需协调主数据团队开发资源，并在 11 月前确定具体的对数比对日期。

3. 遗留问题与风险排查

  • 排查新增问题原因：针对今日新增的第三和第四个问题，需进一步排查具体原因。
  • 排查扫码类型异常：针对近期反馈的解析地址及扫码类型问题，需确认是否存在异常。
  • 云商数据清洗完成：云商数据清洗问题已于昨日完成并提前上线关闭。
  • 更新问题状态：要求相关人员及时将已解决的问题更新至已解决状态，避免继续挂起。

待办 ​

1. 联合中心问题推进

  • 重点推进联合中心确认的四个关键问题处理排期，其余低优先级问题顺延。（责任人待补充）

2. 基础底座与主数据对数

  • 协调主数据团队开发资源，并在 11 月前确定具体的对数比对日期。——@余建新
  • 11 月 1 日启动基础底座与主数据的对数比对工作。（责任人待补充）

3. 遗留问题排查与状态治理

  • 排查今日新增第三、第四个问题的具体原因。（责任人待补充）
  • 确认近期反馈的解析地址及扫码类型问题是否存在异常。（责任人待补充）
  • 及时将已解决问题更新至已解决状态，避免继续挂起。（责任人待补充）

冷饮事业部二期需求评审 ​

发言人：赵敏、郑然然、薛梅、孔玮、王建朝等 6 人；主题：本次会议评审了冷饮事业部二期需求，明确了门店角色卡券核销及配送员角色红包记账与提现方案，并确认了接口调整与后续测试排期安排。

小结 ​

1. 门店类角色（店员、店长、店主）卡券核销逻辑

  • 复用卡券中心 + 新增全部核销：整体复用现有卡券中心能力，新增「全部核销」逻辑。
  • 支持跨经销商合并核销：门店类角色生成核销码时不再区分经销商，卡券中心在核销时按规则（如经销商不匹配）判定部分券核销失败。
  • 新增全部核销功能：账户下卡券数超过页面加载数量时，支持一键全部核销；若账户内券数量大于 500 张，则按到期时间排序仅核销前 500 张。
  • 核销按钮交互互斥：勾选具体卡券时仅激活「批量核销」按钮；未勾选任何卡券时才激活「全部核销」按钮。

2. 卡券发放维度确认

  • 发放至门店维度：冷饮二期卡券发放支持给到门店侧人员，该门店下所有人均可查看并核销此卡券，属门店维度。
  • 活动配置颗粒度待确认：卡券活动配置是否细化到个人维度，需与相关人员进一步确认。

3. 配送员角色红包记账与提现（接口调整）

  • 新增配送员角色枚举：记账流水接口的收款方角色增加配送员枚举，并新增经销商编码与名称字段。
  • OpenID 调整为非必填：营销活动中心奖励发放时可能无法获取配送员小程序 OpenID，该字段调整为非必填；未传 OpenID 时系统仅记录记账流水，不触发自动提现。
  • 提现失败余额转入钱包：因未传 OpenID 或账户原因导致自动提现失败时，余额保留在配送员钱包中，支持后续手动提现。

4. 配送员记账户与钱包展示

  • 新增经销商维度记账户：新增经销商类型的记账户，配送员可按不同经销商查看待提现、已提现及失效余额明细。
  • 提现不区分经销商：手动提现基于总账户余额一次性提现，不按经销商维度拆分。
  • 钱包仅支持一键提现：配送员钱包仅含红包功能，嵌入 SFA 小程序；提现记录区分自动提现与手动提现，并保留失败原因展示与重试机制。

5. 对账功能调整

  • 增加配送员角色与经销商编码：从营销活动中心获取的对账数据中增加配送员角色枚举及对应经销商编码。
  • 报表呈现增加枚举：对账报表的收款方角色字段同步增加配送员枚举类型。

6. 小程序身份认证

  • 对接 SFA 小程序身份注入：配送员钱包 H5 内嵌于 SFA 小程序，沿用现有对接与鉴权方式；登录失败时提供返回小程序重新登录的页面。

7. 后续建议（评审中识别，待补充确认）

  • 「全部核销」的语义与上限需对齐产品口径：账户内券数大于 500 张时按到期时间排序只核销前 500 张，而按钮文案是「全部核销」，且交互互斥设计使得用户无法通过勾选绕过该上限——建议明确提示实际核销张数，或将上限提到配置项，否则易被理解为已全部核销。
  • 角色功能隔离建议在代码层实现：门店类角色（店员/店长/店主）持有卡券能力、配送员角色仅持红包能力，入口差异应由代码按角色判断，不依赖配置人员注意。
  • OpenID 缺失属可预期降级而非异常：已明确「仅记流水、不触发自动提现、余额留钱包」，建议在流水与提现记录中保留可区分的失败原因标记，便于后续批量补提现。

待办 ​

1. 卡券与活动配置确认

  • 确认冷饮二期卡券活动配置是否细化到个人维度。——@孔玮

2. 记账接口口径确认

  • 沟通并确认记账接口中收款方编码的唯一性与必填性。——@赵敏

3. 测试与排期

  • 输出冷饮二期需求的测试计划（包含单元、集成及压测识别），并发送至沟通群内。——@李强

关联与提示

  1. 与 10-16 券中心跨经销商核销研讨并读：10-16 结论是「同经销商可合并、跨经销商不可合并生成核销码，生码阶段不校验经销商，核销阶段按券配置规则校验」。本次冷饮二期把生码端的经销商约束整体移除（门店类角色生码一律不区分经销商），只保留核销端的规则判定，即把 10-16 的限制从「生码层」下沉到「核销层」。影响在于：核销端需真正承载不匹配判定，货补券「全有或全无」的失败语义与自制券「部分核销」的成功语义会同时出现在同一批门店券上，前端「批量核销失败」的提示必须能区分是哪一类原因，否则业务方会按 10-16 的生码约束来理解报错。
  2. 与 10-19 活动计费评审「红包不支持逆向退还」并读：10-19 已定调「新活动积分支持逆向退还，但现金红包无论新老活动均不支持退还」。本次冷饮二期把红包链路从「发放」延伸到「记账 → 自动/手动提现」，并引入「提现失败余额留存钱包、保留失败原因与重试机制」的新分支。影响在于：红包一旦进入提现环节，其逆向场景（门店退货后已提现的红包如何处理）在 10-19 口径下是明确不支持的，而配送员侧余额留存 + 可重试会形成「已发放但可长期挂账」的形态——需与 10-19 的守恒关系（累积=有效+冻结+失效+消耗+负积分）在同一张表里对齐，否则对账报表的失效余额口径会缺一块。

盘点与数据修复方案评审 ​

发言人：余勇军、王建朝、粱健、潘玉平、贾继伟等 10 人；主题：本次会议主要评审了盘点任务类型技术方案、TDS 码表数据修复脚本及 PDA 扫码类型赋值异常修复方案，明确了各方案的改造逻辑、数据影响范围及后续测试验证要求。

小结 ​

1. 盘点任务类型技术方案

  • 新增经销商盘点类型：主表增加任务类型字段，区分经销商与门店盘点任务；门店任务不展示门店类型与门店范围。
  • 记录表信息冗余：记录表中增加门店名称、经销商名称、执行类型、仓库编码及名称，并存储「其他位置」盘点时的经纬度及省市区街道信息。
  • 多场景盘点校验：经销商任务支持门店、仓库、其他位置三种盘点方式；系统校验经纬度是否在国内，以及仓库与经销商的归属关系。
  • 前端参数与拦截逻辑：营销助手和小智需传参进行任务筛选；详情页增加拦截逻辑，仅在门店盘点时返回门店范围信息。
  • 销售激励发放规则：经销商带门店盘点时，仅向门店发放销售激励；其他盘点方式不发放激励。
  • 街道级定位限制：通过「其他位置」盘点时，系统目前只能定位到街道级别，无法精确到具体门店，该限制已与产品确认接受。
  • 接口向下兼容：历史接口仍可使用，仅增加任务类型作为筛选条件，不影响现有校验逻辑。
  • SFA 对接确认：已与 SFA 团队确认，SFA 仅查询经销商任务，新增参数不影响历史逻辑及灰度发布。

2. TDS 码表数据修复方案

  • 修复背景：TDS 经销商编码与门店编码相同导致名称取错，需修复盘点明细、消费者中奖明细及底层码表数据。
  • 修复数据量：码表需修复 10 万条，盘点明细表 2000 多条，消费者中奖明细表 600 多条；B 端出货明细表数据正常，无需修复。
  • 改用分片键更新：修复脚本将更新条件由 seq number 改为使用分片键 code 进行批量更新，每批 1000 条。
  • 全表备份后更新：盘点明细表与消费者中奖明细表均需在全表备份后，通过 update 语句直接更新。
  • 无需上线直接执行：修复脚本无需走上线流程，直接通过脚本更新执行。
  • 补充验证截图：需将临时表的抽样验证截图及测试验证过程补充至方案中。
  • 盘点明细表时间同步：因盘点明细表无 update time 字段，数据清洗完成后需与数据中台进行同步。

3. PDA 扫码类型赋值异常修复方案

  • 异常原因：1015 版本新增 PDA 扫码方式枚举后，代码默认走 none 赋值，导致查证明细表中约 1500 多条 PDA 扫码类型为空。
  • 影响范围：仅影响查证明细表；B 端出货明细表无扫码类型字段展示，不受此异常影响。
  • 代码逻辑对齐：需在代码中增加 PDA 类型枚举，其赋值逻辑与二维码扫码（qr code）保持一致。
  • 存量数据修复：通过 trace code 长度及前缀判断扫码类型——长度大于 12 位为体内码、vx 开头为中转箱、其余为体外码；通过 update 语句修复 15 号之后的空数据。
  • 业务场景确认：确认 SFA 可通过 PDA 扫码，且 PDA 扫码逻辑与二维码一致，数据中存在 PDA 扫码情况属正常业务场景。
  • 需发版并补充自测结论：该修复涉及代码发版，需找测试团队验证，并将自测结论补充至方案中。
  • 修复前需备份：执行修复脚本前需对数据进行备份，以防逻辑异常。

4. 后续建议（评审中识别，待补充确认）

  • 新增枚举必须同步兜底赋值分支：本次根因是「新增枚举后旧分支默认走 none」，属枚举扩展时的典型漏改。建议把「枚举新增/改名必须同步默认值与存量赋值分支」列为代码评审固定检查项，与「录入类字段须有区间校验」同类，不依赖开发自查。
  • 三套修复脚本的执行前置条件不齐：TDS 码表（无需上线直接执行）、盘点明细与消费者中奖明细（备份后 update 直改）、PDA 扫码类型（需发版 + 备份）三者的执行门槛不一致，同批修数建议统一按最高门槛执行（备份 + 抽样验证截图 + 口径留痕），避免低门槛路径成为惯例。
  • 分片键批量更新的收尾要可核对：改用分片键 code、每批 1000 条是正确方向，但需在方案中写明总批次数与「以分片键命中数 = 预期修复数」作为收尾核对口径，否则「修完」只是执行结束、不是数据正确。

待办 ​

1. 需求侧限制备注确认

  • 确认经纬度定位到街道级别的限制影响是否已备注至 PRD 文档。——@粱健

2. 修复方案材料补充

  • 将临时表的抽样验证截图及测试验证过程补充至 TDS 码表数据修复方案中。——@潘玉平
  • 找测试团队进行验证，并将自测结论补充至 PDA 扫码类型修复方案中。——@余勇军

关联与提示

  1. 与今日 10:30「盘点与积分需求评审」并读（同一议题的需求侧 → 技术侧闭环）：需求侧当日只确认了「经销商盘点位置可为仓库、门店或其他位置；若选择其他位置，系统将根据经纬度解析至街道维度进行数据汇总，未传数据将提示异常」，本次技术方案给出了具体实现——记录表冗余经纬度与省市区街道信息、校验经纬度是否在国内、校验仓库与经销商归属关系，并把「只能定位到街道级别」明确为已与产品确认接受的限制，需求侧当日的未定项至此收敛。激励口径也完成细化：需求侧「仅在门店产生的盘点数据纳入售卖激励计算」落到本次「经销商带门店盘点时仅向门店发放销售激励，其他盘点方式不发放激励」，两者一致但本次更明确到发放对象是门店而非经销商。
  2. 与今日 10:30「营销活动中心开发进度同步会」并读（前次待办闭环）：10:30 会上要求「确认近期反馈的解析地址及扫码类型问题是否存在异常」，本次给出了结论——1015 版本新增 PDA 扫码方式枚举后代码默认走 none 赋值，查证明细表约 1500 多条扫码类型为空，影响面仅限查证明细表，B 端出货明细表因无该字段展示而不受影响。该待办已从「待排查」转为「已定位根因 + 已定修复方案 + 已定存量修复规则（trace code 长度 >12 为体内码、vx 开头为中转箱、其余为体外码）」。
  3. 与既有数据修复评审红线的口径核对（需在执行前完成）：本次 TDS 码表方案「无需走上线流程，直接脚本执行」与「盘点明细表、消费者中奖明细表全表备份后 update 语句直接更新」，与已沉淀的两条红线存在口径差——① 批量修复类 SQL 须张喜/李明非/王建朝三人审核后方可上会（9-14 口径），本次评审虽有三方在场但需确认另外两位审核人身份；② SR 表数据修饰一律禁用 SQL 直改、统一由 Java 程序 + Stream Load 分批更新（2026-10 评审确立），需先确认本次涉及的 TDS 码表、盘点明细表、消费者中奖明细表是否为 SR 表——若是，则「update 直接更新」的方案形态本身不成立，须改走程序化更新路线。此项不核对清楚即执行，等于绕开了为 4.9 亿条误清空事故建立的全部防线。