2026-07-27 工作日志

各模块进度同步与数据权限梳理、移动端开发、测试阻塞及数据一致性讨论会

小结

1. 数据权限梳理与对齐

• 营销活动中心将作为试点，盘点明细、批发出货查验明细等场景的权限逻辑将被梳理。
• 当前存在商siv核销等权限方案差异，需尽快与业务方（数字办、香销、渠道）对齐统一方案。

2. 移动端与PC端开发进展

• 移动端出货场景：门店端页面已复制完成并进行微调，本周将进行嵌入开发；权限方案需在周二前确认。
• 移动端盘点场景：PRD 已完成一轮场景澄清，将进入开发阶段。
• PC 端报表优化：已明确 P1、P2、P3 的优先级，将优先上线 P1 部分。

3. 测试与数据问题

• 测试阻塞：扫码盘点及签收功能的集成测试未通过，原因为营销活动中心经销商数据未正常返回，正在解决。
• 门店积分：因业务方要求完整上线，已将盘点计划和基于盘点的检核发激励功能一并纳入，预计周末可完成最后评审。
• 数据一致性：门店侧大批量数据比对仍在进行中；云商侧监控正常；24 类数据中仍有 22 类存在差异，正在分析原因并评估优先级。

4. 新增问题与风险

• 扫码重复生成单号：此问题已从 PDA 扩展至安卓端，将在 8 月 6 日版本中通过定向包解决。
• SFA 门头照识别：因网络抖动导致识别失败，将通过图片上云的方式根治。
• 高并发场景：PDA 高并发场景未被充分测试，将组织专项复盘并加强上线评审。

待办

1. 数据权限与方案对齐

• 各端需在今天给出相关工作的排期。——李亚洲
• 跟进营销助手侧的权限方案，确保与云商侧一致。——孙传熙
• 跟进营销活动中心侧的权限方案梳理工作。——孙传熙

2. 移动端与PC端开发

• 确认并加入小智侧的嵌入方案任务。——孙东栋
• 明确并更新门店积分功能的最终评审计划。——刘晓娜

3. 测试与数据问题跟进

• 解决营销活动中心经销商数据未返回的问题，以推进集成测试。——任铭
• 跟进门店积分功能的最终评审。——刘晓娜
• 分析 24 类数据差异的根本原因并评估优先级。——邢健
• 确认大小写兼容功能是否已正常发版，以便处理历史差异数据。——邢健

4. 新增问题处理

• 解决扫码重复生成单号的问题，并在 8 月 6 日版本中发布定向包。——李赵丹
• 组织 PDA 高并发场景的专项复盘会议。——吴菊

---

本次会议介绍了企业级AI开发规范体系Harnes，阐述了其背景、架构、使用方法及未来发展方向。

小结

1. Harnes的背景与价值

• 背景：当前AI Agent虽具备强大开发能力，但在企业级项目中仍存在需求理解不清、方案不规范、缺乏证据留存及过程散落等问题。
• 价值：Harnes旨在弥补上述流程断点，通过一套标准化的流程引擎，将AI的开发行为纳入规范化管理，确保其产出符合企业级的质量标准和规范要求。

2. Harnes的架构与核心流程

• 分层架构：Harnes采用四层架构：企业规范底座层、流程治理与证据闭环层、AI Agent执行层、项目事实与长期上下文治理层。
• 核心角色：
  • 开发人员：获得AI开发的规范化支持，减少遗漏和返工。
  • 技术经理：可审查设计与实现的差异，确保AI产出符合预期。
  • 企业：形成可复制、可追溯的项目经验和治理文档。
• 核心机制：
  • 流程控制：基于状态机（如需求分析、技术设计、开发、验证、人工审查等）控制AI的执行流程。
  • 任务中断与恢复：利用SQLite checkpoint机制，确保任务可中断、可恢复。
  • 人工审查：最终代码提交前必须经过人工审查和归档，AI不进行自我审查。

3. Harnes的使用方法与环境要求

• 安装环境：需要在Windows或macOS系统上，安装Node.js和PowerShell，并确保IDEA中已开启项目级MCP。
• 安装方式：在项目根目录执行命令行安装脚本。
• 使用流程：用户在IDEA中描述研发目标，Harnes将自动启动任务，引导AI完成需求分析、技术设计、代码开发、测试验证等环节，并在最后等待人工确认归档。

4. Harnes的未来方向

• 平台化：计划搭建"Harnes智"开发平台，将Harnes作为核心组件，并融合更多辅助开发工具。
• 流程定制化：未来将支持根据不同项目（如Java、Python等）配置和定制化开发流程。
• 社区共建：Harnes源码将开源，鼓励各项目组反馈Bug和提出优化建议，共同迭代和完善该工具。

待办

1. Harnes使用反馈

• 会后将提供Harnes试用及反馈收集文档，用于收集安装使用中的问题、Bug及优化建议。刘阳

2. Harnes未来规划文档完善

• 后续将完善Harnes的未来规划、Git管理机制等相关文档。刘阳

---

基于盘点任务的新售卖激励方案讨论会

小结

1. 盘点任务配置与下发

• 盘点任务将在营销活动中心进行配置，支持按促销、效期等多种类型，并可按角色（如店主、业代）和范围（如 SKU、生产日期）进行设定。
• 盘点任务需覆盖所有相关角色，包括本期暂不涉及的导购。
• 前端将通过首页和扫码盘点页两个入口接收并处理盘点任务，用户可选择是否基于任务进行盘点。

2. 盘点任务与售卖激励的关联

• 售卖激励活动可在营销活动中心配置，支持"消费者扫内码"和"通过盘点任务核减"两种触发方式。
• 盘点任务与售卖激励活动的关联采用后置关联模式：活动创建时可先配置核算方式，待盘点任务发布后，再在活动配置中手动关联具体的盘点任务。
• 一个售卖激励活动可关联多个盘点任务，每个任务可配置不同的激励规则。

3. 数据计算与口径

• 售卖激励的核心计算逻辑为：估算售卖量 = 正常签收量 - 盘点核减量。
• 为简化逻辑并降低一线门店理解成本，一期采用统一口径：盘点数据仅针对门店正常签收的货物进行，不区分"盘点签收"和"查证签收"等类型。
• 未来可支持按签收类型灵活配置，但初期保持此简化逻辑。

4. 前端与权限

• 售卖激励的前端主要面向店主，配置界面中不提供"导购"选项。
• 盘点任务的创建与关联遵循数据权限原则，用户只能关联自己创建或其本组织及以下创建的任务。

待办

1. 盘点任务前端交互设计

• 前端需设计当用户进入扫码盘点页时，若有未处理的盘点任务，应弹窗提示用户选择"基于任务盘点"或"正常盘点"。——北京诺德511
• 在关联盘点任务的配置页，需将任务选择方式由下拉菜单改为弹窗，以便筛选和展示更多任务信息。——北京诺德511

2. 盘点任务配置逻辑确认

• 需确认并实现同一 SKU 和生产月份在同一时间范围内，仅能创建一个盘点任务的控制逻辑。——北京诺德511

3. 数据口径与计算逻辑文档化

• 在 PRD 文档中，需明确说明"盘点数据"和"正常签收数据"的统一计算口径，确保所有相关方理解并遵循此逻辑。——北京诺德511

---

sip-mac 单体仓监理素材一条龙沉淀（架构画像→模块清单→优雅停机核对→生产超时排障）

小结

1. 产出清单（4 份，均在 .understand-anything/）

• 架构分析 + 看板：dashboard.html（力导向图 + 两个弹窗：架构形态/枢纽风险），用于投屏讲现状。
• 技术分析 PDF：技术分析报告.pdf（7 页）+ gen_report.py，可脱离浏览器发甲方。
• 全量模块清单：模块清单.md（226 行 / 11 章）+ module-scan.json，用于资产盘点。
• 优雅停机核对表：优雅停机整改核对表.md（5 章）+ scan_graceful.py，用于整改进度跟踪。

2. 关键结论（基于实测，已校正两处旧误判）

• 架构画像：66 个 Maven 模块 + 4 个非 Java 目录；编译期 Maven 内部依赖仅 5 条，真正骨架是运行期 Dubbo RPC（58 条调用边）。sip-mac-data 被 21 个服务依赖，为最大单点风险。
• 模块清单：实际可部署服务 23 个（22 个 Maven + 1 个 Gradle 服务 sip-mac-activity，不在 Maven reactor 内，易漏算）。
• 优雅停机：25 个含配置文件模块中，16 已配 graceful / 9 未配；红线含 gateway、data 等可部署服务；receive、mq-consumer 已配 timeout-per-shutdown-phase:60s（此前误说"全仓无 timeout"，已校正）；Dubbo 提供方优雅停机全仓未显式配置。
• openapi 部署期超时：connection timed out: /172.21.48.109:8119 = 旧 Pod 已销毁但仍挂在网关 Dubbo 目录，根因为「应用优雅停机未覆盖 Dubbo + 仓库内无 K8s 探针/PreStop + 网关重试放大」三者未对齐。已给 A/B/C 三层整改方案。

3. 待跟进（尚未落文档 / 需拍板）

• openapi 排障剧本目前未生成独立文档（已附在对话里），可整理成独立 md 或对账清单。
• 核对表脚本可重复跑——乙方改完配置后重跑即出新版。
• 看板仍依赖 unpkg CDN（vis-network），可内联成离线版便于发甲方内网。