2026-09-16 工作日志
液奶积分集成测试同步会
发言人：刘莉、李宝仟、余建新、粱健、李明非等 12 人
主题摘要：本次会议同步了液奶积分与钱包集成的测试进度及缺陷情况，明确了业务失效过滤规则与门店可见性逻辑，并协调了券核销的支持资源与后续测试安排。
小结
- 盘点任务测试进度：盘点任务共 89 条用例，已测 24 条、通过 20 条，进度约 10%。
- 活动场景测试进度：活动场景共 138 条用例，已测 13 条、通过 12 条。
- 缺陷分布与修复：盘点任务模块发现 8 个缺陷，活动场景模块 3 个缺陷，正边测边改；其中 3 个活动场景缺陷已与开发确认并关闭。
- 待确认与阻塞（液奶积分）：新建盘点任务时，财务失效与业务失效的经销商是否需被过滤仍待业务侧确认；智慧门店小程序因环境切换打不开，无法进行集成测试，需等重新打包或环境恢复。
- 业务失效过滤逻辑：针对盘点任务，若经销商处于业务失效状态，是否允许操作需与现有前端盘点场景保持一致——前端不允许则后端下发任务时也不予下发；若其他业务场景业务失效仍允许操作，则盘点任务也应保持该逻辑，需开发进一步排查其他场景取值。
- 盘点任务门店可见性（需求 vs 现状不符）：需求为新建盘点任务仅选经销商不选门店时应默认该经销商下全部门店可见；当前测试发现未选门店时小智端无法看到盘点任务，与预期不符，需线下与 PM 对齐。
- 钱包测试受阻：钱包模块 40 条积分用例今日仅通过 4 条，因"签收后未产生激励积分"排查耗时 + 智慧门店切环境钱包打不开。
- 环境切换影响：为排查钱包历史数据，接口临时切至 UAT 环境，导致当前 SIT 环境测试受阻，预计明日测试完毕后切回。
- 后续安排与资源协调：若明日钱包环境仍未恢复，转测券核销场景（需卡券中心与 SFA 团队配合）；环境切换后需进一步排查历史数据是否正常展示。
待办
- 填写各业务缺陷的预计解决时间，并标出影响明日测试进度的重点缺陷。 — @各端负责人
- 确认盘点任务中财务失效与业务失效的经销商是否需要被过滤。 — @建新 @业务侧
- 排查其他业务场景对业务失效经销商的取值逻辑，确保与盘点场景一致。 — @开发
- 线下与产品经理确认盘点任务不选门店时的可见性逻辑。 — @南林 @志伟
- 协调卡券中心配合支持券核销场景的测试。 — @建新
- 将测试进度截图与缺陷列表发送至群内同步。 — @刘莉
关联与提示
- 测试进度严重滞后，9.15「集成节点不可动摇」已实质违约：盘点任务仅 10%（89 测 24）、活动场景约 9%（138 测 13）、钱包 40 用例仅过 4。9.14 早会定"9.15 集成节点不可动摇"，但今日（9.16）仍在"环境阻塞、边测边改"——等于 9.15 节点未达成且无叫停。建议明确：9.15 是延期还是口径不同，别让"不可动摇"默默过去；这直接连着 10.15 双事业部切换（无缓冲）的排期可信度。
- 智慧门店环境切换是今日多条阻塞的共同根因：① 小程序打不开无法集成；② 钱包为查历史数据切 UAT 导致 SIT 受阻。说明环境管理缺变更管控——为排一个问题的雷，把另一条测试线堵死。建议建立环境变更审批 + 影响面告知，呼应 9.11 SOP "识别影响范围"（变更也是一类"异常"）。
- "不选门店默认全部门店可见"与 9.14 提现对账节同源：那是"主数据全局更新不区分事业部、使用侧按事业部+状态筛选"的权限/数据切片问题。小智端看不到 vs 需求"默认全部门店可见"不一致，需确认小智端是否走了与 PM 端不同的事业部/状态过滤逻辑，别只当孤立 bug 修。
- 失效过滤必须落到代码层、不能靠配置规范：本场说"前端不允许则后端不下发"——若只是前端隐藏、后端仍下发，过滤形同虚设。呼应 MEMORY 原则第 6 条"功能隔离靠代码不靠规范"，建议明确后端下发时也必须按失效状态过滤，否则失效经销商仍能收到任务。
- 钱包"签收后未产生激励积分"是 9.14 冷饮红包接入节链路的具体故障实例：正好印证那场"门店自动提现 open_id/app_id 上游是否具备"的阻断性风险——若连积分都因上游问题未产生，钱包整体链路堪忧。建议与 9.14 那两条 @王军 待办合并看，同一根因别分两线跟。
- 待办责任人颗粒度不均、易无人认领：@各端负责人 / @开发 / @业务侧 是泛化指称，@建新 / @南林 / @志伟 / @刘莉 是具体人。泛化项务必补具体名，否则"各端负责人"谁填缺陷时间会落空；另 @建新 出现两次（过滤确认 + 券核销协调），需确认是否同一人、避免职责漂移到一人身上。
- "发群同步"与 9.14 早会口径需对齐：当时我提过"企微群只做提醒、结论须落 9.11 Excel 统一台账（群不可检索统计）"。截图发群必要但不充分，缺陷列表应同步进那张台账，否则三个月后查不到影响范围与排期。
- 名字存疑（原文保留）：发言人"粱健"（米字旁）与 9.14 数据修复节待办"粱健"一致，亦与早前"梁健"（木字旁）疑似异写；待办"建新 / 南林 / 志伟"为本场新出现人名，均按原文保留、建议后续统一。
项目测试与上线评审周会
发言人：李亚洲、郑然然、刘晓娜、邢健、孙东栋等 9 人
主题摘要：本次会议同步了各模块测试进度与监控告警情况，明确了货权报错问题的修复方案，并安排了上线评审日程及多项后续跟进任务。
小结
1. 测试进度同步
- 整体测试情况：单元测试通过率 88%，尚未完全通过但不影响集成测试推进；活动场景配置测试通过率 8%（共 121 个场景仅过 12），当前主要进行冒烟测试，核心业务场景测试尚未开展。
- 盘点任务与积分兑换：盘点任务通过率 22%（89 个场景过 20），今日继续联合 SFA 和小智推进；积分兑换卡券模块测试尚未启动。
- 计费与钱包模块：钱包集成测试今日启动（昨日存在单元测试问题），需协调券端资源提供测试支持；当前共 4 个测试问题，2 个需银行活动中心和 SFA 解决、2 个待确认需尽快推进；计费模块从 SST 环境切换至 UAT 环境，可能导致智慧门店钱包历史数据显示受影响，需同步该风险。
2. 每日追踪与监控告警
- 差异数据清单排期：门店与经销商差异数据清单定于 9 月 20 日输出；导购与门店关系差异数据今日拉会沟通，整体计划本周五完成历史数据清洗。
- 监控告警处理：今日共 3 条告警，序号 13 告警需修改规则——出口编码和签收门店编码需在门店基本信息表中存在，但可能存在仓库信息，需进行规则调整。
3. 系统问题排查与修复
- 货权不一致报错：【提问】李亚洲：查流向时提示货权不一致，报错位置与以往不同，是有什么调整吗？【回答】余建新：箱码出货时未将货权配在箱码上，扫箱码查流向时系统不仅查了箱外码、还查了无货权的箱内码状态，导致报错。今日调整查证逻辑仅查箱外码状态，并补充登记该问题。
- 门店积分需求跟进：需跟进黄磊那边门店积分需求，若需求有调整，必须提供书面邮件确认。
4. 上线评审安排
- 上线评审定档 18 号：项目上线评审日程已确定于 18 号进行，相关人员需及时关注日程信息。
- 上线检查清单填写：各相关人员需及时完成上线检查清单的填写，今日将进行统一提醒。
待办
1. 测试推进
- 今日继续联合 SFA 和小智推进盘点任务测试。——郑然然
- 今日推进钱包集成测试，并协调券端资源提供支持。——郑然然
- 尽快确认 2 个待确认的测试问题。——郑然然
- 若计费环境有问题，及时协调解决。——@郑然
- 配合计费侧完成钱包历史余额及新增数据的测试用例。——任铭
2. 数据清洗与告警
- 9 月 20 日输出门店与经销商的差异数据清单。——@小智 @朱书记
- 今日拉会沟通导购与门店关系差异数据情况。——邢健
- 本周五完成导购与门店关系差异数据的历史数据清洗。——邢健
- 修改序号 13 告警规则，解决出口编码和签收门店编码在门店基本信息表中存在仓库信息的问题。——孙东栋
3. 系统修复与跟进
- 今日调整查证逻辑，仅查箱外码状态，并补充登记货权报错问题。——余建新
- 今日跟进黄磊那边门店积分需求，若需调整需获取书面邮件。——@亚洲
- 今日提醒相关人员及时完成上线检查清单的填写。——李亚洲
- 今天发版完成后更新计划内容。——李亚洲
- 完成整体更新。——@东
B端出货明细表产品状态测试评审
发言人：吕杰、余建新、刘晓娜、郑然然、王建朝等 7 人
主题摘要：本次会议围绕 B 端出货明细表新增产品状态功能展开测试用例评审，明确了状态映射逻辑、历史数据展示规则及箱码操作验证，并重点评估了高频导出对 Mongo 数据库的性能压力。
小结
一、产品状态映射与业务逻辑
- 业务诉求与状态映射：业务方期望通过产品状态字段（如工厂在库、经销商在库、在途、已售等）筛选结案数据，而非仅展示已退货、已签收等动作；系统对原有码状态进行了映射——已退货→经销商在库、已售→本店已售、调拨待签收→经销商调拨在途。
- 状态展示与字段调整：后续将原查证页面的产品状态字段更新为当前映射状态，更直观反映产品的物理流转位置；针对业务方期望的工厂在途、调拨等新增状态，因当前系统缺乏底层数据，本期暂不增加。
二、测试用例场景评审
- 生命周期与历史记录状态：测试用例需覆盖码从工厂分仓在库→经销商在库→终端在途→终端在店的完整生命周期，通过模拟退货、退库等操作触发特定状态；同一码在明细表中存在多条历史记录时，导出或查询时所有记录的产品状态均显示该码的最新状态。
- 箱码操作与查询条件：需验证前端通过箱码操作（如签退）时，系统能否正确转换并请求提码，从而准确刷新 B 端出货明细表中的产品状态；测试计划需补充针对新增产品状态字段的查询条件用例，验证按状态筛选功能。
- 历史数据与空值异常：产品状态字段为实时查询码库状态，不涉及历史数据初始化，上线后历史数据也会根据当前码状态实时展示；若测试环境中码库数据被删除导致查询不到状态，字段可能显示为空，需在生产环境验证该空值异常场景。
三、系统性能与导出压力评估
- Mongo 数据库读取压力：新功能需实时从 Mongo 表拉取数据，月底/月初结案、冲销量等高频导出场景下百万级数据导出将对 Mongo 造成较大读取压力；技术评估认为当前 Mongo 为副本集架构，导出可从副本集读取，对主库写入与状态更新影响相对可控，但数据量过大时仍需增加 Mongo 配置。
- 上线后监控策略：上线后需重点关注月底/月初高频导出场景，业务侧需提前同步导出计划，技术侧需在此期间密切盯防系统性能表现。
待办
- 补充并完善测试用例，包括产品状态查询条件、箱码操作验证及生产环境空值异常验证等场景。 — @吕杰
- 在生产环境验证上线后产品状态字段是否存在空值异常的情况。 — @吕杰
- 在月底或月初高频导出期间，密切监控系统性能表现。 — @宋洋
- 今日完成测试用例执行，确认无误后推进上线。 — @吕杰、@余建新
Java架构师技术面试
发言人：cattle、张建利、王建朝、薛碧盈
主题摘要：本次会议为 Java 架构师岗位技术面试，重点考察了候选人在高并发系统、AI 智能告警、微服务部署及跨系统协作等方面的实战经验与技术架构理解。
小结
一、候选人基本情况
- 个人背景与经验：候选人具备十余年 Java 开发经验，曾负责系统架构、业务架构设计及项目管理。
- 京东物流高并发系统经验：曾负责京东物流 WMS 系统及接单系统配置，具备每日处理数百万级单量的高并发系统经验，并参与过 618 等大促的系统稳定性治理。
二、AI 智能告警系统技术架构
- 核心功能与处理效率：系统基于 LangChain 框架，利用大模型结合 MCP 拉取监控数据及内部知识库，实现 CPU/内存等系统告警的自动化分析与诊断；可解决 70%–80% 的告警问题，单次告警排查从人工 40 多分钟缩短至约 5 分钟。
- 触发机制与数据整合：通过接收自建监控系统的告警推送自动触发智能分析，后续计划向业务方向告警扩展；当前主要技术挑战在于打通各类繁杂接口数据，以及构建业务问题分析的专属知识库。
三、研发管理与代码评审
- 评审维度：需求与方案评审重点评估需求合理性、与现有方案一致性、方案逻辑严密性与漏洞；代码评审关注逻辑正确性及常见错误，目前已引入 AI 工具辅助提升评审效率与质量。
四、微服务部署与系统稳定性
- 服务调用与上线流程：系统间调用主要基于京东内部自研 RPC 框架；多微服务依赖场景上线前需通过部署编排工具按百分比分批部署，并强制先摘除机器流量、等待 1–2 分钟确保存量请求处理完毕后再部署。
五、跨系统集成与故障排查
- 跨系统责任划分与降级方案：面对非核心需求或三方系统调用失败，首先排查定位问题归属、通过沟通协调明确责任系统，避免无限制兜底；若确认是三方系统问题且短期无法修复，可在自身系统引入降级方案或兜底机制保障业务连续性。
六、Agent 技术架构与应用
- Agent 能力演进：当前 Agent 已支持通过 MCP 调用三方工具、具备短期与长期记忆并结合知识库解决大模型实时性问题；已应用于需求理解、架构设计、代码编写及 Review 等开发全流程，功能较初期问答型大幅提升；底层基于 LangChain 并利用 LangGraph 实现更复杂流程管控及人工确认节点。
待办
- （本场为技术面试，无明确新增团队待办）
Java开发工程师面试
发言人：王林、张建利、王建朝、薛碧盈、李明非
主题摘要：本次会议为 Java 开发岗位面试，重点考察了候选人在直播 SaaS 平台的微服务拆分、腾讯 IM 弹幕优化经验，并深入探讨了 AI Coding 的落地实践与架构设计选型。
小结
一、候选人背景与项目经验
- 个人背景与核心项目：候选人曾在中关村科技公司任 Java 开发，参与直播 SaaS 平台、客服及双录项目，主要采用 Spring Cloud 微服务架构（Nacos、Gateway、Redis、MQ 等中间件）。
- 直播项目核心功能：负责邮储银行直播项目，涵盖直播间管理、推拉流、投票点赞、礼物弹幕及基于 WebRTC 的多人连麦功能。
二、微服务拆分与部署架构
- 微服务拆分原则：按业务耦合度拆分——在线问卷、答题等活动拆为独立服务，直播间 IM 消息与心跳打点统计也分别拆为独立服务；拆分后整体性能提升、单点故障不互相影响，但跨服务请求使事务一致性控制难度增加；未单独拆用户信息服务，当前通过 Token 解析配合 Redis 获取用户信息，C 端权限校验基本在同一服务内完成。
- 系统部署与上线流程：SaaS 版本部署在自建 K8s 集群（底层跑在腾讯云/华为云/阿里云虚拟机），基础组件由运维负责；生产上线时研发提供镜像、数据库脚本及 Nginx 配置等物料，由运维按上线单执行升级。
三、AI Coding 落地实践探讨
- 应用现状与工具：在复杂度较高的客服项目中引入阿里通义灵码（团队账号，月额度 3000），通过配置规则文件约束 JDK 版本、Spring 版本及阿里编码规范；项目约五六人参与，按业务模块分配需求、上下游接口依赖由同一人负责，AI 主要用于辅助熟悉系统交互与提效。
- 代码生成与验证机制：代码与单元测试均由大模型生成，最终需人工确认合理性后方可应用；候选人预估一个需求一天周期内代码生成约 2 小时、人工 Code Review 约 1 小时，效率提升比例暂无法精准度量。
四、架构设计与技术选型
- 技术选型原则：架构设计首要满足高并发、高可用，优先选成熟 Spring Cloud 生态；组件按场景灵活选用——MongoDB 存 IM 消息、OSS 存双录视频、ES 支持大数据量全文检索、Redis 做缓存、MQ 做异步解耦。
待办
- 后续安排由面试官团队内部讨论面试结果并推进后续流程。 — @薛碧盈
9月研发与运营数据周会
发言人：王建朝、崔建瑞、郭崇岭、王子奇、刘曌阳等 11 人
主题摘要：本次会议同步了 9 月份研发计划，明确了模型替换与代码发布规范，并安排了菜单调整与运营数据上报工作。
小结
一、9 月份研发计划同步
- 主数据与 Agent 模块：主数据 VRD 更换模板后已开发完毕，本周进行 UT 测试；PRD Agent 模块存在模块选择错误，会后由王建朝统一核对并调整对应负责人。
- 线上问题与 Bug 修复：9 月重点为线上问题处理——云飞、文配件、杨老师、白晨凡等暂无新功能开发，集中修复已知 Bug 与运行问题；要求负责修复的成员在 9 月计划中单独列明，并每周同步当周修复的具体 Bug 数量与进度。
- 用户管理与平台优化：用户管理相关代码基本开发完毕，计划近期与系统主界面集成；后续配合各子应用调整平台功能，并优化部分细节用户体验。
二、模型替换与代码发布规范
- 模型替换与申请：本周已将模型替换为千问模型，代码中旧版千问 3.5 需全部切换至 GLM-5.5；已申请千问 3.7 和千问 3.8 两个 Flash 版本多模态模型。
- 代码发布分支规范：生产环境问题必须在 828 分支修改并提交（避免 SQL 未执行导致用户看不到菜单），随后合入 930 分支，最终再合入 master 分支。
三、菜单调整与运营数据上报
- 菜单调整安排：计划明日拉取 Excel 与云飞核对调整后的菜单，核对完成后在 930 版本上更新菜单。
- 运营数据上报：需统计已上线 Agent 的运营数据（用户量、业务价值等），并于今日下班前完成填报。
待办
- 会后核对 Agent 模块文档并调整对应负责人。 — @王建朝
- 在 9 月计划中单独列明 Bug 修复任务，并每周更新修复进度。 — @徐云飞、@文配件
- 将用户管理功能与系统主界面进行集成。 — @郭崇岭
- 在群内及专项群内发布代码发布分支规则说明。 — @崔建瑞
- 明日拉取 Excel 表格核对调整后的菜单。 — @王建朝
- 核对完菜单后，在 930 版本上更新。 — @王子奇
- 统计已上线 Agent 的运营数据并于今日下班前完成填报。 — @全体成员
Java开发工程师技术面试（徐成龙）
发言人：徐成龙、王建朝、张建利、薛碧盈、马奇
主题摘要：本次会议为 Java 开发工程师技术面试，重点考察了候选人在门户下发链路性能优化、线上 OOM 排查及项目交付质量保障等方面的经验，并探讨了 AI 辅助研发的实际应用情况。
小结
一、候选人基本情况介绍
- 个人背景与工作经历：候选人自 2016 年起从事 Java 开发，先后在北京海泰方圆、北京致远互联任职，具备 10 年经验。
- 核心业务与技术栈：熟悉 OA 产品架构——致远互联期间先后参与 V5 单体架构与 V8 分布式微服务架构开发；在 V5 主要负责门户模块线上 Bug 处理，积累丰富日志分析与远程排障经验；在 V8 独立开发全文检索、单据转文档、敏感词等组件，并基于低代码平台搭建电子签章等业务应用。
二、门户下发链路性能优化方案
- 初始问题排查与定位：针对 6 万多家子机构的配置下发任务，原方案在循环中频繁调用 Redis 的 keys 命令清理用户缓存，导致 Redis CPU 被打满，单次下发耗时超 4 小时。
- 现有优化措施与局限：将单批次处理量提升至 1000，并将缓存清理动作移至循环外部统一执行，使单次下发优化至 12 分钟；因调用用户中心查 ID 会更慢，最终选择直接清空当前机构下所有用户缓存，放弃按用户 ID 精准清理。
- 后续优化建议与权衡：建议引入多线程池分批处理（控制线程数避免资源耗尽）；门户配置下发对实时性要求不高（允许十几分钟延迟），采用异步清理缓存方案可行。
三、线上 OOM 问题排查与处理
- 排查工具与流程：线上 OOM 报警时先分析日志确定内存溢出区域，再用 JDK 自带 VisualVM 分析 Dump 文件，定位 GC Root 及具体内存泄漏代码。
- 常见溢出原因与对策：内存泄漏常因资源未释放或对象创建后未清理，需代码审查解决；方法区溢出可通过调大 JVM 参数适当扩内存缓解。
四、项目交付质量与 AI 辅助研发
- 项目迭代与交付机制：项目采用双月迭代（首月开发+演示、次月集中修 Bug+下迭代排期）；开发后需向产品与测试交付演示通过才算完成，再进入测试与产品验证。
- 快速迭代与自测要求：若缩至双周迭代需控制单周期需求规模、合理分配开发与测试时间；分支覆盖率要求 90% 以上，通过注册代码+测试用例自测，结合 AI 提前暴露问题以减少 Bug。
- AI 辅助研发应用：AI 使用率约 30%，主要用于需求梳理、方案落地、代码编写与检查；AI 生成代码须结合预定义方案人工审查，开发人员对最终代码合理性正确性兜底；涉及国企等敏感数据严禁使用 AI 以避免泄露。
五、数据库兼容性与架构探讨
- 多数据库兼容方案：测试环境涵盖 MySQL、Oracle、SQL Server 及国产库以适应不同客户部署；通过平台对 MyBatis 二次封装，用特定组件/Wrapper 实现不同库语法自动适配。
- 产品架构演进：V5 为单体架构、V8 全面升级为分布式微服务架构。
待办
- 联系候选人反馈后续面试安排或消息。 — @薛碧盈
Java后端开发技术面试（武俊勇）
发言人：树上有只熊（候选人武俊勇）、王建朝、张建利、薛碧盈
小结
一、候选人基本情况
- 7 年 Java 开发经验：计算机科学技术专业毕业，具备从 0 到 1 项目搭建经验，技术栈以 Java 为主、Python 为辅。
- 核心项目经验：熟悉 K8s、Docker、CI/CD、Spring Boot/Cloud 及 MySQL、Redis、Elasticsearch；日常用 Cursor 等 AI 编程工具，熟悉 RAG 与模型应用；曾主导智慧水务、高校电子签章（清华、北师大等）及省电力公司统一密码服务平台后台搭建。
二、统一密码服务平台架构与优化
- 微服务架构（Spring Cloud Alibaba）：按业务领域拆分为证书管理、密钥管理、签章验签、审计等模块；签章业务拆为签章/验签两条线并分配独立线程池应对月初月末峰值；大文件签章摒弃全量导入 PDF，改用边读边写+追加模式降低内存消耗。
- 分布式事务与通信优化：月初月末大文件峰值用 RocketMQ 将同步转异步、消费者缓慢拉取保障可靠；计划引入 Dubbo 替代密码机加解密的 HTTP 调用以利用 TCP 提升性能。
- 安全与部署：部署于国网自建 K8s 集群（复用省电力 RDS/KPS、内网光缆、三道安防防火墙）；业务系统均通过平台签发证书加密交互，私钥解密后再传；敏感数据用加密机结合 SM4 对称加密存储。
三、分布式锁与缓存机制
- 分布式锁场景：综合采购平台用于并发库存扣减；电子签章系统用于防止缓存击穿（高频验签结果缓存失效时仅首个请求加载并更新缓存）。
- 缓存设计：文件哈希计算后的验签结果存 Redis，应对同一招标文件多次重复验签，提升效率。
四、技术原理与组件选型考察（张建利提问）
- MQ 选型：RocketMQ 吞吐大、金融级可靠、支持半事务，适合大型项目；RabbitMQ 延迟低、路由丰富、部署简单，适合中小型项目。
- 底层原理掌握：候选人仅从使用层面理解 Dubbo——经 Nacos 注册与拉取、依赖 IP/端口/统一协议通信，对 TCP 底层协议原理掌握不深；被问及常用 Apache 开源项目时了解不多，仅提及 Spring Cloud 等。
待办
- （本场为技术面试，无明确新增团队待办）
风控供应商入场部署方案初步沟通
发言人：待补充
主题摘要：风控供应商今日入场，与团队初步沟通系统部署方案，后续对接与环境准备方向待细化。
小结
- 入场与部署沟通：风控供应商正式入场，双方就系统部署方案进行初步沟通，涉及部署架构、环境对接、上线节奏等方向的初步对齐（具体方案要点待补充）。
待办
- （待补充：沟通中明确的责任事项与后续节点待补充）