2026-09-01 工作日志

小智App接入盘点任务H5页面网络方案评审

• 发言人：王建朝、李明非、宋洋、陈志伟、郝鸿海等 6 人
• 主题摘要：会议否决了通过集成网关转发 H5 页面的方案，决定采用拆分独立 Pod 并申请公网域名的架构，明确了前后端分离部署及 RPC 内部调用的技术路径，并要求补充鉴权与文档。

小结

一、网络接入方案选型与决策

1. 否决集成网关转发方案

• 技术限制明确：郝鸿海指出集成网关（TSE）目前仅支持内网网关，不支持公网 H5 静态资源的代理，且即便代理后端接口也存在限流与安全策略限制，无法满足 ToC 场景需求。
• 架构不匹配：王建朝强调集成网关主要用于系统间集成，而本次需求是前端页面嵌入，若强行通过网关转发会导致架构混乱，且无法解决 H5 页面本身的公网暴露问题。

2. 确立独立公网域名方案

• 架构隔离原则：决定不采用网关，而是申请独立的公网域名，将前端 H5 页面与后端接口服务部署在独立的 Pod 中，实现与内网管理系统的物理隔离。
• 安全边界控制：明确该公网 Pod 仅承载"盘点任务"相关的查询列表及详情接口，严禁暴露其他内部服务，确保权限范围最小化。

二、技术架构与部署细节

1. 前后端分离部署策略

• 前端独立部署：前端 H5 页面部署在独立的 Pod 中，通过公网域名直接对外提供服务，避免内网域名无法被公网访问的问题。
• 后端服务拆分：后端 Controller 层迁移至公网 Pod，Service 层业务逻辑保持在内网，通过 RPC 进行内部调用，确保业务逻辑复用。

2. 内部通信机制

• RPC 调用链路：公网 Pod 中的 Controller 不再走 HTTP 网关，而是直接通过 RPC 调用内网的服务（Service），实现高效的内网通信。
• 鉴权机制补充：王建朝强调公网服务必须增加鉴权逻辑，李明非确认将提供 App Key 和 Secret，并在入口处进行 Token 校验与参数加密，防止数据包被截获。

三、后续规划与规范

1. 方案落地与联调

• 并行推进：鉴于小智 App 侧急需联调，决定服务拆分与公网域名申请同步进行，今日内完成代码拆分并提供调试环境。
• 文档沉淀：要求李明非团队梳理完整的方案文档，包括 Pod 拆分逻辑、接口调用关系及鉴权流程，以便后续维护与评审。

2. 长期架构规范

• 公网出口标准化：王建朝建议营销活动中心后续应统一规划公网出口，新功能开发需提前考虑功能切分与部署位置，避免临时性架构调整。
• 接口分离：未来开发需将 ToC 公网接口与 ToB 内网管理接口进行物理分离，提升系统安全性与扩展性。

待办

• 梳理盘点任务涉及的接口调用清单及技术方案文档。 — @李明非 @宋洋
• 拆分独立 Pod，编写 RPC 调用代码，并申请公网域名。 — @李明非
• 补充 H5 页面的鉴权逻辑（App Key/Secret/Token）。 — @李明非

智慧门店项目进度与数据治理周会

• 发言人：李亚洲、龚明、余建新、金鑫、孙东栋等 11 人
• 主题摘要：本次会议确认了智慧门店项目按 9 月 20 日上线目标推进，重点对齐了计费与 SFA 联调延期至 9 月 4 日的影响，并针对生产日期录入错误及项目管理系统基线缺失问题制定了整改措施。

小结

一、项目进度与排期对齐

1. 核心模块交付与联调计划

• 积分需求提测完成：智慧门店积分需求已提测，待计费模块进入集成后即可开展集成测试，整体仍按 9 月 20 日上线目标推进。
• 计费与 SFA 联调延期：计费模块预计 9 月 4 日进入集成，SFA 联调同步推迟至 9 月 4 日，目前各方反馈该延期对整体上线计划无影响。
• 数据清洗与营销活动中心排期：主数据清洗工作因资源紧张采用每周穿插方式推进；营销活动中心因物码项目上线需求评审延期，具体评估结果需等待 9 月 4 日输出。

2. 研发与测试状态同步

• PC 端报表开发：PC 端报表开发工作正在正常推进，无风险。
• 小智系统监控处理：针对小智系统出现的数字化监控报警问题，团队正在处理中。

二、监控告警与故障复盘

1. 异常数据分析与处理

• 告警数据统计：昨日（周一）共产生 7 条告警，其中 8 条属于日常监控范围，1 条新增异常（序号 12）需重点分析。
• 异常原因排查：针对 8 月 31 日需反馈的异常数据分析，部分已反馈排期（9 月 1 日/9 月 8 日结项），新增异常需进一步分析。

2. 历史故障复盘安排

• SFA 发版问题复盘：针对 8 月 27 日 SFA 发版引起的问题，团队将进行小型复盘。

三、项目管理与流程优化

1. 项目管理系统规范

• 计划更新滞后：项目管理系统显示 8 月 28 日/8 月 29 日任务已过期且未完成，需立即调整计划状态。
• 基线计划缺失：当前项目缺乏基线计划（Baseline Plan），导致无法有效评估进度偏差，需选定一个版本作为基线进行对比。

2. 数据录入校验机制

• 生产日期录入错误：针对业务反馈的"生产日期显示为 2029 年"问题，经排查确认为业务人员在闪提激活操作时人工录入错误。
• 兜底校验建议：为避免类似错误，建议增加兜底校验逻辑，限制录入年份不能超过当前年份过多（如不超过 2027 年）。

待办

• 分析监控告警中新增的异常（序号 12）原因。 — @孙东栋 @余建新
• 调整项目管理系统中的过期任务状态，并建立基线计划。 — @全体成员
• 针对生产日期录入错误问题，增加兜底校验逻辑。 — @金鑫
• 发布修订后的项目计划版本。 — @马奇
• 排查生产日期显示为 2029 年的具体原因。 — @余建新

智能体上线状态对齐与培训筹备会

• 发言人：刘圣、王建朝、杨华峰、施少华、李育佳等 14 人
• 主题摘要：本次会议确认了技术管理与服务体系下 10 余个智能体的上线状态，制定了周四下午的集中培训计划，并解决了系统巡检与数据库调优的访问异常问题。

小结

一、智能体上线状态与培训规划

1. 上线状态确认

• 核心智能体清单：确认了包括工作量评估、BRD/PRD 生成、原型设计评审、架构方案评审、技术方案评审、功能验收、测试相关（含 5 个子项）、系统巡检、数据库调优及 RD 生成在内的 10 余个智能体已具备上线条件。
• 待定与剔除项：宏伟负责的智能体因未部署暂不纳入本次培训；刘阳负责的"技术服务控制台"及"休假"模块因未上线或已合并，本次不做讲解。
• 集成规范：明确所有智能体均需集成至"一智开发平台"，通过单点登录统一访问，不再单独维护独立入口。

2. 培训安排与形式

• 时间节点：计划于本周四中午 1 点开始，预留 1 小时进行集中培训。
• 培训形式：采用实操演示为主，按平台菜单顺序依次进行，每人时长控制在 3-5 分钟，重点讲解功能使用而非技术实现。
• 演示策略：针对评审类耗时较长的功能，要求提前准备已评审完成的案例或历史记录进行展示，避免现场等待。

二、系统访问异常排查与修复

1. 异常现象定位

• 访问差异：刘圣和杨华峰无法访问，提示报错或空白；施少华和李育佳访问正常。
• 初步排查：排除网络策略限制，确认问题与浏览器安全策略及证书信任有关。

2. 解决方案

• 绕过安全限制：发现直接访问 IP 地址（如 119.xx.xx.xx）可正常访问，刷新后即可解决。
• 培训说明：决定在培训时统一说明该访问技巧，即若遇访问异常，需先直接访问 IP 地址进行信任操作。

三、功能定义与优化调整

1. 功能命名与范围修正

• 功能验收定义：明确"开发质量评审"实为"功能验收"，用于验证 PRD 需求是否在代码中实现，需上传 PRD 进行比对。
• 菜单名称统一：决定将菜单名称统一修改为"功能验收"，以保持与业务逻辑的一致性。

2. 功能逻辑优化

• 评审规则结合：PRD 评审功能需结合公司技术规范（如伊利规范）进行优化，以提升评审的准确性与规范性。
• 使用限制说明：数据库调优功能需依赖执行计划及 IO 块读取等底层信息，仅限 DBA 内部或特定平台使用，需在培训中明确使用条件。

待办

• 排查并修复"系统巡检"和"数据库调优"的访问异常，确认网络策略及证书配置。 — @杨华峰 @施少华
• 准备培训演示案例（如 JSON 数据、已评审文件），避免现场等待。 — @施少华 @刘曌阳
• 修改"开发质量评审"菜单名称为"功能验收"。 — @李育佳
• 发布周四下午 1 点培训的日程通知及上线智能体清单。 — @刘圣

电子围栏数据清洗与人员职务表扩展方案评审

• 发言人：郝梓斐、王建朝、贾继伟、马奇、李明非等 7 人
• 主题摘要：会议评审了电子围栏街道编码缺失的兜底清洗方案，明确了通过脚本回填并下线接口的流程；同时讨论了人员职务表扩展方案，因架构归属不清及方案不完整，决定暂缓评审。

小结

一、电子围栏街道编码缺失清洗方案

1. 清洗逻辑与实施策略

• 兜底清洗机制：通过脚本查询街道编码为空且名称不为空的数据，反查行政区划表进行回填，并利用唯一键（街道名称+户籍编码）防止重复数据写入。
• 执行方式确认：确认为一次性清库存操作，非周期性任务。主数据后续推送的有效数据将自带街道编码，无需长期运行该脚本。
• 数据量级评估：目前缺失数据量已从高位降至几百至几千条，属于可控范围。

2. 方案风险控制与优化

• 幂等性保障：确认脚本逻辑具有幂等性，仅处理编码为空的数据，即使重复调用也不会导致数据错乱。
• 接口下线要求：为避免误操作或并发风险，上线执行完毕后必须立即停掉 Controller 入口，防止过期代码残留。
• 测试覆盖要求：上线前需进行全量测试，重点验证并发场景下的数据一致性及服务稳定性。

二、人员职务表扩展方案（暂缓评审）

1. 表结构扩展逻辑

• 新增字段方案：在原有人员职务表中增加独立字段，用于区分内部人员、经销商人员及门店人员等子类型，避免改动原有字段影响历史功能。
• 数据初始化方式：门店人员等固定类型通过代码写死初始化，经销商人员等动态类型通过读取外部数据表进行拆分存储。

2. 评审结论与后续行动

• 架构归属不清：经讨论，该需求涉及"新鲜度盘点"功能，但无法明确归属具体事业部（如夜奶、奶酪、营销活动中心），且涉及跨系统调用。
• 方案完整性不足：当前方案仅涉及底层表结构变更，缺乏上层业务逻辑（如树形结构组装）的完整设计，无法评估整体影响。
• 暂缓决定：决定暂缓此次评审，待明确系统归属并补充完整业务逻辑后，再进行二次评审。

待办

• 补充人员职务表扩展方案的完整业务逻辑（含树形结构组装），并明确所属事业部及系统归属。 — @郝梓斐 @李明非
• 对电子围栏清洗脚本进行全量测试（含并发场景），确保无生产环境风险。 — @郝梓斐
• 电子围栏清洗脚本上线执行完毕后，立即停掉 Controller 入口，防止误操作。 — @郝梓斐