2026-10-15 工作日志
物码早会：线上发版与数据同步汇报
发言人：王建朝、李亚洲、吴菊、刘晓娜、邢健等 6 人；主题：本次会议确认了今晚 10 点后的发版安排，重点复盘了 929 数据问题引发的 MQ 阻塞及漏数事件，明确了补数任务调整与告警机制优化方案，并确认数据已修复。
小结
1. 今晚发版安排
- 今晚 22:00 后发版：团队计划于今晚 22:00 之后执行系统发版操作，要求相关人员提前做好安排。
- 移动端已完成测试：晓娜负责的移动端测试任务已完成，今日无需再安排其他测试。
- 多系统同步发版：根据昨晚发版评审的结果，今日智慧门店、小智以及主数据系统均存在发版事项，需按既定沟通结果执行。
2. 929 数据问题复盘与优化
- 补数导致 MQ 阻塞：929 数据异常后，团队在 10 月 1 日早上执行批量补数任务，巨大的数据量导致 MQ 的 QPS 被打满，进而引发数据发送失败。
- 前后端数据不一致：前端查询的是 Mongo 事实表，后端向 SR 发送数据依赖异步链路。由于 MQ 阻塞，导致后端数据未能成功写入，产生了前后端数据不一致的问题。
- 漏数问题已修复：在 MQ 阻塞过程中，共有 15 条数据发送失败，团队当天下午已完成全面排查并补齐了漏掉的数据，目前数据已恢复正常。
- 调整补数任务时间：为避免补数任务在白天业务执行阶段与正常业务争夺资源，已将补数任务的执行时间调整至凌晨，以减少业务执行期间的资源竞争。
- 完善告警通知机制：针对当前告警日志仅记录在系统中、缺乏主动通知的问题，后续迭代计划将告警信息接入企业微信机器人。当发现数据发送超过三次未成功时，将及时触发人工介入处理进行兜底。
待办
- 于今晚 22:00 后执行系统发版，并在线上做好验证。——宝鑫
关联与提示
- 前次待办闭环：10.13 会议立项的「补数任务执行时间调整至凌晨 2 点」（——张喜）与「建立 MQ 消息发送失败的兜底机制（企微告警或每日巡检表）」（——张喜）本次已确认落地：补数移至凌晨执行，告警将接入企微机器人、发送超过三次未成功即触发人工介入。10.14 记的两处待办（张喜文档输出、补数改凌晨 2 点）状态同步为进行中，待办条目尚未闭环销项。
- 口径仍待收敛：本次机制为「超过三次未成功才告警」，而 10.13 复盘 MQ 限流事件的结论是重试三次即失败并丢失 6 条 B 端退货签收数据。三次阈值意味着最后一次失败后仍需人工介入才闭环，等于把兜底成本留在人身上；建议与 10.14 记账流水「锁竞争失败约 3 分钟重试」一并定「重试次数上限 + 告警阈值 + 责任人」三件套，避免各系统各定一套。
AI 研发协同体系宣讲
发言人：刘阳、丁政曦、贾云飞、刘振源、宁连柱等 7 人；主题：本次会议宣讲了 AI 研发流程协同体系，演示了从需求创建到交付归档的全链路闭环，并围绕工具接入风险及后续平台打通规划进行了答疑与探讨。
小结
1. 建设背景与核心价值
- 解决进度粗估问题：传统研发进度多依赖人工粗估，缺乏体系化的过程记录与阶段依据，难以精准定位阻塞点与风险。
- 实现全过程可追溯：通过平台统一管理任务目标、规范与工程环境，将人与 AI 的协作链路完整规划，实现各阶段文档的自动归档与回溯。
- 研发进度实时监控：平台可监听 AI 开发过程中的需求设计、开发、测试等各阶段状态，并实时回传至任务管理模块。
- 量化统计与沉淀：系统能够量化统计各阶段耗时、需求变更返工原因、测试用例覆盖率以及 AI 代码占比等数据。
- 全过程记录留存：从前期需求设计、方案依据到中间问题记录、变更说明及最终交付材料，均能在平台长期留存，便于后续接手与复盘。
2. 工具接入与项目配置流程
- Runner 中间件定位：Runner 作为本地开发助手，充当平台与本地开发工具（如 Cursor、Kesci 等）的中间件，实现任务拉取、执行进度监听与材料上传的互联。
- 接入码通信机制：平台生成具有时效性的接入码，本地 Runner 输入并验证后，即可建立与平台的通信连接。
- 配置独立工作树目录：为避免污染原分支，需配置独立工作树目录，新任务将在该目录下基于远程 master 分支拉取并执行。
- 自动接入 Harness 环境：点击「接入 Harness」后，系统会自动在本地根目录生成开发过程记录文档及基于 Eli 规范的规格配置，无需手动安装 Node.js 等环境。
3. 研发任务全链路闭环演示
- 需求自动拉取与生成：平台创建需求并指派后，Runner 会自动拉取至本地，AI 根据需求说明生成技术方案设计文档并提交至平台。
- AI 自动拆分与人工指派：技术方案审核通过后，AI 自动将需求拆分为具体子任务，技术经理可将这些任务指派给具体的开发执行人。
- 本地自动化执行：执行人领取任务后，Runner 读取任务文档并驱动本地开发工具完成分析、实现设计、编码及单元测试等阶段。
- 阶段状态回传与归档：开发过程中，各阶段的状态、验证结果及交付包会自动回传至平台，最终完成验收与任务归档。
4. 答疑与后续建设规划
- 进度如何替代人工汇报：平台可实时监控任务所处阶段及基于设计文档的实现覆盖率；后续计划建设 Agent 对沉淀资料进行二次分析，以赋能技术经理的汇报整合。
- 接入 Runner 是否覆盖原有配置：新工具接入会覆盖原有的 Agent.md 配置；如果之前没有修改过底层文件则无影响，后续会提供详细的升级替换文档。
- 材料如何自动上传：Harness 在各阶段埋有触发钩子，执行完成后会通过 MCP 协议调用本地 Runner 的上传接口，以对应人员的身份将材料上传至平台。
- 打通技术管理平台：计划开展微服务改造，将当前分散的项目整合，并打通技术服务与技术管理平台。
- Harness 规范自进化：探索跳过输入开发任务阶段，直接通过平台配置实现任务自动化拉取与执行，并保障执行目录的安全性。
- 贯通研发交付全流程：计划将体系与 Coding 平台打通，实现从 Coding 拉取需求、创建任务，再将进度与结果推回 Coding 的双向闭环。
- 联动工单系统：基于项目沉淀的文档，完善能够监控工单实时运行信息的体系。
- 明确执行与管理的边界：当前体系核心定位为通过智能化手段做研发执行，而非项目管理，未来需与集团现有项目管理系统及 Coding 平台连通。
- 避免重复建设：需与 Eli 巴力正在探索的项目管理模块进行协同，明确分工，避免功能重复。
待办
- 编写详细的升级替换文档，指导存量项目用户如何保留原有 Agent.md 配置并接入新系统。——刘阳
- 与 Eli 巴力项目管理模块负责人讨论两套系统如何协同与连通，避免重复建设。——刘阳、刘振源
关联与提示
- 同根因链新增切面（与 9.14 平台菜单整合研讨并读）：9.14 已定调「AI 开发平台能力整合进项目管理平台、以项目管理平台为主入口，短期先统一 UI 风格 + 菜单目录、后做架构统一」，本次会上提出的「打通技术服务与技术管理平台」「与 Eli 巴力项目管理模块协同避免重复建设」是同一议题的延续，方向未变但本次给出了更具体的路径（微服务改造 + 按工作树目录隔离接入）。待厘清点仍在于WorkBody 与 EdBody 的边界。
- 存量接入存在覆盖风险：会上确认接入 Runner 会覆盖原有 Agent.md 配置，仅「未改过底层文件」才无影响。团队既有项目已沉淀 Eli Spec、Harness 与 Agent.md（如丁政曦项目），批量接入前须有配置备份与回滚手段，否则一次接入即可能覆盖不可还原的存量资产——建议与今日待办第一项「升级替换文档」合并交付，先出备份与校验清单再放开接入。
- 「代替人工汇报」目前仍是半自动：刘阳口径为平台监控阶段 + 实现覆盖率，后续再建 Agent 二次分析赋能技术经理；即当前进度信息仍需技术经理二次整合。若要真正替代汇报，量化口径（实现覆盖率怎么算、AI 代码占比是否含人工修改）需先定义，否则汇报质量仍取决于人工。
历史数据修复方案评审
发言人：潘玉平、张喜、王建朝、余建新、朱学通等 11 人；主题：本次会议评审了系统出货场景历史数据修复逻辑，明确了修复条件与执行策略，并确认了经销商名称修复方案及今晚的发版计划。
小结
1. 系统出货场景历史数据修复方案
- 修复目标：针对盘点签收和查证签收等场景，若当前为系统出货场景，需修复为实际出货场景。
- 核心修复条件：需找到上一次非系统出货且退货类型为系统退货的记录进行修复，手动退货的记录无需修复。
- 增加时间过滤条件：为避免全表扫描，查询 SQL 需增加创建时间过滤条件，建议设定为 6 个月的时间范围。
- 方案文字化要求：要求将业务逻辑以文字形式明确记录，并列出具体场景，避免口述理解偏差。
- 新建方案分支：由于原方案已上线，不允许直接在原方案上修改，必须新建一个方案分支进行后续迭代。
- 临时表验证机制：执行修复前，需将筛选出的数据导入临时表，抽取部分数据验证逻辑无误后再正式执行。
2. 经销商名称数据修复方案
- 涉及数据表与数据量：需修复的表包括码表（10 万条）、盘点明细表（2600 多条）和消费者中奖明细表（521 条）。
- 异常原因：TDS 历史数据存在门店和经销商名称混用，导致名称字段存储错误。
- 码表修复：因码表为分片集群，更新时必须携带分片键（code），建议分批次（每批 1000 条）通过 JS 脚本执行更新。
- 盘点明细表修复：采用全表备份后直接更新的方式，数据分区最早时间为 6 月 10 日，最新至昨天。
- 消费者中奖明细表修复：同样采用全表备份后更新，数据最大时间为 9 月 20 日，更新时需记录当前时间。
3. 发版计划与上线评审安排
- 今晚发版内容：今晚发版仅包含 PDA 增加枚举值及消费者出货明细表取值逻辑修复，不涉及历史数据清洗。
- 历史数据清洗暂缓：消费者中奖明细表的批次数据清洗因需测试新的 CSV 文件上传方案，今晚暂不执行。
- 5:30 上线评审：定于下午 5:30 进行上线评审，需准备包含变更内容、风险评估等在内的完整上线材料。
待办
1. 修复逻辑确认与方案分支
- 与杨辉经理和崔龙龙确认修复逻辑，并将确认的文字描述补充到新建的方案分支中。——余建新
- 将修复方案拆分为两个，恢复已上线版本，并新建一个包含时间过滤条件的方案分支。——潘玉平
- 将码表修复 SQL 中的更新条件替换为分片键 code。——潘玉平
2. 数据准备与验证
- 今天重新根据出货场景建立数据临时表，仅查出 10 万条待修复数据。——潘玉平
- 在测试环境中验证不带分片键更新是否会报错，并将验证结果留痕。——潘玉平
- 数据清洗任务执行完成后，需同步给中台。——潘玉平
3. 上线评审材料
- 准备今晚 5:30 上线评审的相关材料，包括变更内容和风险评估。——余建新
关联与提示
- 前置待办闭环：9.14 记录的「系统出货历史数据修复」（——潘玉平等）与 10.12 记录的「消费者中奖明细表数据修正」（——潘玉平、朱学通）本次合并评审，共涉及码表 10 万条、盘点明细 2600 多条、消费者中奖明细 521 条，方案已拆分为「已上线版本恢复 + 新建带时间过滤条件的分支」。
- 同根因链新增切面（与 10.13 SR 规范并读）：本次对码表更新的要求与 MEMORY 中第 16 条 SR 治理口径一致——更新条件必须替换为分片键 code、分批 1000 条、JS 脚本执行。但本次待办中「验证不带分片键更新是否会报错」与「码表为分片集群、必须携带分片键」是同一件事的两面，若测试环境验证结果为「不带分片键不报错」，则说明该集群行为与预期不一致，须在生产执行前再次确认，否则漏带分片键可能引发大范围更新失败或错更新。
- 修复方案拆分造成的一次性成本：原方案已上线不允许直接改、需恢复后再新建分支，导致同一修复逻辑存在两个版本并存期；待办「修复方案拆分为两个」与「与杨辉、崔龙龙确认修复逻辑」需并行推进——若确认后的文字描述与已上线版本有差异，须明确最终以哪个分支为准，避免现场执行错版本。