2026-09-20 工作日志

门店积分系统排期研讨（物码早会）

发言人：李亚洲、吴菊、刘晓娜

主题摘要：本次会议主要围绕门店积分系统及相关功能的排期展开研讨，明确了积分与绩效合并上线的计划，并针对测试暂停与盘点任务优先级等争议进行了初步沟通。

小结

1. 积分与绩效合并上线

• 整体排期评估：积分正向绩效需合并上线，需重新整体调整排期计划，并于本周内与事业部沟通确认门店积分功能的具体上线时间。

2. 盘点任务暂缓上线

• 盘点任务延后：门店盘点任务因与门店积分关联性较强且当前不紧急，决定暂缓上线，后续统一合并至积分系统一起上线。

3. 测试暂停争议

• 建议全面暂停测试：鉴于排期调整及后续可能面临的功能修改，建议直接暂停当前的测试工作，避免重复测试造成资源浪费。
• 建议维持测试：因对盘点任务优先级存在不确定性，建议今天测试工作照常进行，待今日沟通得出结论后再决定是否彻底停止。

4. 盘点任务优先级评估

• 优先级存疑：部分成员因未参加周末周会，对盘点任务当前的优先级存在疑问，需进一步沟通确认。
• 可继续测试：在最终结论得出前，盘点任务场景的测试可先行完成，不影响后续决策。

待办

1. 排期计划调整

• 与晓娜对接并整体调整包含积分正向绩效的排期计划。——马奇、建新

2. 上线时间确认

• 与事业部沟通确认门店积分功能的具体上线时间。——建新

3. 盘点任务后续安排

• 会后沟通确认门店盘点任务与门店积分的关联性问题及后续安排。——李亚洲、吴菊、刘晓娜

智能体推广与集成推进会（AI专项会议）

发言人：刘圣、贾云飞、王建朝

主题摘要：本次会议明确了智能体使用数据与问题处理的定期同步机制，分类制定了问题反馈策略，并规划了MCP能力接入168平台的统一集成方案。

小结

1. 智能体使用数据与价值同步机制

• 统计上线至今的使用情况：需统计各智能体自上线的累计使用轮次，并具体体现其在设计、评审或运维等业务领域的应用范围与提效价值，严禁仅罗列使用次数。
• 定期同步至大群：要求各负责人按模块统计并反馈，最终由专人统一汇总后发布至大群，以便向领导及产品经理展示智能体产生的实际业务价值。

2. 问题反馈与处理跟进

• 规范反馈收集表：需在现有反馈表中增加"预计处理时间"列，明确各项问题的处理节点，以此作为对提问人的积极反馈，避免问题石沉大海。
• 建立问题分类机制：将反馈问题分为咨询类、Bug类及优化建议类，以便针对性地提供答复或评估，确保反馈闭环。
• 驱动团队处理积压问题：针对当前大量问题未处理的情况，将通过定期同步现状的方式向各模块负责人施加压力，督促其利用项目间隙时间跟进解决。

3. 规范类问题答疑

• 确认按智能体规范修改：针对用户提出的规范类疑问，明确回复必须严格按照智能体专属的PRD模板及规范进行修改，避免因版本混淆导致后续大量问题。

4. 流程集成类问题答疑

• 智能体仅承担提效职责：针对BRD评审与需求提报流程是否与OA流程集成的咨询，明确当前智能体仅作为提效工具，不承担业务决策或流程审批职责。
• OA流程集成延后至二期：回复用户当前仍按原有OA流程提报，智能体与OA流程的深度自动化整合暂不考虑，计划留待二期规划。

5. MCP能力接入168平台方案

• 依赖平台网络策略开通：当前168平台的能力商店权限受限，需将MCP服务端的IP及端口提供给平台侧开通网络策略，方可实现集成。
• 通过语义匹配自动调用：集成后需在平台中启用对应工具，系统将基于提示词描述进行语义匹配，在对话任务中自动调用相应的MCP工具。
• 统一组织集成会议：为避免各模块重复沟通，决定统一组织会议，协调AI团队统一讲解并提供所需的网络策略及IP配置信息。

待办

1. 话术模板编写

• 编写智能体使用情况与价值总结的描述话术模板，并发送给团队成员作为样例参考。——刘圣

2. 使用情况统计反馈

• 统计并反馈所负责的智能体（如伊利哈尼斯、测试、BRD等）的使用情况及问题处理进度，最晚于明天完成。——贾云飞、王建朝

3. 反馈表分类标注

• 在反馈收集表中增加问题分类标签（如咨询类、Bug类、优化建议类），并逐一核对标注。——王建朝

4. 规范类问题跟进

• 确认朝阳组关于智能体规范类问题的具体沟通情况，并协助推动按规范修改。——王建朝

5. MCP集成会议组织

• 统一组织会议，协调AI团队讲解MCP能力接入168平台的具体网络策略与IP配置事宜。——贾云飞

Java高级开发工程师面试（营销活动中心面试）

发言人：张磊、张建利、王建朝、薛碧盈

主题摘要：本次面试围绕候选人张磊的无人机反制平台项目经验、Spring框架原理及微服务架构认知展开，评估了其技术深度与项目落地能力，并明确了后续安排。

小结

1. 候选人基本情况与项目经验

• 12年Java开发经验：候选人主要服务于政府、学校及事业单位，具备全面的Java技术栈经验，近期聚焦于无人机管控与反制业务。
• 无人机侦测与反制平台：系统基于MySQL、Redis、Kafka等常规组件构建，前端通过WebSocket实时推送轨迹，无人机数据通过MQTT协议上送。
• 轨迹数据处理链路：轨迹数据经MQTT上送至代理层，随后转入Kafka进行消费，最终落入时序数据库存储，未直接存入传统关系型数据库。
• 业务并发与数据量现状：目前为政府类项目，QPS相对较低；单日轨迹上报量约300至500架次，系统仍处于各地部署阶段，尚未完全民用。

2. 系统设计与数据一致性方案

• 严格的数据校验机制：针对管控业务中出现的键值重复等问题，在库表设计阶段对索引及数据校验逻辑进行了严格约束与优化。
• 基于操作日志的最终一致性：系统通过记录操作ID和数据域（如操作员、公司等）生成操作日志，向下游同步时仅推送最终状态，以收敛中间态操作。
• 三级重试与定时补偿机制：默认连续重试三次，失败后标记为可用状态，后续通过定时任务再次尝试推送。
• 异常排查与人工干预：若多次重试仍失败，需通过API调用的Call Log排查根本原因（如对方拒收或自身推送失败），并进行人工处理。

3. 技术深度与架构认知

• 大数据平台项目：曾从零学习并应用Hadoop、HBase等大数据生态组件，完成了基础的技术积累与应用落地。
• 数字孪生项目：负责动态大屏设计器的数据接入，采用工厂模式处理Excel及多类型数据库的导入，实现了组件的动态配置与展示。
• Spring Boot核心价值：通过自动化配置和Maven依赖版本集中管理，大幅降低了组件冲突风险，简化了单体应用开发流程。
• Spring Cloud微服务定位：主要用于业务拆分与集群管理，应对高并发与高耦合问题；但候选人指出随着Istio等服务网格技术的兴起，其已非唯一选择。
• 微服务组件应用经验：项目中实际使用过Spring Cloud的配置中心、网关、RPC远程调用、Sentinel流量控制及分布式事务组件。

4. 面试结论与后续安排

• 面试流程结束：本次技术面试问答环节已结束，面试官对候选人的技术背景与项目经验进行了全面评估。
• 待定后续流程：面试官表示如有进一步安排，将通过后续联系通知候选人。

Java后端开发技术面试（营销活动中心面试）

发言人：李康、张建利、王建朝、薛碧盈

主题摘要：本次会议为Java后端开发技术面试，重点考察了候选人在高并发场景下的系统优化经验、大数据平台项目开发经验，以及应对紧急需求变更和老旧系统迭代的解决方案。

小结

1. 候选人背景与项目经验介绍

• 技术栈：候选人熟练掌握Spring Boot、Spring Cloud Alibaba微服务架构，以及Nacos、MyBatis Plus、Redis、Kafka等技术，具备MySQL、MongoDB、TDengine等数据库使用经验。
• 从业经历：近期在北京天翼数据负责虚拟电厂相关业务，此前在神州数码集成负责农业相关项目，具备从需求沟通到平台代码编写及团队管理的经验。
• 大数据平台项目经验：深度参与了宿迁大数据、铜川、广西百色等多个大数据平台项目，其中广西百色芒果项目参与了二期开发。
• 项目具体职责：在百色项目中负责数据整合、地图矢量数据绘制，以及对接海康、大华等物联网设备与第三方视频，并参与外业调查系统与可视化大屏开发。

2. 高并发系统优化方案考察

• 系统崩溃与OOM排查：系统上线初期因全国3万多个乡镇集中填报，导致单体架构内存占满（OOM），出现数据丢失与超时现象；排查发现Excel模板中携带的行政区划基础代码数据过大，通过优化命名或改为查询方式去除冗余数据，解决了OOM与重启问题。
• 多节点部署：初期采用单体架构后，后续部署了三套服务并通过Tomcat进行负载均衡转发，以应对高并发请求。
• Session共享机制：在多Tomcat部署环境下，前端将User ID存入Session Storage，后端将Token存入Redis缓存，通过自定义注解与切面实现鉴权与Session共享。
• Excel异步处理：前端增加格式校验，后端采用异步消费模式，通过定时任务抽取数据至临时表处理，避免直接入库导致系统崩溃。
• 接口限流与幂等性：使用Google Guava实现接口限流，并通过Redis的set nx机制结合文件哈希值与校验码，防止文件重复提交。

3. 项目管理与突发需求应对

• 紧急需求变更处理：常规开发中研发负责人会提前预留3至4天的缓冲时间，以应对客户在排期内的需求变更；面对无预留时间的紧急需求，采取项目经理与开发人员共同加班、按模块拆分任务并即时沟通确认的方式，确保按时交付。
• 老旧系统迭代与交接：面对基于SSM、Dubbo等老旧框架的系统，首先通过咨询交接人了解项目启动顺序与配置，再结合Controller、Service、Mapper的代码层级快速定位临时需求涉及的模块。
• 环境排查与自测：需重点确认Git上的数据库地址是否可用，理清数据库库表结构，避免数据错乱，并在开发完成后进行充分的自测验证。
• 沉淀项目文档：在梳理与开发过程中，将涉及的表结构、业务流程、工具类及服务器部署方式（如脚本或Docker部署、备份规则等）记录并整理成项目文档，方便后续维护。

积分池经销商维度下沉方案研讨（物码项目）

参与讨论：刘晓娜、孔玮、吴菊、吴南林、林焕纯

主题摘要：本次会议围绕积分池核算维度下沉至经销商展开，明确了兑换核销、逆向链路及底层表结构等核心改造点，评估了测试排期与盘点任务拆分方案，并针对交互逻辑与系统性能问题进行了答疑。

小结

1. 需求变更背景与核心改造点

• 积分池维度下沉：业务方要求正向与逆向需求同步上线，积分池核算维度由原有的"门店+人+活动"下沉至"门店+人+活动+经销商"；同一门店下不同经销商需独立设置积分池，余额展示与兑换均按经销商维度分别进行。
• 兑换与核销逻辑调整：门店在兑换产品券或货抵券前，必须先指定目标核销经销商，系统仅消耗该经销商名下的可用积分；生成的卡券需标记来源经销商，后续核销时必须严格匹配对应的经销商。
• 底层数据与逆向链路改造：积分池、积分流水及余额流水表均需新增经销商维度，数据字典同步更新；积分扣减、退回及过期扣减等逆向链路均需带上经销商维度，确保原路归还至对应经销商的积分池。

2. 测试与排期方案评估

• 一期上线与二期迭代权衡：当前正向改造的集成测试已完成30%，需评估是继续测完作为一期上线、二期再迭代经销商维度，还是直接暂停并统一与逆向需求一起上线；测试团队需于明日给出明确结论，判断哪种方案对测试与研发成本最优。
• 盘点任务拆分评估：需评估将盘点任务从积分活动中拆分出来独立在10月份上线的技术成本与可行性；营销活动中心及SFA端需针对拆分方案进行专项评估，并于明日给出反馈。
• 整体排期时间线：智慧门店及营销活动中心的10月15日冷饮相关版本将正常上线，不受影响；涉及经销商维度的夜奶需求预计排期在12月底，具体时间需结合各端改造复杂度最终确认。

3. 交互逻辑与系统性能答疑

• 积分展示与交互逻辑答疑：吴南林提问"一个人有多个店的情况下，兑换时是否还需先选店再选经销商"——刘晓娜答：是的，兑换流程需要先进行选店，再选择经销商。
• 积分逆向与卡券关系答疑：林焕纯提问"积分逆向主要包含哪些情况？卡券过期或退货是否会触发积分回退"——孔玮答：积分逆向包含退货、积分过期及积分被使用等情况，但兑换后的卡券过期或退货均不进行积分回退；刘晓娜补充：积分一旦兑换为卡券即视为已消耗，后续退货或卡券过期仅对剩余积分进行记账扣减，不会退回已兑换的卡券。
• 钱包页面展示逻辑答疑：孔玮提问"钱包页面展示是否会因积分下沉导致余额加加减减出现偏差"——刘晓娜答：钱包页面需按经销商分开展示积分余额，具体展示逻辑需后续拉通业务方对齐确认。
• 系统性能与架构影响答疑：刘晓娜提问"积分维度下沉至经销商后，对并发落库、退货回滚等系统性能及数据库表结构有何影响"——吴菊答：从数据归属逻辑上看，按门店和经销商切分反而简化了事后归因难度，但数据库表结构需向下增加一层子池子或增加标记。

待办

1. 会议录制同步

• 录制本次会议屏幕并发送给请假的测试同学然，供其了解实际调整点并给出判断。——马奇

2. 测试方案评估

• 评估并反馈"继续一期上线"与"暂停统一上线"两种方案对测试与研发成本的影响。——刘莉、然

3. 盘点任务拆分评估

• 评估盘点任务拆分独立上线的可行性，并于明日给出反馈。——陈志伟、王琪

4. PRD文档输出

• 牵头拉齐框架，组织各端输出下沉至经销商维度的PRD文档，并于周二下班前输出初版。——孔玮

5. 系统性能影响评估

• 评估积分维度下沉对系统性能及数据库表结构的影响，并明确所需的优化迭代内容。——建利哥

6. 首页查积分逻辑对齐

• 评估智慧门店首页查积分逻辑的调整，确保与计费端保持一致，避免用户在不同页面看到的数据产生逻辑差异。——任铭

7. 钱包展示逻辑对齐

• 拉通业务方对齐积分钱包页面的具体展示逻辑。——刘晓娜