Work for YILI

Appearance

2026-07-24 工作日志 ​

本次会议同步了各项目进展，明确了后续测试安排，并讨论了扫码签收异常等问题。

小结 ​

1. 各项目进展同步 ​

  • 经销商电子围栏改造：需跟进至8月6日版本。
  • 小智与智慧门店：签收列表签收功能已上线。
  • 必填资料：开发联调已完成，相关接口已可进入集成测试。
  • 一键签收：功能已上线，但需等待SFA前端入口改造完成后才能一同发布。
  • APM项目：整体按计划正常推进，预计8月6日上线。
  • 健康探查：与上一期基本一致，但有4条调天网接口报错500，暂无影响。

2. 问题与风险 ​

  • 扫码签收异常：SFA侧出现扫码出库后，签收时提示"生成一个码"而非"签收成功"的问题。已为受影响用户提供修复版本并继续排查。

待办 ​

1. 需求文档更新 ​

  • 需将"经销商电子围栏改造"需求修订至8月6日版本。余建新

2. 测试安排 ​

  • 整理并同步各端可测试范围，以便明确今日的测试批次。郑然然

3. 技术方案排期 ​

  • 跟进"多优"问题的技术方案排期，本周五需给出。陈祺

4. 健康探查报告更新 ​

  • 检查并更新"健康探查"报告，确保已保存最新结论。张建利

5. 扫码签收问题跟进 ​

  • 继续排查并解决SFA扫码签收异常的问题。王琪

会议讨论了扫码取值逻辑的变更，明确了人、店、货维度的取值规则、接口必填项及流向判断等测试要点。

小结 ​

1. 以人的维度取值逻辑变更 ​

  • 扫码人5段：原由"扫码人"和"经销商"共同决定，现统一由"扫码人"决定。此变更影响扫码查证、出货、签收、退货、盘点等多个场景。
  • 取值验证：为确保新逻辑生效，测试需构造"扫码人5段"与"门店/仓库5段"不一致的数据作为前置条件进行验证。

2. 以店/货维度取值逻辑变更 ​

  • 新增字段：在报表层面新增了"扫码店仓库5段"、"扫码店5段"、"扫码仓库5段"、"扫码仓库关联经销商5段"等字段。
  • 取值逻辑：当扫码人是"我司"人员时，取"门店"或"仓库"的5段；当扫码人是"经销商"人员时，取"扫码人"的5段。

3. 接口必填项确认 ​

  • 必填字段：多个接口（如B端出货明细表、智慧门店签收接口等）的必填项已明确，包括门店/仓库5段、门店/仓库关联经销商、ERP编码等。
  • 测试要求：测试用例需覆盖必填项为空时的报错场景，并确保前端提示与后端一致。

4. 流向判断规则 ​

  • 核心逻辑：系统将根据配置的距离（如500米）判断当前位置与门店的流向是否正常。
  • 影响范围：此规则会影响查证、盘点、签收、退货等操作的报表展示，但不影响用户操作本身。

5. 销售5段与电子围栏映射关系 ​

  • 数据源变更：销售5段的展示数据源由"经营围栏"变更为"电子围栏"。
  • 测试策略：测试将通过构造不同层级的电子围栏数据，验证销售5段的映射逻辑。对于报表中的具体数据，需由开发提供脚本进行后台数据比对。

待办 ​

1. 测试用例与文档完善 ​

  • 在所有涉及"扫码人"、"门店"、"仓库"、"经销商"等角色的场景中，补充"扫码人5段"与"门店/仓库5段"不一致的前置条件。秦丽娜 何兆文
  • 在"查证签收"、"无货权补货权"等场景下，明确当门店关联多个经销商且无法匹配时，系统将按前端传递的顺序取第一个经销商进行处理。陈德智 宋洋 刘晓娜
  • 在"销售5段"相关测试用例中，明确测试策略：通过修改主数据中的电子围栏信息，验证销售5段的映射结果。秦丽娜
  • 在"流向判断"相关测试用例中，补充"待签收列表签收"、"一键转移"、"一键退货"等场景。秦丽娜

2. 产品与开发支持 ​

  • 在PRD文档中补充"查证签收"、"无货权补货权"、"其他位置盘点"等相关场景的逻辑说明。陈德智
  • 提供脚本，用于验证"销售5段"与"电子围栏"的映射关系，以便测试进行数据核对。宋洋
  • 协调中台团队，明确"误码违规表"的测试范围和负责人。刘莉

其他工作 ​

ITSM 性能测试 ​

  • 完成 ITSM 的 7.24 性能测试，已更新到对应的 Excel 文档中。

本次会议分享了存量系统接入Agent的改造方案，重点探讨了Skill与MCP的适用场景，并提出了"先补说明书，再补适配器"的实施路径。

小结 ​

1. 存量系统接入Agent的核心思路 ​

  • 接入Agent并非必须进行大规模系统改造，核心在于将现有业务逻辑"说明书化"。
  • 最终的改造路径总结为"先补说明书，再补适配器"，即优先将复杂的业务流程梳理成清晰的Skill文档，再通过脚本或MCP等方式实现与Agent的连接。

2. Skill与MCP的适用场景与价值 ​

  • Skill (技能)：核心价值在于将"人脑经验"沉淀为可执行的逻辑。它负责组织和编排能力，是业务流程的"大脑"。适用于SOP、经验总结、跨团队知识传递等场景。
  • MCP (多能力协议)：核心价值在于提供标准化的"手脚"，让Agent能稳定、安全、可复用地调用业务能力。适用于通用性强、需要多团队/多客户端复用的功能，如消息通知、数据查询等。

3. 接入路径与实施策略 ​

  • 路径一 (Skill + 脚本)：通过AI生成脚本，直接调用现有API。成本低、速度快，适合快速验证业务场景，但受限于现有API的开放性和认证方式。
  • 路径二 (Agent直连MCP)：将业务系统作为MCP提供给Agent。适用于调用纯工具或执行简单、定性任务的场景，但对复杂业务逻辑的支持不佳。
  • 路径三 (Skill + MCP)：推荐的长期方案。由Skill定义业务流程，Agent通过调用MCP来获取和执行具体能力。此方案解耦良好，灵活性高，适合复杂的、跨系统的业务流程。

4. 关键结论与建议 ​

  • 并非所有业务都需要MCP化：应先通过低投入方式验证Agent带来的业务价值。
  • AI时代的创新在于重组：最好的创新并非从零建造，而是将已有的业务能力、数据和经验通过AI重新编排，创造出全新的业务体验。

待办 ​

1. 提供消息中心Skill的测试环境 ​

  • 齐猛 会后将本次分享的详细资料和在线体验链接同步至开放平台，方便其他同学尝试使用消息中心的Skill。

2. MCP能力开放 ​

  • 齐猛 团队已完成60+个MCP工具的开发，后续将逐步进行稳定性验证并对外开放，欢迎共建。

其他工作 ​

ITSM AI 助手测试 (续) ​

今天继续给 ITSM 测试 AI 助手，主要测试内容与昨日类似，如向助手提问 OA 显示白屏，根据助手响应进行后续对话，最后强调问题未被解决，强制触发创建工单的动作。

与昨日不同之处：重点关注每一次对话的响应，对整个过程进行详细记录，以供系统团队进行优化。

本次会议介绍了企业级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管理机制等相关文档。刘阳