在前后端开发联调前 的提交20260223
This commit is contained in:
297
docs/prd/PRD审阅-Q&A-R2.md
Normal file
297
docs/prd/PRD审阅-Q&A-R2.md
Normal file
@@ -0,0 +1,297 @@
|
||||
# PRD 审阅 Q&A — 第二轮
|
||||
|
||||
> 基于第一轮 Q&A 回答中的新信息，进一步澄清和细化。
|
||||
> 请对每个 Q 填写 A，完成后进入数据依赖矩阵和 SPEC 任务拆分阶段。
|
||||
|
||||
---
|
||||
|
||||
## 一、任务系统深化（基于 Q1.1 回答）
|
||||
|
||||
### Q2.1 任务生成器的"跳过 vs 更新"逻辑
|
||||
|
||||
你说"客户-助教-类型相同则跳过，不同则更新"。这里有几个边界需要确认：
|
||||
|
||||
- Q2.1a：如果类型相同但优先级变了怎么办？例如昨天是"优先召回"（max(WBI,NCI)=6），今天指数涨到 8 变成"高优先召回"。类型都是"召回"，但优先级不同。这种情况是跳过还是更新？
|
||||
- Q2.1b："更新"是指修改原任务记录（保留原 ID，更新类型和时间），还是关闭旧任务、创建新任务？这影响任务历史追溯。
|
||||
- Q2.1c：任务类型的完整枚举是什么？根据 PRD 我整理出以下类型，请确认是否完整：
|
||||
1. 高优先召回（max(WBI,NCI) > 7）
|
||||
2. 优先召回（max(WBI,NCI) > 5）
|
||||
3. 客户回访（完成召回后未备注）
|
||||
4. 关系构建（RS < 6）
|
||||
5. 还有其他类型吗？比如"新客欢迎"、"充值未回访"是否作为独立任务类型？
|
||||
|
||||
**A：例如昨天是"优先召回"（max(WBI,NCI)=6），今天指数涨到 8 变成"高优先召回"，这是2个类型的任务。任务类型有4种："高优先召回""优先召回""客户回访""关系构建"。
|
||||
"更新"是指关闭旧任务、创建新任务。
|
||||
你列全了，就4个条件，优先级从上往下。没有其他任务类型。
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q2.2 回访任务 48 小时滞留机制
|
||||
|
||||
你说"回访类任务需要至少滞留 48 小时"。需要明确：
|
||||
|
||||
- Q2.2a：48 小时是从任务生成时间算起，还是从任务最后一次更新时间算起？
|
||||
- Q2.2b：48 小时内如果任务生成器计算出该客户不再需要回访（比如指数变化），是保留任务不动，还是标记为"待过期"？
|
||||
- Q2.2c：48 小时到期后，如果助教仍未完成回访，任务是自动消失还是降级为其他类型？
|
||||
|
||||
**A：
|
||||
48小时是从任务生成时间算起。
|
||||
我认为，还要加一个机制，对每条产生的任务，有个状态，和有效期（有效期默认为空）。
|
||||
比如，48小时内如果任务生成器计算出该客户不再需要回访（比如指数变化）的情况。先将此任务的有效期填充为任务生成时间+48小时。标记状态为"有效"。
|
||||
每小时会有数据轮询更新（使用系统管理后台控制），轮询到超过48小时的任务，则标记状态为"无效"。
|
||||
新的回访任务会顶替老的回访任务。
|
||||
|
||||
其他可能性：
|
||||
A:优先召回，变更为高优先召回：直接新建一个任务，原优先召回的任务标记无效，有效期始终为空。
|
||||
B:回访任务，5小时变更为高优先召回，24小时后又变回回访任务：5小时时新建一个任务，原回访任务标记为有效，增加有效期。24小时后，发现存在一个有效的回访任务且有有效期，则将原回访任务标记为无效，新建一个新的有效状态的回访任务。
|
||||
|
||||
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q2.3 任务完成的数据时效问题
|
||||
|
||||
你在 Q1.8 中提到了一个关键场景：助教完成召回任务后顺手做了备注，但系统还不知道召回已完成。需要进一步明确：
|
||||
|
||||
- Q2.3a："系统还不知道"是因为 ETL 数据延迟（上游 API 数据还没同步到 DWD），对吗？这个延迟通常是多久？
|
||||
- Q2.3b：数据回溯机制的触发时机是什么？是每次任务生成器运行时检查，还是有独立的回溯任务？
|
||||
- Q2.3c：回溯后，原来的"普通备注"需要重新走 AI 应用 6 的含金量评分吗？
|
||||
|
||||
**A：是的，是因为 ETL 数据延迟（上游 API 数据还没同步到 DWD），通常延迟24小时内。数据回溯机制的触发时机是完成了召回认为时，进行回溯查看召回服务结束后（服务结束时间）有无新的备注，判断是否完成了一个回访任务。回溯后，原来的"普通备注"变为"回访备注"，走AI应用含金量评分。**
|
||||
|
||||
---
|
||||
|
||||
## 二、用户系统与租户管理（基于 Q1.7 回答）
|
||||
|
||||
### Q2.4 球房 ID 与 site_id 的映射
|
||||
|
||||
你说球房 ID 是"2 字母 + 3 数字"的业务代号，和 site_id 一一对应。
|
||||
|
||||
- Q2.4a：这个映射关系存在哪里？是需要新建一张映射表（如 `site_code_mapping`），还是在现有的某个表上加字段？
|
||||
- Q2.4b：球房 ID 是谁来创建和维护的？系统管理员在系统管理后台创建租户/站点时指定？
|
||||
- Q2.4c：如果用户输入了一个不存在的球房 ID，申请流程怎么处理？直接拒绝还是允许提交但标记为"待确认"？
|
||||
|
||||
**A：在系统管路后台进行管理，需要建立映射表。申请流程不是自动的，申请的用户可能填入任何字符，任何信息，最终还是由租户管理员进行审核通过，并关联球房里的助教或员工，当然也支持不关联，直接给身份。所以，如果用户输入了一个不存在的球房 ID，对流程无任何影响，仅在租户的管理后台关联信息处显示“没有找到关联信息”的提示即可。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.5 租户管理后台的定位
|
||||
|
||||
你提到"租户管理后台还未建设"，且功能为：用户审核/用户管理/Excel 上传。需要确认：
|
||||
|
||||
- Q2.5a：租户管理后台是独立的 Web 应用，还是集成到现有的 `apps/admin-web/`（系统管理后台）中作为一个模块？
|
||||
- Q2.5b：租户管理后台的登录方式是什么？你说"单独指定用户名密码"，这是每个店铺一套凭据，还是每个管理员一个账号？
|
||||
- Q2.5c：租户管理后台和系统管理后台的权限边界是什么？系统管理后台能看所有店铺，租户管理后台只能看自己店铺？
|
||||
|
||||
**A：apps/admin-web/和租户管理后台完全是两套应用。
|
||||
租户管理后台是独立的 Web 应用。
|
||||
租户管理后台的登录方式是独立的入口。单独指定用户名密码是指每个租户有一套凭据，一个租户有若干管理员，每个管理员一个账号。
|
||||
租户管理后台和系统管理后台的权限边界是：系统管理后台能看所有店铺，并监控管理所有连接器整个ETL系统，管理所有租户的后台管理员，为系统级维护平台。租户管理后台是开放给租户管理员的，则只能查看管理自己店铺。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.6 用户申请中的"申请身份"
|
||||
|
||||
你说申请表单有"申请身份"字段。
|
||||
|
||||
- Q2.6a：这个"身份"是自由文本输入，还是从预定义列表中选择？如果是列表，有哪些选项？（助教、前台、店长、管理员？）
|
||||
- Q2.6b：申请的身份和审核后实际分配的身份可以不同吗？（比如申请"助教"但管理员审核时改为"前台"）
|
||||
- Q2.6c：一个用户可以同时属于多个店铺吗？（比如连锁店的区域经理）
|
||||
|
||||
**A："身份"是自由输入的文本。仅为申请时文本，审核时需要管理员指定权限管理体系里的身份。一个用户可以同时属于多个店铺，这里有重要补充，租户和店铺是2个概念。比如租户下有连锁店铺。所以在权限管理里，存在租户级的管理员和店铺级的管理员。由租户级管理员进行管理。**
|
||||
|
||||
---
|
||||
|
||||
## 三、Excel 上传细化（基于 Q1.10 回答）
|
||||
|
||||
### Q2.7 Excel 模板与冲突处理
|
||||
|
||||
- Q2.7a：三种 Excel 类型（财务支出、团购收入、助教工资调整）的模板，是否需要我来设计表头结构？还是你已有模板？
|
||||
- Q2.7b：你说"发现主键冲突的进行提示，类似 IDE 的 diff 确认交互"。这个 diff 交互是在前端实现（上传后立即展示冲突），还是后端先存为"待确认"状态，管理员再逐条处理？
|
||||
- Q2.7c：财务支出的维度列表（房租、水电、物业等）是固定的还是可扩展的？如果管理员想加一个新的支出类别怎么办？
|
||||
|
||||
**A：还有一个表要补充，充值业绩归属表，每行将记录充值的日期，会员名称，金额，分配给哪个助教，记多少奖励金额。
|
||||
共4种模版，你来帮我设计表头结构，注意使用中文，设计好后，我来校对。 diff 交互是在前端实现。确认每个替换或保留项目，然后以保存为准进行修改。财务支出的维度列表（房租、水电、物业等）是固定的，若想扩展需要代码级改动，还需要更新小程序UI。
|
||||
再补充下前文，第一轮QA，助教的奖罚，在一个助教，一个月的周期内，可以存在多笔奖罚。
|
||||
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q2.8 助教工资调整的数据流
|
||||
|
||||
- Q2.8a：Excel 上传的扣款/奖金数据，最终写入哪里？是写入 `dws_assistant_salary_calc` 表的某些字段，还是新建一张调整表？
|
||||
- Q2.8b：助教姓名+编号的匹配逻辑是什么？如果 Excel 中的姓名/编号和 ETL 中的 `dim_assistant` 不匹配怎么处理？
|
||||
- Q2.8c：扣款/奖金是否影响定档业绩？还是只影响最终工资金额？
|
||||
|
||||
**A：是写入 `dws_assistant_salary_calc` 表的某些字段，还是新建一张调整表？这个你来分析，看最科学合理的做法。如果 Excel 中的姓名/编号和 ETL 中的 `dim_assistant` 不匹配，在上传时就会校验提醒。扣款/奖金只影响最终工资金额，不影响定档业绩。**
|
||||
|
||||
---
|
||||
|
||||
## 四、定档折算惩罚细化（基于 Q2.6 回答）
|
||||
|
||||
### Q2.9 惩罚规则的数据实现
|
||||
|
||||
你给出了非常详细的惩罚规则，我需要确认几个实现细节：
|
||||
|
||||
- Q2.9a：规则 1（禁止团购自开台挂本人专业课）的检测逻辑：系统如何判断"是助教自己开的台"？是通过订单中的会员 ID = 助教关联的会员 ID 来判断，还是需要其他标识？
|
||||
- Q2.9b：规则 2（同一时间最多 2 名助教挂台）的"同一时间"如何定义？是课程时间段有重叠即算，还是完全相同的开始/结束时间？
|
||||
- Q2.9c：豁免流程在数据层面如何记录？是在订单上打一个"已豁免"标记，还是有独立的豁免审批记录？
|
||||
- Q2.9d：惩罚计算是在 ETL 的 DWS 层自动完成，还是需要人工触发？计算频率是每日还是每月？
|
||||
|
||||
**A：规则1 实际上忽略吧，靠日常运营，前台来控制，系统无法监测。"同一时间"，是课程时间段有重叠即算。豁免不需要审批，在响应的表中做标记记录即可，目的是让业绩和薪酬计算正确无误。惩罚计算是在 ETL 的 DWS 层自动完成，计算频率是每日。**
|
||||
|
||||
---
|
||||
|
||||
## 五、AI 应用细化
|
||||
|
||||
### Q2.10 AI 应用的调用架构
|
||||
|
||||
- Q2.10a：6 个 AI 应用都是阿里云百炼的独立应用（各有自己的 app_id），对吗？还是共用一个应用通过 prompt 区分？
|
||||
- Q2.10b：AI 应用 1（通用对话）需要做信息隔离。这个隔离是在 prompt 层面控制（只传入该用户有权看到的数据），还是在百炼平台侧配置？
|
||||
- Q2.10c：AI 的流式返回，前端是通过 SSE（Server-Sent Events）还是 WebSocket 实现？后端是直接透传百炼的流式响应，还是有中间缓存？
|
||||
|
||||
**A：6 个 AI 应用都是阿里云百炼的独立应用，每个应用都有独立的app_id。AI 应用 1（通用对话）需要做信息隔离，这个隔离是通过传参数给AI 应用实现的。参数有3个 身份（助教/管理者）、昵称 和 ID。然后百炼平台侧根据参数进行数据查询的隔离。AI 的流式返回所有信息，需要你在web上查文档获得**
|
||||
|
||||
---
|
||||
|
||||
### Q2.11 AI 对话入口梳理
|
||||
|
||||
PRD 中提到多个页面有 AI 入口，我整理如下，请确认是否完整：
|
||||
|
||||
| 入口页面 | 触发方式 | 使用的 AI 应用 | 传入上下文 |
|
||||
|---------|---------|-------------|---------|
|
||||
| task-list.html | 长按任务 → "问问AI助手" | 应用 4 + 应用 5 | 任务详情 + 客户-助教关系数据 |
|
||||
| task-detail.html | 页面内 AI 按钮 | 应用 4 + 应用 5 | 任务详情 + 客户-助教关系数据 |
|
||||
| board-finance.html | 页面内"问问助手" | 应用 2 | 当前筛选条件下的财务数据 |
|
||||
| customer-detail.html | 页面内 AI 按钮 | 应用 3 | 客户全信息 |
|
||||
| chat.html | 直接对话 | 应用 1 | 来源页面上下文 |
|
||||
| performance.html | 有 AI 入口吗？ | ？ | ？ |
|
||||
| board-customer.html | 有 AI 入口吗？ | ？ | ？ |
|
||||
| board-coach.html | 有 AI 入口吗？ | ？ | ？ |
|
||||
|
||||
- Q2.11a：上表是否正确？有遗漏或错误吗？
|
||||
- Q2.11b：应用 6（备注含金量判断）是系统自动调用的（提交备注时后台触发），不需要用户手动触发，对吗？
|
||||
- Q2.11c：从非 chat.html 页面跳转到 chat.html 时，是新开一个对话，还是可以继续之前的对话？
|
||||
|
||||
**A：更新：
|
||||
|
||||
| 入口页面 | 触发方式 | 使用的 AI 应用 | 传入上下文 |
|
||||
|---------|---------|-------------|---------|
|
||||
| task-list.html | 长按任务 → "问问AI助手" | 应用 1 | 任务详情 + 客户-助教关系数据 |
|
||||
| board-coach.html；board-customer.html；board-finance.html ；customer-service-records.html；my-profile.html；performance-records.html；performance.html；task-list.html | 右下角AI 按钮 | 应用 1 | 页面内容 |
|
||||
| task-detail.html；coach-detail.html；customer-detail.html | 页面内"问问助手" | 应用 1 | 页面内容 |
|
||||
|
||||
通过以上入口，进入chat.html，新开一个对话，第一条信息就是传入的上下文内容。
|
||||
|
||||
|
||||
用于页面信息更新的：
|
||||
|
||||
| 页面-内容 | 触发方式 | 使用的 AI 应用 | 传入上下文 |
|
||||
|---------|---------|-------------|---------|
|
||||
| board-finance.html - 交叉筛选条件 各结果 AI 智能洞察 | 建立轮询任务，最小间隔：每日更新 | 应用 2 | 页面查询结果原始数据 与 环比数据 |
|
||||
| customer-detail.html - 消费习惯 ， task-detail.html - 消费习惯 | 建立轮询任务：当发现当前客户有新增消费结算时更新 | 应用 3 | 客户60天订单详情（***这里需要整理订单信息详情，你需要做一个文档，整理DWD层暂时只用feiqiu的连接器的DWD***），客户应该到店日期，当前与上次到店的间隔日期。 |
|
||||
| task-detail.html - 客户和我的关系分析、任务建议、一句话总结、我的关系情况总结。 | 建立轮询任务：当发现当前客户有新增消费，且发生了当前助教参与的结算时，进行更新。 | 应用 4 | 客户与我的关系相关60天订单详情（***同应用3的一样，只不过要筛选出与当前助教有关的订单***），客户应该到店日期，当前与上次到店的间隔日期，该助教对此客户的全部备注列表。 |
|
||||
| task-detail.html - 5条话术参考 | 建立轮询任务：应用4调用时。 | 应用 5 | 应用4上传的内容以及应用4返回的内容。 |
|
||||
| task-detail.html - 备注星级 | 建立轮询任务：当完成回访任务时。| 应用 6 | 触发回访任务的备注；本客户的全部信息（客户详情页内容）；所有助教对本客户的全部备注。 |
|
||||
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
## 六、页面与数据细节
|
||||
|
||||
### Q2.12 board-customer.html 的"最大消费潜力"
|
||||
|
||||
你在 PRD 中写"通过统计注册用户日期、最近30天充值与金额、最近30/10天消费金额总和、最近30天消费频率变化，分析出每个客户的消费潜力"。
|
||||
|
||||
- Q2.12a：这个"消费潜力"和新增的 SPI（消费力指数）是什么关系？SPI 已经涵盖了消费水平、消费速度、消费稳定性。是否可以直接用 SPI 替代这个"最大消费潜力"排序维度？
|
||||
- Q2.12b：如果不用 SPI 替代，这个"消费潜力"需要单独建模还是用简单的加权公式？
|
||||
|
||||
**A：SPI 就是"消费潜力"，可以用此维度进行排序**
|
||||
|
||||
---
|
||||
|
||||
### Q2.13 绩效计算中的"到达 XXX 即得 YYY"
|
||||
|
||||
PRD 中的跳档激励计算示例我理解了，但需要确认：
|
||||
|
||||
- Q2.13a：跳档线的时长阈值（Tier0→1: 120h, Tier1→2: 150h, Tier2→3: 180h, Tier3→4: 210h）是固定值还是可配置的？存在哪里？
|
||||
- Q2.13b：打赏课的激励系数（如 0.5-0.4=0.1, 0.4-0.35=0.05）是什么含义？是不同档位的打赏课提成比例差？
|
||||
- Q2.13c：这个"到达即得"的展示，是实时计算的（每次打开页面都重新算），还是基于 DWS 预计算的快照？
|
||||
|
||||
**A：跳档线阈值存在DWS里啊，你去数据库里找找。打赏课的激励系数做减法，是不同档位的打赏课提成比例变化的差值。这个应该是快照，当发现有新的助教服务记录时，计算并落到快照**
|
||||
|
||||
---
|
||||
|
||||
### Q2.14 customer-detail.html 的消费记录展示
|
||||
|
||||
PRD 中区分了"台桌结账"和"商城订单"两种样式。
|
||||
|
||||
- Q2.14a：除了这两种 settle_type，还有其他类型吗？（比如充值、退款、团购核销等）这些类型在消费记录中如何展示？
|
||||
- Q2.14b："正价金额，（若有团购，或折扣，展示实付金额）"——这里的正价金额从哪个字段取？是 `original_amount` 还是 `total_amount`？
|
||||
- Q2.14c：消费记录的时间范围是多少？展示全部历史还是最近 N 天？
|
||||
|
||||
**A：充值需要加入，但我不确定，你要在数据库里寻找下，能否区分"台桌结账"，"商城订单"和"充值"，退款先不用管，团购核销会集成在"台桌结账"中。对于正价金额，我在财务看版设计时，好像一些文档那个中有规定，查询下文档和数据库DWS相关的内容，确定是哪个字段，这个一定要我复核！。customer-detail.html默认显示最近10条，拉到底再懒加载，一次10条。**
|
||||
|
||||
---
|
||||
|
||||
## 七、数据架构确认
|
||||
|
||||
### Q2.15 小程序数据库 Schema 规划
|
||||
|
||||
你确认了小程序的所有表都还没建。在我开始设计之前，需要确认几个架构方向：
|
||||
|
||||
- Q2.15a：`test_zqyy_app` 中的表是全部放在 `public` schema，还是按功能分 schema（如 `auth`、`biz`、`notes`）？
|
||||
- Q2.15b：小程序的业务表（任务、备注、AI 对话等）和现有的 RBAC 表（users、roles、permissions 等）是否在同一个 schema？
|
||||
- Q2.15c：FDW 外部表统一放在 `fdw_etl` schema，这个不变对吧？
|
||||
|
||||
**A：按功能分 schema更合理吧。业务表和用户表应该不在同一个schema。fdw机制不变。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.16 数据新鲜度与缓存策略
|
||||
|
||||
小程序的很多页面依赖 ETL 数据（通过 FDW 读取），ETL 数据的更新频率会影响用户体验。
|
||||
|
||||
- Q2.16a：ETL 的全量刷新频率是多少？每天一次？多次？
|
||||
- Q2.16b：对于实时性要求较高的数据（如任务完成状态、备注），是否需要绕过 ETL 直接从上游 API 获取？
|
||||
- Q2.16c：看板页面（finance/customer/coach）的数据是否需要缓存层？还是每次都实时查询 FDW？
|
||||
|
||||
**A：上线后，ETL 不会全量刷新，仅会间隔1小时，全量刷新最近2小时的数据。不要直接绕过API。看板页面我希望能有缓存层。**
|
||||
|
||||
---
|
||||
|
||||
## 八、遗留操作项确认
|
||||
|
||||
### Q2.17 API Key 迁移
|
||||
|
||||
第一轮 Q4.4 你同意将 API Key 移到 `.env`。确认以下操作：
|
||||
|
||||
- 将 `sk-6def29cab3474cc797e52b82a46a5dba` 添加到 `.env` 中，变量名建议 `BAILIAN_API_KEY`
|
||||
- 将 `541edb3d5fcd4c18b13cbad81bb5fb9d` 添加到 `.env` 中，变量名建议 `BAILIAN_TEST_APP_ID`
|
||||
- 从 PRD 文档中移除这两个值，替换为变量名引用
|
||||
- 同步更新 `.env.template`
|
||||
|
||||
- Q2.17：变量名是否同意？还是你有其他命名偏好？
|
||||
|
||||
**A：同意！**
|
||||
|
||||
---
|
||||
|
||||
### Q2.18 PRD 文档合并
|
||||
|
||||
第一轮 Q1.4 你确认 board-finance.html 两段需要合并。
|
||||
|
||||
- Q2.18：这个合并操作是否等全部 Q&A 完成后，在最终修订 PRD 时一并处理？
|
||||
|
||||
**A：**
|
||||
|
||||
|
||||
|
||||
|
||||
## 补充
|
||||
本次补充的内容中，以及第一轮QA涉及到很多条件触发，可以考虑为这些条件触发的，单独做一个触发器机制。
|
||||
---
|
||||
488
docs/prd/PRD审阅-Q&A.md
Normal file
488
docs/prd/PRD审阅-Q&A.md
Normal file
@@ -0,0 +1,488 @@
|
||||
# PRD 审阅 Q&A
|
||||
|
||||
> 基于 `docs/prd/小程序前后端.txt` 的系统性审阅。
|
||||
> 请对每个 Q 填写 A，完成后我们据此修订 PRD。
|
||||
|
||||
---
|
||||
|
||||
## 一、表达不清楚 / 需要补充的部分
|
||||
|
||||
### Q1.1 任务系统的核心定义
|
||||
|
||||
任务系统是整个小程序的核心，但文档缺少对"任务"概念的正式定义。需要你明确：
|
||||
|
||||
- Q1.1a：任务是系统每天自动生成的（如每日凌晨根据指数重新计算），还是有一个持久化的任务池（一旦生成就一直存在直到完成/过期）？
|
||||
- Q1.1b：任务的完整生命周期是什么？（生成 → 展示 → 完成/放弃/过期？还有其他状态吗？）
|
||||
- Q1.1c：任务是否有过期机制？比如一个召回任务，客户自己来了但不是该助教服务的，算什么？
|
||||
- Q1.1d："置顶"和"放弃"是助教个人维度的操作（只影响自己看到的列表），还是全局的（其他人也能看到）？
|
||||
|
||||
**A：
|
||||
首先，任务是每天动态生成的，每天上午4点之后的第一次启动“任务生成器”时，为每个助教，分配任务。生成规则是基于指数和实时计算和若干规则的条件交叉（原文档已说明）。
|
||||
任务的唯一标识 由客户-助教-类型-生成时间构成。若“任务生成器”生成了一个任务，则读取已存在的 生成时间最晚的 客户-助教-类型 相同的任务进行对比，若客户-助教-类型相同，则跳过，不同则更新任务。这样进行任务更新是否合理？既保证了任务的变更，又可以对持续的任务进行延续。
|
||||
|
||||
举例：客户A之于助教甲，第一天“任务生成器”返回“回访”任务，第二天返回“优先召回”任务。第一天的任务就被覆盖掉了。任务更新，记录时间。
|
||||
若第二天返回“回访”，则最大序号的 客户-助教-类型 任务相同，不做更新。保留任务生成时间。
|
||||
注意，“回访”类任务需要至少滞留48小时。这个看如何科学合理的实现。
|
||||
**
|
||||
---
|
||||
|
||||
### Q1.2 消费指数的定义
|
||||
|
||||
"新增指数"部分提到"增加一个消费指数，依据：消费能力，消费频率，消费趋势，全部会员卡储值额度"，但没有给出算法框架或权重思路。现有的 NCI/WBI 都有详细的分项说明。
|
||||
|
||||
- Q1.2a：这个新消费指数需要达到和 NCI/WBI 同等级别的算法定义吗？还是先给出大致权重方向，实现时再调？
|
||||
- Q1.2b：它和 `dws_member_consumption_summary` 中已有的 `customer_tier`（客户分层）是什么关系？是替代还是补充？
|
||||
|
||||
**A：见文档 docs\prd\SPI 消费力指数.md。用指数替代customer_tier的作用**
|
||||
|
||||
---
|
||||
|
||||
### Q1.3 新增统计的四个指标命名
|
||||
|
||||
文档中多次写"另外，给这个统计，起一个合适的直观易懂的名字"。这些名字需要你定下来，因为它们会成为数据库字段名、API 字段名、前端展示文案的基础。
|
||||
|
||||
需要命名的四个指标：
|
||||
1. 订单流水-助教服务分成（助教参与订单总流水减去助教分成）
|
||||
2. 助教时效流水（按服务时长折算的助教贡献订单金额）
|
||||
3. 助教时效流水-助教服务分成（时效流水减去助教分成）
|
||||
4. 以上三个 + "订单流水"本身，是否需要统一的系列命名？
|
||||
|
||||
**A：你帮我定下来吧，就是个命名的工作，要求合适的直观易懂的名字。最好是统一的系列命名。**
|
||||
|
||||
---
|
||||
|
||||
### Q1.4 board-finance.html 重复
|
||||
|
||||
文档中有两段 `## board-finance.html`，内容不同但有重叠：
|
||||
- 第一段：提到 AI 接口和 DWS 数据快照优化
|
||||
- 第二段：提到筛选逻辑、预收资产板块消失规则、收入结构过滤
|
||||
|
||||
这两段是否应该合并为一段？是否有遗漏的内容？
|
||||
|
||||
**A：需要合并，可能是我疏漏了，没有放在一起**
|
||||
|
||||
---
|
||||
|
||||
### Q1.5 权限列表的完整枚举
|
||||
|
||||
你说"权限列表是固定的"，但文档只提到了部分权限。请完整列出所有权限项，例如：
|
||||
|
||||
- 任务板块可见
|
||||
- 看版板块可见
|
||||
- 看版-财务板块可见
|
||||
- 看版-客户板块可见
|
||||
- 看版-助教板块可见
|
||||
- （还有其他的吗？比如：备注管理、AI 对话、绩效查看、Excel 上传等？）
|
||||
|
||||
**A：其他权限都是通用的了。直接从入口卡死即可。Excel 上传是每个店的WEB管理端，单独指定用户名密码。**
|
||||
|
||||
---
|
||||
|
||||
### Q1.6 users 表和申请审核流程
|
||||
|
||||
数据库中 `users` 表没有申请状态字段，LAUNCH-CHECKLIST 中提到需要建 `user_application` 表但还没建。
|
||||
|
||||
- Q1.6a：`users` 表是审核通过后才创建记录，还是申请时就创建（用 status 字段区分状态）？
|
||||
- Q1.6b：`users` 表目前没有 `avatar_url` 字段，小程序是否需要展示用户头像？如果需要，头像从哪来（微信授权 or 自行上传）？
|
||||
|
||||
**A：这引出了一个很大的话题，小程序的用户系统还未搭建。需要你帮我策划，我现在可以给到的信息：申请时就要创建用户，用 status 字段区分状态；头像通过微信授权获取，暂不支持自行上传，暂时没有必要。**
|
||||
|
||||
---
|
||||
|
||||
### Q1.7 助教和小程序用户的映射
|
||||
|
||||
ETL 中的助教是 `dwd.dim_assistant`（来自上游飞球 SaaS），小程序用户是 `zqyy_app.users`。
|
||||
|
||||
- Q1.7a：一个助教登录小程序后，系统怎么知道他对应 ETL 中的哪个 `assistant_id`？是通过手机号匹配、管理员手动绑定、还是其他方式？
|
||||
- Q1.7b：同理，小程序中的"客户"（member）和 ETL 中的 `dim_member` 是通过什么关联的？客户是否也需要登录小程序？
|
||||
|
||||
**A：这里我需要更改一些信息表单。
|
||||
申请时，需要先验证微信号登录。并填写表单（由一个文本框，改为若干字段）：球房ID、申请身份、手机号、编号、昵称。
|
||||
球房ID：输入框，必填。区别于SiteID，这里的球房ID更偏向于业务侧使用。是一组简单的，由2个字母+3个数字组成的球房代号。和SiteID一一对应。
|
||||
申请身份：输入框，必填。
|
||||
手机号：点击调用微信已记录的用户手机号进行填入。
|
||||
编号：收入框，选填。
|
||||
昵称：收入框，必填。
|
||||
|
||||
申请后，在租户的管理后台（还未建设），新增用户管理页面。其中列出用户列表，可以筛选不同状态的用户。在未审核列表中，管理员可以看到申请信息。系统通过球房ID + 手机号，提示词申请用户与当前助教或员工的对应关系，方便管理员审核。
|
||||
|
||||
注意!客户不用小程序，小程序的用户群体仅为球房管理人员，助教等球房工作人员。是一个TOB的垂直小程序。
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q1.8 备注系统的数据模型
|
||||
|
||||
文档多处提到"备注"（客户备注、放弃任务备注、回访备注），但没有定义备注表的结构。
|
||||
|
||||
- Q1.8a：备注存在哪个库？`zqyy_app` 还是 ETL 库？
|
||||
- Q1.8b：是否需要区分备注类型（普通备注 vs 生日信息 vs 回访备注 vs 放弃任务原因）？还是统一一张表用 `type` 字段区分？
|
||||
- Q1.8c：备注是否支持富文本/图片，还是纯文本？
|
||||
|
||||
**A：对的，小程序的所有数据库，所有Schema，所有表均没有建立。需要完善所有小程序功能需求文档后，你来帮我做数据库的架构和后端服务架构，接口等内容的规划，并一步步完成小程序前后端的开发。
|
||||
|
||||
备注是登录的用户对客户/助教的备注行为，我认为在test_zqyy_app更合理
|
||||
我建议用一张表，type字段区分即可。其中，回访备注，普通备注，生日信息都是通过一个操作口径进行的，使用其他条件进行隔离：
|
||||
回访备注：“回访”类型任务中，添加备注，即为回访备注。走AI含金量判断的流程。完成备注后，即标记此任务完成。这里有个特殊情况需要处理，若某助教完成了召回的任务，顺手做了备注。因为数据不及时的问题，系统还不知道完成了召回认为，此条备注被当做了普通备注。这种情况要单独处理。当发现某助教完成了召回任务，任务应改变为用户回访，但助教也完成了回访（在召回任务数据到达之前），则应标记再次完成回访任务，完成召回任务后的第一条备注当做回访任务完成的依据（走AI含金量判定等流程），然后需要再次刷新，生成任务。做一个数据回溯机制。
|
||||
备注当前是纯文本。
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q1.9 "跟"和"弃"icon 的触发条件
|
||||
|
||||
文档说"跟代表此客户出现在了该助教的任务列表中，且任务类型为高优先召回或优先召回"。
|
||||
|
||||
- Q1.9a："弃"代表什么？是该助教主动放弃了这个客户的任务？
|
||||
- Q1.9b：如果一个客户同时属于多个助教，每个助教看到的"跟/弃"状态是独立的吗？
|
||||
|
||||
**A："弃"是该助教手动放弃了此任务。每个助教与客户的关系都是独立的，任务是独立的，所以"跟/弃"状态是独立的。**
|
||||
|
||||
---
|
||||
|
||||
### Q1.10 Excel 上传的具体需求
|
||||
|
||||
文档最后提到"管理后台 - Excel数据上传"，几乎没有细节。
|
||||
|
||||
- Q1.10a：哪些 DWS 表支持 Excel 导入？目前看 `dws_ml_manual_order_alloc` 和 `dws_ml_manual_order_source` 是 Excel 导入的，还有其他的吗？
|
||||
- Q1.10b：校验规则是什么？（字段类型、必填、外键引用、金额精度？）
|
||||
- Q1.10c：导入是覆盖还是追加？主键冲突怎么处理？
|
||||
- Q1.10d：你提到"针对每个连接器下的租户（tenant 下有 site）的后端管理系统"，这个租户/站点管理的范围是什么？只是 Excel 上传的入口，还是包含租户 CRUD、站点配置等？
|
||||
|
||||
**A：
|
||||
EXCEL导入内容类型：
|
||||
财务类-支出类，按月提交：主键为支出维度：房租；水电；物业；食品饮料进货；耗材；报销；固定人员工资；其他费用；
|
||||
财务类-团购类，按月提交：逐渐为平台名称：平台-收入；
|
||||
工资类-助教工资，按月提交：主键为助教姓名+助教编号+维度（扣款/奖金）：扣款-金额-原因；奖金-金额-原因。
|
||||
每个类型，有一个Excel模版。
|
||||
|
||||
校验规则：必填，金额精度，表头格式，类型合法。提交的月份+主键冲突。
|
||||
发现导入的月份+类型冲突，则默认追加，发现主键冲突的进行提示，类似IDE的diff确认交互。
|
||||
这个针对租户的后台管理系统，现在仅有很少功能：用户审核/用户管理/Excel上传.
|
||||
租户 CRUD、站点配置是通过系统管理后台操作的。
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
## 二、与项目现状的冲突
|
||||
|
||||
### Q2.1 fdw_etl schema 为空
|
||||
|
||||
`zqyy_app` 数据库中 `fdw_etl` schema 存在但没有任何表或视图。小程序后端无法读取 ETL 数据。PRD 中大量页面（task-list、board-finance、board-customer、board-coach、performance 等）都依赖 ETL 数据。
|
||||
|
||||
- Q2.1：你是否已经意识到这个问题？FDW 映射是否作为第一优先级处理？需要映射哪些表？（我可以根据 PRD 页面需求帮你整理完整的 FDW 映射清单）
|
||||
|
||||
**A：为我整理完整的FDW映射清单。注意我们在开发环境，全部使用测试库。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.2 ETL app schema 为空
|
||||
|
||||
ETL 库中的 `app` schema（设计为 RLS 视图层）也没有任何对象。
|
||||
|
||||
- Q2.2：`app` schema 的 RLS 视图是否还在计划中？还是改为在 FDW 层面做数据隔离？
|
||||
|
||||
**A：RLS和FDW两层都要做。注意我们在开发环境，全部使用测试库。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.3 tasks 表结构与 PRD 需求不匹配
|
||||
|
||||
`zqyy_app.public.tasks` 表只有通用字段（id, title, description, status, assignee_id, creator_id, site_id）。PRD 中的任务系统需要：任务类型、优先级、关联 member_id、关联 assistant_id、指数快照值、完成条件、放弃原因、置顶标记等。
|
||||
|
||||
- Q2.3：现有 `tasks` 表是为管理后台的 ETL 任务管理设计的，和小程序的助教任务是两个完全不同的概念。是否同意新建一张专用的助教任务表（如 `coach_tasks`），而不是改造现有表？
|
||||
|
||||
**A：tasks是ETL的调度任务，和小程序的助教任务完全两回事。
|
||||
如我上文所说，支撑小程序的数据库，Schema，表都还没有开始建设，根据需求文档的确定和定稿，逐一进行建立，而且要和ETL的业务进行隔离。仅必要结果通过FDW传递。注意我们在开发环境，全部使用测试库。**
|
||||
|
||||
---
|
||||
|
||||
### Q2.4 dws_member_consumption_summary 缺少字段
|
||||
|
||||
PRD 要求"30天/60天/90天内的累计充值次数/累计充值金额"和"次均消费额度"，但现有表没有这些字段。
|
||||
|
||||
- Q2.4：这些字段是在现有 `dws_member_consumption_summary` 表上扩展，还是新建一张表？
|
||||
|
||||
**A：这个的字段增补方式的决定权给你，分析一个较为科学合理的方式进行扩张或新建表。我认为那些累计的可以放一个表问题不大。但次均消费额度和其他的不一样吧？**
|
||||
|
||||
---
|
||||
|
||||
### Q2.5 助教流水统计表不存在
|
||||
|
||||
PRD 中的"订单流水"、"助教时效流水"等四个新统计指标在 DWS 中完全不存在。
|
||||
|
||||
- Q2.5：这些统计是新建一张 DWS 表（如 `dws_assistant_order_contribution`），还是扩展到现有的 `dws_assistant_customer_stats` 或 `dws_assistant_daily_detail` 中？
|
||||
|
||||
**A：新建表进行实现**
|
||||
|
||||
---
|
||||
|
||||
### Q2.6 绩效计算中的"定档折算惩罚"
|
||||
|
||||
`dws_assistant_salary_calc` 有 `effective_hours` 等字段，但 PRD 中提到的"定档折算30分钟"这种惩罚机制在表结构中没有对应字段。
|
||||
|
||||
- Q2.6：定档折算的具体规则是什么？是否需要在 salary_calc 表中增加 `penalty_minutes` 或类似字段？
|
||||
|
||||
**A：折算触发与规则如下，需要适当的进行数据库建设和后端代码计算支持：
|
||||
|
||||
业绩惩罚补充规则（定档业绩折算）：
|
||||
目的：防止助教利用低价团购/低台费订单/台费拼单等方式，低成本的“补时长、冲档位”，减少作弊空间，保障定档公平与球房收益。
|
||||
|
||||
实施方案：
|
||||
一、助教行为规范
|
||||
【规则1】禁止团购自开台挂本人专业课
|
||||
助教不得使用任何团购/低价套餐/代金券，在适用区域内进行开台/开房。并购买助教专业课，将订单用于计入助教专业课服务时长。
|
||||
适用区域：大厅（A、B、C、S、TV）和 麻将房（M1–M7）。
|
||||
【规则2】指定区域内同一时间仅允许2名助教挂台
|
||||
在指定区域内，同一订单下，同一台/房，同一时间段最多挂2名助教。
|
||||
指定区域：大厅（A、B、C、S、TV）和 麻将房（M1–M7）。
|
||||
若客人购买多人同时的专业课，则必须走“豁免流程”（见下）。
|
||||
*老客户或熟人，需要3助教及以上的，前厅引导另外开台/房。
|
||||
|
||||
二、惩罚豁免（仅针对“真实客需”）
|
||||
【豁免适用条件】
|
||||
若触发了上述 规则1或规则2，但事实为客人真实提出的服务需求（例如：客人指定三名助教同场服务；或团购客人确需助教服务等）。
|
||||
【豁免操作要求】
|
||||
客户结账时，前台需核对真实客人在场，并将订单明确绑定到该真实客人名下。若新客则需要注册新会员。*可配合新客充值优惠或其他新客福利的营销活动。
|
||||
|
||||
未按要求留存客人信息的，一律不视为豁免。按以下方式进行惩罚处理。
|
||||
|
||||
三、惩罚处理
|
||||
【核心原则】
|
||||
本规则仅影响“定档业绩时长”的统计，不影响助教当月实际服务时长的工资结算。只影响定档，不影响实际工资时长。
|
||||
举例说明：某中级助教本月实际服务基础课 140小时。
|
||||
系统按本规则折算后，定档业绩时长被扣除 15小时，则：
|
||||
定档业绩时长 = 140 − 15 = 125小时 → 归入 1档
|
||||
工资档位确定后，工资仍按实际服务时长结算：
|
||||
中级工资单价 = 108 − 18 = 90元/小时
|
||||
工资 = 140 × 90 = 12,600元
|
||||
|
||||
【核算方式】
|
||||
系统将符合处罚条件的订单，按照“每小时每名助教贡献的台费/房费流水”，并据此确定该单可计入的定档业绩时长。
|
||||
步骤：
|
||||
计算台费会房费的每小时实收单价。
|
||||
上步骤的单价 ÷ 本次基础课助教人数 记做 单人贡献流水。
|
||||
若 单人贡献流水 ≥ 24元：每位助教按照课程服务时长，按满额计入定档业绩时长（=实际时长）；
|
||||
若 单人贡献流水 ≤ 24元，该单按比例折算计入定档业绩时长，即：
|
||||
定档业绩时长 = 实际时长 × （单人贡献流水 / 24）
|
||||
|
||||
示例：
|
||||
订单：12.12元团购，A区，时长2小时，购买3个助教服务，2小时后离店，未保留客户信息，疑似助教团购拼单。每小时每名助教贡献：
|
||||
r=(12.12*2)/(2×3)=4.04"元"
|
||||
|
||||
折算系数：
|
||||
(4.04)/24=0.1683
|
||||
|
||||
定档业绩时长：
|
||||
2"小时"×0.1683=0.3367"小时"=20.2"分钟 则定档业绩记录为20分钟"
|
||||
|
||||
|
||||
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
## 三、文档内容的疑问
|
||||
|
||||
### Q3.1 订单流水计算示例数值不一致
|
||||
|
||||
文档中写"订单流水 = 200+400+600+320+100+800 = 2420元。也就是3个助教，每人+2820的订单流水"。
|
||||
|
||||
- Q3.1：2420 和 2820 不一致，正确值应该是 2420 对吧？
|
||||
|
||||
**A：对的，我写错了，不好意思。**
|
||||
|
||||
---
|
||||
|
||||
### Q3.2 客户归属的 RS 差距阈值
|
||||
|
||||
"如果多个助教对某客户的RS没有很大的差距（50%）以上，则此客户属于多个助教"。
|
||||
|
||||
- Q3.2a：50% 是指 RS 值的绝对差还是相对差？例如助教A的RS=8，助教B的RS=5，差距按什么算？
|
||||
- Q3.2b：这和 `dws_member_assistant_relation_index` 中已有的 `os_label`（MAIN/COMANAGE/POOL）机制是什么关系？OS 已经实现了类似的归属逻辑，是否直接复用 OS 而不是用 RS 差距来判断？
|
||||
|
||||
**A：50% 是指 RS 值的相对差。(8-5)/8<0.5，则2个客户都能跟踪一个客户。**
|
||||
|
||||
---
|
||||
|
||||
### Q3.3 任务优先级0的公式
|
||||
|
||||
"根据(WBI+NCI)指数展示列表。>7为高优先召回。>5为优先召回"。
|
||||
|
||||
- Q3.3：WBI 和 NCI 都是 0-10 的分数，直接相加范围是 0-20。阈值 7 和 5 是对相加后的值判断，还是取 max(WBI, NCI) 判断，还是分别判断？
|
||||
|
||||
**A：取max(WBI, NCI)进行判断**
|
||||
|
||||
---
|
||||
|
||||
### Q3.4 回访任务的"2天内备注有效"
|
||||
|
||||
"出现过客户回访后，2天内备注有效。2天内再次出现客户回访任务，则旧的回访任务被顶替"。
|
||||
|
||||
- Q3.4a："2天"是自然日还是 48 小时？
|
||||
- Q3.4b："顶替"是指旧任务自动标记为完成、取消、还是其他状态？
|
||||
|
||||
**A：48小时。"顶替"是指“任务生成器”生成了新认为，进行了顶替。**
|
||||
|
||||
---
|
||||
|
||||
### Q3.5 AI 应用6的评分阈值
|
||||
|
||||
"低于5则不算完成。高于等于5记做完成"，但后面又说"6分为标准分"。
|
||||
|
||||
- Q3.5：5 分是完成的最低线，6 分是"合格"的标准？两个阈值分别用在什么场景？
|
||||
|
||||
**A：统一使用6分为完成，几个线**
|
||||
|
||||
---
|
||||
|
||||
### Q3.6 performance.html 中"我的新客"定义
|
||||
|
||||
"首次服务过的客户在最近2月内，且服务总次数小于等于2"。
|
||||
|
||||
- Q3.6a："首次服务"是指该助教首次服务该客户，还是该客户首次到店？
|
||||
- Q3.6b："服务总次数"是该助教对该客户的服务次数，还是该客户被所有助教服务的总次数？
|
||||
|
||||
**A："首次服务"是指该助教首次服务该客户。"服务总次数"是该助教对该客户的服务次数。**
|
||||
|
||||
---
|
||||
|
||||
## 四、修改优化建议
|
||||
|
||||
### Q4.1 拆分 PRD 为多个模块文档
|
||||
|
||||
当前 PRD 是一个巨大的 txt 文件，混合了指数算法、页面需求、AI 接口、权限系统、管理后台等完全不同的领域。建议拆分为：
|
||||
- `prd/指数与算法.md` — 指数定义、计算逻辑、场景映射
|
||||
- `prd/小程序页面.md` — 每个页面的数据源、交互、权限
|
||||
- `prd/AI集成.md` — 6 个 AI 应用的输入输出定义
|
||||
- `prd/权限与用户.md` — 登录、审核、RBAC
|
||||
- `prd/管理后台扩展.md` — Excel 上传、租户管理
|
||||
|
||||
- Q4.1：你是否同意这个拆分方案？有需要调整的吗？
|
||||
|
||||
**A：对的，这个也是我所担心的。
|
||||
我的开发场景将完全基于 Kiro推进。请按以下规则为我进行任务拆分与文档整理：
|
||||
1、按依赖优先级排序并编号
|
||||
- 先做基础依赖、公共能力、前置模块；
|
||||
- 后做依赖其上的功能模块；
|
||||
- 输出结果需带明确序号（如 P1、P2、P3… 或 1、2、3…）。
|
||||
2、按可归属为同一个 SPEC 的任务进行分组
|
||||
- 将能够归入同一项 SPEC 的相关任务归类到同一份文档中；
|
||||
- 每组任务应具备清晰边界，避免跨 SPEC 混杂。
|
||||
3、按顺序支持我逐个创建 SPEC 任务
|
||||
- 我会按照你给出的顺序，依次创建多个 SPEC，由 Kiro 协助完成开发；
|
||||
- 因此你的拆分结果必须具备明确的执行先后关系和可落地性。
|
||||
4、表达方式面向 Kiro SPEC 启动与落地
|
||||
- 文档表述请尽量采用便于启动 Kiro SPEC 的方式撰写；
|
||||
- 内容应有利于后续生成/整理需求、设计与任务拆解（Kiro 的 Specs 通常围绕 requirements、design、tasks 结构展开）。
|
||||
5、统一放置在单独目录下
|
||||
- 请将上述拆分后的文档统一整理到一个独立目录中，便于我按顺序创建和管理多个 SPEC。
|
||||
**
|
||||
|
||||
---
|
||||
|
||||
### Q4.2 建立数据依赖矩阵
|
||||
|
||||
建议建立一个"页面 → 数据表"的依赖矩阵，明确每个页面需要哪些 DWS/DWD 表，哪些已有，哪些需要新建或扩展。
|
||||
|
||||
- Q4.2：是否需要我在你回答完 Q&A 后生成这个矩阵？
|
||||
|
||||
**A：是的，在4.1之前生成。或单列为单独任务前的准备工作**
|
||||
|
||||
---
|
||||
|
||||
### Q4.3 AI 接口的结构化定义
|
||||
|
||||
目前 6 个 AI 应用的描述都是散文式的。建议每个应用用统一格式：
|
||||
- 触发场景
|
||||
- 输入字段列表（含数据源表）
|
||||
- 输出字段列表
|
||||
- 调用频率预估
|
||||
|
||||
- Q4.3：是否同意这个格式？
|
||||
|
||||
**A：同意！**
|
||||
|
||||
---
|
||||
|
||||
### Q4.4 API 密钥不应出现在 PRD 文档中
|
||||
|
||||
文档中直接写了阿里云百炼的 `api-key`。这个应该移到 `.env` 中，PRD 只写变量名引用。
|
||||
|
||||
- Q4.4：是否同意？我在后续修订时直接移除。
|
||||
|
||||
**A：同意，当前的KEY是临时的，帮我将API-KEY放到.env 中，然后在文档中移除。**
|
||||
|
||||
---
|
||||
|
||||
## 五、缺失的前置依赖
|
||||
|
||||
以下按阻塞程度排序，请确认优先级是否合理：
|
||||
|
||||
### Q5.1 FDW 映射（阻塞级）
|
||||
|
||||
`zqyy_app.fdw_etl` 没有任何外部表，后端无法读取 ETL 数据。需要先建立 FDW 外部表映射 DWS/DWD 关键表。
|
||||
|
||||
- Q5.1：是否同意这是第一优先级？
|
||||
|
||||
**A：是的，我同意这个第一优先级的任务。注意我们在开发环境，全部使用测试库。**
|
||||
|
||||
---
|
||||
|
||||
### Q5.2 用户-助教映射机制（阻塞级）
|
||||
|
||||
小程序用户登录后，系统需要知道他是哪个助教（或哪个角色）。需要建立映射关系。
|
||||
|
||||
- Q5.2：同 Q1.7，确认映射方式后才能设计。
|
||||
|
||||
**A：这个在前文已经说明，使用租户管理后台进行。**
|
||||
|
||||
---
|
||||
|
||||
### Q5.3 备注表（阻塞级）
|
||||
|
||||
任务系统、回访系统、AI 评分都依赖备注数据。
|
||||
|
||||
- Q5.3：同 Q1.8，确认数据模型后才能建表。
|
||||
|
||||
**A：同意这个第一优先级的任务。注意我们在开发环境，全部使用测试库。**
|
||||
|
||||
---
|
||||
|
||||
### Q5.4 任务表重构（阻塞级）
|
||||
|
||||
现有 `tasks` 表不适合 PRD 中的助教任务系统。
|
||||
|
||||
- Q5.4：同 Q2.3，确认方案后才能实施。
|
||||
|
||||
**A：同意，见上文。**
|
||||
|
||||
---
|
||||
|
||||
### Q5.5 AI 对话记录表（高优先）
|
||||
|
||||
PRD 要求"智能体的信息发送和返回内容都要在数据库中保留"。
|
||||
|
||||
- Q5.5：这张表建在 `zqyy_app` 中对吧？需要记录哪些字段？（我的建议：conversation_id, message_id, app_id, user_id, role, content, tokens_used, created_at, site_id）
|
||||
|
||||
**A：支持你的建议，另外，再额外增加 用户昵称，系统的话，昵称为“系统”**
|
||||
|
||||
---
|
||||
|
||||
### Q5.6 新增 DWS 统计字段/表（高优先）
|
||||
|
||||
消费指数、助教流水统计、充值时间窗口统计等。
|
||||
|
||||
- Q5.6：这些 DWS 变更是否需要等 ETL 流程稳定后再做？还是可以并行？
|
||||
|
||||
**A：可以并行，现在ETL相对稳定了。**
|
||||
|
||||
---
|
||||
|
||||
### Q5.7 dws_member_consumption_summary 扩展
|
||||
|
||||
补充充值次数/金额的时间窗口字段和次均消费。
|
||||
|
||||
- Q5.7：同 Q2.4。
|
||||
|
||||
**A：见上文，同意并支持。**
|
||||
706
docs/prd/SPI 消费力指数.md
Normal file
706
docs/prd/SPI 消费力指数.md
Normal file
@@ -0,0 +1,706 @@
|
||||
# PRD：SPI 消费力指数（Spending Power Index）建设方案（MD）
|
||||
|
||||
* **文档版本**：v1.0
|
||||
* **状态**：定稿（可进入研发设计/排期）
|
||||
* **适用范围**：门店客户运营（新客转化、老客召回、增值推荐、资源分配）
|
||||
* **相关指数体系**：`NCI`、`WBI`、`RS`、`OS`、`MS`、`ML`（SPI 为新增客户级指数）
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
### 1.1 背景
|
||||
|
||||
当前体系中：
|
||||
|
||||
* `NCI` 用于新客欢迎与转化优先级
|
||||
* `WBI` 用于老客召回优先级
|
||||
* `RS/OS/MS/ML` 用于关系强度、归属、动量、付费关联（助教-客户关系对粒度）
|
||||
|
||||
但尚缺少一个**客户级的“消费能力/消费层级”指数**，导致以下问题：
|
||||
|
||||
* 高价值客户与普通客户在运营动作上难以区分投入强度
|
||||
* 增值服务推荐缺少“消费能力层级”依据
|
||||
* 资源分配容易只看“紧急程度”，忽略“投入产出比（ROI）”
|
||||
|
||||
### 1.2 目标
|
||||
|
||||
新增 **SPI（Spending Power Index，消费力指数）**，评估客户在门店场景内的“消费力代理值”，重点基于：
|
||||
|
||||
* **消费水平（Level）**
|
||||
* **消费速度（Speed）**
|
||||
* **消费稳定性（Stability，可选修正项）**
|
||||
|
||||
> 说明：稳定性窗口**最长只使用 90 天**，不使用 180 天（按本次需求明确要求）。
|
||||
|
||||
### 1.3 非目标
|
||||
|
||||
* 不评估金融/征信意义上的“信用能力”
|
||||
* 不直接替代 NCI/WBI（紧迫度）
|
||||
* 不直接替代 RS/OS/MS/ML（关系归属与执行人选择）
|
||||
|
||||
---
|
||||
|
||||
## 2. 设计原则与方法依据
|
||||
|
||||
1. **行为数据驱动**：使用消费/充值明细作为消费力代理信号（门店经营场景可解释、可落地）。
|
||||
2. **稳健统计**：金额类数据长尾明显，展示分采用分位截断（Winsorize）降低极端值影响。Winsorization 本质是用指定分位数限制极端值影响，适合交易金额数据。
|
||||
3. **时间敏感**：近期行为更有参考价值，采用指数衰减与 EWMA 平滑（近期更高权重）来处理速度与展示分稳定性。指数衰减与半衰期是标准时间权重形式，EWMA 则是常见的时间序列平滑方法。
|
||||
4. **与现有体系兼容**：沿用现有 `BaseIndexTask` 的映射逻辑（P5/P95 → 压缩 → MinMax 0–10 → 可选 EWMA）。
|
||||
5. **运营闭环导向**：SPI 不是单独使用，需与 NCI/WBI/RS/OS/MS/ML 组合使用。
|
||||
|
||||
> 补充说明：RFM（Recency/Frequency/Monetary）是成熟的客户价值/客户分层框架，SPI 在其基础上强化“消费速度”与门店场景的可执行性。
|
||||
|
||||
---
|
||||
|
||||
## 3. 指数定义
|
||||
|
||||
## 3.1 指数名称
|
||||
|
||||
* 中文：**消费力指数**
|
||||
* 英文：**Spending Power Index**
|
||||
* 缩写：**SPI**
|
||||
|
||||
## 3.2 粒度
|
||||
|
||||
* **客户级（member）**
|
||||
* 主键建议：`(site_id, member_id)`
|
||||
|
||||
## 3.3 业务含义
|
||||
|
||||
SPI 用于衡量客户在门店体系内的综合消费力层级，回答：
|
||||
|
||||
* 这个客户整体消费能力在门店内属于什么层级？
|
||||
* 近期消费推进速度是否明显变快？
|
||||
* 是稳定高消费，还是偶发冲高？
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据来源与口径
|
||||
|
||||
## 4.1 数据来源（建议）
|
||||
|
||||
### A. 消费订单明细（核心）
|
||||
|
||||
* 来源：结算/订单主表及明细表（按现有 DWD 口径）
|
||||
* 字段（至少）：
|
||||
|
||||
* `site_id`
|
||||
* `member_id`
|
||||
* `pay_time`
|
||||
* `pay_amount`（实付）
|
||||
* `settle_type`（必要时过滤）
|
||||
* 明细项分类（台费、商品、服务等）
|
||||
|
||||
### B. 充值订单明细（辅助）
|
||||
|
||||
* 来源：`dwd_recharge_order`
|
||||
* 字段（至少）：
|
||||
|
||||
* `site_id`
|
||||
* `member_id`
|
||||
* `pay_time`
|
||||
* `pay_amount`
|
||||
* `settle_type = 5`
|
||||
|
||||
### C. 可选增强
|
||||
|
||||
* 储值卡余额（用于解释）
|
||||
|
||||
---
|
||||
|
||||
## 4.2 时间窗口（定稿）
|
||||
|
||||
> **稳定性最长只用 90 天。**
|
||||
|
||||
* **短窗口**：30 天（近期消费速度）
|
||||
* **中窗口**：90 天（消费层级、速度基线、稳定性）
|
||||
|
||||
---
|
||||
|
||||
## 4.3 统计口径（建议）
|
||||
|
||||
* 消费金额：使用 `pay_amount`（实付）
|
||||
* 按天去重的消费日：用于计算消费日密度
|
||||
* 若同一天多笔消费：计入总额，消费日数仅计 1 天
|
||||
* 充值金额：使用充值订单 `pay_amount`
|
||||
* 金额单位：与现有系统保持一致（元）
|
||||
|
||||
---
|
||||
|
||||
## 5. SPI 算法设计（v1）
|
||||
|
||||
> v1 采用“主分 + 子分”的结构，保证解释性：
|
||||
|
||||
* `Level`（消费水平）
|
||||
* `Speed`（消费速度）
|
||||
* `Stability`（消费稳定性，作为修正项；最长 90 天）
|
||||
* `SPI = f(Level, Speed, Stability)`
|
||||
|
||||
---
|
||||
|
||||
## 5.1 基础特征定义（客户级）
|
||||
|
||||
设：
|
||||
|
||||
* `spend_30`：近30天消费总额
|
||||
* `spend_90`：近90天消费总额
|
||||
* `recharge_90`：近90天充值总额
|
||||
* `orders_30 / orders_90`：近30/90天消费笔数
|
||||
* `visit_days_30 / visit_days_90`：近30/90天有消费的自然日数（按天去重）
|
||||
* `avg_ticket_90 = spend_90 / max(orders_90, 1)`：90天客单
|
||||
* `weekly_spend_90`：近90天按周汇总消费额序列（约13周）
|
||||
* `daily_spend_series_90`：近90天按日消费额序列（用于 EWMA）
|
||||
|
||||
---
|
||||
|
||||
## 5.2 子分一：消费水平（Level）
|
||||
|
||||
### 目的
|
||||
|
||||
衡量客户的消费金额层级与客单水平，兼顾充值规模（预算能力代理信号）。
|
||||
|
||||
### 建议公式
|
||||
|
||||
[
|
||||
L = w_{s30}\cdot \ln(1+\frac{spend_{30}}{M30})
|
||||
|
||||
* w_{s90}\cdot \ln(1+\frac{spend_{90}}{M90})
|
||||
* w_{ticket}\cdot \ln(1+\frac{avg_ticket_{90}}{T0})
|
||||
* w_{r90}\cdot \ln(1+\frac{recharge_{90}}{R90})
|
||||
]
|
||||
|
||||
### 说明
|
||||
|
||||
* 使用 `log1p` 压缩长尾，避免大额客户过度支配排序
|
||||
* 30天与90天并用：兼顾近期层级与稳定层级
|
||||
* 充值是辅助信号，不应压过真实消费金额
|
||||
|
||||
---
|
||||
|
||||
## 5.3 子分二：消费速度（Speed）
|
||||
|
||||
### 目的
|
||||
|
||||
衡量“近期消费推进快不快”，体现消费节奏变化。
|
||||
|
||||
### A. 绝对速度（近期强度）
|
||||
|
||||
[
|
||||
V_{abs} = \ln \left(1+\frac{spend_{30}}{\max(visit_days_{30},1)\cdot V0}\right)
|
||||
]
|
||||
|
||||
含义：近30天“每个消费日平均消费强度”。
|
||||
|
||||
### B. 相对速度（近期 vs 基线）
|
||||
|
||||
[
|
||||
v_{30}=\frac{spend_{30}}{30}, \quad v_{90}=\frac{spend_{90}}{90}
|
||||
]
|
||||
[
|
||||
V_{rel} = \ln\left(\frac{v_{30}+\epsilon}{v_{90}+\epsilon}\right)
|
||||
]
|
||||
|
||||
* `V_rel > 0`：近期消费速度快于90天基线（加速）
|
||||
* `V_rel < 0`：近期消费速度低于基线（放缓）
|
||||
|
||||
### C. 平滑速度（EWMA，可选）
|
||||
|
||||
对 `daily_spend_series_90` 做 EWMA，得到 `daily_spend_ewma_90`：
|
||||
[
|
||||
V_{ewma}=\ln(1+\frac{daily_spend_ewma_{90}}{E0})
|
||||
]
|
||||
|
||||
### Speed 子分（建议）
|
||||
|
||||
[
|
||||
S = w_{abs}\cdot V_{abs} + w_{rel}\cdot max(0, V_{rel}) + w_{ewma}\cdot V_{ewma}
|
||||
]
|
||||
|
||||
> v1 建议仅对“加速”加分（`max(0,V_rel)`），不对“减速”直接扣分；减速信号已在 WBI 中承担召回压力逻辑。
|
||||
|
||||
---
|
||||
|
||||
## 5.4 子分三：消费稳定性（Stability，最长 90 天）
|
||||
|
||||
### 目的
|
||||
|
||||
识别“稳定高消费”与“偶发冲高”，防止单笔大单导致 SPI 虚高。
|
||||
|
||||
### 窗口要求（定稿）
|
||||
|
||||
**只使用近90天**
|
||||
|
||||
### 建议特征（v1 可二选一或组合）
|
||||
|
||||
[
|
||||
Stab_{cover} = \frac{#(\text{近90天有消费的周数})}{13}
|
||||
]
|
||||
|
||||
### Stability 子分（v1 推荐）
|
||||
|
||||
[
|
||||
P = Stab_{cover}
|
||||
]
|
||||
（v1 先采用覆盖率，简单、稳健、工程成本低）
|
||||
|
||||
---
|
||||
|
||||
## 5.5 SPI 总分（Raw）
|
||||
|
||||
### 建议结构（v1）
|
||||
|
||||
[
|
||||
SPI_{raw} = w_L \cdot L + w_S \cdot S + w_P \cdot P
|
||||
]
|
||||
|
||||
### 建议默认权重（v1）
|
||||
|
||||
* `w_L = 0.60`
|
||||
* `w_S = 0.30`
|
||||
* `w_P = 0.10`
|
||||
|
||||
> 若你希望先简化上线，也可 v1.0 不启用稳定性（`w_P=0`），v1.1 再开启。
|
||||
> 但本需求已明确“稳定性最长 90 天即可”，建议直接纳入 v1，权重先低配。
|
||||
|
||||
---
|
||||
|
||||
## 6. 展示分映射（Raw → Display 0–10）
|
||||
|
||||
SPI 与子分（Level/Speed/Stability）展示分均建议复用现有统一逻辑：
|
||||
|
||||
1. 收集全体 Raw 分数
|
||||
2. 计算 `P5/P95`
|
||||
3. Winsorize 截断到 `[P5, P95]`
|
||||
4. 可选压缩（`none/log1p/asinh`）
|
||||
5. MinMax 映射到 `[0,10]`
|
||||
6. 可选 EWMA 平滑分位点
|
||||
7. 展示分保留 2 位小数
|
||||
|
||||
> 该映射适合金额类/长尾分布指标，可降低极端值造成的排序失真。
|
||||
|
||||
---
|
||||
|
||||
## 7. 输出表设计（新增）
|
||||
|
||||
## 7.1 表名建议
|
||||
|
||||
`billiards_dws.dws_member_spending_power_index`
|
||||
|
||||
## 7.2 主键
|
||||
|
||||
* `(site_id, member_id)`
|
||||
|
||||
## 7.3 字段建议（v1）
|
||||
|
||||
### 基础特征（解释与排查）
|
||||
|
||||
* `spend_30`
|
||||
* `spend_90`
|
||||
* `recharge_90`
|
||||
* `orders_30`
|
||||
* `orders_90`
|
||||
* `visit_days_30`
|
||||
* `visit_days_90`
|
||||
* `avg_ticket_90`
|
||||
* `active_weeks_90`
|
||||
* `daily_spend_ewma_90`（若启用）
|
||||
|
||||
### 子分
|
||||
|
||||
* `score_level_raw`
|
||||
* `score_level_display`
|
||||
* `score_speed_raw`
|
||||
* `score_speed_display`
|
||||
* `score_stability_raw`
|
||||
* `score_stability_display`
|
||||
|
||||
### 总分
|
||||
|
||||
* `raw_score`（SPI_raw）
|
||||
* `display_score`（SPI_display）
|
||||
|
||||
### 元数据
|
||||
|
||||
* `calc_time`
|
||||
* `created_at`
|
||||
* `updated_at`
|
||||
|
||||
---
|
||||
|
||||
## 8. 配置体系（cfg_index_parameters）新增项
|
||||
|
||||
## 8.1 index_type
|
||||
|
||||
新增：
|
||||
|
||||
* `SPI`
|
||||
|
||||
## 8.2 参数清单（建议默认值）
|
||||
|
||||
### 窗口与平滑
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| ------------------------- | --: | ------------- |
|
||||
| `spend_window_short_days` | 30 | 短窗口（速度） |
|
||||
| `spend_window_long_days` | 90 | 长窗口（层级/稳定性上限） |
|
||||
| `ewma_alpha_daily_spend` | 0.3 | 日消费 EWMA 平滑系数 |
|
||||
|
||||
### 金额压缩基数
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| ------------------------- | ---: | ---------- |
|
||||
| `amount_base_spend_30` | 按门店分布校准 | 30天消费压缩基数 |
|
||||
| `amount_base_spend_90` | 按门店分布校准 | 90天消费压缩基数 |
|
||||
| `amount_base_ticket_90` | 按门店分布校准 | 90天客单压缩基数 |
|
||||
| `amount_base_recharge_90` | 按门店分布校准 | 90天充值压缩基数 |
|
||||
| `amount_base_speed_abs` | 按门店分布校准 | 绝对速度压缩基数 |
|
||||
| `amount_base_ewma_90` | 按门店分布校准 | EWMA速度压缩基数 |
|
||||
|
||||
### 权重（总分）
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| ------------------ | ---: | ------------ |
|
||||
| `weight_level` | 0.60 | Level 权重 |
|
||||
| `weight_speed` | 0.30 | Speed 权重 |
|
||||
| `weight_stability` | 0.10 | Stability 权重 |
|
||||
|
||||
### 权重（Level 子分）
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| --------------------- | ---: | -------------- |
|
||||
| `w_level_spend_30` | 0.30 | Level 中 30天消费项 |
|
||||
| `w_level_spend_90` | 0.35 | Level 中 90天消费项 |
|
||||
| `w_level_ticket_90` | 0.20 | Level 中 90天客单项 |
|
||||
| `w_level_recharge_90` | 0.15 | Level 中 90天充值项 |
|
||||
|
||||
### 权重（Speed 子分）
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| -------------- | ---: | --------- |
|
||||
| `w_speed_abs` | 0.50 | 绝对速度项 |
|
||||
| `w_speed_rel` | 0.30 | 相对速度项（加速） |
|
||||
| `w_speed_ewma` | 0.20 | EWMA速度项 |
|
||||
|
||||
### 稳定性参数（90天上限）
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| ----------------------- | --: | ------------- |
|
||||
| `stability_window_days` | 90 | 稳定性窗口（固定上限90） |
|
||||
| `use_stability` | 1 | 是否启用稳定性子分 |
|
||||
| `stability_mode` | 1 | 1=周覆盖率（v1推荐） |
|
||||
|
||||
### 映射与平滑（复用 BaseIndexTask）
|
||||
|
||||
| 参数 | 默认值 | 说明 |
|
||||
| ------------------ | --: | ------------------------ |
|
||||
| `percentile_lower` | 5 | 下分位 |
|
||||
| `percentile_upper` | 95 | 上分位 |
|
||||
| `compression_mode` | 1 | 0=none, 1=log1p, 2=asinh |
|
||||
| `use_smoothing` | 1 | 是否启用分位平滑 |
|
||||
| `ewma_alpha` | 0.2 | 分位 EWMA 平滑系数 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 任务与计算策略（建议）
|
||||
|
||||
## 9.1 任务形态
|
||||
|
||||
* 新增客户级任务：`SpendingPowerIndexTask`
|
||||
* 粒度：`(site_id, member_id)`
|
||||
* 建议频率：**每日**（与 NCI/WBI 接近，便于客户级看板统一刷新）
|
||||
|
||||
## 9.2 计算流程
|
||||
|
||||
1. 抽取消费订单明细（近90天）
|
||||
2. 抽取充值订单明细（近90天）
|
||||
3. 聚合客户级特征（30天/90天）
|
||||
4. 计算 `Level/Speed/Stability` 子分 Raw
|
||||
5. 计算 `SPI_raw`
|
||||
6. 映射为展示分（0–10）
|
||||
7. 写入 `dws_member_spending_power_index`（delete-before-insert 或 upsert）
|
||||
|
||||
---
|
||||
|
||||
## 10. SPI 参与的所有相关运营场景（完整清单）
|
||||
|
||||
> 原则：**SPI 不单独决定“要不要触达”，而是与 NCI/WBI（紧急度）+ RS/OS/MS/ML（执行关系）组合使用。**
|
||||
|
||||
---
|
||||
|
||||
## 10.1 新客运营（NCI 场景）
|
||||
|
||||
### 场景 A1：新客欢迎优先级（欢迎建联）
|
||||
|
||||
* **主用指数**：`NCI_welcome`
|
||||
* **SPI 作用**：决定欢迎动作投入强度（轻触达/强服务）
|
||||
* **策略**
|
||||
|
||||
* `NCI_welcome 高 + SPI 高`：优先人工建联、安排更高质量接待与后续方案
|
||||
* `NCI_welcome 高 + SPI 中低`：标准欢迎流程，重点推动二访而非高价增值
|
||||
|
||||
### 场景 A2：新客二访转化
|
||||
|
||||
* **主用指数**：`NCI_convert`
|
||||
* **SPI 作用**：判断适合推“基础二访”还是“升级体验包/储值方案”
|
||||
* **配合指数**
|
||||
|
||||
* `OS`：谁负责触达
|
||||
* `ML`：若涉及充值/储值，由谁推更容易成交
|
||||
|
||||
### 场景 A3：新客近期活跃（避免过度打扰）
|
||||
|
||||
* **主用指数**：`NCI`（内置活跃抑制）
|
||||
* **SPI 作用**：不用于提高打扰频率，而用于现场服务策略分层
|
||||
* **运营建议**
|
||||
|
||||
* 高 SPI 新客：现场体验升级、服务深度设计
|
||||
* 低 SPI 新客：降低销售压力，先建立习惯
|
||||
|
||||
---
|
||||
|
||||
## 10.2 老客召回（WBI 场景）
|
||||
|
||||
### 场景 B1：老客召回名单排序
|
||||
|
||||
* **主用指数**：`WBI`
|
||||
* **SPI 作用**：决定召回资源优先级（投入强度/人工优先）
|
||||
* **策略**
|
||||
|
||||
* `WBI 高 + SPI 高`：优先人工召回、重点维护
|
||||
* `WBI 高 + SPI 中低`：先低成本触达（消息/轻优惠）
|
||||
|
||||
### 场景 B2：充值未回访专项召回
|
||||
|
||||
* **主用指数**：`WBI`（充值未回访压力）
|
||||
* **SPI 作用**：判断值得投入多大召回成本
|
||||
* **配合指数**
|
||||
|
||||
* `ML`：选执行人（谁推更容易成）
|
||||
* `OS`：定责（避免撞单）
|
||||
|
||||
### 场景 B3：高消费力沉默客户（价值保全）
|
||||
|
||||
* **触发逻辑**：`SPI 高` 且 `WBI` 进入召回区间
|
||||
* **运营重点**：不是纯促销，而是“关系修复/体验恢复/高价值保留”
|
||||
|
||||
---
|
||||
|
||||
## 10.3 活跃客户跟进与升温承接（MS 场景）
|
||||
|
||||
### 场景 C1：近期消费/来店升温客户承接
|
||||
|
||||
* **主用指数**：`MS`（关系动量）
|
||||
* **SPI 作用**：判断承接动作的强度与档位
|
||||
* **配合指数**
|
||||
|
||||
* `OS`：由谁跟进
|
||||
* `RS`：关系强弱决定话术深浅
|
||||
* `ML`：如涉及储值推荐，决定由谁推
|
||||
|
||||
### 场景 C2：关系强但消费层级下滑（潜在降档预警）
|
||||
|
||||
* **组合信号**：`RS 高` + `SPI_speed 下降`（或 SPI 总分下滑）
|
||||
* **运营动作**：先做需求确认/体验诊断，再决定促销或产品调整
|
||||
|
||||
---
|
||||
|
||||
## 10.4 增值服务与储值推荐（ML + SPI 场景）
|
||||
|
||||
### 场景 D1：筛选“值得重点推增值”的客户
|
||||
|
||||
* **主用指数**：`SPI`
|
||||
* **配合指数**：`MS`（时机）、`RS`（关系）、`WBI/NCI`（是否当前应触达）
|
||||
* **策略**
|
||||
|
||||
* `SPI 高 + MS 高`：优先推增值（最佳时机）
|
||||
* `SPI 高 + WBI 高`：先召回再推，不要直接硬销
|
||||
* `SPI 低 + RS 高`：可做低门槛增值尝试，不推高价方案
|
||||
|
||||
### 场景 D2：确定“由谁来推更可能成功”
|
||||
|
||||
* **主用指数**：`ML`
|
||||
* **SPI 作用**：决定是否值得高成本人力投入
|
||||
* **配合指数**
|
||||
|
||||
* `OS`：责任边界
|
||||
* `RS`：关系基础
|
||||
* `MS`：时机窗口
|
||||
|
||||
---
|
||||
|
||||
## 10.5 客户分层与运营资源配置（门店/店长视角）
|
||||
|
||||
### 场景 E1：客户池分层（高/中/低消费力）
|
||||
|
||||
* **主用指数**：`SPI_display`
|
||||
* **作用**：作为全店客户分层基础维度（可与活跃度、风险度交叉）
|
||||
* **建议分层**
|
||||
|
||||
* 高消费力（Top 10–20%）
|
||||
* 中消费力
|
||||
* 低消费力
|
||||
|
||||
### 场景 E2：人力资源分配（助教时间预算）
|
||||
|
||||
* **组合指数**
|
||||
|
||||
* 客户优先级：`NCI/WBI`
|
||||
* 客户消费力：`SPI`
|
||||
* 执行人选择：`OS/ML`
|
||||
* **规则示例**
|
||||
|
||||
* 高 NCI/WBI + 高 SPI：优先人工跟进
|
||||
* 高 NCI/WBI + 低 SPI：半自动/标准化触达
|
||||
* 低 NCI/WBI + 高 SPI：低频但重点维系
|
||||
|
||||
### 场景 E3：活动名单筛选
|
||||
|
||||
* **SPI 作用**：筛选活动档位与名单
|
||||
* **示例**
|
||||
|
||||
* 高 SPI 客户：高阶体验/高客单活动
|
||||
* 中低 SPI 客户：入门体验/拉频次活动
|
||||
|
||||
---
|
||||
|
||||
## 10.6 管理与复盘（分析场景）
|
||||
|
||||
### 场景 F1：增值策略复盘
|
||||
|
||||
* **组合指标**：`SPI`（客户层级） + `ML`（执行人付费关联）
|
||||
* **看什么**
|
||||
|
||||
* 高 SPI 客户是否被正确触达
|
||||
* 高 SPI 客户的增值转化是否集中在正确助教（ML 高者）
|
||||
|
||||
### 场景 F2：客户结构变化监控
|
||||
|
||||
* **主用指数**：`SPI`
|
||||
* **看什么**
|
||||
|
||||
* 高 SPI 客户数量变化
|
||||
* 各层级客户占比变化
|
||||
* 高 SPI 客户的活跃/沉默迁移（结合 WBI）
|
||||
|
||||
### 场景 F3：门店经营质量诊断（非直接派单）
|
||||
|
||||
* **组合信号**
|
||||
|
||||
* `SPI 高` 客户群体的 `WBI` 是否整体抬升（高价值流失预警）
|
||||
* `SPI 高` 客户群体的 `MS` 是否持续走低（热度下降）
|
||||
|
||||
---
|
||||
|
||||
## 11. 运营使用规则（落地建议）
|
||||
|
||||
## 11.1 统一原则
|
||||
|
||||
* **NCI/WBI 决定“要不要优先触达”**
|
||||
* **SPI 决定“投入多大资源、用什么档位策略”**
|
||||
* **OS/RS/MS/ML 决定“谁来做、什么时候做、谁更容易做成”**
|
||||
|
||||
## 11.2 一个实用的组合模板
|
||||
|
||||
### 新客转化
|
||||
|
||||
* 选人群：`NCI_convert 高`
|
||||
* 分档：`SPI 高/中/低`
|
||||
* 落人：`OS`（若已有关系）否则新客官
|
||||
* 增值时机：`MS 高` 再推，执行人选 `ML 高`
|
||||
|
||||
### 老客召回
|
||||
|
||||
* 选人群：`WBI 高`
|
||||
* 分档：`SPI 高` 优先人工，`SPI 低` 低成本触达
|
||||
* 落人：`OS=MAIN`，若无归属则公海召回组
|
||||
* 若涉及储值：执行人优先 `ML 高`
|
||||
|
||||
---
|
||||
|
||||
## 12. 验收标准（数据与业务）
|
||||
|
||||
## 12.1 数据正确性
|
||||
|
||||
* `SPI_raw` 在新增消费/充值后总体应单调不减（同等其他条件下）
|
||||
* `score_speed_raw` 在近30天消费速度高于近90天基线时应提升
|
||||
* `score_stability_raw` 仅使用近90天数据（不引用 180 天）
|
||||
* 展示分稳定：在总体分布无大变化时，`display_score` 不应异常跳变（启用 EWMA）
|
||||
|
||||
## 12.2 业务可用性
|
||||
|
||||
* 运营可基于 SPI 完成客户分层（高/中/低）
|
||||
* 运营可在 NCI/WBI 队列中使用 SPI 做资源投入分层
|
||||
* 增值推荐场景可用 SPI + ML + OS 形成可执行规则
|
||||
|
||||
---
|
||||
|
||||
## 13. 风险与控制
|
||||
|
||||
1. **异常大单抬高 SPI**
|
||||
|
||||
* 控制：Winsorize + 压缩变换 + 稳定性子分（90天覆盖率）
|
||||
|
||||
2. **充值替代真实消费导致高估**
|
||||
|
||||
* 控制：充值在 Level 子分中权重较低（辅助信号）
|
||||
|
||||
3. **短期活动造成速度异常升高**
|
||||
|
||||
* 控制：速度项只部分加权；稳定性项用于修正
|
||||
|
||||
4. **跨门店可比性问题**
|
||||
|
||||
* 控制：SPI 默认用于门店内排序；如需跨店对比，需后续增加门店标准化层
|
||||
|
||||
---
|
||||
|
||||
## 14. 上线计划（建议）
|
||||
|
||||
### Phase 1：影子跑数（1–2 周）
|
||||
|
||||
* 后台计算 SPI，不对运营展示
|
||||
* 验证分布、极值、客户样本解释性
|
||||
|
||||
### Phase 2：看板展示与规则试运行（2–4 周）
|
||||
|
||||
* 接入 NCI/WBI 队列的辅助分档
|
||||
* 先用于“投入强度分层”，不直接自动派单
|
||||
|
||||
### Phase 3：策略联动
|
||||
|
||||
* 用于活动名单筛选、增值推荐档位
|
||||
* 与 `ML/OS/MS` 联动形成自动建议
|
||||
|
||||
---
|
||||
|
||||
## 15. 研发实现清单（交付物）
|
||||
|
||||
1. 新增任务：`SpendingPowerIndexTask`
|
||||
2. 新增结果表：`dws_member_spending_power_index`
|
||||
3. 新增配置：`cfg_index_parameters` 中 `index_type='SPI'`
|
||||
4. 新增看板字段：
|
||||
|
||||
* `SPI_display`
|
||||
* `Level/Speed/Stability` 子分展示
|
||||
5. 新增运营策略读取逻辑（可选）：
|
||||
|
||||
* NCI/WBI 队列中读取 SPI 做资源分档
|
||||
|
||||
---
|
||||
|
||||
## 16. 附录：公式与约定（实现参考）
|
||||
|
||||
### 16.1 指数衰减（如后续引入时间衰减特征）
|
||||
|
||||
[
|
||||
decay(d; h)=exp(-ln(2)\cdot d / h)
|
||||
]
|
||||
（半衰期形式，`d=h` 时权重降为 0.5）([维基百科][2])
|
||||
|
||||
### 16.2 展示分映射（沿用现有 BaseIndexTask）
|
||||
|
||||
* P5/P95 Winsorize
|
||||
* `compression_mode`: `none / log1p / asinh`
|
||||
* MinMax → `[0,10]`
|
||||
* 可选 EWMA 分位平滑（`ewma_alpha`）([维基百科][1])
|
||||
269
docs/prd/specs/00-数据依赖矩阵.md
Normal file
269
docs/prd/specs/00-数据依赖矩阵.md
Normal file
@@ -0,0 +1,269 @@
|
||||
# 数据依赖矩阵（页面 → 数据表映射）
|
||||
|
||||
> 生成日期：2026-02-23
|
||||
> 基于 PRD 审阅 Q&A 两轮结果 + 真实数据库现状
|
||||
|
||||
---
|
||||
|
||||
## 图例
|
||||
|
||||
| 标记 | 含义 |
|
||||
|------|------|
|
||||
| ✅ | ETL 库已有表，可直接通过 FDW 映射 |
|
||||
| 🔧 | ETL 库已有表但需扩展字段 |
|
||||
| 🆕 | 需要新建的 ETL 表（DWS/DWD 层） |
|
||||
| 📱 | 需要新建的业务库表（`test_zqyy_app`） |
|
||||
| 🤖 | 需要 AI 应用调用（百炼） |
|
||||
| ⏰ | 需要后台轮询/触发器机制 |
|
||||
|
||||
---
|
||||
|
||||
## 一、小程序页面 → 数据源
|
||||
|
||||
### task-list.html（任务列表）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 助教任务列表 | `zqyy_app.biz.coach_tasks` | 📱 新建 |
|
||||
| 任务优先级（max(WBI,NCI)） | `dws.dws_member_winback_index` + `dws.dws_member_newconv_index` | ✅ FDW |
|
||||
| 客户-助教关系（RS/OS） | `dws.dws_member_assistant_relation_index` | ✅ FDW |
|
||||
| 客户基本信息 | `dwd.dim_member` | ✅ FDW |
|
||||
| 助教基本信息 | `dwd.dim_assistant` | ✅ FDW |
|
||||
| 任务置顶/放弃状态 | `zqyy_app.biz.coach_tasks` | 📱 新建 |
|
||||
| 绩效计算快照 | `dws.dws_assistant_salary_calc` | ✅ FDW |
|
||||
| 定档业绩配置 | `dws.cfg_performance_tier` | ✅ FDW |
|
||||
| 助教等级单价 | `dws.cfg_assistant_level_price` | ✅ FDW |
|
||||
| 跳档激励展示 | `dws.cfg_performance_tier` + `dws.dws_assistant_salary_calc` | ✅ FDW |
|
||||
| 定档折算惩罚 | `dws.dws_assistant_daily_detail`（需扩展） | 🔧 扩展 |
|
||||
|
||||
### task-detail.html（任务详情）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 任务详情 | `zqyy_app.biz.coach_tasks` | 📱 新建 |
|
||||
| 客户全信息 | `dwd.dim_member` + `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 客户-助教亲密度 | `dws.dws_member_assistant_intimacy` | ✅ FDW |
|
||||
| 近期服务记录 | `dwd.dwd_assistant_service_log` | ✅ FDW |
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
| AI 消费习惯分析 | 应用 3 返回结果缓存 | 📱🤖⏰ |
|
||||
| AI 关系分析/任务建议 | 应用 4 返回结果缓存 | 📱🤖⏰ |
|
||||
| AI 话术参考 | 应用 5 返回结果缓存 | 📱🤖⏰ |
|
||||
| AI 备注星级 | 应用 6 返回结果 | 📱🤖⏰ |
|
||||
| 客户喜好标签（🎱斯🀅🎤） | `dwd.dwd_table_fee_log`（按房间类型统计） | ✅ FDW |
|
||||
|
||||
### performance.html（我的绩效）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 收入与业绩档位 | `dws.dws_assistant_salary_calc` | ✅ FDW |
|
||||
| 服务记录明细 | `dwd.dwd_assistant_service_log` | ✅ FDW |
|
||||
| 我的新客 | `dws.dws_assistant_customer_stats`（首次服务+次数过滤） | ✅ FDW |
|
||||
| 我的常客 | `dws.dws_assistant_customer_stats` | ✅ FDW |
|
||||
| 定档折算惩罚展示 | `dws.dws_assistant_daily_detail`（需扩展） | 🔧 扩展 |
|
||||
|
||||
### performance-records.html（业绩明细）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 全部业绩记录 | `dwd.dwd_assistant_service_log` | ✅ FDW |
|
||||
| 定档折算展示 | `dws.dws_assistant_daily_detail`（需扩展） | 🔧 扩展 |
|
||||
| 按天/月归总 | 后端聚合查询 | — |
|
||||
|
||||
### board-finance.html（财务看板）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 财务日报 | `dws.dws_finance_daily_summary` | ✅ FDW |
|
||||
| 收入结构 | `dws.dws_finance_income_structure` | ✅ FDW |
|
||||
| 充值汇总 | `dws.dws_finance_recharge_summary` | ✅ FDW |
|
||||
| 折扣明细 | `dws.dws_finance_discount_detail` | ✅ FDW |
|
||||
| 支出汇总 | `dws.dws_finance_expense_summary` | ✅ FDW |
|
||||
| 平台结算 | `dws.dws_platform_settlement` | ✅ FDW |
|
||||
| AI 财务洞察 | 应用 2 返回结果缓存 | 📱🤖⏰ |
|
||||
| 环比数据 | 后端聚合计算 | — |
|
||||
|
||||
### board-customer.html（客户看板）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 最应召回（WBI 排序） | `dws.dws_member_winback_index` | ✅ FDW |
|
||||
| 最大消费潜力（SPI 排序） | `dws.dws_member_spending_power_index` | 🆕 新建 |
|
||||
| 最高余额 | `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 最近充值 | `dwd.dwd_recharge_order` | ✅ FDW |
|
||||
| 最高消费 60 天 | `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 最频繁 60 天 | `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 最近到店 | `dws.dws_member_visit_detail` | ✅ FDW |
|
||||
| 最专一（RS 最大值） | `dws.dws_member_assistant_relation_index` | ✅ FDW |
|
||||
| 客户喜好标签 | `dwd.dwd_table_fee_log` | ✅ FDW |
|
||||
|
||||
### board-coach.html（助教看板）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 定档业绩排序 | `dws.dws_assistant_salary_calc` | ✅ FDW |
|
||||
| 工资排序 | `dws.dws_assistant_salary_calc` | ✅ FDW |
|
||||
| 高客源储值额 | `dws.dws_member_assistant_relation_index` + `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 任务完成数 | `zqyy_app.biz.coach_tasks`（统计已完成） | 📱 新建 |
|
||||
| 助教月度汇总 | `dws.dws_assistant_monthly_summary` | ✅ FDW |
|
||||
|
||||
### customer-detail.html（客户详情）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 客户基本信息 | `dwd.dim_member` + `dwd.dim_member_card_account` | ✅ FDW |
|
||||
| 消费汇总 | `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 消费记录（台桌结账） | `dwd.dwd_settlement_head` + `dwd.dwd_table_fee_log` | ✅ FDW |
|
||||
| 消费记录（商城订单） | `dwd.dwd_settlement_head` + `dwd.dwd_store_goods_sale` | ✅ FDW |
|
||||
| 消费记录（充值） | `dwd.dwd_recharge_order` | ✅ FDW |
|
||||
| 指数总览（WBI/NCI/SPI） | 各指数表 | ✅🆕 FDW |
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
| AI 消费习惯分析 | 应用 3 缓存 | 📱🤖⏰ |
|
||||
| 生日信息 | `zqyy_app.biz.notes`（type=birthday） | 📱 新建 |
|
||||
|
||||
### coach-detail.html（助教详情）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 助教基本信息 | `dwd.dim_assistant` | ✅ FDW |
|
||||
| 客户数（RS>2） | `dws.dws_member_assistant_relation_index` | ✅ FDW |
|
||||
| 工龄 | `dwd.dim_assistant.hire_date` | ✅ FDW |
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
|
||||
### chat.html（AI 对话）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 对话记录 | `zqyy_app.biz.ai_conversations` | 📱 新建 |
|
||||
| 来源页面上下文 | 前端传入 | — |
|
||||
| AI 应用 1 调用 | 百炼 API | 🤖 |
|
||||
|
||||
### notes.html（备注管理）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
|
||||
### chat-history.html（对话历史）
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 历史对话列表 | `zqyy_app.biz.ai_conversations` | 📱 新建 |
|
||||
|
||||
### login/apply/reviewing 等登录流程页
|
||||
|
||||
| 数据需求 | 数据源 | 状态 |
|
||||
|---------|--------|------|
|
||||
| 用户信息 | `zqyy_app.auth.users` | 📱 新建（重构现有 public.users） |
|
||||
| 微信登录 | 微信 API（code2Session） | — |
|
||||
| 申请记录 | `zqyy_app.auth.user_applications` | 📱 新建 |
|
||||
|
||||
---
|
||||
|
||||
## 二、租户管理后台 → 数据源
|
||||
|
||||
| 功能 | 数据源 | 状态 |
|
||||
|------|--------|------|
|
||||
| 用户审核列表 | `zqyy_app.auth.user_applications` + `zqyy_app.auth.users` | 📱 新建 |
|
||||
| 用户-助教关联建议 | `dwd.dim_assistant`（通过球房ID+手机号匹配） | ✅ FDW |
|
||||
| 球房ID映射 | `zqyy_app.auth.site_code_mapping` | 📱 新建 |
|
||||
| Excel 上传-财务支出 | `dws.dws_finance_expense_summary`（或新建 staging 表） | 🔧/📱 |
|
||||
| Excel 上传-团购收入 | `dws.dws_platform_settlement`（或新建 staging 表） | 🔧/📱 |
|
||||
| Excel 上传-助教奖罚 | `zqyy_app.biz.salary_adjustments` | 📱 新建 |
|
||||
| Excel 上传-充值业绩归属 | `dws.dws_assistant_recharge_commission`（或新建 staging 表） | 🔧/📱 |
|
||||
|
||||
---
|
||||
|
||||
## 三、后台轮询/触发器任务 → 数据源
|
||||
|
||||
| 触发器/轮询任务 | 触发条件 | 数据源 | 状态 |
|
||||
|---------------|---------|--------|------|
|
||||
| 任务生成器 | 每日 4:00 后首次运行 | 全部指数表 + `coach_tasks` | 📱⏰ |
|
||||
| 任务状态轮询 | 每小时 | `coach_tasks` + 有效期检查 | 📱⏰ |
|
||||
| 召回完成检测 | ETL 数据更新后 | `dwd.dwd_assistant_service_log` + `coach_tasks` | ⏰ |
|
||||
| 数据回溯（备注重分类） | 召回完成时 | `notes` + `coach_tasks` | 📱⏰ |
|
||||
| AI 应用 2 财务洞察 | 每日 | 财务 DWS 表 | 🤖⏰ |
|
||||
| AI 应用 3 消费习惯 | 客户新增消费时 | DWD 订单明细 | 🤖⏰ |
|
||||
| AI 应用 4 关系分析 | 助教参与新结算时 | DWD 订单明细 | 🤖⏰ |
|
||||
| AI 应用 5 话术 | 应用 4 调用时 | 应用 4 输入+输出 | 🤖⏰ |
|
||||
| AI 应用 6 备注评分 | 回访任务完成时 | 备注 + 客户信息 | 🤖⏰ |
|
||||
|
||||
---
|
||||
|
||||
## 四、汇总：需要新建/扩展的数据对象
|
||||
|
||||
### ETL 库（`test_etl_feiqiu`）— 新建
|
||||
|
||||
| 表名 | Schema | 说明 |
|
||||
|------|--------|------|
|
||||
| `dws_member_spending_power_index` | dws | SPI 消费力指数 |
|
||||
| `dws_assistant_order_contribution` | dws | 助教订单流水四项统计 |
|
||||
| `app.*`（RLS 视图） | app | 全部 FDW 映射表的 RLS 视图层 |
|
||||
|
||||
### ETL 库 — 扩展
|
||||
|
||||
| 表名 | 扩展内容 |
|
||||
|------|---------|
|
||||
| `dws_member_consumption_summary` | 增加 30/60/90 天充值次数/金额、次均消费 |
|
||||
| `dws_assistant_daily_detail` | 增加定档折算惩罚字段（penalty_minutes、penalty_reason、is_exempt） |
|
||||
|
||||
### 业务库（`test_zqyy_app`）— 新建
|
||||
|
||||
| 表名 | Schema | 说明 |
|
||||
|------|--------|------|
|
||||
| `users`（重构） | auth | 小程序用户（增加 status、wx_openid、wx_avatar 等） |
|
||||
| `user_applications` | auth | 用户申请记录 |
|
||||
| `site_code_mapping` | auth | 球房ID ↔ site_id 映射 |
|
||||
| `user_assistant_bindng` | auth | 用户-助教绑定关系 |
|
||||
| `coach_tasks` | biz | 助教任务（类型、优先级、状态、有效期等） |
|
||||
| `coach_task_history` | biz | 任务变更历史（关闭/新建追溯） |
|
||||
| `notes` | biz | 统一备注表（type 区分） |
|
||||
| `ai_conversations` | biz | AI 对话记录 |
|
||||
| `ai_messages` | biz | AI 对话消息明细 |
|
||||
| `ai_cache` | biz | AI 应用 2-6 结果缓存 |
|
||||
| `salary_adjustments` | biz | 助教奖罚明细（Excel 上传） |
|
||||
| `excel_upload_log` | biz | Excel 上传记录与冲突处理日志 |
|
||||
| `trigger_jobs` | biz | 触发器/轮询任务配置与执行日志 |
|
||||
|
||||
### FDW 映射（`test_zqyy_app.fdw_etl`）
|
||||
|
||||
需要映射的 ETL 表（通过 `app` schema RLS 视图）：
|
||||
|
||||
| 来源表 | 用途 |
|
||||
|--------|------|
|
||||
| `dwd.dim_member` | 客户基本信息 |
|
||||
| `dwd.dim_assistant` | 助教基本信息 |
|
||||
| `dwd.dim_member_card_account` | 会员卡余额 |
|
||||
| `dwd.dim_table` | 台桌信息 |
|
||||
| `dwd.dwd_settlement_head` | 结算主表 |
|
||||
| `dwd.dwd_table_fee_log` | 台费明细 |
|
||||
| `dwd.dwd_assistant_service_log` | 助教服务记录 |
|
||||
| `dwd.dwd_recharge_order` | 充值订单 |
|
||||
| `dwd.dwd_store_goods_sale` | 商品销售 |
|
||||
| `dws.dws_member_consumption_summary` | 客户消费汇总 |
|
||||
| `dws.dws_member_visit_detail` | 客户到店明细 |
|
||||
| `dws.dws_member_winback_index` | WBI 指数 |
|
||||
| `dws.dws_member_newconv_index` | NCI 指数 |
|
||||
| `dws.dws_member_recall_index` | 召回指数 |
|
||||
| `dws.dws_member_spending_power_index` | SPI 指数（新建后映射） |
|
||||
| `dws.dws_member_assistant_relation_index` | RS/OS/MS/ML 指数 |
|
||||
| `dws.dws_member_assistant_intimacy` | 亲密度 |
|
||||
| `dws.dws_assistant_daily_detail` | 助教日明细 |
|
||||
| `dws.dws_assistant_monthly_summary` | 助教月汇总 |
|
||||
| `dws.dws_assistant_salary_calc` | 薪资计算 |
|
||||
| `dws.dws_assistant_customer_stats` | 助教客户统计 |
|
||||
| `dws.dws_assistant_order_contribution` | 助教订单流水（新建后映射） |
|
||||
| `dws.dws_assistant_finance_analysis` | 助教财务分析 |
|
||||
| `dws.dws_finance_daily_summary` | 财务日报 |
|
||||
| `dws.dws_finance_income_structure` | 收入结构 |
|
||||
| `dws.dws_finance_recharge_summary` | 充值汇总 |
|
||||
| `dws.dws_finance_discount_detail` | 折扣明细 |
|
||||
| `dws.dws_finance_expense_summary` | 支出汇总 |
|
||||
| `dws.dws_platform_settlement` | 平台结算 |
|
||||
| `dws.dws_assistant_recharge_commission` | 充值业绩归属 |
|
||||
| `dws.cfg_performance_tier` | 定档配置 |
|
||||
| `dws.cfg_assistant_level_price` | 助教等级单价 |
|
||||
| `dws.cfg_bonus_rules` | 奖金规则 |
|
||||
| `dws.cfg_index_parameters` | 指数参数配置 |
|
||||
| `dws.dws_order_summary` | 订单汇总 |
|
||||
|
||||
---
|
||||
332
docs/prd/specs/01-SPEC任务拆分总览.md
Normal file
332
docs/prd/specs/01-SPEC任务拆分总览.md
Normal file
@@ -0,0 +1,332 @@
|
||||
# SPEC 任务拆分总览
|
||||
|
||||
> 生成日期：2026-02-23
|
||||
> 按依赖优先级排序，按 SPEC 边界分组，面向 Kiro SPEC 工作流
|
||||
|
||||
---
|
||||
|
||||
## 执行顺序总览
|
||||
|
||||
```
|
||||
P1 基础设施层（数据库 Schema + FDW + RLS）
|
||||
P2 ETL 扩展层（DWS 新表 + 字段扩展 + SPI 指数）
|
||||
P3 用户认证层（微信登录 + 申请审核 + 权限体系）
|
||||
P4 核心业务层（任务系统 + 备注系统 + 触发器机制）
|
||||
P5 AI 集成层（百炼对接 + 对话系统 + 轮询缓存）
|
||||
P6 小程序前端-任务模块（task-list + task-detail + notes）
|
||||
P7 小程序前端-绩效模块（performance + performance-records）
|
||||
P8 小程序前端-看板模块（board-finance + board-customer + board-coach）
|
||||
P9 小程序前端-详情模块（customer-detail + coach-detail + chat）
|
||||
P10 租户管理后台（独立 Web 应用 + Excel 上传）
|
||||
P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## P1：基础设施层 — 数据库 Schema + FDW + RLS
|
||||
|
||||
### SPEC 名称建议：`miniapp-db-foundation`
|
||||
|
||||
### 需求概述
|
||||
为小程序建立完整的数据库基础设施，包括业务库 Schema 规划、ETL 库 RLS 视图层、FDW 外部表映射。这是所有后续 SPEC 的硬依赖。
|
||||
|
||||
### 关键交付物
|
||||
1. `test_zqyy_app` 新建 Schema：`auth`（用户认证）、`biz`（业务数据）
|
||||
2. `test_etl_feiqiu.app` Schema：为所有需要 FDW 映射的 DWS/DWD 表创建 RLS 视图（按 `site_id` 隔离）
|
||||
3. `test_zqyy_app.fdw_etl` Schema：创建全部 FDW 外部表（约 33 张，见数据依赖矩阵）
|
||||
4. 迁移脚本：`db/zqyy_app/migrations/` + `db/etl_feiqiu/migrations/`
|
||||
|
||||
### 依赖
|
||||
- 无前置依赖（第一个 SPEC）
|
||||
|
||||
### 验收标准
|
||||
- `fdw_etl` 下所有外部表可正常 SELECT
|
||||
- RLS 视图按 `site_id` 正确过滤
|
||||
- `auth` 和 `biz` Schema 存在且权限正确
|
||||
|
||||
---
|
||||
|
||||
## P2：ETL 扩展层 — DWS 新表 + 字段扩展 + SPI 指数
|
||||
|
||||
### SPEC 名称建议：`etl-dws-miniapp-extensions`
|
||||
|
||||
### 需求概述
|
||||
扩展 ETL 的 DWS 层以支持小程序的数据需求，包括新建 SPI 指数表、助教订单流水统计表，以及扩展现有表的字段。
|
||||
|
||||
### 关键交付物
|
||||
1. 新建 `dws.dws_member_spending_power_index`（SPI 消费力指数，含 Level/Speed/Stability 子分）
|
||||
2. 新建 `dws.dws_assistant_order_contribution`（助教订单流水四项统计）
|
||||
3. 扩展 `dws.dws_member_consumption_summary`：增加 30/60/90 天充值次数/金额、次均消费
|
||||
4. 扩展 `dws.dws_assistant_daily_detail`：增加定档折算惩罚字段
|
||||
5. 新建 ETL 任务：`SpendingPowerIndexTask`、`AssistantOrderContributionTask`
|
||||
6. 扩展现有 ETL 任务以填充新字段
|
||||
7. 更新 `app` Schema RLS 视图 + FDW 映射（新表）
|
||||
|
||||
### 依赖
|
||||
- P1（FDW 基础设施就绪后才能验证端到端）
|
||||
|
||||
### 验收标准
|
||||
- SPI 指数可正常计算并写入，展示分 0-10 分布合理
|
||||
- 四项助教流水统计数值正确（对照 PRD 示例验算）
|
||||
- 消费汇总表新字段有值
|
||||
- 定档折算惩罚字段在符合条件的订单上正确填充
|
||||
|
||||
### 四项统计命名方案（Q1.3）
|
||||
|
||||
| 序号 | 中文名 | 英文字段名 | 含义 |
|
||||
|------|--------|-----------|------|
|
||||
| 1 | 订单总流水 | `order_gross_revenue` | 助教参与订单的全部流水 |
|
||||
| 2 | 订单净流水 | `order_net_revenue` | 订单总流水 - 助教服务分成 |
|
||||
| 3 | 时效贡献流水 | `time_weighted_revenue` | 按服务时长折算的助教个人贡献 |
|
||||
| 4 | 时效净贡献 | `time_weighted_net_revenue` | 时效贡献流水 - 助教服务分成 |
|
||||
|
||||
---
|
||||
|
||||
## P3：用户认证层 — 微信登录 + 申请审核 + 权限体系
|
||||
|
||||
### SPEC 名称建议：`miniapp-auth-system`
|
||||
|
||||
### 需求概述
|
||||
构建小程序的完整用户认证体系，包括微信登录、用户申请、审核流程、RBAC 权限、用户-助教绑定。
|
||||
|
||||
### 关键交付物
|
||||
1. 新建表：`auth.users`（重构，增加 wx_openid、status、site_id 等）、`auth.user_applications`、`auth.site_code_mapping`、`auth.user_assistant_binding`
|
||||
2. 重构现有 `public.roles`、`public.permissions`、`public.user_roles`、`public.role_permissions` 迁移至 `auth` Schema
|
||||
3. 后端 API：微信 code2Session 登录、用户申请提交、JWT 签发
|
||||
4. 后端 API：用户状态查询（审核中/通过/拒绝）
|
||||
5. 权限中间件：基于角色的 API 访问控制
|
||||
|
||||
### 依赖
|
||||
- P1（`auth` Schema 已创建）
|
||||
|
||||
### 验收标准
|
||||
- 微信登录 → 新用户自动创建申请记录
|
||||
- 申请状态正确流转（pending → approved/rejected）
|
||||
- JWT 签发与验证正常
|
||||
- 权限中间件正确拦截无权请求
|
||||
|
||||
---
|
||||
|
||||
## P4：核心业务层 — 任务系统 + 备注系统 + 触发器机制
|
||||
|
||||
### SPEC 名称建议：`miniapp-core-business`
|
||||
|
||||
### 需求概述
|
||||
实现小程序的核心业务逻辑：助教任务生成/管理、备注系统、后台触发器/轮询机制。
|
||||
|
||||
### 关键交付物
|
||||
|
||||
#### 任务系统
|
||||
1. 新建表：`biz.coach_tasks`、`biz.coach_task_history`
|
||||
2. 任务生成器：每日 4:00 后运行，基于指数计算为每个助教分配任务
|
||||
3. 任务类型：高优先召回、优先召回、客户回访、关系构建（优先级从高到低）
|
||||
4. 任务状态机：有效/无效 + 有效期机制
|
||||
5. 48 小时回访滞留逻辑
|
||||
6. 召回完成检测（ETL 数据到达后自动标记）
|
||||
7. 数据回溯机制（召回完成后回溯备注分类）
|
||||
8. 任务置顶/放弃 API
|
||||
|
||||
#### 备注系统
|
||||
9. 新建表：`biz.notes`（type 区分：普通/回访/生日/放弃原因）
|
||||
10. 备注 CRUD API
|
||||
11. 生日信息隔离存储（不被 ETL 数据覆盖）
|
||||
|
||||
#### 触发器机制
|
||||
12. 新建表：`biz.trigger_jobs`（触发器配置与执行日志）
|
||||
13. 轮询调度框架：支持按条件触发（数据变更、定时、事件驱动）
|
||||
14. 任务状态轮询（每小时检查有效期）
|
||||
|
||||
### 依赖
|
||||
- P1（数据库基础）
|
||||
- P2（指数数据可用，用于任务生成器）
|
||||
- P3（用户认证，知道当前助教身份）
|
||||
|
||||
### 验收标准
|
||||
- 任务生成器正确按指数分配 4 种类型任务
|
||||
- 同客户-助教-类型跳过，不同类型关闭旧任务+新建
|
||||
- 48 小时滞留机制正常工作
|
||||
- 召回完成后自动标记任务完成
|
||||
- 数据回溯正确将普通备注重分类为回访备注
|
||||
- 备注 CRUD 正常，生日信息独立存储
|
||||
|
||||
---
|
||||
|
||||
## P5：AI 集成层 — 百炼对接 + 对话系统 + 轮询缓存
|
||||
|
||||
### SPEC 名称建议：`miniapp-ai-integration`
|
||||
|
||||
### 需求概述
|
||||
对接阿里云百炼 6 个 AI 应用，实现对话系统、后台轮询缓存、备注含金量评分。
|
||||
|
||||
### 关键交付物
|
||||
1. 新建表：`biz.ai_conversations`、`biz.ai_messages`、`biz.ai_cache`
|
||||
2. 百炼 API 封装：统一调用层（支持流式/非流式）
|
||||
3. 应用 1：通用对话 API（SSE 流式返回）
|
||||
4. 应用 2：财务洞察轮询任务（每日更新，多时间维度交叉）
|
||||
5. 应用 3：客户消费习惯分析轮询（客户新增消费时触发）
|
||||
6. 应用 4：客户-助教关系分析轮询（助教参与新结算时触发）
|
||||
7. 应用 5：话术参考（应用 4 调用时联动）
|
||||
8. 应用 6：备注含金量评分（回访任务完成时触发）
|
||||
9. AI 结果缓存读写 API
|
||||
10. 页面内容文本化工具（将页面数据转为 AI 可读文本）
|
||||
|
||||
### 依赖
|
||||
- P3（用户身份，AI 信息隔离需要传入身份参数）
|
||||
- P4（备注系统 + 触发器机制，应用 6 依赖回访任务完成事件）
|
||||
|
||||
### 验收标准
|
||||
- 应用 1 流式对话正常
|
||||
- 应用 2-5 轮询任务按条件触发并缓存结果
|
||||
- 应用 6 在回访备注提交后自动评分，6 分以上标记完成
|
||||
- 所有 AI 对话记录持久化（含系统调用）
|
||||
|
||||
---
|
||||
|
||||
## P6：小程序前端 — 任务模块
|
||||
|
||||
### SPEC 名称建议：`miniapp-fe-tasks`
|
||||
|
||||
### 需求概述
|
||||
实现小程序任务相关页面：task-list、task-detail、notes。
|
||||
|
||||
### 关键交付物
|
||||
1. task-list.html → 小程序页面：任务列表（按优先级分组）、长按操作（置顶/放弃/AI）、绩效计算展示、跳档激励
|
||||
2. task-detail.html → 小程序页面：任务详情、近期服务记录、备注入口、AI 分析展示（消费习惯/关系分析/话术/备注星级）
|
||||
3. notes.html → 小程序页面：备注列表、删除（二次确认）
|
||||
4. 通用组件：爱心 icon（💖🧡💛💙）、喜好标签（🎱斯🀅🎤）、跟/弃 icon、预估标记
|
||||
|
||||
### 依赖
|
||||
- P3（登录态）
|
||||
- P4（任务/备注 API）
|
||||
- P5（AI 缓存数据展示）
|
||||
|
||||
---
|
||||
|
||||
## P7：小程序前端 — 绩效模块
|
||||
|
||||
### SPEC 名称建议：`miniapp-fe-performance`
|
||||
|
||||
### 需求概述
|
||||
实现绩效相关页面：performance、performance-records。
|
||||
|
||||
### 关键交付物
|
||||
1. performance.html → 小程序页面：收入与业绩档位、服务记录明细（按天归总）、我的新客、我的常客
|
||||
2. performance-records.html → 小程序页面：按口径展示全部业绩、定档折算惩罚展示
|
||||
3. 后端 API：绩效数据聚合查询（按天/月归总）
|
||||
|
||||
### 依赖
|
||||
- P3（登录态）
|
||||
- P2（定档折算字段）
|
||||
|
||||
---
|
||||
|
||||
## P8：小程序前端 — 看板模块
|
||||
|
||||
### SPEC 名称建议：`miniapp-fe-boards`
|
||||
|
||||
### 需求概述
|
||||
实现三个看板页面：board-finance、board-customer、board-coach。
|
||||
|
||||
### 关键交付物
|
||||
1. board-finance.html → 小程序页面：财务数据展示、多维度筛选交叉、环比、AI 洞察、预收资产条件隐藏
|
||||
2. board-customer.html → 小程序页面：8 个维度筛选（最应召回/最大消费潜力/最高余额/最近充值/最高消费/最频繁/最近到店/最专一）、类型筛选、前 100 名列表
|
||||
3. board-coach.html → 小程序页面：维度筛选（定档业绩/工资/高客源储值/任务完成）、项目筛选、日期维度筛选
|
||||
4. 后端 API：看板数据聚合查询 + 缓存层
|
||||
5. 通用组件：时间筛选器、维度筛选器、环比展示
|
||||
|
||||
### 依赖
|
||||
- P3（登录态 + 权限控制看板可见性）
|
||||
- P2（SPI 指数用于"最大消费潜力"排序）
|
||||
- P5（AI 财务洞察缓存）
|
||||
|
||||
---
|
||||
|
||||
## P9：小程序前端 — 详情与对话模块
|
||||
|
||||
### SPEC 名称建议：`miniapp-fe-details`
|
||||
|
||||
### 需求概述
|
||||
实现详情页和 AI 对话页：customer-detail、coach-detail、customer-service-records、chat、chat-history。
|
||||
|
||||
### 关键交付物
|
||||
1. customer-detail.html → 小程序页面：客户信息、消费记录（台桌/商城/充值三种样式）、指数总览、备注、AI 入口
|
||||
2. coach-detail.html → 小程序页面：助教信息、客户数、工龄、备注
|
||||
3. customer-service-records.html → 小程序页面：服务记录列表
|
||||
4. chat.html → 小程序页面：AI 对话（流式展示）、来源展示、历史消息
|
||||
5. chat-history.html → 小程序页面：对话历史列表
|
||||
6. 后端 API：消费记录分页查询（懒加载，每次 10 条）
|
||||
|
||||
### 依赖
|
||||
- P3（登录态）
|
||||
- P5（AI 对话系统）
|
||||
- P4（备注系统）
|
||||
|
||||
---
|
||||
|
||||
## P10：租户管理后台
|
||||
|
||||
### SPEC 名称建议：`tenant-admin-web`
|
||||
|
||||
### 需求概述
|
||||
独立的租户管理 Web 应用，提供用户审核、用户管理、Excel 数据上传功能。
|
||||
|
||||
### 关键交付物
|
||||
1. 独立 Web 应用（React + Vite + Ant Design，类似 `apps/admin-web/` 技术栈）
|
||||
2. 租户管理员登录（独立凭据体系）
|
||||
3. 用户审核页面：申请列表、状态筛选、关联建议（球房ID+手机号匹配助教）、审核操作
|
||||
4. 用户管理页面：用户列表、身份编辑、店铺归属编辑
|
||||
5. Excel 上传页面：4 种模板（财务支出/团购收入/助教奖罚/充值业绩归属）
|
||||
6. Excel 校验：必填、金额精度、表头格式、类型合法
|
||||
7. 冲突处理：前端 diff 交互（逐条确认替换/保留）
|
||||
8. 后端 API：Excel 解析、校验、冲突检测、确认写入
|
||||
9. 新建表：`biz.salary_adjustments`、`biz.excel_upload_log`
|
||||
|
||||
### 依赖
|
||||
- P1（数据库基础）
|
||||
- P3（用户体系，共享 `auth` Schema）
|
||||
|
||||
### 验收标准
|
||||
- 租户管理员只能看到自己租户下的店铺数据
|
||||
- Excel 上传校验正确，冲突 diff 交互可用
|
||||
- 用户审核流程完整（申请→审核→分配身份→关联助教）
|
||||
|
||||
---
|
||||
|
||||
## P11：部署与上线
|
||||
|
||||
### SPEC 名称建议：`deployment-launch`
|
||||
|
||||
### 需求概述
|
||||
完成部署环境配置、监控、灰度上线。参考 `docs/deployment/LAUNCH-CHECKLIST.md`。
|
||||
|
||||
### 关键交付物
|
||||
1. 生产环境数据库初始化（`etl_feiqiu` + `zqyy_app`）
|
||||
2. FDW 生产环境配置
|
||||
3. 后端部署（FastAPI + Uvicorn）
|
||||
4. 小程序审核与发布
|
||||
5. 租户管理后台部署
|
||||
6. ETL 定时调度配置（每小时增量）
|
||||
7. 监控与告警
|
||||
8. 灰度上线方案
|
||||
|
||||
### 依赖
|
||||
- P1-P10 全部完成
|
||||
|
||||
---
|
||||
|
||||
## 附：SPEC 依赖关系图
|
||||
|
||||
```
|
||||
P1 ─────┬──→ P2 ──→ P7
|
||||
│ ↘
|
||||
├──→ P3 ──→ P4 ──→ P5 ──→ P6
|
||||
│ │ ↗ ↘
|
||||
│ └──→ P10 P8 ←── P9
|
||||
│
|
||||
└──→ P11（全部完成后）
|
||||
```
|
||||
|
||||
可并行的 SPEC 组合：
|
||||
- P2 和 P3 可并行（无互相依赖）
|
||||
- P6、P7、P8、P9 在后端 API 就绪后可部分并行
|
||||
- P10 在 P1+P3 完成后即可启动，与 P4-P9 并行
|
||||
63
docs/prd/specs/P1-miniapp-db-foundation.md
Normal file
63
docs/prd/specs/P1-miniapp-db-foundation.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# P1：基础设施层 — miniapp-db-foundation
|
||||
|
||||
> 优先级：P1（最高，无前置依赖）
|
||||
> 预估工作量：中等
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为后端开发者，我需要 `test_zqyy_app` 中有清晰的 Schema 划分（`auth` + `biz`），以便按功能组织业务表。
|
||||
2. 作为后端开发者，我需要通过 FDW 从 `test_zqyy_app` 读取 ETL 库的 DWS/DWD 数据，以便小程序页面展示 ETL 计算结果。
|
||||
3. 作为系统管理员，我需要 RLS 视图按 `site_id` 隔离数据，以便多门店数据安全。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：`test_zqyy_app` 中存在 `auth` 和 `biz` 两个 Schema，权限配置正确
|
||||
- AC2：`test_etl_feiqiu.app` Schema 中为数据依赖矩阵列出的所有表创建了 RLS 视图
|
||||
- AC3：`test_zqyy_app.fdw_etl` 中所有外部表可正常 `SELECT`，数据与源表一致
|
||||
- AC4：RLS 视图在设置 `app.current_site_id` 后正确过滤数据
|
||||
- AC5：所有变更有对应的迁移脚本（`db/zqyy_app/migrations/` + `db/etl_feiqiu/migrations/`）
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### Schema 规划
|
||||
|
||||
```
|
||||
test_zqyy_app
|
||||
├── auth — 用户认证、权限、映射
|
||||
├── biz — 业务数据（任务、备注、AI、Excel）
|
||||
├── fdw_etl — FDW 外部表（只读，映射 ETL app schema）
|
||||
└── public — 保留现有系统管理表（admin_users 等）
|
||||
```
|
||||
|
||||
### RLS 实现方案
|
||||
|
||||
```sql
|
||||
-- ETL 库 app schema 示例
|
||||
CREATE VIEW app.v_dws_member_consumption_summary AS
|
||||
SELECT * FROM dws.dws_member_consumption_summary
|
||||
WHERE site_id = current_setting('app.current_site_id')::bigint;
|
||||
```
|
||||
|
||||
### FDW 映射
|
||||
|
||||
- 使用 `postgres_fdw` 扩展
|
||||
- 外部服务器指向 `test_etl_feiqiu`
|
||||
- 外部表映射 `app` schema 的 RLS 视图（而非直接映射 dws/dwd 表）
|
||||
- 映射表清单见 `00-数据依赖矩阵.md` 第四节
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `auth` 和 `biz` Schema + 权限配置
|
||||
- [ ] T2：在 `test_etl_feiqiu.app` 中创建全部 RLS 视图（约 33 张）
|
||||
- [ ] T3：配置 `postgres_fdw` 外部服务器和用户映射
|
||||
- [ ] T4：在 `fdw_etl` 中创建全部外部表
|
||||
- [ ] T5：编写验证脚本（检查所有外部表可查询）
|
||||
- [ ] T6：编写迁移脚本并归档
|
||||
133
docs/prd/specs/P10-tenant-admin-web.md
Normal file
133
docs/prd/specs/P10-tenant-admin-web.md
Normal file
@@ -0,0 +1,133 @@
|
||||
# P10：租户管理后台 — tenant-admin-web
|
||||
|
||||
> 优先级：P10（依赖 P1 + P3，可与 P4-P9 并行）
|
||||
> 预估工作量：中等
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为租户管理员，我需要独立的 Web 管理后台来审核用户申请。
|
||||
2. 作为租户管理员，我需要管理用户（编辑身份、店铺归属、关联助教）。
|
||||
3. 作为租户管理员，我需要上传 Excel 数据（财务支出/团购收入/助教奖罚/充值业绩归属）。
|
||||
4. 作为租户管理员，上传 Excel 时如果发现主键冲突，我需要逐条确认替换或保留（类似 diff 交互）。
|
||||
5. 作为系统，租户管理员只能看到自己租户下的店铺数据。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：租户管理后台是独立 Web 应用，独立登录入口
|
||||
- AC2：租户管理员只能看到自己租户下的店铺和用户
|
||||
- AC3：用户审核页面：申请列表、状态筛选、球房ID+手机号关联建议、审核操作
|
||||
- AC4：Excel 上传校验：必填、金额精度、表头格式、类型合法
|
||||
- AC5：主键冲突时前端展示 diff 交互，逐条确认后保存
|
||||
- AC6：助教奖罚支持同一助教同月多笔
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### 技术栈
|
||||
|
||||
- 独立 Web 应用：React + Vite + Ant Design（与 `apps/admin-web/` 同技术栈）
|
||||
- 部署路径：`apps/tenant-admin/`
|
||||
- 后端复用 `apps/backend/` 的 FastAPI，新增租户管理路由模块
|
||||
|
||||
### 登录体系
|
||||
|
||||
- 独立凭据：每个租户有若干管理员账号（用户名+密码）
|
||||
- 租户级管理员：可管理租户下所有店铺
|
||||
- 店铺级管理员：只能管理指定店铺
|
||||
- 与系统管理后台（`apps/admin-web/`）完全隔离
|
||||
|
||||
### Excel 4 种模板
|
||||
|
||||
#### 1. 财务支出（按月）
|
||||
|
||||
| 列名 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 月份 | YYYY-MM | 是 | 提交月份 |
|
||||
| 支出类别 | 文本 | 是 | 房租/水电/物业/食品饮料进货/耗材/报销/固定人员工资/其他费用 |
|
||||
| 金额 | 数值(2) | 是 | 支出金额 |
|
||||
| 备注 | 文本 | 否 | |
|
||||
|
||||
主键：月份 + 支出类别
|
||||
|
||||
#### 2. 团购平台收入（按月）
|
||||
|
||||
| 列名 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 月份 | YYYY-MM | 是 | |
|
||||
| 平台名称 | 文本 | 是 | |
|
||||
| 收入金额 | 数值(2) | 是 | |
|
||||
| 备注 | 文本 | 否 | |
|
||||
|
||||
主键：月份 + 平台名称
|
||||
|
||||
#### 3. 助教奖罚（按月）
|
||||
|
||||
| 列名 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 月份 | YYYY-MM | 是 | |
|
||||
| 助教姓名 | 文本 | 是 | |
|
||||
| 助教编号 | 文本 | 是 | |
|
||||
| 类型 | 文本 | 是 | 扣款/奖金 |
|
||||
| 金额 | 数值(2) | 是 | |
|
||||
| 原因 | 文本 | 是 | |
|
||||
|
||||
主键：月份 + 助教姓名 + 助教编号 + 类型 + 原因（同一助教同月可多笔）
|
||||
|
||||
#### 4. 充值业绩归属（按月）
|
||||
|
||||
| 列名 | 类型 | 必填 | 说明 |
|
||||
|------|------|------|------|
|
||||
| 充值日期 | YYYY-MM-DD | 是 | |
|
||||
| 会员名称 | 文本 | 是 | |
|
||||
| 充值金额 | 数值(2) | 是 | |
|
||||
| 归属助教 | 文本 | 是 | |
|
||||
| 奖励金额 | 数值(2) | 是 | |
|
||||
|
||||
主键：充值日期 + 会员名称 + 归属助教
|
||||
|
||||
### 冲突处理流程
|
||||
|
||||
```
|
||||
上传 Excel → 后端解析+校验 → 返回校验结果
|
||||
├── 无冲突 → 直接写入
|
||||
└── 有冲突 → 返回冲突列表（旧值 vs 新值）
|
||||
→ 前端展示 diff 交互
|
||||
→ 用户逐条选择"替换"或"保留"
|
||||
→ 提交确认 → 后端按选择写入
|
||||
```
|
||||
|
||||
### 新建表
|
||||
|
||||
```
|
||||
biz.salary_adjustments
|
||||
- id, site_id, assistant_id, assistant_name, assistant_number
|
||||
- salary_month, adjustment_type (deduction/bonus)
|
||||
- amount, reason
|
||||
- upload_batch_id, created_at
|
||||
|
||||
biz.excel_upload_log
|
||||
- id, site_id, upload_type (expense/platform_income/salary_adj/recharge_commission)
|
||||
- file_name, uploaded_by, row_count
|
||||
- conflict_count, resolved_count
|
||||
- status (pending/confirmed/failed)
|
||||
- created_at
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `apps/tenant-admin/` 项目骨架（React + Vite + Ant Design）
|
||||
- [ ] T2：实现租户管理员登录（独立凭据）
|
||||
- [ ] T3：实现用户审核页面（申请列表 + 状态筛选 + 关联建议 + 审核操作）
|
||||
- [ ] T4：实现用户管理页面（用户列表 + 身份编辑 + 店铺归属）
|
||||
- [ ] T5：创建 `biz.salary_adjustments` + `biz.excel_upload_log` 表
|
||||
- [ ] T6：实现 Excel 上传后端（解析 + 校验 + 冲突检测）
|
||||
- [ ] T7：实现 Excel 上传前端（模板下载 + 上传 + diff 交互 + 确认）
|
||||
- [ ] T8：实现 4 种 Excel 模板的校验规则
|
||||
- [ ] T9：实现助教姓名+编号匹配校验（对照 `dim_assistant`）
|
||||
59
docs/prd/specs/P11-deployment-launch.md
Normal file
59
docs/prd/specs/P11-deployment-launch.md
Normal file
@@ -0,0 +1,59 @@
|
||||
# P11：部署与上线 — deployment-launch
|
||||
|
||||
> 优先级：P11（依赖 P1-P10 全部完成）
|
||||
> 预估工作量：中等
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为运维，我需要将全部系统部署到生产环境并完成上线。
|
||||
2. 作为运维，我需要监控系统运行状态和告警。
|
||||
3. 作为产品经理，我需要灰度上线方案以降低风险。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：生产环境数据库初始化完成（`etl_feiqiu` + `zqyy_app`）
|
||||
- AC2：FDW 生产环境配置正确
|
||||
- AC3：后端 API 可正常访问
|
||||
- AC4：小程序审核通过并发布
|
||||
- AC5：租户管理后台可正常访问
|
||||
- AC6：ETL 定时调度正常运行（每小时增量）
|
||||
- AC7：监控告警配置完成
|
||||
|
||||
---
|
||||
|
||||
## 关键交付物
|
||||
|
||||
1. 生产环境数据库初始化脚本
|
||||
2. FDW 生产环境配置（`etl_feiqiu` → `zqyy_app`）
|
||||
3. 后端部署配置（FastAPI + Uvicorn + Nginx）
|
||||
4. 小程序审核材料准备与提交
|
||||
5. 租户管理后台部署
|
||||
6. ETL 定时调度配置（cron / systemd timer）
|
||||
7. 监控方案（数据库连接、API 响应、ETL 执行状态）
|
||||
8. 灰度上线方案（先单店 → 多店 → 全量）
|
||||
9. 回滚方案
|
||||
|
||||
---
|
||||
|
||||
## 参考
|
||||
|
||||
- 现有部署清单：`docs/deployment/LAUNCH-CHECKLIST.md`
|
||||
- 环境配置：`.env.template`
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：生产环境数据库初始化（Schema + 表 + 种子数据）
|
||||
- [ ] T2：生产环境 FDW 配置
|
||||
- [ ] T3：后端部署（含 HTTPS、CORS、JWT 生产配置）
|
||||
- [ ] T4：小程序审核与发布
|
||||
- [ ] T5：租户管理后台部署
|
||||
- [ ] T6：ETL 定时调度配置
|
||||
- [ ] T7：监控与告警配置
|
||||
- [ ] T8：灰度上线执行
|
||||
- [ ] T9：更新 `LAUNCH-CHECKLIST.md`
|
||||
69
docs/prd/specs/P2-etl-dws-miniapp-extensions.md
Normal file
69
docs/prd/specs/P2-etl-dws-miniapp-extensions.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# P2：ETL 扩展层 — etl-dws-miniapp-extensions
|
||||
|
||||
> 优先级：P2（依赖 P1）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为产品经理，我需要 SPI 消费力指数来评估客户消费层级，替代现有的 `customer_tier` 分层。
|
||||
2. 作为产品经理，我需要助教订单流水四项统计（订单总流水/订单净流水/时效贡献流水/时效净贡献），以便评估助教个人能力。
|
||||
3. 作为产品经理，我需要客户 30/60/90 天充值次数和金额、次均消费，以便在客户看板中展示。
|
||||
4. 作为产品经理，我需要定档折算惩罚数据，以便在绩效页面展示折算详情。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：`dws_member_spending_power_index` 表存在，SPI 展示分 0-10 分布合理
|
||||
- AC2：`dws_assistant_order_contribution` 表存在，四项统计数值可对照 PRD 示例验算
|
||||
- AC3：`dws_member_consumption_summary` 新增字段有值（`recharge_count_30d/60d/90d`、`recharge_amount_30d/60d/90d`、`avg_ticket_amount`）
|
||||
- AC4：`dws_assistant_daily_detail` 新增字段在符合惩罚条件的订单上正确填充
|
||||
- AC5：新表的 RLS 视图和 FDW 映射已同步创建
|
||||
- AC6：`cfg_index_parameters` 中新增 `SPI` 类型的配置行
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### SPI 指数
|
||||
- 完整算法见 `docs/prd/SPI 消费力指数.md`
|
||||
- 新建 ETL 任务 `SpendingPowerIndexTask`，继承 `BaseIndexTask`
|
||||
- 粒度：`(site_id, member_id)`，每日计算
|
||||
|
||||
### 助教订单流水四项统计
|
||||
- 新建 ETL 任务 `AssistantOrderContributionTask`
|
||||
- 粒度：`(site_id, assistant_id, stat_date)`
|
||||
- 计算逻辑见 PRD "新增统计"节
|
||||
|
||||
### 命名方案
|
||||
|
||||
| 中文名 | 字段名 | 含义 |
|
||||
|--------|--------|------|
|
||||
| 订单总流水 | `order_gross_revenue` | 助教参与订单的全部流水 |
|
||||
| 订单净流水 | `order_net_revenue` | 总流水 - 助教服务分成 |
|
||||
| 时效贡献流水 | `time_weighted_revenue` | 按服务时长折算的个人贡献 |
|
||||
| 时效净贡献 | `time_weighted_net_revenue` | 时效贡献 - 助教服务分成 |
|
||||
|
||||
### 定档折算惩罚
|
||||
- 扩展 `dws_assistant_daily_detail`：`penalty_minutes`、`penalty_reason`、`is_exempt`、`per_hour_contribution`
|
||||
- 检测逻辑：同一台桌同一时段 >2 名助教 → 计算单人贡献流水 → <24 元则按比例折算
|
||||
- 豁免标记：在订单级别打标（`is_exempt` 字段）
|
||||
- 每日 ETL 自动计算
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：设计并创建 `dws_member_spending_power_index` 表
|
||||
- [ ] T2：实现 `SpendingPowerIndexTask`（含 Level/Speed/Stability 子分）
|
||||
- [ ] T3：在 `cfg_index_parameters` 中插入 SPI 默认参数
|
||||
- [ ] T4：设计并创建 `dws_assistant_order_contribution` 表
|
||||
- [ ] T5：实现 `AssistantOrderContributionTask`
|
||||
- [ ] T6：扩展 `dws_member_consumption_summary`（充值窗口 + 次均消费字段）
|
||||
- [ ] T7：修改 `MemberConsumptionSummaryTask` 填充新字段
|
||||
- [ ] T8：扩展 `dws_assistant_daily_detail`（定档折算惩罚字段）
|
||||
- [ ] T9：实现定档折算惩罚检测与计算逻辑
|
||||
- [ ] T10：为新表创建 RLS 视图 + FDW 映射
|
||||
- [ ] T11：影子跑数验证（SPI 分布、流水统计对账）
|
||||
88
docs/prd/specs/P3-miniapp-auth-system.md
Normal file
88
docs/prd/specs/P3-miniapp-auth-system.md
Normal file
@@ -0,0 +1,88 @@
|
||||
# P3：用户认证层 — miniapp-auth-system
|
||||
|
||||
> 优先级：P3（依赖 P1，可与 P2 并行）
|
||||
> 预估工作量：中等
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为球房工作人员，我需要通过微信登录小程序，首次登录时填写申请表单（球房ID、申请身份、手机号、编号、昵称）。
|
||||
2. 作为租户管理员，我需要审核用户申请，将用户关联到对应的助教/员工，并分配身份权限。
|
||||
3. 作为系统，我需要通过球房ID+手机号自动建议用户与助教的对应关系。
|
||||
4. 作为用户，我需要看到自己的申请状态（审核中/通过/拒绝）。
|
||||
5. 作为用户，我可以同时属于多个店铺（连锁场景），权限按店铺独立。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：微信 code2Session 登录正常，返回 JWT
|
||||
- AC2：新用户首次登录后进入申请页面，提交后状态为 pending
|
||||
- AC3：管理员审核通过后，用户状态变为 approved，可正常访问小程序
|
||||
- AC4：球房ID 不存在时，申请仍可提交，管理端显示"未找到关联信息"
|
||||
- AC5：权限中间件正确拦截无权请求（如助教不能看财务看板）
|
||||
- AC6：一个用户可关联多个店铺，切换店铺后数据正确隔离
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### 表结构
|
||||
|
||||
```
|
||||
auth.users
|
||||
- id, wx_openid, wx_union_id, wx_avatar_url, nickname, phone
|
||||
- status (pending/approved/rejected/disabled)
|
||||
- created_at, updated_at
|
||||
|
||||
auth.user_applications
|
||||
- id, user_id, site_code (球房ID文本), applied_role_text (自由文本)
|
||||
- employee_number (选填), status, reviewer_id, review_note
|
||||
- created_at, reviewed_at
|
||||
|
||||
auth.site_code_mapping
|
||||
- id, site_code (2字母+3数字), site_id (ETL bigint), site_name
|
||||
- tenant_id, created_at
|
||||
|
||||
auth.user_site_roles
|
||||
- id, user_id, site_id, role_id
|
||||
- created_at
|
||||
|
||||
auth.user_assistant_binding
|
||||
- id, user_id, site_id, assistant_id (ETL dim_assistant)
|
||||
- binding_type (assistant/staff/manager)
|
||||
- created_at
|
||||
```
|
||||
|
||||
### 权限列表（固定）
|
||||
|
||||
| 权限 code | 说明 |
|
||||
|-----------|------|
|
||||
| `view_tasks` | 任务板块可见 |
|
||||
| `view_board` | 看板板块可见 |
|
||||
| `view_board_finance` | 财务板块可见 |
|
||||
| `view_board_customer` | 客户板块可见 |
|
||||
| `view_board_coach` | 助教板块可见 |
|
||||
|
||||
### 租户层级
|
||||
|
||||
```
|
||||
租户 (tenant)
|
||||
└── 店铺 (site) ← site_code 映射
|
||||
└── 用户 (user) ← 可属于多个 site
|
||||
└── 角色 (role) ← 按 site 独立分配
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `auth` Schema 下全部表（users, user_applications, site_code_mapping, user_site_roles, user_assistant_binding）
|
||||
- [ ] T2：迁移现有 RBAC 表到 `auth` Schema（或保留 public 但建立关联）
|
||||
- [ ] T3：实现微信 code2Session 登录 API
|
||||
- [ ] T4：实现用户申请提交 API
|
||||
- [ ] T5：实现 JWT 签发与刷新
|
||||
- [ ] T6：实现权限中间件（基于 user_site_roles）
|
||||
- [ ] T7：实现用户状态查询 API
|
||||
- [ ] T8：种子数据：预置权限列表和默认角色
|
||||
102
docs/prd/specs/P4-miniapp-core-business.md
Normal file
102
docs/prd/specs/P4-miniapp-core-business.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# P4：核心业务层 — miniapp-core-business
|
||||
|
||||
> 优先级：P4（依赖 P1 + P2 + P3）
|
||||
> 预估工作量：大（本 SPEC 是业务核心）
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我每天打开小程序能看到系统为我分配的任务列表，按优先级排序。
|
||||
2. 作为助教，我可以置顶/放弃任务，放弃时必须填写原因。
|
||||
3. 作为助教，我完成召回任务后（客户到店被服务），系统自动标记任务完成。
|
||||
4. 作为助教，我给客户添加回访备注后，系统自动评估备注含金量（≥6 分算完成）。
|
||||
5. 作为系统，回访任务至少保留 48 小时，到期后自动失效。
|
||||
6. 作为系统，当 ETL 数据延迟导致召回完成晚于备注提交时，需要回溯重分类备注。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：任务生成器每日 4:00 后运行，正确按 max(WBI,NCI) 分配 4 种任务类型
|
||||
- AC2：同客户-助教-类型的任务跳过；不同类型则关闭旧任务+新建
|
||||
- AC3：回访任务 48 小时滞留机制正常（生成时间算起）
|
||||
- AC4：任务有效/无效状态 + 有效期字段正确流转
|
||||
- AC5：召回完成检测在 ETL 数据到达后自动触发
|
||||
- AC6：数据回溯将普通备注重分类为回访备注并触发 AI 评分
|
||||
- AC7：备注 CRUD 正常，type 字段正确区分
|
||||
- AC8：生日信息独立于 ETL 数据，不被覆盖
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### 任务类型与优先级
|
||||
|
||||
| 优先级 | 类型 | 触发条件 | 完成条件 |
|
||||
|--------|------|---------|---------|
|
||||
| 0 | 高优先召回 | max(WBI,NCI) > 7 | 助教为该客户服务（ETL 检测） |
|
||||
| 0 | 优先召回 | max(WBI,NCI) > 5 | 同上 |
|
||||
| 1 | 客户回访 | 完成召回后未备注 | 提交备注且 AI 评分 ≥ 6 |
|
||||
| 2 | 关系构建 | RS < 6 | 无自动完成条件（手动标记或指数变化） |
|
||||
|
||||
### 任务状态机
|
||||
|
||||
```
|
||||
[生成] → 有效(无有效期)
|
||||
├── 类型变更 → 旧任务无效(无有效期) + 新任务有效
|
||||
├── 指数不再满足 → 有效(填充有效期=生成时间+48h)
|
||||
│ └── 轮询检查 → 超过有效期 → 无效
|
||||
├── 新回访任务顶替 → 旧任务无效 + 新任务有效
|
||||
├── 助教放弃 → 无效(记录放弃原因)
|
||||
└── 完成 → 已完成(记录完成时间和完成时状态)
|
||||
```
|
||||
|
||||
### coach_tasks 表核心字段
|
||||
|
||||
```
|
||||
biz.coach_tasks
|
||||
- id, site_id, assistant_id, member_id
|
||||
- task_type (high_priority_recall / priority_recall / follow_up_visit / relationship_building)
|
||||
- status (active / inactive / completed / abandoned)
|
||||
- priority_score (max(WBI,NCI) 快照)
|
||||
- expires_at (有效期，默认 NULL)
|
||||
- is_pinned (置顶)
|
||||
- abandon_reason (放弃原因)
|
||||
- completed_at, completed_task_type (完成时的任务类型快照)
|
||||
- parent_task_id (被顶替的旧任务 ID)
|
||||
- created_at, updated_at
|
||||
```
|
||||
|
||||
### 触发器机制
|
||||
|
||||
```
|
||||
biz.trigger_jobs
|
||||
- id, job_type, job_name
|
||||
- trigger_condition (cron / event / interval)
|
||||
- trigger_config (JSON: cron表达式 / 事件名 / 间隔秒数)
|
||||
- last_run_at, next_run_at
|
||||
- status (enabled / disabled)
|
||||
- created_at
|
||||
```
|
||||
|
||||
预置触发器：
|
||||
1. `task_generator` — cron: 每日 04:00
|
||||
2. `task_expiry_check` — interval: 每小时
|
||||
3. `recall_completion_check` — event: ETL 数据更新后
|
||||
4. `note_reclassify_backfill` — event: 召回完成时
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `biz.coach_tasks` + `biz.coach_task_history` 表
|
||||
- [ ] T2：创建 `biz.notes` 表（type: normal/follow_up/birthday/abandon_reason）
|
||||
- [ ] T3：创建 `biz.trigger_jobs` 表 + 轮询调度框架
|
||||
- [ ] T4：实现任务生成器（读取指数 → 分配任务 → 跳过/更新逻辑）
|
||||
- [ ] T5：实现 48 小时滞留机制 + 有效期轮询
|
||||
- [ ] T6：实现召回完成检测（ETL 数据到达后匹配 service_log）
|
||||
- [ ] T7：实现数据回溯机制（普通备注 → 回访备注 + 触发 AI 评分）
|
||||
- [ ] T8：实现任务 CRUD API（列表/详情/置顶/放弃/取消置顶/取消放弃）
|
||||
- [ ] T9：实现备注 CRUD API（创建/列表/删除）
|
||||
- [ ] T10：实现生日信息隔离存储逻辑
|
||||
96
docs/prd/specs/P5-miniapp-ai-integration.md
Normal file
96
docs/prd/specs/P5-miniapp-ai-integration.md
Normal file
@@ -0,0 +1,96 @@
|
||||
# P5：AI 集成层 — miniapp-ai-integration
|
||||
|
||||
> 优先级：P5（依赖 P3 + P4）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我可以在任意页面点击 AI 按钮，跳转到对话页面与 AI 交流，AI 了解当前页面上下文。
|
||||
2. 作为助教，我在任务详情页能看到 AI 生成的消费习惯分析、关系分析、话术参考。
|
||||
3. 作为助教，我提交回访备注后，系统自动通过 AI 评估备注含金量。
|
||||
4. 作为管理者，我在财务看板能看到 AI 生成的财务洞察分析。
|
||||
5. 作为系统，所有 AI 对话（含系统调用）都要持久化记录。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：应用 1 通用对话支持流式返回（SSE），前端逐字展示
|
||||
- AC2：应用 2 财务洞察每日自动更新，覆盖 8 个时间维度
|
||||
- AC3：应用 3 消费习惯在客户新增消费时自动更新
|
||||
- AC4：应用 4+5 在助教参与新结算时联动更新
|
||||
- AC5：应用 6 在回访备注提交后自动评分，返回 1-10 分 + 评价文本
|
||||
- AC6：所有 AI 调用记录持久化（conversation_id, message_id, app_id, user_id/系统, role, content, tokens_used, nickname, created_at, site_id）
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### 6 个 AI 应用
|
||||
|
||||
| 应用 | 用途 | 调用方式 | 触发条件 |
|
||||
|------|------|---------|---------|
|
||||
| 应用 1 | 通用对话 | 用户主动（流式） | 点击 AI 入口 |
|
||||
| 应用 2 | 财务洞察 | 后台轮询 | 每日 |
|
||||
| 应用 3 | 消费习惯分析 | 后台轮询 | 客户新增消费 |
|
||||
| 应用 4 | 关系分析/任务建议 | 后台轮询 | 助教参与新结算 |
|
||||
| 应用 5 | 话术参考 | 后台联动 | 应用 4 调用时 |
|
||||
| 应用 6 | 备注含金量 | 后台事件 | 回访任务完成时 |
|
||||
|
||||
### 信息隔离
|
||||
|
||||
应用 1 通过 `biz_params.user_prompt_params` 传入：
|
||||
- `User_ID`：当前用户 ID
|
||||
- `Role`：身份（助教/管理者）
|
||||
- `Nickname`：昵称
|
||||
|
||||
百炼平台侧根据参数做数据查询隔离。
|
||||
|
||||
### AI 入口汇总
|
||||
|
||||
所有入口统一使用应用 1，跳转 chat.html，第一条消息为页面上下文：
|
||||
|
||||
| 来源页面 | 触发方式 | 上下文内容 |
|
||||
|---------|---------|-----------|
|
||||
| task-list | 长按任务 → AI | 任务详情 + 客户-助教关系 |
|
||||
| task-detail / coach-detail / customer-detail | "问问助手" | 页面完整内容 |
|
||||
| board-* / performance-* / customer-service-records / my-profile | 右下角 AI 按钮 | 页面内容摘要 |
|
||||
|
||||
### 表结构
|
||||
|
||||
```
|
||||
biz.ai_conversations
|
||||
- id, user_id, nickname, app_id, site_id
|
||||
- source_page, source_context (JSON)
|
||||
- created_at
|
||||
|
||||
biz.ai_messages
|
||||
- id, conversation_id, role (user/assistant/system)
|
||||
- content, tokens_used
|
||||
- created_at
|
||||
|
||||
biz.ai_cache
|
||||
- id, cache_type (app2_finance/app3_habit/app4_analysis/app5_tactics/app6_score)
|
||||
- site_id, target_id (member_id 或 assistant_id 或 pair)
|
||||
- result_json, score (应用6专用)
|
||||
- triggered_by (trigger_job_id)
|
||||
- created_at, expires_at
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `biz.ai_conversations` + `biz.ai_messages` + `biz.ai_cache` 表
|
||||
- [ ] T2：实现百炼 API 统一封装层（流式/非流式、重试、日志）
|
||||
- [ ] T3：实现应用 1 通用对话 API（SSE 流式返回）
|
||||
- [ ] T4：实现页面内容文本化工具（各页面数据 → AI 可读文本）
|
||||
- [ ] T5：实现应用 2 财务洞察轮询任务
|
||||
- [ ] T6：实现应用 3 消费习惯分析轮询任务
|
||||
- [ ] T7：实现应用 4 关系分析轮询任务
|
||||
- [ ] T8：实现应用 5 话术参考联动任务
|
||||
- [ ] T9：实现应用 6 备注含金量评分（集成到回访完成事件）
|
||||
- [ ] T10：实现 AI 缓存读写 API（前端读取缓存结果）
|
||||
- [ ] T11：查阅百炼文档确认流式返回技术方案（SSE vs WebSocket）
|
||||
58
docs/prd/specs/P6-miniapp-fe-tasks.md
Normal file
58
docs/prd/specs/P6-miniapp-fe-tasks.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# P6：小程序前端 — 任务模块 — miniapp-fe-tasks
|
||||
|
||||
> 优先级：P6（依赖 P3 + P4 + P5）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我打开小程序首页看到按优先级排序的任务列表，高优先召回在最上面。
|
||||
2. 作为助教，我长按任务可以置顶、放弃（需填原因）、或问 AI。
|
||||
3. 作为助教，我点击任务进入详情页，看到客户信息、近期服务记录、AI 分析、备注入口。
|
||||
4. 作为助教，我在绩效区域看到当月业绩、档位、工资预估、跳档激励。
|
||||
5. 作为助教，我能管理自己的备注（查看、删除需二次确认）。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：任务列表按优先级 0→1→2 分组展示，每组内按分数降序
|
||||
- AC2：置顶任务固定在列表顶部，已放弃任务在独立列表
|
||||
- AC3：爱心 icon 正确展示（💖>8.5 / 🧡>7 / 💛>5 / 💙<5）
|
||||
- AC4：喜好标签正确展示（🎱/斯/🀅/🎤）
|
||||
- AC5：跟/弃 icon 正确展示
|
||||
- AC6：当月数据显示"预估"标记
|
||||
- AC7：跳档激励"到达XXX即得YYY"计算正确
|
||||
|
||||
---
|
||||
|
||||
## 页面清单
|
||||
|
||||
### task-list（任务列表 + 绩效）
|
||||
- 任务列表：优先级分组、长按操作
|
||||
- 绩效区域：当月业绩/档位/工资/跳档激励
|
||||
- 通用组件：爱心 icon、喜好标签、跟/弃 icon
|
||||
|
||||
### task-detail（任务详情）
|
||||
- 客户信息卡片
|
||||
- 近期服务记录（时间+时长）
|
||||
- AI 区域：消费习惯（应用3缓存）、关系分析+任务建议+一句话总结（应用4缓存）、话术参考（应用5缓存）、备注星级（应用6）
|
||||
- 备注入口（提交后触发回访完成判定）
|
||||
- "问问助手"按钮 → chat.html
|
||||
|
||||
### notes（备注管理）
|
||||
- 备注列表
|
||||
- 删除操作（二次确认弹窗）
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现 task-list 页面（任务列表 + 分组 + 排序）
|
||||
- [ ] T2：实现长按操作（置顶/放弃/AI）
|
||||
- [ ] T3：实现绩效展示区域（业绩/档位/工资/跳档激励）
|
||||
- [ ] T4：实现 task-detail 页面（客户信息 + 服务记录 + AI 区域）
|
||||
- [ ] T5：实现备注提交功能（集成回访完成判定）
|
||||
- [ ] T6：实现 notes 页面（列表 + 删除）
|
||||
- [ ] T7：实现通用组件（爱心 icon、喜好标签、跟/弃 icon、预估标记）
|
||||
67
docs/prd/specs/P7-miniapp-fe-performance.md
Normal file
67
docs/prd/specs/P7-miniapp-fe-performance.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# P7：小程序前端 — 绩效模块 — miniapp-fe-performance
|
||||
|
||||
> 优先级：P7（依赖 P2 + P3）
|
||||
> 预估工作量：中等
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我在绩效页面能看到当月收入、业绩档位、工资预估。
|
||||
2. 作为助教，我能看到本月/上月的服务记录明细，按天归总。
|
||||
3. 作为助教，我能看到"我的新客"（首次服务且 2 月内服务 ≤2 次的客户）和"我的常客"（2 月内服务次数最多的客户）。
|
||||
4. 作为助教，我在业绩明细页能看到每条服务的详情，包括定档折算惩罚展示。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：收入与业绩档位数据从 `dws_assistant_salary_calc` 正确读取
|
||||
- AC2：服务记录按天归总展示，支持本月/上月切换
|
||||
- AC3："我的新客"筛选逻辑正确（该助教首次服务 + 2 月内 + 服务次数 ≤2）
|
||||
- AC4："我的常客"按服务次数降序，展示次数、小时数、工资合计
|
||||
- AC5：业绩明细每条展示：结账时间、课程类型、台桌/房间、会员昵称、开始/结束时间、业绩分钟
|
||||
- AC6：有定档折算惩罚时展示"120分钟（定档折算30分钟）"格式
|
||||
- AC7：当月数据显示"预估"标记
|
||||
|
||||
---
|
||||
|
||||
## 页面清单
|
||||
|
||||
### performance（我的绩效）
|
||||
|
||||
- 收入与业绩档位卡片
|
||||
- 服务记录明细（按天归总，本月/上月切换）
|
||||
- 我的新客列表（按最后服务时间排列）
|
||||
- 我的常客列表（按服务次数降序）
|
||||
- 服务明细：按天/月归总整合数据
|
||||
|
||||
### performance-records（业绩明细）
|
||||
|
||||
- 口径选择（本月/上月/本周/上周等）
|
||||
- 业绩列表（每条含：结账时间、课程类型、台桌/房间、会员昵称、开始/结束时间、业绩分钟+折算展示）
|
||||
- 按天/月归总整合
|
||||
|
||||
---
|
||||
|
||||
## 后端 API 需求
|
||||
|
||||
| API | 说明 | 数据源 |
|
||||
|-----|------|--------|
|
||||
| `GET /api/performance/summary` | 当月绩效汇总 | `fdw_etl.dws_assistant_salary_calc` |
|
||||
| `GET /api/performance/service-records` | 服务记录明细（分页） | `fdw_etl.dwd_assistant_service_log` |
|
||||
| `GET /api/performance/my-new-customers` | 我的新客列表 | `fdw_etl.dws_assistant_customer_stats` |
|
||||
| `GET /api/performance/my-regulars` | 我的常客列表 | `fdw_etl.dws_assistant_customer_stats` |
|
||||
| `GET /api/performance/records` | 业绩明细（按口径） | `fdw_etl.dwd_assistant_service_log` + `fdw_etl.dws_assistant_daily_detail` |
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现绩效汇总 API（含定档、工资、档位）
|
||||
- [ ] T2：实现服务记录明细 API（按天归总 + 分页）
|
||||
- [ ] T3：实现我的新客/常客 API
|
||||
- [ ] T4：实现业绩明细 API（含定档折算惩罚字段）
|
||||
- [ ] T5：实现 performance 小程序页面
|
||||
- [ ] T6：实现 performance-records 小程序页面
|
||||
- [ ] T7：实现"预估"标记组件（当月/本周数据自动标记）
|
||||
85
docs/prd/specs/P8-miniapp-fe-boards.md
Normal file
85
docs/prd/specs/P8-miniapp-fe-boards.md
Normal file
@@ -0,0 +1,85 @@
|
||||
# P8：小程序前端 — 看板模块 — miniapp-fe-boards
|
||||
|
||||
> 优先级：P8（依赖 P2 + P3 + P5）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为管理者，我在财务看板能看到多维度交叉筛选的财务数据、环比、AI 洞察。
|
||||
2. 作为管理者，我在客户看板能按 8 个维度排序查看前 100 名客户。
|
||||
3. 作为管理者，我在助教看板能按业绩/工资/客源储值/任务完成等维度排序查看助教。
|
||||
4. 作为系统，看板数据需要缓存层以提升查询性能。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：财务看板支持 2 组筛选交叉（区域 × 时间），选择非"全部区域"时预收资产板块消失
|
||||
- AC2：财务看板环比数据正确计算
|
||||
- AC3：财务看板 AI 洞察从缓存读取（应用 2 每日更新）
|
||||
- AC4：客户看板 8 个维度筛选正确（最应召回/最大消费潜力/最高余额/最近充值/最高消费60天/最频繁60天/最近到店/最专一）
|
||||
- AC5：客户看板"最专一"维度下类型筛选锁定为"不限"
|
||||
- AC6：助教看板维度×项目×日期三重筛选交叉正确
|
||||
- AC7：看板数据有缓存层，非每次实时查询 FDW
|
||||
|
||||
---
|
||||
|
||||
## 页面清单
|
||||
|
||||
### board-finance（财务看板）
|
||||
|
||||
- 筛选器：区域筛选 + 时间筛选（本月/上月/本周/上周/前3月/本季/上季/近6月）
|
||||
- 数据板块：收入结构、预收资产（条件隐藏）、支出汇总、平台结算
|
||||
- 环比展示
|
||||
- AI 智能洞察（应用 2 缓存结果）
|
||||
- "问问助手"入口 → chat.html
|
||||
|
||||
### board-customer（客户看板）
|
||||
|
||||
- 维度筛选（8 个维度，默认"最应召回"）
|
||||
- 类型筛选（全部/台球/斯诺克/麻将/团建 + 台费包厢流水过滤）
|
||||
- 筛选互斥规则："最专一"锁定类型为"不限"
|
||||
- 客户列表（前 100 名）
|
||||
- 每个客户卡片：昵称、爱心 icon、喜好标签、关键指标值
|
||||
- 右下角 AI 按钮 → chat.html
|
||||
|
||||
### board-coach（助教看板）
|
||||
|
||||
- 维度筛选：定档业绩最高/最低、工资最高/最低、高客源储值额最高、任务完成最多
|
||||
- 项目筛选：全部/中🎱/斯诺克/麻将/团建
|
||||
- 日期维度筛选：本月/上月/本周/上周/前3月/本季/上季/近6月
|
||||
- 助教列表
|
||||
- 右下角 AI 按钮 → chat.html
|
||||
|
||||
---
|
||||
|
||||
## 后端 API 需求
|
||||
|
||||
| API | 说明 | 缓存 |
|
||||
|-----|------|------|
|
||||
| `GET /api/board/finance` | 财务看板数据（交叉筛选） | 是 |
|
||||
| `GET /api/board/finance/ai-insight` | 财务 AI 洞察 | 是（应用2缓存） |
|
||||
| `GET /api/board/customers` | 客户看板（维度+类型筛选） | 是 |
|
||||
| `GET /api/board/coaches` | 助教看板（维度×项目×日期） | 是 |
|
||||
|
||||
### 缓存策略
|
||||
|
||||
- 看板数据缓存层：Redis 或内存缓存
|
||||
- 缓存粒度：`site_id` + 筛选条件组合
|
||||
- 缓存过期：ETL 数据更新后失效（约 1 小时）
|
||||
- AI 洞察缓存：从 `biz.ai_cache` 读取（应用 2 每日更新）
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现看板缓存层（Redis/内存，按 site_id + 筛选条件）
|
||||
- [ ] T2：实现财务看板 API（交叉筛选 + 环比 + 预收资产条件隐藏）
|
||||
- [ ] T3：实现客户看板 API（8 维度排序 + 类型筛选 + 互斥规则）
|
||||
- [ ] T4：实现助教看板 API（维度×项目×日期三重筛选）
|
||||
- [ ] T5：实现 board-finance 小程序页面
|
||||
- [ ] T6：实现 board-customer 小程序页面
|
||||
- [ ] T7：实现 board-coach 小程序页面
|
||||
- [ ] T8：实现通用筛选器组件（时间/维度/项目）
|
||||
108
docs/prd/specs/P9-miniapp-fe-details.md
Normal file
108
docs/prd/specs/P9-miniapp-fe-details.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# P9：小程序前端 — 详情与对话模块 — miniapp-fe-details
|
||||
|
||||
> 优先级：P9（依赖 P3 + P4 + P5）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我在客户详情页能看到客户全信息、消费记录（三种样式）、指数总览、备注、AI 分析。
|
||||
2. 作为助教，我在助教详情页能看到助教信息、客户数、工龄、备注。
|
||||
3. 作为助教，我在 AI 对话页能与 AI 流式对话，看到来源页面信息。
|
||||
4. 作为助教，我能查看历史 AI 对话记录。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：消费记录区分三种样式（台桌结账→下沉台费明细、商城订单、充值）
|
||||
- AC2：消费记录默认 10 条，拉到底懒加载（每次 10 条）
|
||||
- AC3：金额为 0 的项不展示；有团购/折扣时展示正价+实付
|
||||
- AC4：总金额仅在消费条目 >1 时出现
|
||||
- AC5：AI 对话支持流式展示（逐字输出）
|
||||
- AC6：从其他页面进入 chat.html 时新开对话，第一条消息为页面上下文
|
||||
- AC7：对话历史列表可查看、可继续对话
|
||||
|
||||
---
|
||||
|
||||
## 页面清单
|
||||
|
||||
### customer-detail（客户详情）
|
||||
|
||||
- 客户信息卡片（昵称、手机、会员卡等级、余额、注册日期）
|
||||
- 指数总览（WBI/NCI/SPI 展示分 + 爱心 icon）
|
||||
- 消费记录列表（三种样式，懒加载）
|
||||
- 台桌结账：下沉到 `dwd_table_fee_log`，每条台费详情，关联总金额汇总
|
||||
- 商城订单：助教列表（花名+级别+课程类型+服务时长+定档绩效）、支付金额、食品酒水总金额
|
||||
- 充值：充值金额、支付方式
|
||||
- 备注列表
|
||||
- AI 消费习惯分析（应用 3 缓存）
|
||||
- "问问助手"入口 → chat.html
|
||||
|
||||
### coach-detail（助教详情）
|
||||
|
||||
- 助教信息卡片（花名、级别、工龄）
|
||||
- 客户数（RS > 2 的客户数量）
|
||||
- 备注按钮（查看此助教为该客户做的备注）
|
||||
|
||||
### customer-service-records（客户服务记录）
|
||||
|
||||
- 服务记录列表（时间 + 持续时长）
|
||||
|
||||
### chat（AI 对话）
|
||||
|
||||
- 来源展示（来源页面 title + 基本信息）
|
||||
- 对话界面（IM 风格）
|
||||
- AI 回复流式展示（SSE）
|
||||
- 消息输入 + 发送
|
||||
|
||||
### chat-history（对话历史）
|
||||
|
||||
- 历史对话列表（按时间倒序）
|
||||
- 点击进入继续对话
|
||||
|
||||
---
|
||||
|
||||
## 后端 API 需求
|
||||
|
||||
| API | 说明 |
|
||||
|-----|------|
|
||||
| `GET /api/customers/:id` | 客户详情 |
|
||||
| `GET /api/customers/:id/consumption-records` | 消费记录（分页，懒加载） |
|
||||
| `GET /api/customers/:id/indexes` | 客户指数总览 |
|
||||
| `GET /api/coaches/:id` | 助教详情 |
|
||||
| `GET /api/coaches/:id/customer-count` | 助教客户数（RS>2） |
|
||||
| `GET /api/customers/:id/service-records` | 客户服务记录 |
|
||||
| `POST /api/chat/conversations` | 创建对话 |
|
||||
| `POST /api/chat/conversations/:id/messages` | 发送消息（SSE 流式返回） |
|
||||
| `GET /api/chat/conversations` | 对话历史列表 |
|
||||
| `GET /api/chat/conversations/:id/messages` | 对话消息列表 |
|
||||
|
||||
### 消费记录 settle_type 区分
|
||||
|
||||
需要查库确认的字段（待 P1 完成后验证）：
|
||||
- 台桌结账：`settle_type` 对应值（需查 `dwd_settlement_head`）
|
||||
- 商城订单：`settle_type` 对应值
|
||||
- 充值：从 `dwd_recharge_order` 单独查询
|
||||
|
||||
### 正价金额字段（待用户复核）
|
||||
|
||||
需要在 `dwd_settlement_head` 或相关 DWS 表中确认：
|
||||
- `original_amount` vs `total_amount` vs 其他字段
|
||||
- 此项标记为"需用户复核"
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现客户详情 API
|
||||
- [ ] T2：实现消费记录分页 API（三种样式区分 + 懒加载）
|
||||
- [ ] T3：实现客户指数总览 API
|
||||
- [ ] T4：实现助教详情 API
|
||||
- [ ] T5：实现对话 API（创建/发送/历史/消息列表，SSE 流式）
|
||||
- [ ] T6：实现 customer-detail 小程序页面
|
||||
- [ ] T7：实现 coach-detail 小程序页面
|
||||
- [ ] T8：实现 customer-service-records 小程序页面
|
||||
- [ ] T9：实现 chat 小程序页面（流式展示 + 来源信息）
|
||||
- [ ] T10：实现 chat-history 小程序页面
|
||||
406
docs/prd/小程序前后端.txt
Normal file
406
docs/prd/小程序前后端.txt
Normal file
@@ -0,0 +1,406 @@
|
||||
# 指数和用法
|
||||
均在DWS层实现，指数单独有INDEX标记
|
||||
## 指数参数新增
|
||||
|
||||
### 新增指数
|
||||
对全部客户，增加一个消费指数，依据：消费能力，消费频率，消费趋势，全部会员卡储值额度。
|
||||
|
||||
### 新增参数
|
||||
对全部客户，增加：30天/60天/90天内的 到店次数/消费总金额/次均消费额度/累计充值次数/累计充值金额。
|
||||
|
||||
### 新增统计
|
||||
统计每名助教带来的订单流水，订单流水-助教服务分成，助教时效流水，助教时效流水-助教服务分成。
|
||||
为了好说明，我们假设一个订单结构：
|
||||
- 台费 2 份：A台3小时 小计200元，B台4小时，小计400元。
|
||||
- 酒水食品：600元。
|
||||
- 助教 3 人 均为专业课：
|
||||
甲服务 A台 2个小时 小计320元，助教分成280元；
|
||||
乙服务 B台 1个小时 小计100元，助教分成80元；
|
||||
丙服务 A台 2小时，B台2小时 小计800元，助教分成750元；
|
||||
|
||||
#### 订单流水
|
||||
即助教参与的本订单的流水 = 200+400+600+320+100+800 = 2420元。也就是3个助教，每人+2820的订单流水。
|
||||
意义：知道助教的营业最大流水，潜力上限。
|
||||
|
||||
#### 订单流水-助教服务分成
|
||||
即助教参与的本订单的流水 - 助教费用提供的流水 = 2420-280-80-750 = 1310元。也就是3个助教，每人+1310。
|
||||
意义：知道助教为球房带来的毛利最大流水，潜力上限。
|
||||
另外，给这个统计，起一个合适的直观易懂的名字。
|
||||
|
||||
#### 助教时效流水
|
||||
每名助教折算其参与的服务时长，贡献的订单金额。
|
||||
计算：
|
||||
1、先计算台桌与助教服务时长的关系，如果助教服务时长总和大于台桌使用时间，则按照助教服务时长平分。如果小于台桌使用时间，则按比例折算台桌使用时间后，再按照助教服务时长平分。
|
||||
台桌A：甲丙助教共计服务4小时，大于台桌使用时长3小时，按4小时计算单价。
|
||||
台桌B：乙丙助教共计服务3小时，小于台桌使用时长4小时，按台桌使用3小时的比例计算。
|
||||
2、计算助教总时长：2+1+2+2 = 7小时
|
||||
3、台费比例（上述计算） + 助教各自服务流水 + 酒水食品按助教总时长与目标助教服务的比例均分。
|
||||
|
||||
助教甲 = 200/(2+2)*2 + 320 + 600/7*2 = 520元
|
||||
助教乙 = (400/4*3)/(1+2)*1 + 100 + 600/7*1 = 285.71元
|
||||
助教丙 = 200/(2+2)*2 + (400/4*3)/(1+2)*2 + 800 + 600/7*(2+2) = 1442.86元
|
||||
|
||||
意义：知道助教单人实力，为球房带来的最大流水，直观能力。
|
||||
另外，给这个统计，起一个合适的直观易懂的名字。
|
||||
|
||||
#### 助教时效流水-助教服务分成
|
||||
即每名助教在上述 助教时效流水 基础上，减去助教分成。
|
||||
计算：
|
||||
助教甲 = 520 - 280 = 240元
|
||||
助教乙 = 285.71 - 80 = 205.71元
|
||||
助教丙 = 1442.86 - 750 = 692.86元
|
||||
|
||||
意义：知道助教单人实力，为球房带来的最大毛利，直观能力。
|
||||
另外，给这个统计，起一个合适的直观易懂的名字。
|
||||
|
||||
#### 超休/打赏课
|
||||
超休/打赏课个算各的，我们假设一个订单结构：
|
||||
助教丁 打赏流水：190元 助教分走100元
|
||||
|
||||
助教丁 订单流水 = 190元
|
||||
助教丁 订单流水-助教服务分成 = 190-100 = 90元
|
||||
助教丁 助教时效流水 = 190 元
|
||||
助教丁 助教时效流水-助教服务分成 = 190-100=90 元
|
||||
|
||||
## 现有指数参数
|
||||
- NCI 新客转化指数（member）
|
||||
作用：新客欢迎建联与二访转化优先级排序、抑制高活跃避免打扰。
|
||||
原始数据：首访/单访、近14/60天到店次数、距上次到店/充值天数、消费与余额、充值未回访。
|
||||
可分解分项：welcome 子分、convert 子分、紧迫度、可救度、充值未回访压力/价值加成、免打扰窗口与 touch_multiplier、活跃抑制项。
|
||||
使用数据：客户行为数据（到店/充值/消费/余额）+“充值未回访”派生状态。
|
||||
算法：欢迎/转化双窗口评分→抑制→0–10 映射。
|
||||
|
||||
- WBI 老客挽回指数（member）
|
||||
作用：老客召回紧急程度与价值潜力综合排序，并给出建议回访时点。
|
||||
原始数据：距上次到店/充值天数、个人到店间隔分布（周期）、近14/60天降频、充值未回访、近180天消费与余额、分层NEW/OLD/STOP（高余额STOP例外）。
|
||||
可分解分项：分流标签、超期度（经验CDF及 alpha 变换）、降频项、充值未回访压力项、价值项、抑制/门控（hard_floor_days、recency_gate_days、slope_days）、额外输出 ideal_interval_days/ideal_next_visit_date。
|
||||
使用数据：客户到店/充值/消费/余额 + 历史到店间隔统计。
|
||||
算法：分流→组合评分→门控抑制→0–10 映射。
|
||||
|
||||
- RS 关系强度指数（pair：客户-助教）
|
||||
作用：判断助教与客户是否真正熟络、作为关系底座。
|
||||
原始数据：合并会话次数、会话时长、课型权重、会话距今天数、最近一次服务距今天数。
|
||||
可分解分项：f_score、d_score、base=weight_f*f_score+weight_d*d_score、时间衰减项、门控 gate=r_score^gate_alpha、rs_raw=base*gate。
|
||||
使用数据：客户-助教互动/服务日志（含课型权重、时长、时间戳）。
|
||||
算法：互动量衰减×最近接触门控→0–10 映射。
|
||||
|
||||
- OS 归属份额指数（pair：客户-助教）
|
||||
作用：客户归属分配、防多人撞单，输出主责/共管/公海/未分配。
|
||||
原始数据：同一客户在各助教上的 RS。
|
||||
可分解分项：过滤阈值 min_rs_raw_for_ownership、总量阈值 min_total_rs_raw、份额 os=rs_i/sum(rs_eligible)、os_rank、标签阈值 main_threshold/gap_threshold/comanage_threshold。
|
||||
使用数据：仅 RS 及阈值策略（不直接用行为明细）。
|
||||
算法：过滤→份额化→阈值打标。
|
||||
|
||||
- MS 动量/升温指数（pair：客户-助教）
|
||||
作用：识别近期升温/回流趋势，用于跟进紧急程度（不替代关系强度）。
|
||||
原始数据：短期加权频次 f_short、长期加权频次 f_long、课型权重 course_weight、时间衰减（不含时长、且不乘 RS）。
|
||||
可分解分项：ratio=f_short/f_long、ms_raw=max(0,log(ratio))（及短/长期频次本身）。
|
||||
使用数据：客户-助教频次序列（带课型权重、时间衰减）。
|
||||
算法：短期相对长期的正向增量→0–10 映射。
|
||||
|
||||
- ML 付费关联指数（pair：客户-助教）
|
||||
作用：判断由谁推动储值/增值更可能成功，严格使用人工归因。
|
||||
原始数据：人工台账归因充值金额、距今天数，来源 dws_ml_manual_order_alloc（Excel 导入）。
|
||||
可分解分项：对数压缩 log1p(amount/amount_base)、时间衰减累加、无台账则 ml_raw=0。
|
||||
使用数据：仅人工台账表（不使用自动归因/行为推断归因）。
|
||||
算法：金额log压缩+时间衰减累加→0–10 映射。
|
||||
|
||||
- 理想到店间隔天数 ideal_interval_days（days）
|
||||
作用：估计客户个人理想回访节奏，为召回门控与建议日期提供标尺。
|
||||
原始数据：历史到店日期序列→间隔天数分布（并结合近期是否降频/超期的派生信号）。
|
||||
可分解分项：个人周期统计量（如分位/均值/稳定度等实现相关）、配套输出 ideal_next_visit_date。
|
||||
使用数据：客户到店历史（时间戳/日期）+ 由此计算的间隔分布。
|
||||
算法：从个人历史间隔估计合理周期并推算下一次建议到店日期。
|
||||
|
||||
更详细的文档见项目文件。
|
||||
|
||||
## 场景说明
|
||||
### 客户任务分配相关
|
||||
- 新客首次到店/单访（NEW）
|
||||
主用指数为 NCI（welcome），如存在服务记录则辅用 RS/OS。分派时，NEW 客户按 NCI_welcome 从高到低分配给“新客官/当班”；若已出现服务记录，则优先分给 RS 最高的助教（更匹配既有服务关系）。
|
||||
|
||||
- 多助教共同服务、避免撞单
|
||||
主用指数为 OS，辅用 RS。先过滤 RS 过低的噪声配对；当 OS ≥ 阈值 时判定主责助教；OS 处于中间区间则进入共管机制；OS 较低则客户进入公海，避免多人重复跟进。
|
||||
|
||||
- 老客召回紧急程度
|
||||
OLD 客户召回（过门槛且可触达）：主用指数为 WBI，辅用 OS/RS（选人），如涉及储值则辅用 ML。OLD 客户按 WBI 排序形成召回队列；优先派给 OS 主责助教；无明确归属的客户进入公海召回组统一处理。
|
||||
|
||||
- 跟进紧急程度
|
||||
近期明显升温/回流：主用指数为 MS，辅用 OS、RS。在各助教名下按 MS 排序生成任务优先级；派单仅给 OS 主责助教执行，减少多人同时触达造成干扰。
|
||||
|
||||
- 关系强但开始变冷（尚未进入老客召回）
|
||||
主用指数为 RS，辅用 MS。优先处理“RS 高 + 近期温度下降”的组合客户；执行仍由 OS 主责助教承接，保证动作一致性与归属稳定。
|
||||
|
||||
- 充值未回访（recharge_unconsumed=1）：主用指数为 WBI（充值相关信号），辅用 ML、OS、RS。按 WBI 高者优先；由 ML 高 且 OS 合理 的助教主推，以提高转化与成交效率。
|
||||
|
||||
- 二访转化窗口（Need×Salvage 高）
|
||||
主用指数为 NCI（convert），辅用 OS/RS（用于选人）。NEW 客户按 NCI_convert 排序推进；触达频次由 NCI 的内置抑制机制控制，防止过度打扰。
|
||||
|
||||
- 增值推荐（由谁推）储值/包时/陪练等：
|
||||
主用指数为 ML，辅用 OS、RS、MS。先基于客户价值/意愿侧筛人（该部分通常已体现在 NCI/WBI 的价值项中），再用 ML 选择最适合的助教推进，并用 OS 明确责任归属。
|
||||
|
||||
- 触达控制（避免打扰）
|
||||
新客刚来过、仍活跃：主用指数为 NCI（内置抑制），无辅助指数。对触达任务队列，直接使用 NCI 的抑制结果 下调优先级或不派单，控制触达节奏与打扰风险。
|
||||
|
||||
- 门店管理/复盘—助教名下 RS 高但 WBI 也高（熟客仍流失）：
|
||||
这里不是派单场景，而是“异常监控看板”。用 WBI + RS 作为主信号组合，辅用 OS、MS 辅助定位；通过组合筛选出需要复盘的助教与客户群，用于服务质量诊断与管理改进。
|
||||
|
||||
# 身份与登录
|
||||
- 登录与审核：如docs/h5_ui/pages/login.html页面所示，用户需要使用微信登录，若是新用户，则提交申请信息：docs/h5_ui/pages/apply.html。通过提交申请，根据审核情况有若干状态：
|
||||
审核中：docs/h5_ui/pages/reviewing.html；
|
||||
审核拒绝：docs/h5_ui/pages/no-permission.html；
|
||||
审核通过：根据指定店面，指定身份，进入相应页面。
|
||||
- 每个页面，都要根据登录用户身份权限，展示允许的数据和与其相关的关联内容。
|
||||
|
||||
## 用户与身份管理
|
||||
- 小程序的用户管理，身份配置，各种身份权限对应 的功能，需要集成到web-admin管理后台中。设计并实现轻量级用户管理功能：
|
||||
- 用户申请后，可指定是否通过。若选择通过，则通过前将其归属至哪个店（siteID，显示名称），并指定其身份。以及用户身份用户归属店面的编辑。
|
||||
- 可新建身份，编辑身份权限。身份对应的权限有：任务板块可见；看版板块可见以及下属财务板块、客户板块、助教板块可见；
|
||||
- 权限列表是固定的.
|
||||
|
||||
# 全局功能逻辑
|
||||
## 任务与完成任务的条件
|
||||
- 展示任务：见指数表格和用法说明，筛选每个助教今天的任务列表。这里你需要思考并再补充一些规则细节。比如任务逻辑是什么，我的想法是一旦助教和客人发生过服务，则就会出现在我的新客及我的常客列表中，作为销售线索；任务列表中会根据各种指数进行判断。
|
||||
- 所以，我觉得任务列表中的任务更像该客户的关系体现，完成任务只是标记一次服务，但展示上，一定是一个任务一个任务构成的。不知道我表达清楚没有，你认为是否合理？
|
||||
- 助教的召回任务完成：当有和该任务匹配的助教，为匹配的客户服务订单出现，则标记本次任务已完成。注意，无论此任务当前状态是高优先召回；优先召回；关系构建还是客户回访都算召回完成。但要记录此任务完成时的状态。
|
||||
- 助教的回访任务完成：当有客户回访任务时，该助教给该客户增加了一条备注，则通过AI应用6进行评分，低于5则不算完成。高于等于5记做完成。允许删除重新备注，只计算客户回访任务后的第一个备注。关于任务标签跳变：出现过客户回访后，2天内备注有效。2天内再次出现客户回访任务，则旧的回访任务被顶替。
|
||||
|
||||
## 某助教客源（客户所属助教）
|
||||
- 根据指数，确定某客户是哪个助教的客源。
|
||||
- 注意！客户可能属于多个助教，这是正常的。如果多个助教对某客户的RS没有很大的差距（50%）以上，则此客户属于多个助教。
|
||||
|
||||
## icon与表示：
|
||||
- 助教与客户成对的RS指数，会有4档爱心icon进行意会传达：
|
||||
💖：RS>8.5 | 🧡：RS>7 | 💛：RS>5 | 💙：RS<5
|
||||
- 助教 及 客户喜好项目的标签，通过房间消费得出：
|
||||
台球/黑八/追分：🎱；斯诺克：斯；麻将：🀅；团建 为 🎤；
|
||||
- 任务归属与放弃：在列表页，反应客户和助教关系的场景时，助教名称右侧会出现“跟”和“弃”的文字icon。跟代表此客户出现在了该助教的任务列表中，且任务类型为“高优先召回”，或“优先召回”。
|
||||
|
||||
## 当月/本周 的展示：
|
||||
- 当展示内容有当月/本周 等含有正在进行的状态，则对于财务金额，绩效工资等内容将出现"预估"字样。但注意！这个字样根据页面和样式不同，展示位置和展示方式均不同。要结合页面进行处理。
|
||||
|
||||
## 备注
|
||||
用户会对某客户增加各种各样的备注。
|
||||
对于特殊的内容，要进行字段归总和抽象。现在有生日这个信息，我们要记录这个生日信息是谁添加的，添加时间和生日的值。在后续数据更新时，主要不要覆盖这个记录，建议和通过API - ODS - DWD上来的值做隔离。
|
||||
|
||||
|
||||
# AI接口
|
||||
## 模型
|
||||
- 接入多个阿里云百炼的AI智能体应用：
|
||||
应用1 对话使用：需要和权限，即可见信息方面进行联动，做信息隔离限制。
|
||||
应用2 看版 - 财务 使用。
|
||||
应用3 客户全信息 分析使用。
|
||||
应用4 单助教对客户（任务视角） 任务及客户分析使用。
|
||||
应用5 单助教对客户（任务视角） 任务话术分析使用。
|
||||
应用6 完成客户回访，备注含金量的判断分析使用。
|
||||
|
||||
作为测试，先调通一个AI智能体应用：
|
||||
|
||||
文档参考：https://help.aliyun.com/zh/model-studio/first-api-call-to-qwen#e4cd73d544i3r
|
||||
Base URL：
|
||||
|
||||
华北2（北京）：https://dashscope.aliyuncs.com/compatible-mode/v1
|
||||
|
||||
用来测试的应用ID: 见 .env → BAILIAN_TEST_APP_ID
|
||||
api-key: 见 .env → BAILIAN_API_KEY
|
||||
|
||||
变量名：传入当前用户ID。变量名：User_ID（通过 biz_params 中的 user_prompt_params 字段传值）
|
||||
|
||||
传入内容：当前页面的内容文本。提供开启对话的背景信息。
|
||||
|
||||
## 入口与信息
|
||||
部分页面右下角存在AI按钮，点击跳转chat.html页面进行对话。
|
||||
部分页面下方催在“问问助手”，点击跳转chat.html页面进行对话。
|
||||
会将本页的信息带到AI对话页面。
|
||||
在开启AI对话后，任何AI对话的开启，使用应用1 ，且要传值页面内容和当前用户信息。
|
||||
|
||||
## 通用
|
||||
- 智能体的信息发送和返回内容都要在数据库中保留。记录时间，ID，返回内容等接口返回的字段 和 发起人。有登录用户和系统，也就是说，系统发送的也要记录。
|
||||
- 使用业界较为成熟的方法，将每个页的内容转化成文本，方便AI阅读。用户会针对某些内容提问AI。
|
||||
- 应用1 一般对话，若从其他页面触发对话，会有一些页面上下文信息传入，开启AI对话。
|
||||
|
||||
## 财务
|
||||
- 应用2
|
||||
上传：当前页面中的信息（2个条件的交叉结果+环比） 。
|
||||
上传内容变量控制：智能分析，需要将几个时间筛选，分别进行更新。含本月/上月/本周/上周/前3个月 不含本月/本季度/上季度/最近6个月不含本月。
|
||||
返回变量的财务分析报告。
|
||||
|
||||
## 客户
|
||||
- 应用3 客户全信息
|
||||
上传：客户60天订单详情（***这里需要整理订单信息详情，你需要做一个文档，整理DWD层暂时只用feiqiu的连接器的DWD***），客户应该到店日期，当前与上次到店的间隔日期。
|
||||
返回：客户分析含标签，消费习惯分析。
|
||||
|
||||
|
||||
## 助教
|
||||
### 单独任务
|
||||
- 应用4
|
||||
上传：客户与我的关系相关60天订单详情（***同应用3的一样，只不过要筛选出与当前助教有关的订单***），客户应该到店日期，当前与上次到店的间隔日期。
|
||||
返回：客户和我的关系分析、任务建议、一句话总结、我的关系情况。
|
||||
|
||||
- 应用5
|
||||
上传：客户与我的关系相关订单详情（***同应用4***），应用3的返回内容，客户应该到店日期，当前与上次到店的间隔日期，客户和我的关系分析、任务建议。
|
||||
返回：5条话术参考。
|
||||
|
||||
### 回访信息含金量
|
||||
- 应用6
|
||||
上传：触发回访任务的备注，客户信息及全部备注。
|
||||
返回：1-10分数，以及评价。(6分为标准分，被别人备注过多的信息酌情扣分，无价值/低价值/时效性低/个性化弱/业务性若/私密性低等弱销售线索信息酌情扣分。反之高价值信息则酌情加分)
|
||||
|
||||
|
||||
|
||||
# 页面
|
||||
|
||||
## task-list.html
|
||||
- 展示当前任务（结合任务分配逻辑），按照以下顺序，优先级归类：
|
||||
优先级0：根据(WBI+NCI)指数展示列表。>7为高优先召回。>5为优先召回。
|
||||
优先级1：完成某任务后没有备注，且则标记tag客户回访。完成任务后加了备注，则跳过。
|
||||
优先级2：关系分数<6，则标记tag关系构建。
|
||||
|
||||
### 长按任务
|
||||
- 按住任务可弹出选项：置顶任务，放弃任务，问问AI助手。
|
||||
- 点击放弃任务弹出备注，必须输入放弃任务的原因，后端进行记录。放入已放弃列表。并将任务简述，替换为放弃原因。
|
||||
点击置顶任务，展示在置顶列表中。
|
||||
- 可以对已置顶任务取消置顶；可以对已放弃任务取消放弃。
|
||||
- AI接口：每个任务，将任务详情页信息带给AI。跳转到chat.html中。
|
||||
|
||||
|
||||
### 绩效计算
|
||||
通过 当前用户的门店，助教级别，按照DWS符合的绩效规则，计算当前月绩效、跳档和工资核算。展示相关数据。
|
||||
此页面展示的所有数据均为折算后的数据。
|
||||
|
||||
到达XXX即得YYY
|
||||
XXX为每个档位跳档线的时长。
|
||||
YYY为max(跳档线满足后前后的差值最小值,当前助教实际跳档后获得的差值)。
|
||||
跳档线满足后前后的差值最小值（没有超休打赏激励）：
|
||||
Tier0 → Tier1：120*（28-18）= 1200元
|
||||
Tier1 → Tier2：150*（18-13）= 750元
|
||||
Tier2 → Tier3：180*（13-10）= 540元
|
||||
Tier3 → Tier4：210*（10-8）= 420元
|
||||
|
||||
举例：
|
||||
助教A 普通课50小时 打赏课10小时。
|
||||
则 50*（28-18）+10*190*（0.5-0.4）=690
|
||||
max(1200,690)=1200
|
||||
|
||||
助教B 普通课130小时 打赏课10小时。
|
||||
则 130*（18-13）+15*190*（0.4-0.35）= 792.5
|
||||
max(750,792.5)=792.5
|
||||
|
||||
|
||||
## performance.html
|
||||
- 收入与业绩档位在DWS（没有的话DWD）中读出，展示。
|
||||
- 本月/上月服务记录明细列出有我的所有服务课程，按照由近及远的时间顺序排列，从DWS（没有的话DWD）中获取。需要处理按天的的归总整合数据。
|
||||
- 我的新客（首次服务过的客户在最近2月内，且服务总次数小于等于2），按照最后服务时间排列。
|
||||
- 我的常客 （2月内，服务次数最多的客户）。次数，小时数，我从其支付的助教费中，能拿到多少工资的合计。
|
||||
- 服务明细：需要处理天/月的归总整合数据。展示每次服务的详情和收入/预估收入。
|
||||
|
||||
|
||||
## performance-records.html
|
||||
- 按照页面选择的口径，展示口径范围内全部业绩。
|
||||
- 需要处理天/月的归总整合数据。
|
||||
|
||||
### 每条业绩展示内容
|
||||
记录时间：结账时间。
|
||||
课程类型：基础课/包厢课/打赏课
|
||||
台桌/房间：如果是没有台桌房间的打赏课 则显示 “打赏”
|
||||
会员昵称：如果有则显示。
|
||||
开始时间：课程开始时间。
|
||||
结束时间：课程结束时间。
|
||||
业绩分钟：展示业绩分钟，如果有定档折算惩罚，则括号中展示。格式：120分钟（定档折算30分钟）。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## board-finance.html
|
||||
- AI接口：对于当前页面中的信息，智能分析，需要将几个时间筛选，分别进行更新。含本月/上月/本周/上周/前3个月 不含本月/本季度/上季度/最近6个月不含本月。
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化，可以考虑DWS层进行数据快照。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## board-finance.html
|
||||
- AI接口：展示当前筛选项，财务的AI分析。
|
||||
- 筛选：展示当前2组筛选的交集结果。选择了除全部区域以外的选项，则预收资产板块消失。收入结构去掉非筛选的区域。
|
||||
|
||||
## board-customer.html
|
||||
- 每个筛选维度，都展示不同内容。列表展示前100名。
|
||||
- 维度筛选更新，按顺序：最应召回（默认），最大消费潜力，最高余额，最近充值，最高消费 近60天，最频繁 近60天，最近到店，最专一
|
||||
- 维度筛选：
|
||||
最应召回：取客户召回指数，由高到低排列。
|
||||
最大消费潜力：通过统计 注册用户日期 最近30天充值与金额（高权重） 最近30、10天消费金额总和（高权重） 最近30天消费频率变化 这几个指标单独或权重加成，分析出每个客户的消费潜力。需要符合经营直觉，科学合理。
|
||||
最高消费 最近60天：统计每个客户最近60天的所有消费，从高到底排列。
|
||||
最高余额：统计最近当前，每个客户的余额(客户名下所有卡的余额)，从高到底排列。
|
||||
最频繁 近60天：统计每个客户60天内到店的总天数，从高到底排列。
|
||||
最近到店：统计每个客户到店的时间，从近到远。
|
||||
最专一：统计每个客户对全部助教的亲密度，并取最大值，由高到低排列。
|
||||
- 类型筛选：加上选项中台费包厢流水的过滤。
|
||||
- 筛选互斥：
|
||||
最专一默认类型筛选为不限，且不能修改。
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化，可以考虑DWS层进行数据快照。
|
||||
|
||||
|
||||
## board-coach.html
|
||||
展示以下选项的交集结果
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化，可以考虑DWS层进行数据快照。
|
||||
|
||||
### 维度筛选
|
||||
- 筛选条件：定档业绩最高，定档业绩最低，工资最高，工资最低，高客源储值额最高，任务完成最多。
|
||||
- 业绩是定档业绩
|
||||
- 工资是核算后的工资
|
||||
- 高客源储值：统计助教 关系值>2的 全部客户的全部会员卡储值额，按照会员卡储值总额从高到到底排列。
|
||||
- 任务完成最多：统计周期内每个助教完成任务数量。
|
||||
- 客源储值：统计每个助教关系大于3的客户，每个客户的所有卡金额合计。
|
||||
|
||||
|
||||
|
||||
### 项目筛选
|
||||
- 按项目类型分：全部，中🎱，斯诺克，麻将，团建。
|
||||
|
||||
### 日期维度筛选
|
||||
- 按日期间隔分：本月，上月，本周，上周，前3个月不含本月，本季度，上季度，最近6个月不含本月。
|
||||
|
||||
|
||||
## coach-detail.html
|
||||
- 客户数：RS > 2的 客户数量。
|
||||
- 工龄：入职时间到当前的时间的年数。
|
||||
- 点击备注按钮，支持查看此助教为该客户做的备注。
|
||||
|
||||
## customer-detail.html
|
||||
### 消费记录
|
||||
每条样式分为2种：
|
||||
- dwd_settlement_head 的 settle_type 为 台桌结账的，下沉到table_fee_log，因为有的订单包含多个房间台桌。每条记录是该台费详情，展示关联/统计项，台桌关联总金额需要汇总。
|
||||
- dwd_settlement_head 的 settle_type 为 商城订单 的，每条记录含：助教列表（助教花名级别，课程类型，服务时长（若有绩效折算，则展示“定档绩效：XXX小时”），支付的金额，食品酒水总金额。
|
||||
- 金额为0的项，不展示。正价金额，（若有团购，或折扣，展示实付金额）
|
||||
- 总金额只在消费条目>1时出现。
|
||||
|
||||
|
||||
|
||||
## task-detail.html
|
||||
近期服务记录 时间和小时 是课程的时间和持续时长。
|
||||
备注：点击弹出备注输入窗口，让客户输入。提交按钮文案“提交”。提交后进行记录。
|
||||
|
||||
|
||||
近期服务记录 时间和小时 是课程的时间和持续时长。
|
||||
|
||||
|
||||
|
||||
## customer-service-records.html
|
||||
服务记录 时间和小时 是课程的时间和持续时长。
|
||||
|
||||
|
||||
## chat.html
|
||||
展示进入的来源。（你帮我梳理下所有可能进入AI的入口，并帮我定义来源展示的title和基本信息）。
|
||||
与正常IM或AI对话交互一样的交互操作。AI回复支持流式展示。
|
||||
|
||||
## notes.html
|
||||
支持删除，需二次校验。
|
||||
|
||||
## chat-history.html
|
||||
|
||||
|
||||
|
||||
## 管理后台
|
||||
## Excel数据上传
|
||||
Reference in New Issue
Block a user