2026-09-09 工作日志
智能研发平台进度周会
- 发言人：贾云飞、刘阳、赵清、李宏伟、柳瑞军等 10 人
- 主题摘要：本次会议同步了 BRD、PRD 及原型设计等 Agent 的开发与测试进度，明确了测试环境与运营数据，并讨论了后续目录结构对齐与 MRD 测试方案。
小结
一、核心 Agent 开发与测试进度
1. PRD Agent 上线与体验安排
- 已上线供测试：按最新模板完成修改并上线，进入产品团队体验试用阶段。
- 产品团队负责试用反馈：王谦经理与赵经理需安排时间协助测试，检查是否存在问题。
- 信息缺失时自动留空：系统严格按模板生成内容，上传文档中缺少对应信息时自动留空，不做发散性补充。
2. BRD Agent 自测进展
- 需按新模板重新自测：BRD Agent 仍按最新沟通的产品模板调整中，需完成本地自测后再推进。
- 自测遇分支合并问题：新分支合并至主干存在异常，正在调试；整体开发进度保持正常。
3. 原型设计 Agent
- 本周完成测试、下周上线：模块正常推进，预计本周内完成测试，下周上线。
4. Harness 接入与测试环境
- 任务调度机制需优化：本地安装 Harness 存在无故进入非预期流程的问题，后续需与平台打通，仅针对平台分配的具体任务进行调用。
- 单次任务耗时增加 2—3 分钟：修复后的 Harness 响应有所改善，但整体执行时间仍额外增加 2—3 分钟。
- 平台任务预计 9.20 转入测试：平台开发任务持续推进，大部分任务预计 9 月 20 日左右完成并投入测试。
二、测试运营数据与后续计划
1. 测试运营数据
- 覆盖 42 个用户：测试环境已搭建完成。
- 用例生成情况：测试过程中使用 64 项用例的生成与评审内容，累计生成 3000 多条测试用例。
2. 控制台目录结构对齐
- 需与平台团队对齐：需约见建朝与崔建瑞，就控制台目录结构及数据看板整合方案进行对齐确认。
- 对齐后再推进开发：目录结构与整合方案先定下来，后续开发基于此推进。
三、BRD 与 MRD 测试方案
- BRD Agent 定位：核心功能是引导用户表达业务想法、生成结构规整的 BRD 文档，目前仍由开发团队内部测试。
- MRD Agent 暂不开放测试：仍在开发中，后续利用历史需求沟通纪要或新项目资料作为输入测试生成效果。
- 产品团队优先测 PRD Agent：当前用现有 BRD 资料测试 PRD Agent，后续建立共享表格收集测试结果。
四、评审 Agent 调整安排
- 按最新模板调整评审 Agent：针对赵群经理团队关注的评审 Agent，需按产品最新模板维度调整，确保 PRD、MRD 等文档评审符合规范。
待办
- 明天完成 BRD Agent 的自测工作。 — @柳瑞军
- 协助测试 PRD Agent，检查是否存在问题。 — @王谦经理 @赵经理
- 安排时间约见建朝与崔建瑞，对齐控制台目录结构及数据看板整合方案。 — @刘阳
- 在 9 月至 10 月的新项目中，结合 BRD 输入测试 MRD Agent 的生成效果。 — @赵清
- 使用现有 BRD 资料测试 PRD Agent，并在共享表格中记录测试结果。 — @陈梦
- 将 PRD Agent 的最新模板转发给建朝，以便其调整评审 Agent。 — @贾云飞
关联与提示：
- 与 9.02 两条战线呼应：9.02「智能体项目上线进度与后续规划周会」与「AI 辅助开发平台项目周会」均提出按业务阶段重组目录、避免 URL 挂载式拼装、功能重叠预警。本场把这件事落到了具体动作——@刘阳 约见建朝与崔建瑞对齐控制台目录结构与数据看板整合，是整合专项的关键一步，建议带上 9.02 的两条结论一起谈，别重新讨论一遍。
- ⭐ "信息缺失自动留空、不做发散性补充"是个重要设计决策：与通用大模型"尽量补全"的默认行为相反，宁可留空也不编。这实际上是在用可控的缺失换可信的输出——评审场景下，一条编造的约束比一个空格危险得多。建议把这条固化成平台所有生成类 Agent 的默认规则，并在留空处给出提示（"此处需补充 XX"），降低用户困惑。
- ⚠️ 测试数据的两个口径需核对：原文"生成 50 份测试用例"与"累计生成 3000 多条测试用例"并存，"64 项用例的生成与评审内容"与"50 份"关系不明。若用于对外汇报或运营价值总结（9.02 待办），建议先统一口径。
- Harness 的 2—3 分钟额外耗时需评估可接受度：若 Agent 链路中每次任务都叠加该耗时，用户体验会有明显感知。建议给出耗时构成说明（调度 / 执行 / 回传各占多少），再决定是否优化。
- 转写存疑：「王谦经理」「赵经理」「赵群经理」「赵清」多人称谓混用，原文保留未合并；「建朝」按全项目语境为王建朝；「Harness」为原文写法，未见正式中文名。
AI工具研发9月计划同步周会
- 发言人：王建朝、崔建瑞、王磊、温浩、刘曌阳等 13 人
- 主题摘要：本次会议同步了各 AI 工具 9 月份的研发与优化计划，明确了 930 版本分支的合并策略，并决定建立两周一次的运营数据统计机制以跟踪上线效果。
小结
一、各模块 9 月份研发与优化计划
1. PRD 评审工具
- 模板升级开发中：上周已与产品侧沟通确定新模板，本周开发升级，后续瑞军、郑然需按新规则模板修改一版。
- 规则展示功能待补充：曌阳需补充 9 月计划，后续开发具体规则展示功能，让用户了解当前评审使用了哪些规则及其需求覆盖情况。
2. 产品评审 Agent
- 推进产品侧使用与优化：目前用户使用量较少，正推动产品在内部使用并基于反馈优化。
- 支持多格式与多文件输入：计划支持多种格式输入、多文件上传分析，并增加模型分析时的知识输入以提高准确性。
- 节奏待细化：预计 9 月完成上述功能上线，具体时间节点后续细化。
3. 技术方案评审工具
- 遗留问题已修复发版：问题清单中的两个问题已修复并发版，目前无遗留问题。
- 等待运营与问题记录：目前主要由技术 BP 使用，后续按实际使用情况在清单中记录并随时修改。
4. 文配工具
- 按排期优化：已上线，问题列表中尚有 20 多个待优化问题，将按排期优化并推广使用。
5. 域名相关工具
- 域名已申请完成：目前主要处理登录等反馈问题，视使用情况跟进修复。
- 采用免密登录机制：为降低使用门槛，用户免密直接登录，下载报告后可自行删除报告。
6. 知识库文档工具
- 补充技术标准规范：计划扩充知识库内容，加入技术标准规范文档，向全员开放以提高受众范围。
7. 脚本工具
- 验证与集成中：脚本基本完成并正在验证，后续完成界面、用户及单点登录功能，预计下下周完成集成。
8. 架构评审 Agent 与 MCP 配置
- 高代码开发 MCP 配置完成：本周完成几个高代码开发的 MCP 配置，车上测试可实现功能但输出不够规范化。
- BR 架构评审 MCP 已开发：已尝试完成开发，后续需进一步讨论其实际应用场景。
9. UI 组件库升级
- 优化用户体验：主要做视觉交互优化，并对可切换的 UI 组件库进行升级。
二、研发规范与运营安排
1. 930 版本分支合并策略
- 统一切出 930 分支：为解决当前 UAT 分支难以合并的问题，前端与后端统一切出 930 分支，9 月 30 日前的所有版本均往该分支合并。
2. 运营数据统计机制
- 两周一次收集：从下周起创建在线文档，要求各负责人在周会前统计并同步各自运营数据，暂定每两周收集一次。
待办
- 将具体的规则展示功能补充到 9 月份计划表中。 — @刘曌阳
- 细化产品评审 Agent 支持多格式输入、多文件上传及知识输入功能的整体节奏与时间节点。 — @张建利
- 将文配工具的问题优化与推广计划补充到计划表中。 — @郑然然
- 与崔建瑞过一下 BR 架构评审 MCP 的实际应用场景。 — @王建朝 @崔建瑞
- 在群内发布切出的 930 版本分支信息。 — @崔建瑞
- 创建运营数据统计在线文档，并每两周收集一次各模块的运营数据。 — @王建朝
关联与提示：
- ⭐ 运营数据统计机制是关键补位：9.02 提出"梳理上线后运营指标做价值总结"、9.09 首场又出现"测试数据口径不一致"（50 份 / 3000 多条），根子都在没有统一的统计口径与收集节奏。本次定为每两周一次、周会前同步到在线文档，正是对该缺口的修复。建议文档里固定字段（使用人数、调用次数、生成量、问题数、满意度），否则下次汇报仍会出现口径打架。
- 930 分支策略是对 9.02 分支混乱的纠偏：9.02 曾出现"近期优化代码合并至 8.28 版本分支、暂不合 master"与"宏伟代码先独立构建 UAT 再合主干"两条并行口径；9.09 首场 BRD Agent 又遇到"新分支合并主干异常"。统一切 930 分支、9.30 前全部往该分支合并，方向正确，但需明确 9.30 之后如何回主干，否则会形成新的长期分支。
- 两个"已开发但场景未明"的 MCP 需警惕空转：高代码开发 MCP"能实现功能但输出不够规范化"、BR 架构评审 MCP"已开发但应用场景待讨论"。这类"先做出来再找场景"的投入，与 9.02 提出的功能重叠预警是同一类风险，建议在 @王建朝 @崔建瑞 讨论应用场景时一并回答"这与现有评审 Agent 的边界在哪"。
- 产品评审 Agent 使用量偏少值得单独跟："用户使用量较少、正推动内部使用"——结合 9.03 EdBody 宣讲中"算力受限、短期不大规模宣推"的约束，推广节奏不可预期过快，但应先把为什么用得少查清楚（不好用 / 不知道 / 用不上），再决定是优化功能还是做培训。
- 转写存疑：「瑞军」按全项目语境为柳瑞军；「郑然」疑为「郑然然」（9.04 冷饮用例评审发言人），未合并；「BR 架构评审」的「BR」含义不明，疑为语音转写，原文保留。
券中心接口方案评审
- 发言人：王军、王建朝、林焕纯
- 主题摘要：本次会议主要评审券中心接口调整方案，明确了升码与发券的字段变更，探讨了多数据源分页与核销状态展示的技术实现，并确认了跨门店核销的校验逻辑。
小结
一、接口字段与发券逻辑调整
1. 升码与发券字段变更
- 升码新增门店人员编码：升码接口新增该字段，券中心仅做记录，后续数据推送时返回给计费系统。
- 发券新增四个必传字段：针对货款抵扣券的发券接口新增四个必传字段，查询券列表与数据推送列表同步返回这些数据。
2. 发券与查询逻辑兼容
- 不影响老活动发券：本次调整仅针对货款抵扣券，不影响营销活动中心老活动使用的产品券和立减券。
- 恢复按门店加人员发券：新版需求恢复为按"门店 + 人员"发券，与原有自制券逻辑兼容，无需额外改动。
- 查询接口不做数据聚合：为避免上千万券量查询的性能问题，查询接口不再做数据聚合，按入参的发放条件（按店 / 按门店加人员）直接返回对应数据。
二、分页查询与状态展示方案
1. 多数据源分页方案
- 按用户类型做内存归并：针对按门店、按门店加人员两种发放模式的券，前端需在内存中归并分页。两者数据池互相隔离，技术上可行。
- 接口性能压测达标：券中心接口已按营销活动最高标准压测，当前 QPS 600 以上，结合游标分页，可支撑门店维度查询。
2. 核销状态展示分歧（暂缓重构）
- 状态合并展示导致感知异常：前端将待核销与核销中合并展示，用户点击核销后状态变更，该券会从待核销列表消失。
- 归并分页失效：核销中是中间态，会随时在待核销与已核销之间切换，导致基于状态的池子互相连通，无法做稳定的内存归并分页。
- 暂缓技术重构：券列表接口被多方调用、影响范围大，决定暂不修改底层逻辑，先按现有方式实现，后续视运行情况再优化。
三、核销校验与接口参数规则
1. 跨门店核销校验规则
- 支持多种核销配置：券中心支持仅限发券门店核销、同经销商下门店核销、跨门店核销等配置项，提交核销时按活动选项校验。
- 计费侧自行校验一致性：积分兑换优惠券场景规定必须本店核销、不能跨门店；券中心只推送真实核销数据，计费系统需在回调时自行校验核销门店与兑换门店是否一致。
2. 接口参数必填规则
- 券码详情查询：券码 ID 必填；经销商编码按应用方判断——计费侧可不填，营销助手侧因需做最终核销操作故必填。
- 数据查询条件：门店编码、经销商编码等未强制必填，系统按传入的组合条件返回数据，调用方自行保证传参逻辑正确。
待办
- 10 月 15 日前完成本次券中心接口调整相关需求的开发。
- 评估券列表接口的性能压测情况，并留意后续是否有大量用户遇到核销状态展示异常的场景，以便从产品层面优化升级。
- 在积分兑换优惠券的回调逻辑中，增加核销门店与兑换门店是否一致的校验。
- 后续接口升级考虑采用增加版本号（如 211、311）的方式，避免在同一接口内过度兼容不同需求。
关联与提示：
- 与 9.08 积分体系技术方案评审直接咬合：9.08 定的是"券核销门店/人员必须与发放门店/人员一致、禁止跨门店核销"，本场明确该校验的实现位置在计费侧回调——券中心只推送真实核销数据，不做业务判断。责任边界清楚了，但两条待办需并起来看：9.08 遗留的"门店员工调店/兼岗多店时已发未核销券如何处理"与本场的"回调增加一致性校验"是同一处逻辑的两面，建议一并定边界，否则调店场景会在校验这步直接被判死。
- ⚠️ 核销状态展示是已知的产品体验缺陷，被主动接受：会议明确"状态切换导致归并分页失效"却仍决定不做底层重构，理由是接口影响面大。这个取舍可以理解，但缺陷已从技术层转移到用户层——用户会看到券"点了核销就消失"。建议至少补一层兜底（如列表短暂保留并置灰、或给出"已提交核销"提示），并在上线后把"核销中"停留时长作为监控项，超过阈值说明回调链路有问题。
- 性能口径需留意：QPS 600 以上 + 游标分页是基于"不做数据聚合"的前提。若后续产品侧重新要求聚合展示（如券列表要按活动汇总），该结论即失效，需重新压测。
- 版本号机制值得推广："采用增加版本号（211、311）而非在同一接口内过度兼容"——这与接口治理的通用做法一致，建议固化为券中心后续所有接口升级的默认方式，避免兼容逻辑堆积。
- 转写存疑：本场待办均未标注责任人（原文如此），日志中保留原样；如需跟进请补充责任人。"货款抵扣券"为原文写法。
门店域建模与报表方案评审
- 发言人：潘玉平、王建朝、邱毅、李明非、张喜等 12 人
- 主题摘要：本次会议围绕门店域宽表设计、多事业部改造、TDS 解析优化及多张报表字段变更展开评审，重点讨论了数据库索引策略、数据初始化方案、缓存机制及历史数据修复脚本的优化。
小结
一、门店域宽表与多事业部改造
1. 宽表数据量与更新机制
- 数据量膨胀评估：理想状态下若 1000 万门店 × 5 个事业部，宽表将膨胀至 5000 万条，且存在字段冗余。
- ⚠️ PG 更新膨胀风险：PG 采用 MVCC 机制，每次更新相当于物理插入新记录，大规模批量更新极易导致记录集膨胀。
- 更新量监控：日常门店更新约每天 10 万条；需警惕定时任务批量刷新造成几十万至上百万级数据灌入。
2. 门店标签与人员表处理
- 标签表行转列：门店标签表由行存储改为列存储于单一字段，未增加数据量反而减少冗余。
- 旧人员表保留：旧的门店人员五段表及门店联系表仍被部分业务端使用，确认无业务依赖前必须保留，不可直接废弃。
3. 多事业部角色改造
- 索引改造顺序：先删原有唯一索引 → 新增普通索引 → 待数据清洗完成且排查无重复或空值后，再建联合唯一索引。
- 数据初始化：门店多角色数据达千万级，需通过接口由各端做兜底校验，确保初始化时 business unit 字段不为空。
- 双轨接口策略：新增 V2 接口且事业部编码必传，保留原接口；排查并通知所有调用方完成接口更换与缓存隔离。
二、TDS 文件解析与缓存优化
1. 保质期字段解析前置
- 新增保质期字段：TDS 解析模板新增该字段，上游未提供时系统按产品基础信息自动计算并落库至 Mongo。
- 在途数据兼容：优先读取落库的保质期，为空则降级调用原有实时计算方法，确保业务不受影响。
2. 解析性能与缓存机制
- 批次解析防并发：为保证数据完整性采用内存循环解析而非并发，单批次最多处理 3—4 万个码，避免冲击后端服务。
- Redis 缓存优化：缓存产品基本信息，当前默认 5 分钟，后续可按产品保质期规律适当延长，降低对基础数据服务的调用。
三、云商报表字段变更
1. 盘点明细表
- 新增签收类型字段：查询接口通过 MapStruct 自动填充，导出接口需手动 Set。
- 依赖上游字段填充：实际填充逻辑依赖梁建负责的上游需求，本方案仅负责读取和展示。
2. B 端出货明细表
- 补充缺失查询列：将缺失的活动 ID、人员等三个字段补进查询 SQL（数据库底层已存在）。
- 产品状态实时展示争议：原计划直连 Mongo 查询，因数据库连接池压力被否，改为通过 RPC 接口批量查询。
四、历史数据修复方案
1. 消费者中奖明细表
- 修复空值：针对 8 月 6 日发版前产生的 358 条产品信息空值异常数据，用 SQL 脚本更新修复。
- 脚本优化要求：去除冗余过滤条件，改用追溯码 + 创建时间作为联合主键；必须先转 Select 验证执行计划，避免全表扫描。
2. B 端出货明细表退货地址修复
- 批量修复范围：高德事故期间（2 号至 4 号）产生的 42000 多条退货地址空值数据，通过定时任务调用高德逆解析修复。
- 临时表策略：为避免全表扫描和分区检索风险，先将异常数据筛选至临时表，再从临时表读取并精准修复原表。
待办
- 确认单独推送的表（如门店人员五段表）是否包含事业部信息，若缺失需提前提需求让上游补充。 — @孙传熙
- 确认经销商表与门店联系表的业务含义及是否仍被业务端使用。 — @李明非
- 评估并确认 Redis 缓存产品基本信息的时长，建议根据产品保质期规律适当延长。 — @张喜
- 与梁建确认 B 端出货明细表新增字段的填充方案，并重新评估上线排期。 — @潘玉平
- 与产品经理确认 B 端出货明细表产品状态是否必须展示为实时状态，并更新 PRD 文档。 — @潘玉平
- 修改消费者中奖明细表修复 SQL：去除冗余条件、改用追溯码 + 创建时间作联合主键、验证执行计划。 — @潘玉平
- 修改 B 端出货明细表退货地址修复方案，改为先筛至临时表再从临时表精准修复原表。 — @潘玉平
关联与提示：
- ⚠️ 高德事故产生第二笔待修数据：本场"2 号至 4 号高德事故致 42000 多条退货地址空值"与 9.08「盘点数据补录」（9.1 起 SR 资源不足 1.8 万条丢失）、9.04「高德调用优化评审」属同一条故障链的三个切面。三笔数据分属不同责任人（本场 @潘玉平，9.08 @余勇军，9.04 @李明非），建议指定统一收口人，否则修完没人确认是否真的不再产生。
- ⚠️ 宽表 5000 万条 + PG MVCC 是本场最大隐患：1000 万门店 × 5 事业部 = 5000 万行，叠加 PG"更新即插入"的特性，一次批量刷新就能让表膨胀到需要 VACUUM 兜底。建议：① 明确是否有对应 VACUUM / 分区维护策略；② 定时任务批量刷新必须限流并避开业务高峰；③ 上线前用真实量级做一次更新压测，别只验功能。
- 索引三步走的顺序是对的，但缺了回滚判据：删唯一索引 → 加普通索引 → 清洗后建联合唯一索引，逻辑正确。但**"清洗完成且排查无重复或空值"这一步如果不过**，联合唯一索引就建不上，此时系统处于"无唯一约束"的中间态。建议明确该中间态的存续时限与兜底（比如多久内必须完成，超时怎么处置）。
- 两次出现的"临时表 + 精准修复"模式值得固化：本场退货地址修复与 9.04「盘点签收故障修复」（备份表与修复语句 WHERE 条件必须逐字一致）是同一套方法论——先隔离出待修集合，再按主键精准改，不碰全表。建议纳入数据修复的标准动作。
- 产品状态实时性被否的过程值得记：直连 Mongo 因连接池压力改 RPC 批量查询，说明**"实时"的代价在连接池**。但会议没有回答"改为 RPC 后还算不算实时"（批量查询通常有延迟）。建议 @潘玉平 与产品经理确认时把"实时"定义成具体时延（如 5 秒内 / 分钟级），别留成模糊承诺。
- 转写存疑：「business unit」为原文英文，指事业部编码；「梁建」为原文写法，疑为 9.02 冷饮 H5 评审中的「张建利」，未合并；「MapStruct」为技术框架名，保留原样。
今日待盯（由 9.08 结转）
- 门店积分（9.11 开发节点）：各相关端确认积分接口变更方案 — @孔玮 @王建朝；存量积分池门店维度回填口径与责任人待定；计费侧技术方案与测试用例评审结论收口。
- 门店二级渠道类型字段：基础底座 + 老营销活动两个项目补技术方案 — @郝梓斐；确认字段长度 — @郝梓斐；旧活动链路中间表与落库表同步加字段 — @郝梓斐。
- 千万级加索引：拉通中台 DBA（钟阳、李斌）评估执行方案、避免锁表 — @李明非。
- 盘点数据补录：向腾讯云确认 MQ 批量导入是否占用现有通道量，并在测试环境小批量验证 — @李明非；统计 1—8 号门店/经销商变更记录并评估影响 — @余勇军。
- 内部人员接口排期：9.04 记录"受供应商评估影响延至 9.9"，今日到期，需确认是否已出结论。