2026-06-08｜埋点数据查询与借测订单需求梳理

一、今日主要工作#

根据业务侧对 AI 智能助手埋点数据的提取需求，围绕埋点事件表、反馈表、供应风险预警表和用户角色表编写并调整 SQL 查询语句。
梳理三类角色相关的监控指标，包括销售人员、供应链交付组、合同履行经理管理等不同视角下的模块访问、转人工、供应风险和人工协助反馈数据。
在 SQL 编写过程中排查并修正假表名、跨库关联键错误、数据库环境差异、跨库 JOIN 排序规则冲突、模块英文名映射、部门层级字段选择、处理人员 ID 推导等问题。
形成最终版埋点查询 SQL，共覆盖 11 个需求模块，并额外整理人工协助反馈全字段明细查询。
下午围绕”借测订单查询”需求，梳理智能交付助手后续需要从资产管理平台获取的关键字段和取数逻辑。
明确借测订单查询入口、订单号格式、联想输入提示、核心展示字段和已发货明细字段，为后续与资产管理平台所属 IT 部门协商定制接口做准备。

二、核心完成内容#

1. 数据埋点查询 SQL 梳理与实现#

今天业务侧需要提取 AI 智能助手相关埋点数据，因此主要围绕 gong-agent 项目中的埋点表和业务统计表编写 SQL 查询语句。

本次查询需求不是单表查询，而是需要结合多个真实业务表，覆盖模块访问、转人工、订单关注、供应风险预警、人工反馈、角色权限和用户部门等多个维度。最终梳理出的核心表包括：

ai_instrumentation_event：埋点事件主表，用于记录 MODULE_ACCESS、TO_HUMAN_ESCALATION、ORDER_FOLLOW 等事件；
portal_chat_feedback：对话反馈表，其中 DISLIKE 类型可作为人工协助诉求来源；
portal_supply_risk_alert：供应风险预警主表；
portal_supply_risk_notification：供应风险预警推送和已读记录；
portal_supply_risk_feedback：供应风险预警销售反馈；
portal_role、portal_user_role：角色与用户关联表；
portal_skill_def：技能 / 模块主数据，用于模块英文编码到中文名称的映射；
sys_user：用户主数据，用于补充姓名、工号、部门层级等信息；
order_product、sfsys_parameter：订单产品行状态相关数据。

2. 真实表结构与关联关系确认#

今天 SQL 编写过程中首先遇到的问题是：初版查询中存在一些假表名。为了解决这个问题，在项目中检索 SQL DDL 文件、MyBatis 实体类和 @TableName 注解，逐步确认了真实的数据来源。

最终确认的关键关联关系包括：

ai_instrumentation_event.employee_id 对应 sys_user.code；
portal_chat_feedback.sys_user_id 对应 sys_user.user_id；
portal_supply_risk_alert.publisher_sys_user_id 对应 sys_user.user_id；
portal_supply_risk_notification.recipient_sys_user_id 对应 sys_user.user_id；
portal_supply_risk_feedback.submitter_sys_user_id 对应 sys_user.user_id；
portal_user_role.sys_user_id 对应 sys_user.user_id。

3. 人工协助反馈查询字段梳理#

今天重点完善了人工协助反馈的明细查询，覆盖字段包括：上级部门、所属部门、人员 ID、模块来源、转人工时间、诉求内容、处理人员 ID、诉求查看时间、闭环时间、处理状态。

处理人员 ID 的获取经历调整：最初考虑使用 portal_feedback_dept_liability 部门到履行经理的手动映射表，但该表依赖人工维护，覆盖不完整。后续改为通过同部门用户 + portal_user_role.role_code='manager' 自动推导合同履行经理。为避免一个部门存在多个 manager 导致反馈行重复，最终采用标量子查询 + LIMIT 1。

4. SQL 编写过程中的问题排查#

关联键错误：埋点表中的 employee_id 实际是工号，应关联 sys_user.code，而非 sys_user.user_id
订单关注事件无数据：ORDER_FOLLOW / ORDER_UNFOLLOW 前端埋点尚未上线，临时改用 module_code='order-delivery-ui' 访问记录
数据库环境差异：dev 环境库名不同，补充了环境差异注释
跨库 JOIN 排序规则冲突：采用 CONVERT(xxx USING utf8mb4) 统一编码
模块名可读性：通过关联 portal_skill_def 将编码映射为中文名称
部门层级口径：调整为 dept_second_name 和 dept_third_name

5. 最终埋点 SQL 产出#

最终形成了埋点查询 SQL，覆盖 11 个需求模块。同时沉淀了当前已知 Gap：订单关注事件暂无数据、经理查看详情页未写入查看时间、当前无 resolved_by 字段等，作为后续优化依据。

6. 借测订单查询需求梳理#

下午主要围绕智能交付助手中的借测订单查询需求进行接口字段梳理。借测订单号可能以 T 或 S 开头，需要支持联想结果选择。梳理的核心字段包括：最终客户、使用人、发运集、产品名称、总数量、已备数量、已发数量、预计发货时间、SN、快递单号、快递详细信息等。

7. 后续跨部门接口协商准备#

明确了智能交付助手借测订单查询模块对资产管理平台的数据依赖，后续需要协商：是否已有可复用接口、是否支持联想查询、请求参数和分页策略、是否需要定制轻量查询接口等。

三、今日工作产出#

完成业务侧埋点数据查询需求的 SQL 梳理与调整
确认埋点相关真实表结构和多类跨表关联关系
完成人工协助反馈明细查询字段设计
解决假表名、关联键错误、数据库环境差异、跨库排序规则冲突、模块名映射、部门层级口径等问题
形成最终埋点查询 SQL，覆盖 11 个需求模块
沉淀《数据埋点查询语句 — 过程记录》
完成借测订单查询需求的字段梳理
明确借测订单号输入形式和前端提示要求
梳理后续与资产管理平台沟通定制接口的问题清单

四、遇到的问题与解决情况#

1. 初版 SQL 使用了不存在的表名#

问题：按照需求语义编写了假表名，无法在项目库中执行
处理：通过项目 DDL、实体类和 @TableName 注解确认真实表结构
结果：明确 ai_instrumentation_event 是核心埋点表

2. 用户关联字段口径不一致#

问题：部分表存工号，部分表存系统用户 ID，统一关联 sys_user.user_id 会导致用户信息为空
处理：逐表梳理关联关系，区分 sys_user.code 和 sys_user.user_id
结果：用户姓名、工号、部门等字段正常补充

3. 订单关注事件暂无数据#

问题：ORDER_FOLLOW 和 ORDER_UNFOLLOW 事件当前没有实际数据
处理：临时使用 module_code='order-delivery-ui' 的访问记录
结果：在事件尚未上线前仍能提供可用的访问统计口径

4. 跨库 JOIN 出现排序规则冲突#

问题：pangugong.sys_user 与 zhineng_ai 表跨库比较出现 collation 冲突
处理：使用 CONVERT(xxx USING utf8mb4) 统一编码
结果：跨库 JOIN 能够正常执行

5. 处理人员 ID 查询导致重复行#

问题：一个部门可能存在多个 manager，直接 LEFT JOIN 导致反馈记录翻倍
处理：改用标量子查询 + LIMIT 1
结果：避免笛卡尔积，保证输入输出行数一致

6. 借测订单字段来源依赖外部平台#

问题：借测订单查询字段需要从资产管理平台获取
处理：先梳理字段清单作为后续接口协商材料
结果：明确了外部 IT 部门的沟通范围

五、明日计划#

将最终埋点查询 SQL 提交业务侧核对，确认字段口径和指标解释
根据业务反馈继续调整 SQL 输出字段、筛选条件和角色过滤逻辑
跟进订单关注埋点事件未上线问题
与资产管理平台 IT 部门沟通借测订单查询接口
根据接口协商结果推进借测订单查询模块技术方案

六、总结#

今日主要围绕两个方向展开工作：一是根据业务侧要求整理 AI 智能助手埋点数据查询 SQL，从真实表结构、跨库关联、角色口径、部门层级和处理人员推导等多个维度进行了反复调整，最终形成了覆盖 11 个需求模块的查询脚本。二是梳理借测订单查询模块的数据来源和字段需求，明确了后续接口协商方向。