2026-07-10 工作日志
项目进度与版本规划同步会
本次会议同步了项目整体进度、版本发布计划及各模块进展，并明确了APM监控方案和门店积分需求。
小结
1. 项目整体进度与版本规划
- 项目管理系统的主计划将在今日更新并发布，各团队需同步更新进度。
- 整体版本规划如下：
- 后端正式发版时间：8月6日。
- UAT测试时间：8月3日或4日。
- 上线评审时间：8月5日。
- SFA灰度上线时间：8月7日和8日。
2. 各模块进展同步
- 前端走查与监控：
- 将采用APM进行统一监控，替代部分神测买点，以提升前端性能监控能力。
- 将针对加载和崩溃问题进行专项测试，通过灰度包找关键用户验证。
- 监控系统在7月2日升级后，共发现19类异常，目前已完成50%的分析。
- 数据与遗留问题：
- 数据表梳理基本完成，将与主数据团队对齐。
- 遗留问题已登记在案，需持续关注。
3. 门店积分需求
- 下一版本的门店积分需求方案已进入各端对齐阶段，将输出PRD文档。
待办
1. 项目管理与需求
- 各团队需在今日下班前更新主计划中的最终时间。—— 所有人
- 李亚洲需将监控问题补充到项目新增项中，以便共识。
2. APM监控
- P0接口优化将在今日11点进行上线评审，评审通过后确定上线时间。—— 任铭
3. 监控问题跟进
- BQ需在会后将已完成分析的监控问题明细补充进去。
4. 门店积分需求
- 余建新需在今日组织各端对齐门店积分需求方案，并输出PRD文档。
营销活动中心服务频繁重启问题排查
前天发现营销活动中心新活动模块频繁重启的问题，原因是健康检查频繁检测 126 邮箱服务导致的服务重启。本人探活时发现 126 邮箱服务无法正常响应，触发了探针的自动重启功能。关闭 126 探活结果后，整个服务运行稳定。
关于 126 邮箱使用原因的沟通
与李明飞沟通了使用 126 邮箱的原因：
- 系统功能设计中有一项系统通知功能，是通过邮件方式通知的。
- 供应商在开发过程中使用的是自己的 126 邮箱，不知道在伊犁使用邮箱服务该找谁申请。
针对第二点，已给出明确反馈，可以让小娜去联系李龙解决。
总结
在涉及到邮箱服务，尤其是 B 端业务系统的邮箱服务时，一定要使用企业的官方邮件服务，避免用户对系统产生不信任。如果使用 126 邮箱，会被认为是个人用户，会影响企业的品牌力。
上线代码管理规范评审会
本次会议主要讨论并确定了后续项目的上线代码管理规范，明确了基于需求 ID 的开发流程及分支管理策略。
小结
1. 上线代码管理规范
- 为实现代码的快速追溯和管控，将采用统一的上线管理规范。
- 在 Coding 平台创建迭代，将需求拆分为带有唯一 ID 的工作项。
- 开发人员在提交代码时，需附带对应需求的 ID，以便于追踪代码与需求的关联关系。
2. 分支管理策略
- 针对需求迭代中"部分需求上线"的情况，制定了详细的分支管理流程：
- Bug 修复: 针对线上 Bug 创建独立的 hotfix 分支进行修复，每个 Bug 需有唯一的编号。
- 新功能开发: 从主干（master）或基线版本创建 feature 分支进行开发。
- 版本发布: 测试通过的功能分支将合并至 release 分支进行集成测试（UAT），最终发布至生产环境。
3. 特殊场景讨论
- 运维需求: 讨论了将大量运维需求合并到一个分支的风险，可能导致分支管理复杂化。结论是需根据实际情况评估，若分支过多则需寻找替代方案。
- 集成测试: 明确了集成测试不应修改代码。对于需要模拟异常数据的测试，应通过 Postman 等工具进行，而非修改代码。
待办
1. 分享并完善分支管理流程文档
- 李宏伟需将本次会议确定的分支管理流程补充完整并发送至群内，以便各方共识。
2. 对齐 Bug 修复的编码规则
- 张建利需与产品团队对齐，为每个 Bug 修复任务制定一个统一的、唯一的编码规则。
消费者中奖明细表与出货签收数量逻辑评审会
本次会议主要讨论了消费者中奖明细表的字段更新需求，以及出货签收数量的取值逻辑变更，并明确了相关的测试范围。
小结
1. 消费者中奖明细表字段更新
- 新增 C 端活动编码、C 端活动名称、开始时间、结束时间、创建人所属部门等字段。
- B 端活动相关字段的展示逻辑将根据消费者是否参与营销活动中心活动进行区分：若参与，则显示对应活动信息；若未参与，则显示"杠"。
- 全国活动的 C 端活动类型将根据事业部和品牌进行区分。
- 特殊奖品（如"金条"）的处理方式为保持原有逻辑不变。
2. 出货签收数量取值逻辑变更
- 新增"开启出货签收数量"配置，用于判断是否启用新的数量统计逻辑。
- 明确了多种签收方式（扫码、链接、代签收等）和流转场景（如出货单转移、退货、一键退货）下的出货数量和签收数量的计算规则。
- 讨论了已售、已退货、已过期等特殊状态下，对"已售"流向的展示逻辑。
3. 测试范围与工具
- 测试需覆盖所有签收场景，包括盘点和查证签收，但需注意其不计入出货签收数量的判断。
- 测试需验证 B 端出货明细表不受本次改动影响。
- 测试需关注功能的实时性，确保开关状态变更后能即时生效。
- 测试需将"巡查管家"工具纳入测试范围。
待办
1. 需求文档与用例完善
- 在 PRD 文档中补充"重金条"等特殊奖品的处理逻辑说明。—— 刘莉
- 在测试用例中补充"巡查管家"的使用场景。—— 刘莉
- 在测试用例中补充"开启/关闭"功能开关的实时性验证。—— 刘莉
- 在测试用例中补充"已售"、"已退货"等特殊状态下，对"已售"流向的展示逻辑。—— 刘莉
- 在测试用例中补充"代签收"、"待签收"、"分享链接签收"等场景下的箱码流向验证。—— 刘莉
2. 测试验证
- 测试时需验证 B 端出货明细表不受本次改动的影响。—— 刘莉
AI 编程演进与 HARNESS 工程体系分享
本次会议分享了 AI 编程从 L3 到 L4 的演进路径，重点介绍了团队构建的 HARNESS 工程体系、落地场景及评估方法。
小结
1. AI 编程的演进与挑战
- AI 编程从 L3（人驱动单个 Agent）向 L4（事件驱动、团队协作）演进，旨在实现批量管理和与运维系统的打通。
- 当前 AI 编程面临三大挑战：经验不流通、规范软约束、代码质量验证不足。
2. HARNESS 工程体系解决方案
- 项目手册 (agents.md)：由各项目 Owner 负责编写，作为团队记忆，包含项目概述、构建测试方法、架构依赖、约束规范等内容，确保 Agent 能理解项目。
- 知识体系：结合本地知识库（理解项目代码）和 ContestDB（理解企业业务知识），构建完整的知识体系。
- 工程化门禁：通过多模型交叉评审、强制的代码质量门禁（如单测覆盖率）等方式，确保代码质量和工程规范。
- Skill 体系：建立团队内部的 Skill 中心（Scale Center），沉淀和共享开发经验与技巧。
3. L4 Coding Service 落地场景与成效
- 研发辅助：通过钉钉机器人接收需求，由 AI 辅助开发。
- 自动修复：定时任务监控线上 500 错误日志，自动触发根因分析、代码修复、测试验证的闭环流程。
- 测试用例补齐：利用 AI 自动为老旧项目补充测试用例，提升覆盖率。
- 代码优化：对无效代码、命名不规范等问题进行持续治理。
- MR/CR 自动化：AI 参与代码审查，减少人力负担并保障代码质量。
4. 评估体系与模型策略
- 评估指标：包括代码质量（MR 一次性通过率）、测试质量（覆盖率）、交付效率（需求周期缩短近 50%）。
- 模型策略：从单一高成本模型转向分工式的国内外模型组合。核心环节（如需求分析）使用强效模型，大部分开发和测试环节使用性价比更高的国产模型（如千问），同时结合 HARNESS 工程弥补其不足，整体成本降低 82%，效果保持不变。
待办
1. 产品资料分享
- 李志磊会后将团队已产品化的"ContestDB"和"可观测"服务的产品文档发给参会老师。
扫码机盘点签收与查证机签收改造方案评审会
本次会议主要讨论了扫码机盘点机签收及查证机签收功能的改造方案，明确了技术实现、数据存储、异常处理及后续优化方向。
小结
1. 扫码机盘点及签收改造
- 数据存储: 将原有的两个 MongoDB 小集合（盘点单、明细）合并为一个大的 MongoDB 集合，以简化数据模型。
- 接口变更: 新增了门店仓库的 5 段、经销商、经纬度、渠道和级别等必填字段。作弊上传接口需新增"单据 id"字段。
- 业务逻辑: 改造后，盘点操作将从一次性盘点多个码，变为单个码进行盘点。盘点完成后，将异步调用签收联动接口。
2. 查证机签收改造
- 数据存储: 数据库沿用现有事实表，仅在门店的 5 段、渠道和级别等字段上新增索引。
- 核心逻辑: 明确了"查证即签收"的业务场景，即在门店进行查证时，系统将尝试为该码补录签收记录。此过程将通过 MQ 消息异步实现，以保证主流程的响应速度。
- 签收类型: 新增了多种签收类型，包括查证签收、盘点签收、查证异常签收、盘点异常签收等，以覆盖不同的业务场景。
3. 技术方案与优化讨论
- 数据清洗: 计划上线后，将对最近几个月的历史数据进行清洗，将旧的 MongoDB 集合数据迁移至新的大集合中。
- 异常处理: 讨论了当前接口返回 400 错误码过于笼统的问题，建议后续进行细化，以便于前端进行问题排查。
- 消息队列: 针对"查证即签收"的异步调用，会议决定将当前的 RPC 调用改为使用 MQ 消息队列，以提升系统的可靠性、可扩展性和容错能力。
待办
1. 技术方案优化与完善
- 在数据表设计中补充创建时间、更新时间等审计字段。—— 余勇军
- 在"扫码机盘点及签收"方案中，移除将经纬度作为字符串处理的逻辑，改为与现有存储保持一致。—— 余勇军
- 在"扫码机盘点及签收"方案中，将"查证即签收"的异步调用逻辑改为使用 MQ 消息队列实现。—— 张喜
- 在"扫码机盘点及签收"方案中，补充对敏感信息（如手机号）的加密或脱敏处理。—— 余勇军
- 在"扫码机盘点及签收"方案中，补充对"盘点即签收"和"查证即签收"场景的详细逻辑说明。—— 余勇军
2. 数据清洗与部署计划
- 与业务方确认数据清洗的具体计划，包括清洗周期（如每月清洗一个月数据）和执行时间。—— 宋洋
3. 外部依赖确认
- 确认经典小程序的查证功能是否已覆盖，以及其调用链路。—— 王建朝