2026-10-20 工作微博

一、今日工作总结 1、模块TOP大事 ① 盘点与积分两条会形成需求到技术方案的闭环，三套修数脚本同时待执行。需求侧定下经销商与门店双任务类型：经销商盘点位置可为仓库、门店或其他位置，选其他位置按经纬度解析至街道维度汇总，仅门店产生的盘点数据纳入售卖激励计算，退货时无论活动是否下架均需逆向冲减并退还，现金红包新老活动都不支持退还，积分明细报表增经销商维度且已发放、剩余、退还三者需保持相等。技术侧给出落地：主表加任务类型、记录表冗余门店与经销商名称及经纬度街道信息，校验经纬度是否在国内与仓库经销商归属，接口向下兼容仅加筛选条件。修数三套并存，TDS 码表 10 万条、盘点明细表 2000 多条、消费者中奖明细表 600 多条改用分片键 code 每批 1000 条更新并在全表备份后执行，盘点明细与中奖明细无 update time 字段需与数据中台同步；PDA 扫码类型约 1500 多条为空，根因是 1015 版本新增枚举后代码默认走 none 赋值，存量按 trace code 长度大于 12 为体内码、vx 开头为中转箱、其余为体外码回填。风险点有三：枚举新增未同步兜底赋值分支属典型漏改，应列为代码评审固定检查项；三套脚本执行门槛不一致，最低门槛是直接脚本执行，须统一按备份加抽样验证加口径留痕执行；分片键更新需写明总批次数并以命中数等于预期修复数作为收尾核对口径。 ② 冷饮事业部二期需求评审定稿门店类角色核销与配送员红包链路。门店类角色复用卡券中心并新增全部核销，生成核销码不再区分经销商，由卡券中心在核销阶段按规则判定不匹配券失败，账户内券数超过 500 张时按到期时间排序仅核销前 500 张，勾选具体卡券只激活批量核销、未勾选才激活全部核销，卡券发放落在门店维度，门店下所有人均可查看与核销。配送员侧记账流水接口收款方角色增加配送员枚举与经销商编码名称字段，OpenID 调整为非必填，未传时仅记录流水不触发自动提现，提现失败余额留存钱包可手动提现，新增经销商类型记账户可按经销商查看待提现、已提现与失效余额，手动提现按总账户余额一次性提现不分经销商，钱包仅含红包并嵌入 SFA 小程序，沿用现有身份注入与鉴权方式。需产品确认项：全部核销文案与 500 张上限不一致且交互互斥让用户无法绕过，建议提示实际核销张数或把上限做成配置项；卡券活动配置是否细化到个人维度待定；角色能力差异应由代码按角色判断，不依赖配置人员注意。 ③ 述职材料三个案例完成选型与定稿，内核是把手上的单点经验转成可复制机制。BRD 评审 MCP 能力开放给 Tool Hub 与 WorkBuddy，改造点有三处：凭证侧用 mcp_ 前缀 PAT 配合自助签发页并只存 SHA-256 哈希，把接入方的门槛从懂 JWT 降为能自助签发一个凭证；身份侧做平台参数注入优先、HTTP 令牌回落的双通道，接入方无需重构鉴权；质量侧修掉解析器硬编码模型输出层级导致的静默降级，改为按语义识别并新增 brd_task.parse_status 对外透出 OK 与 DEGRADED，接入方可自查而不必回来问人；配套沉淀《存量系统 MCP 改造升级方案》五步法。9.30 B 端出货明细表 4.9 亿条数据误清空事故完成根因三层梳理与机制整改，恢复耗时一天半，落地批量修复类 SQL 三人审核后方可上会、SR 表数据修饰禁用 SQL 直改统一走 Java 程序加 Stream Load 分批更新、上线评审表固定增加 SR 操作与新老接口兼容及 SFA、PDA、App 版本兼容三项检查。面试机制案例以五轮面试记录实证考察维度与七人固定编组交叉面评。诚实边界一并保留：MCP 能力截至 week42 仍处待发版验证不得表述为已全量上线，两场复盘会议的主导者署名待确认，多轮面试的评议结论本身未落文字。

2、重点/基础工作 ① 营销活动中心开发进度同步会明确关键节点。开发计划已更新完毕并直接发布，各端确认了本周协同时间节点；营销活动中心后续切换至基础底座、数据不再走主数据，计划 11 月 1 日启动基础底座与主数据的对数比对，需协调主数据团队开发资源并在 11 月前定下具体比对日期；联合中心确认的四个关键问题本周重点推进处理排期，其余低优先级问题向后顺延，新增的第三与第四个问题需进一步排查原因；云商数据清洗已完成并提前上线关闭；已解决问题要求及时更新为已解决状态，避免继续挂起。 ② 盘点与积分需求侧待办落实到人。@余建新 与业务方确认盘点任务需过滤的执行人员名单与品牌范围并同步技术团队，@马奇 拉会确认盘点任务其余待确认事项，@吴南林 将逆向冲减的详细逻辑含活动下架与退货场景补进需求文档并与计费团队确认过期积分的减少数据能否同步至积分明细报表。 ③ 冷饮二期与修复方案的材料补充待办落实到人。@孔玮 确认卡券活动配置是否细化到个人维度，@赵敏 确认记账接口中收款方编码的唯一性与必填性，@李强 输出含单元、集成与压测识别的冷饮二期测试计划并发群，@潘玉平 将临时表抽样验证截图与测试验证过程补入 TDS 码表数据修复方案，@余勇军 找测试团队验证并把自测结论补入 PDA 扫码类型修复方案，@粱健 确认经纬度仅定位到街道级别的限制是否已备注至 PRD。

3、每日总结&思考： 【AI&Agent】今天唯一成体系的 AI 素材是 BRD 评审 MCP 的对外开放，做法上有三点值得复用。共赢的杠杆来自三处把接入方成本移回自己的改造：凭证侧把前提从懂 JWT 降为自助签发一个 PAT，身份侧做平台注入优先与 HTTP 令牌回落双通道兼容接入方各自鉴权能力，质量侧把自身静默降级缺陷转成对外可见的 parse_status，接入方可自查。解析器不该硬编码模型输出的层级格式，模型输出结构会漂移，解析层需要按语义识别并显式暴露解析质量，降级状态静默发生时接入方既无法自查也无从判断结果可信度。这三条与《存量系统 MCP 改造升级方案》五步法一起构成存量系统对外开放的通用路径：能力盘点、工具设计、身份鉴权、结果错误分层、接入验收。 【工作思考】三套修数脚本门槛不一致是今天最需要警惕的一点。同一批修数里既有无需上线直接脚本执行、也有备份后 update 直改、还有需发版加备份，最低门槛那条路径最容易被后续沿用，等于把 4.9 亿条事故建立起来的防线从旁边绕开。正确做法是同批修数统一按最高门槛执行，执行门槛写进方案而不是留给执行人临场判断。枚举扩展漏改兜底分支同理，PDA 扫码类型空值 1500 多条的直接原因是新增枚举后旧分支默认走 none，靠开发自查发现不了，枚举新增或改名必须同步默认值与存量赋值分支，该进代码评审固定检查项。全部核销的文案与 500 张上限不一致也是同一类问题，交互互斥让用户绕不过上限，文案与上限要一起设计，失败成本不应由用户承担。角色能力差异由代码按角色判断、由配置人员注意，是把隔离责任放在人的注意力上。

二、明日工作计划 1、模块TOP大事 ① 冷饮二期接口口径确认与测试准备。@赵敏 确认记账接口中收款方编码的唯一性与必填性，@孔玮 确认卡券活动配置是否细化到个人维度，@李强 输出含单元、集成与压测识别的测试计划并发送至沟通群。 ② 述职材料三处事实确认。核实 BRD 评审 MCP 当前发版状态与 ai_call_record.user_id 落库报错修复进展以定稿已落地表述，确认 9.30 复盘与 SR 修复方案评审两场会议的主导者署名口径，向薛碧盈确认多轮面试的实际评议流程。 ③ 盘点与积分需求文档收口与修数方案材料补充。@吴南林 将逆向冲减逻辑补进需求文档并与计费团队确认过期积分减少数据同步报表，@潘玉平 补入临时表抽样验证截图与测试验证过程，@余勇军 补入 PDA 扫码类型修复的自测结论。

2、重点/基础工作

• 营销活动中心-技术梳理专项
• 物码技术支持，营销活动中心液奶、奶酪、冷饮、计费管理、券中心、帖码
• 技术管理智能体研发