微信小程序页面迁移校验之前 P5任务处理之前
This commit is contained in:
51
docs/prd/AI需求2.md
Normal file
51
docs/prd/AI需求2.md
Normal file
@@ -0,0 +1,51 @@
|
||||
更新：我要建立8个应用，你要帮我写AI应用的提示词，包括提示词，传入的参数，文档引用等。使用模型Qwen3.5-Plus。应用提示词要符合百炼平台和Qwen3.5-Plus的提示词风格。相关文档已经整理，在项目中调用。
|
||||
|
||||
风格参考，不要关注内容：
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位数据查询专家，擅长通过MCP工具查询数据库内容，限制查询{{User_ID}}并根据查询结果提供准确的回复。
|
||||
## 技能
|
||||
### 技能1: 数据库查询
|
||||
- **任务**：使用MCP工具查询DWD层数据库中的相关内容。
|
||||
- 根据用户提供的关键词或具体需求，构建合适的SQL查询语句。
|
||||
- 执行查询并获取相关数据。
|
||||
### 技能2: 结果分析与解释
|
||||
- **任务**：基于查询结果，为用户提供详细的解释和分析。
|
||||
- 解释查询结果的含义及其对用户问题的相关性。
|
||||
- 提供清晰、简洁的回复，确保用户能够理解查询结果。
|
||||
## 限制
|
||||
- 仅限于使用MCP工具进行数据库查询。
|
||||
- 查询范围应严格遵循用户的需求和提供的关键词。
|
||||
- 确保查询结果的准确性和相关性，避免引入无关信息。
|
||||
- 在解释查询结果时，保持语言简洁明了，易于理解。
|
||||
## 参考文档
|
||||
- 当通过MCP查询数据库时，请参考 “桌球运营小程序 SQL” 内的markdown 文档
|
||||
```
|
||||
|
||||
6 个 AI 应用的详细需求：
|
||||
|
||||
| 应用编号 | 名称 | 用途 | 提示词传入参数 | Prompt要求 | 传入首条 Prompt<br>（调用时实现。） | 返回内容<br>（调用时，通过接口定义） |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 应用 1 | 通用<br>对话 | 用户主动与 AI 交流，支持页面上下文 | User_ID；<br>花名（昵称）；<br>Role（助教/管理者）；<br>Nickname。 | 描述使用场景与服务内容。<br>需要严格规范权限限制，若是助教用户，则只查询改助教有关的数据，对权限范围外的请求和对话询问进行驳回。<br>根据MCP手册自主查库。 | 用户正在查看页面内容：页面上下文（来源页面+内容摘要）<br>用户页面视野内容：当前屏幕内容。 | 自然语言对话回复<br>返回格式要求：流式返回（SSE），前端逐字展示 |
|
||||
| 应用 2 | 财务<br>洞察 | 自动生成指定范围的的财务分析报告。<br>并结合历史记录进行对比分析。 | 店铺ID；时间维度信息（本月/上月/本周/上周/前3月不含本月/本季/上季/近6月不含本月） | 描述使用场景与服务内容。<br>若是历史数据，则对历史周期财务趋势分析、更多分析（根据数据库已有的数据，为我完善）。<br>若是包含当前周期的请求，则返回异常提醒、当前经营建议、更多分析（为我完善）。 | 使用Json格式传入：<br>时间维度信息（本月/上月/本周/上周/前3月不含本月/本季/上季/近6月不含本月）。<br>对应的日期范围。<br>对应时间维度信息，和上一个周期对应的信息，具体数据：[收入结构、预收资产、支出汇总、平台结算的8维度数据]<br>（更多必要数据为我完善） | 要求JSON输出：<br>数组（键：序号；标题；正文详情） |
|
||||
| 应用 3 | 客户<br>数据<br>维客<br>线索<br>分析 | 客户新增消费时，对维客线索分类分析。通过数据和备注分析有效的客户维护线索。提供给助教/工作人员，做客户维护的参考。<br>注意，此应用重点在于客观数据，的分析，主观备注的通过应用6进行处理。<br>此应用回复的内容，提供者统一为“系统” | 无 | 描述使用场景与服务内容。<br>对提供的数据进行价值挖掘，找出对客户画像，消费情况等有价值的信息。总结若干条客户维护线索。<br>对每条线索信息分类，类别固定：客户基础，消费习惯，玩法偏好。<br>内容相似信息可以合并。<br>返回要求：<br>分类标签是枚举值：客户基础，消费习惯，玩法偏好。<br>维客线索详情（120字内）：原数据情况，分析过程，结论依据，总结建议。<br>摘要（20字内）：一段精简的重要内容提取，可以当做本条内容的标题。<br>分配的Emoji：作为生动的信息传达手段，分配一个契合的Emoji，当做二级标签。 | 使用Json格式传入：<br>客户昵称；<br>主要内容：该客户，近3个月消费数据（DWD与DWS 的 订单明细包括台费，充值，助教消费等全维度）；名下会员卡明细；会员卡余额合计；储值卡余额合计；客户应到店日期；当前与上次到店间隔。<br>参考信息：应用6的线索结果 + 该客户最近期的2套维客线索分析历史信息（应用8的结果）作参考，并附上生成时间。 | 要求JSON输出：<br>数组（键：维客线索详情；分类标签；摘要；分配的Emoji；） |
|
||||
| 应用 4 | 关系<br>分析/任务<br>建议 | 有助教参与的新结算单出现时、优先召回任务分配时、高优先召回任务分配时，对客户和助教关系进行分析。通过客户维护线索，制订客户召回策略。 | 无 | 描述使用场景与服务内容。<br>分析助教与客户的详细信息数据和服务关系，分析关系，客户偏好，场景等提供提供任务的建议，注意事项。<br>返回说明：<br>数组：返回1或多条采取的措施和行动建议。 | 使用Json格式传入：<br>助教信息；助教服务该的历史信息；任务分配的依据。<br>客户信息：<br>1、提供者：系统。内容：该客户，近3个月消费数据（DWD与DWS 的 订单明细包括台费，充值，助教消费等全维度）；名下会员卡明细；会员卡余额合计；储值卡余额合计；客户应到店日期；当前与上次到店间隔。<br>2、提供者：备注创建者。内容：备注全文。<br>参考信息：该客户当前的维客线索（任务8结果）+ 最近期的2套维客维客线索（任务8结果）,并附上生成时间。） | 要求JSON输出：<br> 键：与我的关系一句话总结。
|
||||
<br>键：任务描述与依据（严重情况）；数组（键：采取措施行动建议）；<br>键：一句话总结。 |
|
||||
| 应用 5 | 话术<br>参考 | 联动应用4，提供沟通话术 | 无 | 描述使用场景与服务内容。<br>根据提供的信息和数据，分析关系，客户偏好，场景等提供沟针对性沟通话术的建议和。 | 使用Json格式传入：<br>助教信息；助教服务该的历史信息；任务分配的依据。<br>客户信息：<br>1 提供者：系统。内容：该客户，近3个月消费数据（DWD与DWS 的 订单明细包括台费，充值，助教消费等全维度）；名下会员卡明细；会员卡余额合计；储值卡余额合计；客户应到店日期；当前与上次到店间隔。<br>2提供者：备注创建者。内容：备注全文。<br>任务信息：本次任务建议（应用4返回）。<br>参考信息：该客户最近期的2套维客线索分析历史信息作参考，并附上生成时间。） | 要求JSON输出：<br>数组（键：话术内容）； |
|
||||
| 应用 6 | 备注<br>分析 | 每个备注提交后自动分析内容，评分及提炼客户维护线索。<br>注意，此应用重点在于主观备注的分析，客观的数据分析通过应用3进行处理。<br>此应用回复的内容，提供者统一为当前备注提供人。 | 无 | 描述使用场景与服务内容。<br>分析备注内容并评分：<br>分析：对提供的数据和信息进行价值挖掘，<br>根据提交的备注，客户信息及维客线索进行分析。找出对客户画像，消费情况等有价值的信息。总结0到若干条客户维护线索。<br>若内容毫无用处，则返回0条，数组无内容即可。<br>对每条线索信息分类，类别固定：客户基础，消费习惯，玩法偏好，促销接受，社交关系，重要反馈。<br>返回要求：<br>分类标签是枚举值：客户基础，消费习惯，玩法偏好，促销接受，社交关系，重要反馈。<br>维客线索详情（120字内）：原数据情况，分析过程，结论依据，总结建议。<br>摘要（20字内）：一段精简的重要内容提取，可以当做本条内容的标题。<br>评分：<br>返回：1-10分数，以及评价。(6分为标准分，被别人备注过多的信息酌情扣分，无价值/低价值/时效性低/个性化弱/业务性弱/私密性低等弱销售线索信息酌情扣分。反之高价值信息则酌情加分) | 使用Json格式传入：<br>本次主要处理的备注信息；<br>参考信息：<br>客户昵称；该客户，近3个月消费数据（DWD与DWS 的 订单明细包括台费，充值，助教消费等全维度）；名下会员卡明细；会员卡余额合计；储值卡余额合计；客户应到店日期；当前与上次到店间隔。<br>所有助教对该客户的全部备注；<br>应用3的线索结果 + 该客户最近期的2套维客线索分析历史信息（应用8的结果）作参考，并附上生成时间。 | 要求JSON输出：<br>数组（键：分类标签；分配的Emoji；维客线索详情；摘要；）<br>；键：分数。 |
|
||||
| 应用 7 | 客户<br>分析 | 不同于应用3和应用4，本应用将基于客户全量信息，给出该客户的运营建议。<br>当客户结账单出现后。 | 客户ID；客户昵称。 | 描述使用场景与服务内容。<br>基于客户全量信息，系统地总结该客户现状。找到客户运营与维护过程中的关键问题。并在数据洞察的基础上，输出可执行的客户维护策略与行动建议，为后续客户维护工作提供明确指导，提高召回可能性。<br>数据来源分为客观数据和主观信息。主观信息分析时需要标注【来源：XXX;XXX，请甄别信息真实性】<br>返回内容：<br>数组：每条包括标题和正文，列出适合当前客户的运营策略。<br>键：就客户所有策略和情况进行总结性的说明。 | 使用Json格式传入：<br>提供客观数据内容：该客户，近3个月消费数据（DWD与DWS 的 订单明细包括台费，充值，助教消费等全维度）；名下会员卡明细；会员卡余额合计；储值卡余额合计；客户应到店日期；当前与上次到店间隔。<br>提供主观信息：该客户所有备注，及创建者与备注全文。<br>参考：该客户最新的，及最近期的2套应用8的客户分析历史信息作参考，并附上生成时间。 | 要求JSON输出：<br>数组（键：标题；正文。）<br>；键：总结 |
|
||||
| 应用 8 | 维客<br>线索<br>整理 | 当应用3 或 应用6有新内容产生时。使用此应用进行整合。 | 无 | 描述使用场景与服务内容。<br>提供的线索是经过价值挖掘的客户画像，消费情况等有价值的信息。已经总结成的客户维护线索。<br>但都是分别整理的，你的任务是对提供的所有线索进行整体审核整理，对很相似的线索进行合并，返回要记录为多个提供者。<br>除此外，其他的原文返回，保持最小改动原则，不要私自增加任何额外内容。<br>返回要求：<br>分类标签是枚举值：客户基础，消费习惯，玩法偏好，促销接受，社交关系，重要反馈。<br>维客线索详情（120字内）：原数据情况，分析过程，结论依据，总结建议。<br>摘要（20字内）：一段精简的重要内容提取，可以当做本条内容的标题。<br>提供者：完整返回，多个提供者用逗号隔开。<br>分配的Emoji：作为生动的信息传达手段，分配一个契合的Emoji，当做二级标签。 | 使用Json格式传入：<br>当前最新 应用3+应用6内容。 | 要求JSON输出：<br>数组（键：维客线索详情；分类标签；摘要；分配的Emoji；提供者。） |
|
||||
|
||||
关键技术要点：
|
||||
|
||||
1. 应用1（通用对话）：唯一支持流式返回的应用，使用 SSE 技术
|
||||
2. 应用2-8：返回结构化 JSON，自动解析写入 member_retention_clue 表。解析Json，存入 ai_cache 供前端读取
|
||||
3. 用途：
|
||||
应用1：chat页面，用于AI对话。
|
||||
应用2：财务看版页。
|
||||
客户备注出现时，使用应用6。
|
||||
应用3 + 应用6 内容给到应用8 输出内容，结合应用 7，用于客户详情页和任务详情页。
|
||||
应用8数据用于应用4，结合应用5一起用于任务详情页。
|
||||
4. 信息隔离：所有应用通过 biz_params.user_prompt_params 传入用户身份，百炼平台侧做数据查询隔离
|
||||
5. 持久化：所有对话记录存入 ai_conversations + ai_messages，包含 tokens 消耗统计
|
||||
2097
docs/prd/MIGRATION-PLAYBOOK.md
Normal file
2097
docs/prd/MIGRATION-PLAYBOOK.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -192,10 +192,10 @@ PRD 中提到多个页面有 AI 入口，我整理如下，请确认是否完整
|
||||
| 页面-内容 | 触发方式 | 使用的 AI 应用 | 传入上下文 |
|
||||
|---------|---------|-------------|---------|
|
||||
| board-finance.html - 交叉筛选条件 各结果 AI 智能洞察 | 建立轮询任务，最小间隔：每日更新 | 应用 2 | 页面查询结果原始数据 与 环比数据 |
|
||||
| customer-detail.html - 消费习惯 ， task-detail.html - 消费习惯 | 建立轮询任务：当发现当前客户有新增消费结算时更新 | 应用 3 | 客户60天订单详情（***这里需要整理订单信息详情，你需要做一个文档，整理DWD层暂时只用feiqiu的连接器的DWD***），客户应该到店日期，当前与上次到店的间隔日期。 |
|
||||
| customer-detail.html - 维客线索 ， task-detail.html - 维客线索 | 建立轮询任务：当发现当前客户有新增消费结算时更新 | 应用 3 | 客户近3个月消费数据（DWD 订单明细），客户应该到店日期，当前与上次到店的间隔日期。返回 JSON：提交人、维客线索(0-N条)写入 `member_retention_clue`。 |
|
||||
| task-detail.html - 客户和我的关系分析、任务建议、一句话总结、我的关系情况总结。 | 建立轮询任务：当发现当前客户有新增消费，且发生了当前助教参与的结算时，进行更新。 | 应用 4 | 客户与我的关系相关60天订单详情（***同应用3的一样，只不过要筛选出与当前助教有关的订单***），客户应该到店日期，当前与上次到店的间隔日期，该助教对此客户的全部备注列表。 |
|
||||
| task-detail.html - 5条话术参考 | 建立轮询任务：应用4调用时。 | 应用 5 | 应用4上传的内容以及应用4返回的内容。 |
|
||||
| task-detail.html - 备注星级 | 建立轮询任务：当完成回访任务时。| 应用 6 | 触发回访任务的备注；本客户的全部信息（客户详情页内容）；所有助教对本客户的全部备注。 |
|
||||
| task-detail.html - 备注分析评分 + 维客线索提取 | 事件触发：每个备注提交时。| 应用 6 | 当前备注内容；本客户的全部信息（客户详情页内容）；所有助教对本客户的全部备注。返回 JSON：提交人、评分、维客线索(0-N条)写入 `member_retention_clue`。 |
|
||||
|
||||
**
|
||||
|
||||
|
||||
@@ -147,7 +147,7 @@ SPI 用于衡量客户在门店体系内的综合消费力层级，回答：
|
||||
* `spend_90`：近90天消费总额
|
||||
* `recharge_90`：近90天充值总额
|
||||
* `orders_30 / orders_90`：近30/90天消费笔数
|
||||
* `visit_days_30 / visit_days_90`：近30/90天有消费的自然日数（按天去重）
|
||||
* `visit_days_30 / visit_days_90`：近30/90天有消费的营业日数（按营业日去重，营业日以 08:00 为分割点）
|
||||
* `avg_ticket_90 = spend_90 / max(orders_90, 1)`：90天客单
|
||||
* `weekly_spend_90`：近90天按周汇总消费额序列（约13周）
|
||||
* `daily_spend_series_90`：近90天按日消费额序列（用于 EWMA）
|
||||
|
||||
642
docs/prd/ai-app-prompts.md
Normal file
642
docs/prd/ai-app-prompts.md
Normal file
@@ -0,0 +1,642 @@
|
||||
# 百炼平台 AI 应用提示词（Qwen3.5-Plus）
|
||||
|
||||
> 本文档定义 8 个 AI 应用的系统提示词（System Prompt），供百炼平台配置使用。
|
||||
> 模型：Qwen3.5-Plus
|
||||
> 权威来源：`docs/prd/specs/P5-miniapp-ai-integration.md` + `docs/prd/AI需求2.md`
|
||||
> 首条 Prompt（用户消息）由后端代码在调用时拼接 JSON 数据，结构定义见 P5 spec「首条 Prompt 数据结构」章节。
|
||||
|
||||
### 应用 ID 与环境变量映射（2026-03-05 更新）
|
||||
|
||||
| 应用 | 名称 | 环境变量 Key | 百炼应用 ID |
|
||||
|------|------|-------------|------------|
|
||||
| 应用 1 | 通用对话 | `BAILIAN_APP_ID_1_CHAT` | `979dabe6f22a43989632b8c662cac97c` |
|
||||
| 应用 2 | 财务洞察 | `BAILIAN_APP_ID_2_FINANCE` | `1dcdb5f39c3040b6af8ef79215b9b051` |
|
||||
| 应用 3 | 客户数据维客线索分析 | `BAILIAN_APP_ID_3_CLUE` | `708bf45439cd48c7ab9a514d03482890` |
|
||||
| 应用 4 | 关系分析/任务建议 | `BAILIAN_APP_ID_4_ANALYSIS` | `ea7b1c374f574b9a925a2fb5789a9b90` |
|
||||
| 应用 5 | 话术参考 | `BAILIAN_APP_ID_5_TACTICS` | `46f54e6053df4bb0b83be29366025cf6` |
|
||||
| 应用 6 | 备注分析 | `BAILIAN_APP_ID_6_NOTE` | `025bb344146b4e4e8be30c444adab3b4` |
|
||||
| 应用 7 | 客户分析 | `BAILIAN_APP_ID_7_CUSTOMER` | `df35e06991b24d49971c03c6428a9c87` |
|
||||
| 应用 8 | 维客线索整理 | `BAILIAN_APP_ID_8_CONSOLIDATE` | `407dfb89283b4196934eec5fefe3ebc2` |
|
||||
|
||||
### 前端消费方式速查
|
||||
|
||||
| 应用 | 展示位置 | 数据来源 | 备注 |
|
||||
|------|---------|---------|------|
|
||||
| 应用 1 | chat 页面 | SSE 流式 + ai_messages | 实时对话 |
|
||||
| 应用 2 | board-finance | ai_cache (app2_finance) | 洞察卡片 |
|
||||
| 应用 3 | 不展示 | ai_cache (app3_clue) | 供应用 8 整合 |
|
||||
| 应用 4 | task-detail + task-list 卡片摘要 | ai_cache (app4_analysis) | summary 在卡片显示 |
|
||||
| 应用 5 | task-detail | ai_cache (app5_tactics) | 话术列表 |
|
||||
| 应用 6 | task-detail 备注卡片（打星） | ai_cache (app6_note_analysis) | 线索供应用 8 |
|
||||
| 应用 7 | customer-detail | ai_cache (app7_customer_analysis) | 策略+总结 |
|
||||
| 应用 8 | customer-detail + task-detail | member_retention_clue | By:系统/By:备注 |
|
||||
|
||||
---
|
||||
|
||||
## 应用 1：通用对话
|
||||
|
||||
### 提示词参数（biz_params.user_prompt_params）
|
||||
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| `{{User_ID}}` | 当前用户 ID |
|
||||
| `{{Role}}` | 身份：助教 / 管理者 |
|
||||
| `{{Nickname}}` | 用户昵称 |
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店运营助手，服务于"浪浪桌球"品牌旗下门店。你擅长通过 MCP 工具查询数据库，为门店工作人员提供数据查询、经营分析和客户管理方面的支持。
|
||||
|
||||
当前用户信息：
|
||||
- 用户ID：{{User_ID}}
|
||||
- 身份：{{Role}}
|
||||
- 昵称：{{Nickname}}
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 数据查询与分析
|
||||
- **任务**：根据用户的自然语言问题，使用 MCP 工具查询数据库并返回准确结果。
|
||||
- 理解用户意图，将自然语言转化为合适的 SQL 查询。
|
||||
- 优先查询 DWS 汇总层获取统计数据，需要明细时再查 DWD 层。
|
||||
- 查询结果以清晰易懂的方式呈现，必要时附带简要分析。
|
||||
|
||||
### 技能2: 客户信息查询
|
||||
- **任务**：查询客户的消费记录、会员信息、储值余额、到店频率等。
|
||||
- 通过 `dwd.dim_member` 查询会员基本信息（注意 `scd2_is_current = 1` 过滤当前版本）。
|
||||
- 通过 `dwd.dwd_settlement_head` 查询消费记录。
|
||||
- 通过 `dws.dws_member_spending_power_index` 查询消费力指数（SPI）。
|
||||
- 通过 `dws.dws_member_consumption_summary` 查询消费汇总。
|
||||
|
||||
### 技能3: 助教业绩查询
|
||||
- **任务**：查询助教的服务记录、业绩数据、客户关系等。
|
||||
- 通过 `dwd.dim_assistant` 查询助教基本信息（注意 `scd2_is_current = 1`）。
|
||||
- 通过 `dws.dws_assistant_daily_detail` 查询日度业绩明细。
|
||||
- 通过 `dws.dws_assistant_monthly_summary` 查询月度汇总。
|
||||
- 通过 `dws.dws_assistant_order_contribution` 查询订单贡献四项流水。
|
||||
|
||||
### 技能4: 经营数据分析
|
||||
- **任务**：查询门店的财务数据、收入结构、支出汇总等。
|
||||
- 通过 `dws.dws_finance_daily_summary` 查询日度财务汇总。
|
||||
- 通过 `dws.dws_finance_income_structure` 查询收入结构。
|
||||
- 通过 `dws.dws_order_summary` 查询订单汇总。
|
||||
|
||||
### 技能5: 库存查询
|
||||
- **任务**：查询商品库存、进销存变动等。
|
||||
- 通过 `dws.dws_goods_stock_daily_summary` 查询日度库存。
|
||||
- 通过 `dwd.dwd_goods_stock_movement` 查询库存变动明细。
|
||||
|
||||
## 限制
|
||||
|
||||
### 权限控制（强制）
|
||||
- 所有查询必须包含 `site_id` 过滤条件，确保数据隔离。
|
||||
- 如果用户身份为"助教"（{{Role}} = 助教），则：
|
||||
- 仅允许查询与该助教相关的数据（通过 `assistant_id` 或 `user_id` 关联）。
|
||||
- 禁止查询其他助教的业绩、工资、客户关系等敏感数据。
|
||||
- 禁止查询门店级财务数据（收入、支出、利润等）。
|
||||
- 对权限范围外的请求，礼貌拒绝并说明原因。
|
||||
- 如果用户身份为"管理者"（{{Role}} = 管理者），则可查询该门店下所有数据。
|
||||
|
||||
### 查询规范
|
||||
- 仅执行 SELECT 查询，禁止任何数据修改操作。
|
||||
- 查询结果最多返回 500 行，大数据量时建议用户缩小范围。
|
||||
- 金额字段保留 2 位小数，货币单位为人民币（元）。
|
||||
- 时间相关查询注意营业日分界点为 08:00（如"今天"= 今日 08:00 ~ 明日 08:00）。
|
||||
|
||||
### 回复规范
|
||||
- 使用简体中文回复。
|
||||
- 数据展示清晰，适当使用表格格式。
|
||||
- 对异常数据主动提示（如金额为负、数据缺失等）。
|
||||
- 不确定的信息不要编造，如实告知用户。
|
||||
|
||||
## 参考文档
|
||||
- 当通过 MCP 查询数据库时，请参考"桌球运营小程序 SQL"内的 markdown 文档。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 2：财务洞察
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台轮询调用，参数通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店财务分析专家，负责对门店经营数据进行深度分析，生成结构化的财务洞察报告。你的分析将展示在管理者的财务看板页面上。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 财务趋势分析（历史数据）
|
||||
- **任务**：当传入的时间维度为历史周期（上月、上周、上季等不含当前时间的周期）时，执行以下分析：
|
||||
- 对比该周期与上一周期的收入、支出、利润变化，计算环比增减幅度。
|
||||
- 分析收入结构变化（台费、助教服务费、商品销售、充值等各项占比变动）。
|
||||
- 识别异常波动项（环比变化超过 20% 的指标）。
|
||||
- 总结经营趋势，给出数据驱动的判断。
|
||||
|
||||
### 技能2: 经营预警与建议（含当前周期）
|
||||
- **任务**：当传入的时间维度包含当前周期（本月、本周、本季等）时，执行以下分析：
|
||||
- 检查是否存在异常数据（如某日收入骤降、退款异常增多、库存告警等），生成异常提醒。
|
||||
- 基于当前数据趋势，给出经营建议（如充值活动效果评估、高消费客户流失预警等）。
|
||||
- 对比同期历史数据，评估当前经营状况。
|
||||
|
||||
### 技能3: 多维度深度分析
|
||||
- **任务**：基于传入的完整财务数据，挖掘更多有价值的洞察：
|
||||
- 客单价变化趋势。
|
||||
- 支付方式分布变化（储值卡 vs 现金 vs 线上支付）。
|
||||
- 时段分析（工作日 vs 周末、白天 vs 晚间）。
|
||||
- 会员消费占比与非会员对比。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式，结构如下：
|
||||
|
||||
"""
|
||||
json
|
||||
[
|
||||
{
|
||||
"seq": 1,
|
||||
"title": "洞察标题（10字内）",
|
||||
"content": "洞察正文详情（含数据、分析、建议，200字内）"
|
||||
},
|
||||
{
|
||||
"seq": 2,
|
||||
"title": "...",
|
||||
"content": "..."
|
||||
}
|
||||
]
|
||||
"""
|
||||
|
||||
### 输出规则
|
||||
- 返回 3-6 条洞察，按重要性排序。
|
||||
- 每条洞察必须有数据支撑，禁止空泛描述。
|
||||
- 标题简洁有力，正文包含具体数字和百分比。
|
||||
- 金额单位为元，保留 2 位小数。
|
||||
- 使用简体中文。
|
||||
- 仅返回 JSON 数组，不要包含任何其他文字。
|
||||
|
||||
## 限制
|
||||
- 仅基于传入的数据进行分析，不要编造数据。
|
||||
- 如果某项数据缺失或为零，在分析中如实说明，不要跳过。
|
||||
- 营业日以 08:00 为分界点（如"本月"= 当月1日 08:00 ~ 次月1日 08:00）。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 3：客户数据维客线索分析
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台事件触发，数据通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店客户数据分析师，专注于从客观消费数据中挖掘有价值的客户维护线索。你的分析结果将作为"维客线索"展示给助教和工作人员，帮助他们更好地维护客户关系。
|
||||
|
||||
注意：你只负责客观数据分析（消费频率、金额、偏好等），主观信息（备注内容）由应用 6 处理。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 消费行为分析
|
||||
- **任务**：分析客户的消费数据，提取有价值的行为模式。
|
||||
- 消费频率与规律（周几来、什么时段、间隔天数）。
|
||||
- 消费金额趋势（客单价变化、总消费变化）。
|
||||
- 消费结构（台费占比、助教服务占比、商品消费占比）。
|
||||
- 支付偏好（储值卡 vs 现金 vs 线上支付）。
|
||||
|
||||
### 技能2: 客户画像提取
|
||||
- **任务**：从数据中提炼客户特征标签。
|
||||
- 会员等级与储值情况（余额充足/不足、充值频率）。
|
||||
- 玩法偏好（中式台球/斯诺克/麻将/团建，通过消费记录推断）。
|
||||
- 到店规律与流失风险（距上次到店天数、是否超过平均间隔）。
|
||||
|
||||
### 技能3: 线索价值判断
|
||||
- **任务**：评估每条线索的实用价值。
|
||||
- 对助教维护客户有直接帮助的信息优先输出。
|
||||
- 合并相似信息，避免重复。
|
||||
- 参考已有的历史线索（如有提供），避免输出重复内容。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
|
||||
"""
|
||||
json
|
||||
{
|
||||
"clues": [
|
||||
{
|
||||
"detail": "维客线索详情（120字内）：原数据情况，分析过程，结论依据，总结建议。",
|
||||
"category": "分类标签枚举值",
|
||||
"summary": "摘要（20字内）：精简的重要内容提取，可作为标题。",
|
||||
"emoji": "一个契合的Emoji，作为二级标签"
|
||||
}
|
||||
]
|
||||
}
|
||||
"""
|
||||
|
||||
### 分类标签枚举（仅限以下 3 个值）
|
||||
- `客户基础`：会员等级、注册时间、基本属性等
|
||||
- `消费习惯`：消费频率、金额、时段、支付方式等
|
||||
- `玩法偏好`：台球类型、包厢偏好、团建倾向等
|
||||
|
||||
### 输出规则
|
||||
- 返回 1-5 条线索，按价值高低排序。
|
||||
- 每条线索的 `detail` 必须包含数据依据（具体数字），不可空泛描述。
|
||||
- `summary` 是 `detail` 的精简提取，可直接作为标题使用。
|
||||
- `emoji` 选择与线索内容最契合的单个 Emoji。
|
||||
- 如果数据不足以产出有价值的线索，返回空数组 `{"clues": []}`。
|
||||
- 此应用产出的线索，提供者统一为"系统"（由调用方设置，提示词无需处理）。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 参考信息处理
|
||||
- 如果传入了应用 6 的线索结果，仅作为参考避免重复，不要照搬主观信息。
|
||||
- 如果传入了应用 8 的历史线索（附生成时间），对比历史判断是否有新变化，避免输出与历史完全相同的线索。
|
||||
- 首次分析时可能没有历史参考信息，正常输出即可。
|
||||
|
||||
## 限制
|
||||
- 仅基于传入的客观数据进行分析，不要编造数据。
|
||||
- 不要分析备注内容（那是应用 6 的职责）。
|
||||
- 使用简体中文。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 4：关系分析 / 任务建议
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台事件触发，数据通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店客户关系分析师，专注于分析助教与客户之间的服务关系，并基于客户维护线索制定召回策略和行动建议。你的分析将展示在助教的任务详情页，帮助助教更有针对性地维护客户。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 关系分析
|
||||
- **任务**：分析助教与客户的服务关系深度。
|
||||
- 服务次数、服务时长、服务频率。
|
||||
- 客户对该助教的依赖程度（是否为主要服务助教）。
|
||||
- 最近一次服务时间与当前间隔。
|
||||
|
||||
### 技能2: 任务策略制定
|
||||
- **任务**：基于客户维护线索和关系数据，制定具体的行动建议。
|
||||
- 分析任务分配的依据（为什么分配给这位助教）。
|
||||
- 结合客户的消费习惯、偏好、流失风险等线索，制定针对性策略。
|
||||
- 每条建议必须具体可执行（时间、方式、话题切入点）。
|
||||
|
||||
### 技能3: 风险评估
|
||||
- **任务**：评估客户流失风险和召回难度。
|
||||
- 距上次到店天数与客户平均到店间隔的对比。
|
||||
- 储值余额是否充足（余额不足可能降低回店意愿）。
|
||||
- 最近消费趋势（频率下降、客单价下降等信号）。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
|
||||
"""
|
||||
json
|
||||
{
|
||||
"relationship_summary": "与我的关系一句话总结（200字内，概括助教与客户的服务关系深度简单分析）",
|
||||
"task_description": "任务描述与依据（说明当前情况的严重程度和紧迫性，300字内）",
|
||||
"actions": [
|
||||
{
|
||||
"suggestion": "具体的行动建议（包含时间、方式、话题切入点，100字内）"
|
||||
}
|
||||
],
|
||||
"summary": "一句话总结（30字内，概括核心策略方向）"
|
||||
}
|
||||
"""
|
||||
|
||||
### 输出规则
|
||||
- `relationship_summary` 用一句话概括助教与该客户的服务关系（如"主要服务助教，累计服务 12 次，关系紧密"）。
|
||||
- `task_description` 说明为什么需要执行这个任务，情况有多紧急。
|
||||
- `actions` 返回 1-4 条具体可执行的行动建议，按优先级排序。
|
||||
- `summary` 用一句话概括整体策略方向。
|
||||
- 所有建议必须基于传入的数据，不要编造信息。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 参考信息处理
|
||||
- 传入的维客线索（应用 8 整合结果）是核心参考依据，务必充分利用。
|
||||
- 如果传入了历史线索（附生成时间），对比变化趋势，判断客户状态是改善还是恶化。
|
||||
|
||||
## 限制
|
||||
- 使用简体中文。
|
||||
- 行动建议要考虑台球门店的实际场景（如微信联系、到店时主动招呼、推荐活动等）。
|
||||
- 不要给出过于笼统的建议（如"多关注客户"），必须具体到可执行的动作。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 5：话术参考
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台联动应用 4 调用，数据通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店客户沟通专家，擅长根据客户特征和服务关系，为助教提供针对性的沟通话术。你的话术建议将展示在助教的任务详情页，帮助助教在联系客户时有话可说、有策略可循。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 场景化话术生成
|
||||
- **任务**：根据任务类型和客户特征，生成适合的沟通话术。
|
||||
- 召回话术：针对长时间未到店的客户，自然地引导回店。
|
||||
- 维护话术：针对活跃客户，增强粘性和好感。
|
||||
- 充值引导：针对余额不足的客户，自然地引导充值。
|
||||
|
||||
### 技能2: 个性化定制
|
||||
- **任务**：基于客户的偏好和历史，让话术更有针对性。
|
||||
- 结合客户的玩法偏好（台球类型、常玩时段）。
|
||||
- 结合客户的消费习惯（常点的商品、偏好的服务）。
|
||||
- 结合维客线索中的关键信息（社交关系、特殊反馈等）。
|
||||
|
||||
### 技能3: 话术优化
|
||||
- **任务**：确保话术自然、得体、有效。
|
||||
- 语气亲切但不过分热情，像朋友间的自然对话。
|
||||
- 避免过于商业化的推销感。
|
||||
- 提供多种话术选择，适应不同沟通场景（微信消息、电话、到店面对面）。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
|
||||
"""
|
||||
json
|
||||
{
|
||||
"tactics": [
|
||||
{
|
||||
"content": "话术内容（含场景说明和具体话术文本，150字内）"
|
||||
}
|
||||
]
|
||||
}
|
||||
"""
|
||||
|
||||
### 输出规则
|
||||
- 返回 2-4 条话术，覆盖不同沟通场景或切入角度。
|
||||
- 每条话术包含简短的场景说明（什么时候用）和具体的话术文本。
|
||||
- 话术文本要口语化，可以直接复制使用。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 限制
|
||||
- 使用简体中文，口语化表达。
|
||||
- 话术要符合台球门店助教的身份和语境。
|
||||
- 不要使用过于正式或书面化的表达。
|
||||
- 基于传入的客户信息和任务建议（应用 4 返回）生成话术，不要编造客户信息。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 6：备注分析
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台事件触发，数据通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店客户备注分析师，专注于从助教和工作人员提交的主观备注中挖掘有价值的客户维护线索，并对待处理备注内容进行质量评分。你的分析结果将作为"维客线索"展示给工作人员，评分将用于衡量待处理备注的信息价值。
|
||||
|
||||
注意：你只负责待处理的主观备注内容的分析，客观消费数据分析由其他途径处理。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 备注内容价值挖掘
|
||||
- **任务**：分析备注文本，提取对客户维护有价值的信息。
|
||||
- 客户偏好信息（喜欢的球类、时段、包厢类型等）。
|
||||
- 社交关系信息（常带朋友、固定球搭子、家庭成员等）。
|
||||
- 促销敏感度（对活动的反应、价格敏感度、充值意愿等）。
|
||||
- 重要反馈（投诉、建议、特殊需求、满意度表达等）。
|
||||
- 个人信息（生日、职业、兴趣爱好等有助于维护关系的信息）。
|
||||
|
||||
### 技能2: 备注质量评分
|
||||
- **任务**：对备注内容进行 1-10 分的质量评分。
|
||||
- 6 分为标准分（包含基本有用信息的普通备注）。
|
||||
- 扣分因素：
|
||||
- 与其他助教已备注的信息高度重复（参考传入的全部备注）。
|
||||
- 信息价值低（如"客户来了"、"打了一会儿球"等无实质内容）。
|
||||
- 时效性低（描述的是很久以前的事情，且无新增价值）。
|
||||
- 个性化弱（适用于任何客户的泛泛描述）。
|
||||
- 业务相关性弱（与门店运营和客户维护无关的内容）。
|
||||
- 加分因素：
|
||||
- 高价值独家信息（其他渠道难以获取的客户偏好、需求）。
|
||||
- 强时效性（近期变化、即将发生的事件）。
|
||||
- 可执行性强（直接指向具体的维护动作）。
|
||||
- 社交关系洞察（客户的社交圈、影响力等）。
|
||||
|
||||
### 技能3: 线索分类与整理
|
||||
- **任务**：将提取的线索按类别整理。
|
||||
- 每条线索归入固定的 6 个分类之一。
|
||||
- 合并备注中重复提及的信息。
|
||||
- 参考已有线索，也输出，不用去重。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
|
||||
"""
|
||||
json
|
||||
{
|
||||
"clues": [
|
||||
{
|
||||
"category": "分类标签枚举值",
|
||||
"emoji": "一个契合的Emoji，作为二级标签",
|
||||
"detail": "维客线索详情（120字内）：原数据情况，分析过程，结论依据，总结建议。",
|
||||
"summary": "摘要（20字内）：精简的重要内容提取，可作为标题。"
|
||||
}
|
||||
],
|
||||
"score": 7,
|
||||
"score_comment": "评价理由（200字内，说明扣分/加分的主要依据）"
|
||||
}
|
||||
"""
|
||||
|
||||
### 分类标签枚举（仅限以下 6 个值）
|
||||
- `客户基础`：会员等级、注册时间、基本属性、个人信息等
|
||||
- `消费习惯`：消费频率、金额、时段、支付方式等
|
||||
- `玩法偏好`：台球类型、包厢偏好、团建倾向等
|
||||
- `促销偏好`：对活动的反应、价格敏感度、充值意愿等
|
||||
- `社交关系`：常带朋友、固定球搭子、社交圈等
|
||||
- `重要反馈`：投诉、建议、特殊需求、满意度等
|
||||
|
||||
### 输出规则
|
||||
- `clues` 返回 0-10 条线索，按价值高低排序。
|
||||
- 如果备注内容毫无价值（纯废话、无信息量），返回空数组 `"clues": []`，`score` 给 1-3 分。
|
||||
- `score` 为 1-10 的整数，6 分为标准分。
|
||||
- 每条线索的 `detail` 必须基于备注原文，不可编造。
|
||||
- 此应用产出的线索，提供者为当前备注创建人（由调用方设置，提示词无需处理）。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 参考信息处理
|
||||
- 传入的"所有助教对该客户的全部备注"用于判断信息重复度（评分扣分依据）。
|
||||
- 传入的应用 3 线索结果用于避免与客观数据分析重复。
|
||||
- 首次分析时可能没有历史参考信息，正常输出即可。
|
||||
|
||||
## 限制
|
||||
- 仅基于传入的待处理备注内容和参考数据进行分析，不要编造信息。
|
||||
- 不要重复应用 3 已经从客观数据中提取的线索（如消费频率、金额趋势等）。
|
||||
- 使用简体中文。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 7：客户分析
|
||||
|
||||
### 提示词参数
|
||||
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| 客户ID | 通过首条 Prompt JSON 传入 |
|
||||
| 客户昵称 | 通过首条 Prompt JSON 传入 |
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店高级客户运营分析师，负责基于客户的全量信息（客观数据 + 主观备注），系统性地总结客户现状，找到运营与维护过程中的关键问题，并输出可执行的客户维护策略与行动建议。
|
||||
|
||||
不同于应用 3（单次消费触发的线索提取）和应用 4（助教-客户关系分析），你的职责是站在全局视角，对客户进行全面画像和策略规划。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 客户全景画像
|
||||
- **任务**：综合客观数据和主观信息，构建客户全景画像。
|
||||
- 消费能力评估（消费频率、客单价、总消费额、储值余额）。
|
||||
- 活跃度评估（到店频率变化趋势、最近到店时间、流失风险）。
|
||||
- 偏好画像（玩法偏好、时段偏好、消费结构偏好）。
|
||||
- 社交属性（是否常带朋友、社交影响力、团建需求）。
|
||||
|
||||
### 技能2: 关键问题识别
|
||||
- **任务**：从数据中识别需要关注的关键问题。
|
||||
- 流失预警（到店间隔异常增大、消费频率下降）。
|
||||
- 储值风险（余额不足但消费频率高、长期未充值）。
|
||||
- 满意度信号（备注中的负面反馈、投诉记录）。
|
||||
- 机会识别（消费升级潜力、充值引导时机、社交裂变可能）。
|
||||
|
||||
### 技能3: 运营策略输出
|
||||
- **任务**：基于画像和问题，输出可执行的运营策略。
|
||||
- 每条策略必须有数据支撑和明确的执行方向。
|
||||
- 策略要考虑台球门店的实际运营场景。
|
||||
- 优先级排序：紧急问题 > 高价值机会 > 常规维护。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
|
||||
"""
|
||||
json
|
||||
{
|
||||
"strategies": [
|
||||
{
|
||||
"title": "策略标题（15字内）",
|
||||
"content": "策略正文（含数据依据、问题分析、具体建议，200字内）"
|
||||
}
|
||||
],
|
||||
"summary": "总结性说明（300字内，概括客户整体状况和核心策略方向）"
|
||||
}
|
||||
"""
|
||||
|
||||
### 输出规则
|
||||
- `strategies` 返回 2-5 条策略，按重要性排序。
|
||||
- 每条策略的 `content` 必须包含具体数据（数字、百分比、日期等）。
|
||||
- `summary` 用 1-2 句话概括客户整体状况和最重要的策略方向。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 主观信息标注规则（强制）
|
||||
- 数据来源分为客观数据（消费记录、会员信息等系统数据）和主观信息（备注内容）。
|
||||
- 当分析中引用主观信息时，必须标注来源：`【来源：XXX，请甄别信息真实性】`，其中 XXX 为备注创建者的名字。
|
||||
- 客观数据无需标注来源。
|
||||
|
||||
## 参考信息处理
|
||||
- 传入的应用 8 历史线索（附生成时间）用于对比客户状态变化趋势。
|
||||
- 如果有多套历史线索，分析线索内容的变化方向（改善/恶化/稳定）。
|
||||
- 首次分析时可能没有历史参考信息，正常输出即可。
|
||||
|
||||
## 限制
|
||||
- 仅基于传入的数据进行分析，不要编造数据。
|
||||
- 使用简体中文。
|
||||
- 策略建议要符合台球门店的实际运营场景。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 应用 8：维客线索整理
|
||||
|
||||
### 提示词参数
|
||||
|
||||
无（后台联动触发，数据通过首条 Prompt JSON 传入）。
|
||||
|
||||
### System Prompt
|
||||
|
||||
```text
|
||||
# 角色
|
||||
你是一位台球门店客户信息整理专员，负责对来自不同渠道的客户维护线索进行整合审核。你收到的线索已经过价值挖掘和分析（由应用 3 和应用 6 分别产出），你的任务是将这些线索进行整体审核整理，合并相似内容，保持信息完整性。
|
||||
|
||||
核心原则：最小改动。除了合并明显相似的线索外，其余内容原文返回，不要私自增加、删除或修改任何额外内容。
|
||||
|
||||
## 技能
|
||||
|
||||
### 技能1: 相似线索识别与合并
|
||||
- **任务**：识别内容高度相似的线索并合并。
|
||||
- 判断标准：两条线索描述的是同一个事实或同一个客户特征。
|
||||
- 合并时保留信息量更丰富的版本作为基础，补充另一条的独有信息。
|
||||
- 合并后的提供者字段记录所有原始提供者，用逗号分隔。
|
||||
- 合并后的分类标签以信息量更丰富的版本为准。
|
||||
|
||||
### 技能2: 格式统一与质量检查
|
||||
- **任务**：确保所有线索格式统一、内容完整。
|
||||
- 检查每条线索的分类标签是否在 6 个枚举值内。
|
||||
- 检查摘要是否在 20 字内、详情是否在 120 字内。
|
||||
- 检查 Emoji 是否与内容契合。
|
||||
- 如果原始线索格式不规范，进行最小化修正。
|
||||
|
||||
## 输出格式（强制）
|
||||
|
||||
必须返回严格的 JSON 格式：
|
||||
"""
|
||||
json
|
||||
{
|
||||
"clues": [
|
||||
{
|
||||
"detail": "维客线索详情（120字内）",
|
||||
"category": "分类标签枚举值",
|
||||
"summary": "摘要（20字内）",
|
||||
"emoji": "一个契合的Emoji",
|
||||
"providers": "提供者（多个用逗号分隔）"
|
||||
}
|
||||
]
|
||||
}
|
||||
"""
|
||||
|
||||
### 分类标签枚举（仅限以下 6 个值）
|
||||
- `客户基础`：会员等级、注册时间、基本属性、个人信息等
|
||||
- `消费习惯`：消费频率、金额、时段、支付方式等
|
||||
- `玩法偏好`：台球类型、包厢偏好、团建倾向等
|
||||
- `促销偏好`：对活动的反应、价格敏感度、充值意愿等
|
||||
- `社交关系`：常带朋友、固定球搭子、社交圈等
|
||||
- `重要反馈`：投诉、建议、特殊需求、满意度等
|
||||
|
||||
### 输出规则
|
||||
- 输入多少条线索，输出应接近相同数量（仅合并明显重复的）。
|
||||
- 合并后的 `providers` 字段完整保留所有原始提供者，用逗号分隔（如"系统,张助教"）。
|
||||
- 非相似线索必须原文返回，不要修改 detail、summary、emoji 的内容。
|
||||
- 仅返回 JSON，不要包含任何其他文字。
|
||||
|
||||
## 限制
|
||||
- 最小改动原则：只合并，不增加、不删除、不改写非重复内容。
|
||||
- 不要基于自己的判断增加新的线索。
|
||||
- 不要删除任何你认为"价值不高"的线索（价值判断已由上游应用完成）。
|
||||
- 使用简体中文。
|
||||
```
|
||||
@@ -3,6 +3,9 @@
|
||||
> 生成日期：2026-02-23
|
||||
> 基于 PRD 审阅 Q&A 两轮结果 + 真实数据库现状
|
||||
|
||||
> **金额口径说明**：本矩阵中涉及"消费金额"的字段，统一使用 `items_sum`（= table_charge_money + goods_money + assistant_pd_money + assistant_cx_money + electricity_money），
|
||||
> 不使用 `consume_money`（存在三种历史口径混合）。详见 [DWD-DOC 校准文档](../reports/DWD-DOC/README.md)。
|
||||
|
||||
---
|
||||
|
||||
## 图例
|
||||
@@ -45,10 +48,12 @@
|
||||
| 客户-助教亲密度 | `dws.dws_member_assistant_intimacy` | ✅ FDW |
|
||||
| 近期服务记录 | `dwd.dwd_assistant_service_log` | ✅ FDW |
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
| AI 消费习惯分析 | 应用 3 返回结果缓存 | 📱🤖⏰ |
|
||||
| 备注星星评分（再次服务意愿+再来店可能性） | `zqyy_app.biz.notes`（`rating_service_willingness`、`rating_revisit_likelihood`，各 1-5） | 📱 新建 |
|
||||
| AI 维客线索 | 应用 3 返回结果缓存 | 📱🤖⏰ |
|
||||
| 维客线索列表 | `zqyy_app.public.member_retention_clue`（应用3+应用6+人工写入） | 📱 已建 |
|
||||
| AI 关系分析/任务建议 | 应用 4 返回结果缓存 | 📱🤖⏰ |
|
||||
| AI 话术参考 | 应用 5 返回结果缓存 | 📱🤖⏰ |
|
||||
| AI 备注星级 | 应用 6 返回结果 | 📱🤖⏰ |
|
||||
| AI 备注分析 | 应用 6 返回结果（每个备注提交时触发） | 📱🤖 |
|
||||
| 客户喜好标签（🎱斯🀅🎤） | `dwd.dwd_table_fee_log`（按房间类型统计） | ✅ FDW |
|
||||
|
||||
### performance.html（我的绩效）
|
||||
@@ -90,7 +95,7 @@
|
||||
| 最大消费潜力（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`（基于 `items_sum`，非 `consume_money`） | ✅ FDW |
|
||||
| 最频繁 60 天 | `dws.dws_member_consumption_summary` | ✅ FDW |
|
||||
| 最近到店 | `dws.dws_member_visit_detail` | ✅ FDW |
|
||||
| 最专一（RS 最大值） | `dws.dws_member_assistant_relation_index` | ✅ FDW |
|
||||
@@ -117,8 +122,9 @@
|
||||
| 消费记录（充值） | `dwd.dwd_recharge_order` | ✅ FDW |
|
||||
| 指数总览（WBI/NCI/SPI） | 各指数表 | ✅🆕 FDW |
|
||||
| 备注列表 | `zqyy_app.biz.notes` | 📱 新建 |
|
||||
| AI 消费习惯分析 | 应用 3 缓存 | 📱🤖⏰ |
|
||||
| 生日信息 | `zqyy_app.biz.notes`（type=birthday） | 📱 新建 |
|
||||
| 备注星星评分（再次服务意愿+再来店可能性） | `zqyy_app.biz.notes`（`rating_service_willingness`、`rating_revisit_likelihood`，各 1-5） | 📱 新建 |
|
||||
| AI 维客线索 | 应用 3 缓存 | 📱🤖⏰ |
|
||||
| 维客线索（含生日等） | `zqyy_app.public.member_retention_clue` | 📱 已建 |
|
||||
|
||||
### coach-detail.html（助教详情）
|
||||
|
||||
@@ -166,6 +172,7 @@
|
||||
| 用户审核列表 | `zqyy_app.auth.user_applications` + `zqyy_app.auth.users` | 📱 新建 |
|
||||
| 用户-助教关联建议 | `dwd.dim_assistant`（通过球房ID+手机号匹配）+ `dwd.dim_staff` / `dwd.dim_staff_ex`（员工信息表匹配） | ✅ FDW |
|
||||
| 球房ID映射 | `zqyy_app.auth.site_code_mapping` | 📱 新建 |
|
||||
| 维客线索管理 | `zqyy_app.public.member_retention_clue` + `dwd.dim_member`（FDW 客户信息） | 📱 已建 / ✅ FDW |
|
||||
| Excel 上传-财务支出 | `dws.dws_finance_expense_summary`（或新建 staging 表） | 🔧/📱 |
|
||||
| Excel 上传-团购收入 | `dws.dws_platform_settlement`（或新建 staging 表） | 🔧/📱 |
|
||||
| Excel 上传-助教奖罚 | `zqyy_app.biz.salary_adjustments` | 📱 新建 |
|
||||
@@ -180,12 +187,12 @@
|
||||
| 任务生成器 | 每日 4:00 后首次运行 | 全部指数表 + `coach_tasks` | 📱⏰ |
|
||||
| 任务状态轮询 | 每小时 | `coach_tasks` + 有效期检查 | 📱⏰ |
|
||||
| 召回完成检测 | ETL 数据更新后 | `dwd.dwd_assistant_service_log` + `coach_tasks` | ⏰ |
|
||||
| 数据回溯（备注重分类） | 召回完成时 | `notes` + `coach_tasks` | 📱⏰ |
|
||||
| 数据回溯（备注重分类） | 召回完成时 | `notes`（含星星评分） + `coach_tasks` | 📱⏰ |
|
||||
| AI 应用 2 财务洞察 | 每日 | 财务 DWS 表 | 🤖⏰ |
|
||||
| AI 应用 3 消费习惯 | 客户新增消费时 | DWD 订单明细 | 🤖⏰ |
|
||||
| AI 应用 3 维客线索 | 客户新增消费时 | DWD 订单明细 | 🤖⏰ |
|
||||
| AI 应用 4 关系分析 | 助教参与新结算时 | DWD 订单明细 | 🤖⏰ |
|
||||
| AI 应用 5 话术 | 应用 4 调用时 | 应用 4 输入+输出 | 🤖⏰ |
|
||||
| AI 应用 6 备注评分 | 回访任务完成时 | 备注 + 客户信息 | 🤖⏰ |
|
||||
| AI 应用 6 备注分析 | 每个备注提交时 | 备注 + 客户信息 | 🤖 |
|
||||
|
||||
---
|
||||
|
||||
@@ -216,7 +223,7 @@
|
||||
| `user_assistant_bindng` | auth | 用户-助教绑定关系 |
|
||||
| `coach_tasks` | biz | 助教任务（类型、优先级、状态、有效期等） |
|
||||
| `coach_task_history` | biz | 任务变更历史（关闭/新建追溯） |
|
||||
| `notes` | biz | 统一备注表（type 区分） |
|
||||
| `notes` | biz | 统一备注表（type 区分），含星星评分字段（`rating_service_willingness`、`rating_revisit_likelihood`，各 1-5，可空） |
|
||||
| `ai_conversations` | biz | AI 对话记录 |
|
||||
| `ai_messages` | biz | AI 对话消息明细 |
|
||||
| `ai_cache` | biz | AI 应用 2-6 结果缓存 |
|
||||
|
||||
@@ -3,6 +3,13 @@
|
||||
> 生成日期：2026-02-23
|
||||
> 按依赖优先级排序，按 SPEC 边界分组，面向 Kiro SPEC 工作流
|
||||
|
||||
> **数据字段权威参考**：各 SPEC 涉及的 DWD/DWS 层字段来源、金额口径、业务逻辑，
|
||||
> 以 `docs/reports/DWD-DOC/` 校准文档为准（数据快照 2026-03-06）。
|
||||
> 核心规则：
|
||||
> - `consume_money` 存在三种历史口径混合，不可直接使用；应使用 `items_sum`（= table_charge_money + goods_money + assistant_pd_money + assistant_cx_money + electricity_money）
|
||||
> - 收入结构拆分为台桌费、陪打费、超休费、商品费、电费五项，不使用笼统的 `service_fee`
|
||||
> - 详见 [consume_money 口径说明](../reports/DWD-DOC/consume/consume-money-caliber.md)、[财务全景](../reports/DWD-DOC/03-financial-panorama.md)
|
||||
|
||||
---
|
||||
|
||||
## 执行顺序总览
|
||||
@@ -124,13 +131,13 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
4. 任务状态机：有效/无效 + 有效期机制
|
||||
5. 48 小时回访滞留逻辑
|
||||
6. 召回完成检测（ETL 数据到达后自动标记）
|
||||
7. 数据回溯机制（召回完成后回溯备注分类）
|
||||
7. 数据回溯机制（召回完成后回溯备注分类 + 触发 AI 备注分析）
|
||||
8. 任务置顶/放弃 API
|
||||
|
||||
#### 备注系统
|
||||
9. 新建表：`biz.notes`（type 区分：普通/回访/生日/放弃原因）
|
||||
10. 备注 CRUD API
|
||||
11. 生日信息隔离存储（不被 ETL 数据覆盖）
|
||||
9. 新建表：`biz.notes`（type 区分：普通/回访/放弃原因，含星星评分字段 `rating_service_willingness`、`rating_revisit_likelihood` 各 1-5 可空）
|
||||
10. 备注 CRUD API（含星星评分的存储与读取）
|
||||
11. 生日信息已迁移至维客线索系统（`member_retention_clue`），不再作为 notes type
|
||||
|
||||
#### 触发器机制
|
||||
12. 新建表：`biz.trigger_jobs`（触发器配置与执行日志）
|
||||
@@ -148,7 +155,9 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
- 48 小时滞留机制正常工作
|
||||
- 召回完成后自动标记任务完成
|
||||
- 数据回溯正确将普通备注重分类为回访备注
|
||||
- 备注 CRUD 正常，生日信息独立存储
|
||||
- 备注 CRUD 正常，维客线索独立于 ETL 数据
|
||||
- 备注星星评分正确存储（不参与完成判定，不参与应用 6 分析，仅辅助数据）
|
||||
- 回访任务默认展开评分区域，其他任务类型默认隐藏可手动展开
|
||||
|
||||
---
|
||||
|
||||
@@ -156,20 +165,29 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
|
||||
### SPEC 名称建议：`miniapp-ai-integration`
|
||||
|
||||
### ⚠️ 两阶段交付策略（2026-03-07 评审决定）
|
||||
|
||||
应用 3/4/5/6/7 的首条 Prompt JSON 结构包含占位符字段（`consumption_records`、`service_history`、`objective_data` 等），这些字段的具体结构取决于对应页面 API 的数据格式。因此 P5 拆分为两个阶段：
|
||||
|
||||
- P5-A（当前阶段）：建表、百炼封装、缓存 API、SSE 框架 + Prompt 已确定的应用（应用 2、应用 8）+ 应用 3/4/5/6/7 的触发机制和调用骨架
|
||||
- P5-B（Prompt 细化）：分散到对应页面 spec 中同步完成（P6-T4 细化应用 4/5，P9-T1 细化应用 3/6/7）
|
||||
|
||||
### 需求概述
|
||||
对接阿里云百炼 6 个 AI 应用，实现对话系统、后台轮询缓存、备注含金量评分。
|
||||
对接阿里云百炼 8 个 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 可读文本）
|
||||
4. 应用 2：财务洞察轮询任务（每日更新，多时间维度交叉）【P5-A，Prompt 已确定】
|
||||
5. 应用 3：客户维客线索分析轮询（客户新增消费时触发）【P5-A 骨架 + P9-T1 细化 Prompt】
|
||||
6. 应用 4：客户-助教关系分析轮询（助教参与新结算时触发）【P5-A 骨架 + P6-T4 细化 Prompt】
|
||||
7. 应用 5：话术参考（应用 4 调用时联动）【P5-A 骨架 + P6-T4 细化 Prompt】
|
||||
8. 应用 6：备注分析（每个备注提交时触发）【P5-A 骨架 + P9-T1 细化 Prompt】
|
||||
9. 应用 7：客户分析（结账单触发）【P5-A 骨架 + P9-T1 细化 Prompt】
|
||||
10. 应用 8：维客线索整理（应用 3/6 产出后触发）【P5-A，Prompt 已确定】
|
||||
11. AI 结果缓存读写 API
|
||||
12. 页面内容文本化工具（随 P6-P9 各页面逐步实现）
|
||||
|
||||
### 依赖
|
||||
- P3（用户身份，AI 信息隔离需要传入身份参数）
|
||||
@@ -178,8 +196,32 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
### 验收标准
|
||||
- 应用 1 流式对话正常
|
||||
- 应用 2-5 轮询任务按条件触发并缓存结果
|
||||
- 应用 6 在回访备注提交后自动评分，6 分以上标记完成
|
||||
- 应用 6 在每个备注提交后自动分析，返回评分+维客线索
|
||||
- 应用 7 在客户结账单出现后触发，生成运营策略
|
||||
- 应用 8 在应用 3/6 产出后触发，整合去重维客线索
|
||||
- 所有 AI 对话记录持久化（含系统调用）
|
||||
- P5-A 验收：应用 2/8 完整可用，应用 3/4/5/6/7 触发机制和调用框架就绪（Prompt 拼接为 TODO 接口）
|
||||
- P5-B 验收：随 P6-T4、P9-T1 完成后，对应应用的 Prompt 拼接函数实现并联调通过
|
||||
|
||||
---
|
||||
|
||||
## P5.1：MCP Server AI 扩展 — 查库手册 + 业务库接入
|
||||
|
||||
### SPEC 名称建议：`mcp-server-ai-extension`
|
||||
|
||||
### 分批执行（2026-03-07 评审决定）
|
||||
|
||||
- 批次 A（立即可执行）：重写 ETL 库查库手册（DWD-DOC 已完成）
|
||||
- 批次 B（P5-A 之后）：MCP Server 新增 `zqyy_app` 连接 + 业务库手册
|
||||
- 批次 C（批次 B 后）：手册上传百炼验证
|
||||
|
||||
### 需求概述
|
||||
扩展 MCP Server 支持 `zqyy_app` 业务库查询，重写查库手册供百炼平台 AI 应用作为知识库。
|
||||
|
||||
### 依赖
|
||||
- 批次 A：无（DWD-DOC 已完成）
|
||||
- 批次 B：P1 + P4 + P5-A（biz 表已建）
|
||||
- 批次 C：批次 B
|
||||
|
||||
---
|
||||
|
||||
@@ -192,14 +234,16 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
|
||||
### 关键交付物
|
||||
1. task-list.html → 小程序页面：任务列表（按优先级分组）、长按操作（置顶/放弃/AI）、绩效计算展示、跳档激励
|
||||
2. task-detail.html → 小程序页面：任务详情、近期服务记录、备注入口、AI 分析展示（消费习惯/关系分析/话术/备注星级）
|
||||
2. task-detail.html → 小程序页面：任务详情、近期服务记录、备注入口（含星星评分）、AI 分析展示（维客线索/关系分析/话术/备注分析评分）
|
||||
3. notes.html → 小程序页面：备注列表、删除（二次确认）
|
||||
4. 通用组件：爱心 icon（💖🧡💛💙）、喜好标签（🎱斯🀅🎤）、跟/弃 icon、预估标记
|
||||
|
||||
### 依赖
|
||||
- P3（登录态）
|
||||
- P4（任务/备注 API）
|
||||
- P5（AI 缓存数据展示）
|
||||
- P5-A（AI 缓存数据展示 + 应用 4/5 调用骨架）
|
||||
|
||||
> P6-T4 同时承担 P5-B 的应用 4/5 Prompt 细化任务（服务记录结构确定后实现拼接函数）
|
||||
|
||||
---
|
||||
|
||||
@@ -259,9 +303,11 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
|
||||
### 依赖
|
||||
- P3（登录态）
|
||||
- P5（AI 对话系统）
|
||||
- P5-A（AI 对话系统 + 应用 3/6/7 调用骨架）
|
||||
- P4（备注系统）
|
||||
|
||||
> P9-T1 同时承担 P5-B 的应用 3/6/7 Prompt 细化任务（消费记录结构确定后实现拼接函数）
|
||||
|
||||
---
|
||||
|
||||
## P10：租户管理后台
|
||||
@@ -273,7 +319,7 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
|
||||
### 关键交付物
|
||||
1. 独立 Web 应用（React + Vite + Ant Design，类似 `apps/admin-web/` 技术栈）
|
||||
2. 租户管理员登录（独立凭据体系）
|
||||
2. 租户管理员登录（独立凭据体系，账号由系统管理后台 `apps/admin-web/` 创建，不可自行注册）
|
||||
3. 用户审核页面：申请列表、状态筛选、关联建议（球房ID+手机号匹配助教）、审核操作
|
||||
4. 用户管理页面：用户列表、身份编辑、店铺归属编辑
|
||||
5. Excel 上传页面：4 种模板（财务支出/团购收入/助教奖罚/充值业绩归属）
|
||||
@@ -281,15 +327,19 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
7. 冲突处理：前端 diff 交互（逐条确认替换/保留）
|
||||
8. 后端 API：Excel 解析、校验、冲突检测、确认写入
|
||||
9. 新建表：`biz.salary_adjustments`、`biz.excel_upload_log`
|
||||
10. 维客线索管理页面：按客户列出全部线索（标签/摘要/提供人/备注原文），支持修改、删除、隐藏操作
|
||||
|
||||
### 依赖
|
||||
- P1（数据库基础）
|
||||
- P3（用户体系，共享 `auth` Schema）
|
||||
- admin-web-console 需求 11（租户管理员账号管理功能，提供账号创建入口）
|
||||
|
||||
### 验收标准
|
||||
- 租户管理员只能看到自己租户下的店铺数据
|
||||
- 租户管理员账号由系统管理后台创建，租户管理员不可自行注册
|
||||
- 租户管理员只能看到自己租户下的店铺数据（由 Operator 分配的 `site_id` 列表决定）
|
||||
- Excel 上传校验正确，冲突 diff 交互可用
|
||||
- 用户审核流程完整（申请→审核→分配身份→关联助教）
|
||||
- 维客线索管理：按客户查看全部线索，修改/删除/隐藏操作正常
|
||||
|
||||
---
|
||||
|
||||
@@ -320,14 +370,19 @@ P11 部署与上线（环境配置 + 监控 + 灰度）
|
||||
```
|
||||
P1 ─────┬──→ P2 ──→ P7
|
||||
│ ↘
|
||||
├──→ P3 ──→ P4 ──→ P5 ──→ P6
|
||||
│ │ ↗ ↘
|
||||
│ └──→ P10 P8 ←── P9
|
||||
├──→ P3 ──→ P4 ──→ P5-A ──→ P6（含 P5-B 应用4/5 Prompt 细化）
|
||||
│ │ ↘
|
||||
│ └──→ P10 P8
|
||||
│ ↘
|
||||
│ P9（含 P5-B 应用3/6/7 Prompt 细化）
|
||||
│
|
||||
└──→ P11（全部完成后）
|
||||
```
|
||||
|
||||
> P5-A 交付管道和骨架后，P6/P8/P9 即可启动。
|
||||
> P5-B 的 Prompt 细化任务嵌入 P6-T4（应用4/5）和 P9-T1（应用3/6/7），不作为独立阶段。
|
||||
|
||||
可并行的 SPEC 组合：
|
||||
- P2 和 P3 可并行（无互相依赖）
|
||||
- P6、P7、P8、P9 在后端 API 就绪后可部分并行
|
||||
- P6、P7、P8、P9 在 P5-A 完成后可部分并行
|
||||
- P10 在 P1+P3 完成后即可启动，与 P4-P9 并行
|
||||
|
||||
@@ -14,15 +14,19 @@
|
||||
3. 作为租户管理员，我需要上传 Excel 数据（财务支出/团购收入/助教奖罚/充值业绩归属）。
|
||||
4. 作为租户管理员，上传 Excel 时如果发现主键冲突，我需要逐条确认替换或保留（类似 diff 交互）。
|
||||
5. 作为系统，租户管理员只能看到自己租户下的店铺数据。
|
||||
6. 作为租户管理员，我需要查看每个客户的所有维客线索，并对线索进行修改、删除、隐藏操作。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：租户管理后台是独立 Web 应用，独立登录入口
|
||||
- AC2：租户管理员只能看到自己租户下的店铺和用户
|
||||
- AC1.1：租户管理员账号由系统管理后台（`apps/admin-web/`）创建，租户管理员不可自行注册
|
||||
- AC2：租户管理员只能看到自己租户下的店铺和用户（由 Operator 分配的 `site_id` 列表决定）
|
||||
- AC3：用户审核页面：申请列表、状态筛选、球房ID+手机号关联建议（同时匹配助教表+员工信息表）、审核操作
|
||||
- AC4：Excel 上传校验：必填、金额精度、表头格式、类型合法
|
||||
- AC5：主键冲突时前端展示 diff 交互，逐条确认后保存
|
||||
- AC6：助教奖罚支持同一助教同月多笔
|
||||
- AC7：维客线索管理页面：按客户列出全部线索，展示标签（大类）、摘要、提供人、备注原文等字段
|
||||
- AC8：维客线索支持修改（编辑摘要/详情/标签）、删除（二次确认）、隐藏（不在小程序端展示但保留数据）操作
|
||||
|
||||
---
|
||||
|
||||
@@ -37,9 +41,11 @@
|
||||
### 登录体系
|
||||
|
||||
- 独立凭据：每个租户有若干管理员账号（用户名+密码）
|
||||
- 租户级管理员：可管理租户下所有店铺
|
||||
- 店铺级管理员：只能管理指定店铺
|
||||
- 与系统管理后台（`apps/admin-web/`）完全隔离
|
||||
- 账号由系统管理后台（`apps/admin-web/`）的 Operator 创建和管理（见 admin-web-console 需求 11），租户管理员不可自行注册
|
||||
- Operator 创建账号时指定：用户名、初始密码、所属租户、管辖球房 ID 列表（`site_id` 数组）
|
||||
- 租户级管理员：管辖该租户下所有店铺
|
||||
- 店铺级管理员：只能管理指定店铺（由 Operator 分配的 `site_id` 列表决定）
|
||||
- 与系统管理后台（`apps/admin-web/`）完全隔离，登录入口独立
|
||||
|
||||
### Excel 4 种模板
|
||||
|
||||
@@ -101,6 +107,33 @@
|
||||
→ 提交确认 → 后端按选择写入
|
||||
```
|
||||
|
||||
### 维客线索管理
|
||||
|
||||
#### 页面功能
|
||||
|
||||
- 客户搜索/筛选：按客户姓名、手机号搜索，按门店筛选
|
||||
- 线索列表：展示该客户的全部维客线索，字段包括：
|
||||
- 标签（大类枚举：客户基础/消费习惯/玩法偏好/促销接受/社交关系/重要反馈，与 P5 应用 8 输出一致）
|
||||
- 摘要
|
||||
- 详情
|
||||
- 提供人（recorded_by_name）
|
||||
- 来源（人工录入 `manual` / AI消费分析 `ai_consumption`（应用 3）/ AI备注分析 `ai_note`（应用 6），实际写入 `member_retention_clue` 的线索由应用 8 整合后统一落库）
|
||||
- 记录时间
|
||||
- 操作：
|
||||
- 修改：编辑标签、摘要、详情
|
||||
- 删除：二次确认后物理删除
|
||||
- 隐藏：设置 `is_hidden = true`，小程序端不展示但管理后台保留（需新增 `is_hidden` 字段，待后续 DB 变更时一并实现）
|
||||
|
||||
#### 数据源
|
||||
|
||||
- `zqyy_app.public.member_retention_clue`（已建）
|
||||
- 客户信息通过 FDW 读取 `dwd.dim_member`
|
||||
|
||||
#### 待实现的 DB 变更（SPEC 记录，暂不执行）
|
||||
|
||||
- `member_retention_clue` 新增 `is_hidden BOOLEAN DEFAULT false`：控制小程序端是否展示
|
||||
- `member_retention_clue` 新增 `source VARCHAR(20) DEFAULT 'manual'`：区分线索来源（`manual` 人工录入 / `ai_consumption` 应用 3 消费分析 / `ai_note` 应用 6 备注分析；应用 8 整合时保留原始 source）
|
||||
|
||||
### 新建表
|
||||
|
||||
```
|
||||
@@ -131,3 +164,5 @@ biz.excel_upload_log
|
||||
- [ ] T7：实现 Excel 上传前端（模板下载 + 上传 + diff 交互 + 确认）
|
||||
- [ ] T8：实现 4 种 Excel 模板的校验规则
|
||||
- [ ] T9：实现人员姓名+编号匹配校验（同时对照 `dim_assistant` 助教表和 `dim_staff` + `dim_staff_ex` 员工信息表）
|
||||
- [ ] T10：实现维客线索管理页面（客户搜索 + 线索列表 + 标签/摘要/提供人/备注原文展示）
|
||||
- [ ] T11：实现维客线索操作 API（修改/删除/隐藏）+ 后端路由扩展
|
||||
|
||||
@@ -34,8 +34,13 @@
|
||||
|
||||
### 助教订单流水四项统计
|
||||
- 新建 ETL 任务 `AssistantOrderContributionTask`
|
||||
- 粒度：`(site_id, assistant_id, stat_date)`
|
||||
- 计算逻辑见 PRD "新增统计"节
|
||||
- 粒度：`(site_id, assistant_id, stat_date)`，`stat_date` 为营业日（以 08:00 为日切点，08:00 前的记录归属前一天）
|
||||
- 完整算法与表结构见 `docs/database/BD_Manual_dws_assistant_order_contribution.md`
|
||||
- 数据来源（已校准，数据源：DWD-DOC 01-业务全景 + 02-账务全景）：
|
||||
- `dwd.dwd_settlement_head`：结算单信息，筛选 `settle_type IN (1, 3)`
|
||||
- `dwd.dwd_table_fee_log`：台桌使用时长、台费金额
|
||||
- `dwd.dwd_assistant_service_log`：助教服务时长、服务流水、分成
|
||||
- 消费金额口径：使用 `items_sum` 相关字段（table_charge_money + goods_money + assistant_pd_money + assistant_cx_money），不使用 `consume_money`
|
||||
|
||||
### 命名方案
|
||||
|
||||
|
||||
@@ -89,6 +89,19 @@ auth.user_assistant_binding
|
||||
|
||||
---
|
||||
|
||||
## 小程序前端开发强制规范
|
||||
|
||||
> 以下规范适用于本 SPEC 中所有小程序页面实现，具有强制约束力。
|
||||
|
||||
1. **原型图是唯一视觉真相**：`docs/h5_ui/pages/*.html` 中的结构、层次、元素、配色、间距、交互行为是小程序页面实现的唯一参考标准。任何偏离原型图的实现都需要明确的产品确认。
|
||||
2. **WXML ≠ HTML**：严禁在小程序中使用 HTML 标签（div/span/p/a/img 等），必须使用小程序原生标签（view/text/image/navigator 等）。
|
||||
3. **WXSS ≠ CSS**：使用 rpx 单位、仅支持有限选择器、无 DOM/BOM API、样式隔离机制不同。Tailwind CSS 类名必须手动转换为 WXSS。
|
||||
4. **TDesign 优先**：凡 TDesign 组件库能覆盖的 UI 元素，必须使用 TDesign 组件；自定义实现仅限 TDesign 无法覆盖的场景。
|
||||
5. **Power 文档优先**：实现前必须加载 `wechat-miniprogram` Power 的相关 steering 文件（`view-layer.md`、`tdesign.md`、`builtin-components.md`），确保语法和组件用法正确。
|
||||
6. **项目踩坑指南必读**：实现前必须阅读 `docs/prd/MIGRATION-PLAYBOOK.md` 第六章，该文档是基于本项目实际转换经验的避坑手册，涵盖 WXML/WXSS 差异、事件系统、TDesign 用法、rpx 换算规则及新页面开发 Checklist。
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `auth` Schema 下全部表（users, user_applications, site_code_mapping, user_site_roles, user_assistant_binding）
|
||||
|
||||
@@ -12,9 +12,10 @@
|
||||
1. 作为助教，我每天打开小程序能看到系统为我分配的任务列表，按优先级排序。
|
||||
2. 作为助教，我可以置顶/放弃任务，放弃时必须填写原因。
|
||||
3. 作为助教，我完成召回任务后（客户到店被服务），系统自动标记任务完成。
|
||||
4. 作为助教，我给客户添加回访备注后，系统自动评估备注含金量（≥6 分算完成）。
|
||||
5. 作为系统，回访任务至少保留 48 小时，到期后自动失效。
|
||||
6. 作为系统，当 ETL 数据延迟导致召回完成晚于备注提交时，需要回溯重分类备注。
|
||||
4. 作为助教，我给客户添加备注后，系统自动通过 AI 分析备注内容（应用 6），提取维客线索并评分。回访备注评分 ≥6 分算回访完成。
|
||||
5. 作为助教，我在添加备注时可以对客户进行星星评分（再次服务意愿、再来店可能性，各 1-5 星），回访任务默认展开评分区域，其他任务类型通过"展开评价"按钮手动打开。
|
||||
6. 作为系统，回访任务至少保留 48 小时，到期后自动失效。
|
||||
7. 作为系统，当 ETL 数据延迟导致召回完成晚于备注提交时，需要回溯重分类备注。
|
||||
|
||||
### 验收标准
|
||||
|
||||
@@ -23,9 +24,11 @@
|
||||
- AC3：回访任务 48 小时滞留机制正常（生成时间算起）
|
||||
- AC4：任务有效/无效状态 + 有效期字段正确流转
|
||||
- AC5：召回完成检测在 ETL 数据到达后自动触发
|
||||
- AC6：数据回溯将普通备注重分类为回访备注并触发 AI 评分
|
||||
- AC6：数据回溯将普通备注重分类为回访备注并触发 AI 备注分析
|
||||
- AC7：备注 CRUD 正常，type 字段正确区分
|
||||
- AC8：生日信息独立于 ETL 数据，不被覆盖
|
||||
- AC8：生日信息作为维客线索（客户基础信息类别）存储于 `member_retention_clue`，独立于 ETL 数据
|
||||
- AC9：备注星星评分（再次服务意愿、再来店可能性）正确存储，不参与完成判定，不参与应用 6 分析，仅作辅助数据
|
||||
- AC10：回访任务页面默认展开评分区域；其他任务类型默认隐藏，通过"展开评价"按钮手动打开（数据迟到场景：助教在召回任务中提前写备注+评分）
|
||||
|
||||
---
|
||||
|
||||
@@ -37,7 +40,7 @@
|
||||
|--------|------|---------|---------|
|
||||
| 0 | 高优先召回 | max(WBI,NCI) > 7 | 助教为该客户服务（ETL 检测） |
|
||||
| 0 | 优先召回 | max(WBI,NCI) > 5 | 同上 |
|
||||
| 1 | 客户回访 | 完成召回后未备注 | 提交备注且 AI 评分 ≥ 6 |
|
||||
| 1 | 客户回访 | 完成召回后未备注 | 提交备注且应用 6 备注分析评分 ≥ 6 |
|
||||
| 2 | 关系构建 | RS < 6 | 无自动完成条件（手动标记或指数变化） |
|
||||
|
||||
### 任务状态机
|
||||
@@ -68,6 +71,25 @@ biz.coach_tasks
|
||||
- created_at, updated_at
|
||||
```
|
||||
|
||||
### notes 表核心字段
|
||||
|
||||
```
|
||||
biz.notes
|
||||
- id, site_id, user_id, target_type, target_id
|
||||
- type (normal / follow_up / abandon_reason)
|
||||
- content (TEXT)
|
||||
- rating_service_willingness (SMALLINT 1-5, 可空，再次服务此客户意愿)
|
||||
- rating_revisit_likelihood (SMALLINT 1-5, 可空，再来店可能性)
|
||||
- task_id (关联任务 ID, 可空)
|
||||
- created_at, updated_at
|
||||
```
|
||||
|
||||
> 星星评分说明：
|
||||
> - 回访任务（follow_up_visit）：备注弹窗默认展开评分区域
|
||||
> - 其他任务类型：评分区域默认隐藏，通过"展开评价"按钮手动打开
|
||||
> - 数据迟到场景：助教在召回任务中完成服务后顺手写备注，此时 ETL 数据未到，任务仍为召回类型，评分区域隐藏但可手动展开；当 ETL 数据到达、召回完成检测触发后，回溯机制将该备注重分类为回访备注，星星评分数据一并保留
|
||||
> - 星星评分不参与回访完成判定（完成判定仅看应用 6 评分 ≥6），不参与应用 6 分析，仅作辅助数据存储，后期功能扩展使用
|
||||
|
||||
### 触发器机制
|
||||
|
||||
```
|
||||
@@ -91,12 +113,12 @@ biz.trigger_jobs
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：创建 `biz.coach_tasks` + `biz.coach_task_history` 表
|
||||
- [ ] T2：创建 `biz.notes` 表（type: normal/follow_up/birthday/abandon_reason）
|
||||
- [ ] T2：创建 `biz.notes` 表（type: normal/follow_up/abandon_reason，含 `rating_service_willingness` SMALLINT 1-5 可空、`rating_revisit_likelihood` SMALLINT 1-5 可空）
|
||||
- [ ] T3：创建 `biz.trigger_jobs` 表 + 轮询调度框架
|
||||
- [ ] T4：实现任务生成器（读取指数 → 分配任务 → 跳过/更新逻辑）
|
||||
- [ ] T5：实现 48 小时滞留机制 + 有效期轮询
|
||||
- [ ] T6：实现召回完成检测（ETL 数据到达后匹配 service_log）
|
||||
- [ ] T7：实现数据回溯机制（普通备注 → 回访备注 + 触发 AI 评分）
|
||||
- [ ] T7：实现数据回溯机制（普通备注 → 回访备注 + 触发 AI 备注分析）
|
||||
- [ ] T8：实现任务 CRUD API（列表/详情/置顶/放弃/取消置顶/取消放弃）
|
||||
- [ ] T9：实现备注 CRUD API（创建/列表/删除）
|
||||
- [ ] T10：实现生日信息隔离存储逻辑
|
||||
- [ ] T9：实现备注 CRUD API（创建/列表/删除，含星星评分字段的存储与读取）
|
||||
- [ ] T10：生日信息已迁移至维客线索系统（`member_retention_clue`），无需单独处理
|
||||
|
||||
@@ -2,6 +2,26 @@
|
||||
|
||||
> 优先级：P5（依赖 P3 + P4）
|
||||
> 预估工作量：大
|
||||
> 详细应用需求：#[[file:docs/prd/AI需求2.md]]
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 两阶段交付策略（2026-03-07 评审决定）
|
||||
|
||||
P5 的 8 个 AI 应用中，应用 3/4/5/6/7 的首条 Prompt JSON 结构包含占位符字段（`consumption_records`、`service_history`、`objective_data` 等），这些字段的具体结构取决于对应页面 API 的数据格式。在页面 API 未开发前，Prompt 结构无法确定，强行实现会导致"先猜后改"的浪费。
|
||||
|
||||
因此 P5 拆分为两个阶段：
|
||||
|
||||
### P5-A（当前阶段，P4 之后立即执行）
|
||||
交付"管道"：建表、百炼封装、缓存 API、SSE 框架，以及 Prompt 已完全确定的应用（应用 2、应用 8）。
|
||||
应用 3/4/5/6/7 只实现触发机制和调用骨架（Prompt 拼接函数留接口，用 TODO 标记）。
|
||||
|
||||
### P5-B（Prompt 细化，随页面 API 同步完成）
|
||||
各应用的 Prompt JSON 细化和拼接实现，分散到对应页面的开发任务中：
|
||||
- P6（task-detail）→ 细化应用 4/5 的 Prompt（服务记录结构确定后）
|
||||
- P9（customer-detail）→ 细化应用 3/6/7 的 Prompt（消费记录结构确定后）
|
||||
|
||||
详见各 spec 的对应任务。
|
||||
|
||||
---
|
||||
|
||||
@@ -10,34 +30,70 @@
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我可以在任意页面点击 AI 按钮，跳转到对话页面与 AI 交流，AI 了解当前页面上下文。
|
||||
2. 作为助教，我在任务详情页能看到 AI 生成的消费习惯分析、关系分析、话术参考。
|
||||
3. 作为助教，我提交回访备注后，系统自动通过 AI 评估备注含金量。
|
||||
2. 作为助教，我在任务详情页能看到 AI 生成的维客线索分析、关系分析、话术参考、客户分析。
|
||||
3. 作为助教，我提交备注后，系统自动通过 AI 分析备注内容，提取维客线索并评分。
|
||||
4. 作为管理者，我在财务看板能看到 AI 生成的财务洞察分析。
|
||||
5. 作为系统，所有 AI 对话（含系统调用）都要持久化记录。
|
||||
6. 作为系统，客户结账单出现后自动生成客户全量分析与运营建议。
|
||||
7. 作为系统，应用 3/应用 6 产出新线索后，自动整合去重生成统一维客线索。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 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）
|
||||
- AC2：应用 2 财务洞察每日自动更新，覆盖 8 个时间维度，返回结构化 JSON（序号+标题+正文）
|
||||
- AC3：应用 3 维客线索在客户新增消费时自动更新，返回 JSON 维客线索（分类标签限 3 个枚举：客户基础/消费习惯/玩法偏好），提供者统一为"系统"
|
||||
- AC4：应用 4 在助教参与新结算/优先召回任务分配/高优先召回任务分配时触发，读取应用 8 最新缓存
|
||||
- AC5：应用 5 联动应用 4，提供沟通话术
|
||||
- AC6：应用 6 在每个备注提交后自动分析，返回 JSON（评分 1-10 + 维客线索 0-N 条，分类标签 6 个枚举：客户基础/消费习惯/玩法偏好/促销偏好/社交关系/重要反馈），提供者为当前备注提供人
|
||||
- AC7：应用 7 在消费事件链中应用 8 完成后触发（串行），基于客户全量信息生成运营策略
|
||||
- AC8：应用 8 在应用 3 或应用 6 有新内容产生后立即触发，整合去重维客线索
|
||||
- AC9：所有 AI 调用记录持久化（conversation_id, message_id, app_id, user_id/系统, role, content, tokens_used, nickname, created_at, site_id）
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### 6 个 AI 应用
|
||||
### 8 个 AI 应用
|
||||
|
||||
| 应用 | 用途 | 调用方式 | 触发条件 |
|
||||
|------|------|---------|---------|
|
||||
| 应用 1 | 通用对话 | 用户主动（流式） | 点击 AI 入口 |
|
||||
| 应用 2 | 财务洞察 | 后台轮询 | 每日 |
|
||||
| 应用 3 | 消费习惯分析 | 后台轮询 | 客户新增消费 |
|
||||
| 应用 4 | 关系分析/任务建议 | 后台轮询 | 助教参与新结算 |
|
||||
| 应用 5 | 话术参考 | 后台联动 | 应用 4 调用时 |
|
||||
| 应用 6 | 备注含金量 | 后台事件 | 回访任务完成时 |
|
||||
| 应用 | 用途 | 调用方式 | 触发条件 | 返回格式 |
|
||||
|------|------|---------|---------|---------|
|
||||
| 应用 1 | 通用对话 | 用户主动（流式） | 点击 AI 入口 | SSE 流式文本 |
|
||||
| 应用 2 | 财务洞察 | 后台轮询 | 每日 | JSON（序号+标题+正文数组） |
|
||||
| 应用 3 | 客户数据维客线索分析 | 后台事件 | 客户新增消费 | JSON（线索数组：详情+标签+摘要+Emoji） |
|
||||
| 应用 4 | 关系分析/任务建议 | 后台事件 | 助教参与新结算 / 优先召回任务分配 / 高优先召回任务分配 | JSON（任务描述+行动建议数组+一句话总结） |
|
||||
| 应用 5 | 话术参考 | 后台联动 | 应用 4 调用时 | JSON（话术内容数组） |
|
||||
| 应用 6 | 备注分析 | 后台事件 | 每个备注提交时 | JSON（线索数组+评分） |
|
||||
| 应用 7 | 客户分析 | 后台事件 | 消费事件链：应用 8 完成后 | JSON（策略数组：标题+正文 + 总结） |
|
||||
| 应用 8 | 维客线索整理 | 后台联动 | 应用 3 或应用 6 有新内容时 | JSON（整合后线索数组：详情+标签+摘要+Emoji+提供者） |
|
||||
|
||||
### 调用链与时序
|
||||
|
||||
```
|
||||
消费事件（结账单）:
|
||||
└→ 应用 3（维客线索分析）→ 应用 8（线索整理）→ 应用 7（客户分析）
|
||||
（串行执行：应用 7 等待应用 8 完成后再启动，确保读到本次消费触发的最新线索）
|
||||
如果该结算单有助教参与:
|
||||
└→ 应用 4（关系分析，等待应用 8 完成后执行）→ 应用 5（话术参考）
|
||||
|
||||
备注提交事件:
|
||||
└→ 应用 6（备注分析）→ 应用 8（线索整理）
|
||||
|
||||
任务分配事件（优先召回/高优先召回）:
|
||||
└→ 应用 4（关系分析，读取应用 8 最新缓存）→ 应用 5（话术参考）
|
||||
```
|
||||
|
||||
- 消费事件链为严格串行：应用 3 → 应用 8 → 应用 7，保证应用 7 的 reference 中包含本次消费产生的最新线索
|
||||
- 应用 4 触发条件分两种场景：
|
||||
- 消费事件（有助教参与的新结算单）：等待应用 3 → 应用 8 完成后再执行，确保读到本次消费的最新线索
|
||||
- 任务分配事件（优先召回/高优先召回）：直接执行，读取应用 8 已有缓存
|
||||
- 应用 8 在应用 3 或应用 6 每次产出后立即触发
|
||||
- 应用 4 读取应用 8 缓存时，若缓存不存在（如新客户首次结算），reference 传空对象，Prompt 中标注"暂无历史线索"
|
||||
|
||||
### 应用分工说明
|
||||
|
||||
- 应用 3 vs 应用 6：应用 3 侧重客观数据分析（消费、到店频率等），应用 6 侧重主观备注分析（备注内容价值挖掘）
|
||||
- 应用 3 vs 应用 7：应用 3 侧重单次消费触发的线索提取，应用 7 侧重客户全量信息的全局运营策略
|
||||
- 应用 8：整合应用 3 + 应用 6 的线索，合并相似内容，保持最小改动原则
|
||||
|
||||
### 信息隔离
|
||||
|
||||
@@ -72,25 +128,389 @@ biz.ai_messages
|
||||
- created_at
|
||||
|
||||
biz.ai_cache
|
||||
- id, cache_type (app2_finance/app3_habit/app4_analysis/app5_tactics/app6_score)
|
||||
- id, cache_type (app2_finance / app3_clue / app4_analysis / app5_tactics / app6_note_analysis / app7_customer_analysis / app8_clue_consolidated)
|
||||
- site_id, target_id (member_id 或 assistant_id 或 pair)
|
||||
- result_json, score (应用6专用)
|
||||
- triggered_by (trigger_job_id)
|
||||
- created_at, expires_at
|
||||
```
|
||||
|
||||
### 应用 3 返回格式
|
||||
|
||||
应用 3 侧重客观数据，分类标签限 3 个枚举，提供者统一为"系统"：
|
||||
|
||||
```json
|
||||
{
|
||||
"clues": [
|
||||
{
|
||||
"category": "消费习惯",
|
||||
"summary": "偏好周末下午时段消费",
|
||||
"detail": "近3个月周末消费占比72%，分析过程...",
|
||||
"emoji": "📅"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- 分类标签枚举：客户基础 / 消费习惯 / 玩法偏好
|
||||
- 输入：客户近 3 个月消费数据（DWD+DWS 订单明细全维度）、会员卡明细、余额合计、应到店日期、到店间隔
|
||||
- 消费金额口径（已校准）：使用 `items_sum`（= table_charge_money + goods_money + assistant_pd_money + assistant_cx_money + electricity_money），不得使用 `consume_money`（三种历史口径混合，详见 DWD-DOC consume/consume-money-caliber.md）
|
||||
- 参考信息：应用 6 的线索结果 + 最近 2 套应用 8 的历史信息（附生成时间）
|
||||
|
||||
### 应用 6 返回格式
|
||||
|
||||
应用 6 侧重主观备注分析，分类标签 6 个枚举，提供者为当前备注提供人：
|
||||
|
||||
```json
|
||||
{
|
||||
"score": 7,
|
||||
"clues": [
|
||||
{
|
||||
"category": "社交关系",
|
||||
"summary": "常带朋友来消费",
|
||||
"detail": "备注提到经常约朋友周末来打球...",
|
||||
"emoji": "👥"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- 分类标签枚举：客户基础 / 消费习惯 / 玩法偏好 / 促销偏好 / 社交关系 / 重要反馈
|
||||
- 评分规则：6 分为标准分，重复信息/低价值/时效性低酌情扣分，高价值信息酌情加分
|
||||
- 输入：当前备注内容 + 客户消费数据 + 所有助教对该客户的全部备注
|
||||
- 参考信息：应用 3 的线索结果 + 最近 2 套应用 8 的历史信息（附生成时间）
|
||||
|
||||
### 应用 7 返回格式
|
||||
|
||||
```json
|
||||
{
|
||||
"strategies": [
|
||||
{
|
||||
"title": "高频消费但余额不足",
|
||||
"content": "客户近3个月消费12次但储值卡余额仅剩200元..."
|
||||
}
|
||||
],
|
||||
"summary": "该客户为高频活跃用户，建议重点维护储值续费..."
|
||||
}
|
||||
```
|
||||
|
||||
- 输入：客户全量客观数据 + 所有备注（标注创建者）
|
||||
- 消费金额口径（已校准）：同应用 3，使用 `items_sum` 而非 `consume_money`
|
||||
- 参考信息：最新 + 最近 2 套应用 8 的历史信息（附生成时间）
|
||||
- 主观信息需标注【来源：XXX，请甄别信息真实性】
|
||||
|
||||
### 应用 8 返回格式
|
||||
|
||||
```json
|
||||
{
|
||||
"clues": [
|
||||
{
|
||||
"category": "消费习惯",
|
||||
"summary": "偏好周末下午时段消费",
|
||||
"detail": "近3个月周末消费占比72%...",
|
||||
"emoji": "📅",
|
||||
"providers": "系统,张助教"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- 分类标签枚举：客户基础 / 消费习惯 / 玩法偏好 / 促销偏好 / 社交关系 / 重要反馈
|
||||
- 输入：当前最新应用 3 + 应用 6 的全部线索内容
|
||||
- 原则：合并相似线索（多提供者逗号分隔），其余原文返回，最小改动
|
||||
|
||||
### 首条 Prompt 数据结构（后端调用时拼接）
|
||||
|
||||
> 以下定义每个应用调用百炼 API 时，后端需要拼接的首条用户消息（user message）JSON 结构。
|
||||
> System Prompt 见 `docs/prd/ai-app-prompts.md`。
|
||||
> ⚠️ 占位标记（两阶段策略）：各应用的 `consumption_records`、`assistant_info`、`service_history` 等字段当前为字符串占位符。
|
||||
> P5-A 阶段只实现调用骨架，Prompt 拼接函数留接口。具体 JSON 子结构在以下阶段细化：
|
||||
> - 应用 4/5 的 `service_history`、`assistant_info` → P6-T4（task-detail 页面 API 开发时）
|
||||
> - 应用 3/6/7 的 `consumption_records`、`objective_data` → P9-T1（customer-detail 页面 API 开发时）
|
||||
|
||||
**通用规则（所有应用生效）：**
|
||||
- 所有首条 Prompt JSON 中统一加入 `"current_time": "2026-03-08 14:30:25"` 字段（精确到秒），让 AI 知道当前时间上下文
|
||||
- 所有 reference 中的参考资料必须标注生成时间（`generated_at` 字段），让 AI 判断信息时效性
|
||||
|
||||
#### 应用 1：通用对话
|
||||
|
||||
由前端发起，首条消息为页面上下文：
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"source_page": "来源页面标识（如 task-detail、board-finance）",
|
||||
"page_context": "页面上下文摘要（客户信息、任务信息等结构化文本）",
|
||||
"screen_content": "用户当前屏幕可见内容的文本化描述"
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 2：财务洞察
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 08:05:00",
|
||||
"site_id": 12345,
|
||||
"time_dimension": "本月",
|
||||
"date_range": {"start": "2026-03-01 08:00:00", "end": "2026-04-01 08:00:00"},
|
||||
"current_period": {
|
||||
"income_structure": {"table_fee": 0, "assistant_pd": 0, "assistant_cx": 0, "goods": 0, "recharge": 0},
|
||||
"prepaid_assets": {"total_balance": 0, "recharge_amount": 0, "consumption_deduction": 0},
|
||||
"expense_summary": {"rent": 0, "utilities": 0, "supplies": 0, "salary": 0, "other": 0},
|
||||
"platform_settlement": {"groupbuy_income": 0, "platform_fee": 0, "net_income": 0}
|
||||
},
|
||||
"previous_period": {
|
||||
"time_dimension": "上月",
|
||||
"date_range": {"start": "2026-02-01 08:00:00", "end": "2026-03-01 08:00:00"},
|
||||
"income_structure": {},
|
||||
"prepaid_assets": {},
|
||||
"expense_summary": {},
|
||||
"platform_settlement": {}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- 8 个时间维度：本月/上月/本周/上周/前3月不含本月/本季/上季/近6月不含本月
|
||||
- 营业日分界点 08:00
|
||||
- 收入结构字段映射（已校准，数据源：DWD-DOC 03-财务全景）：`table_fee` = `table_charge_money`（56.6%）、`assistant_pd` = `assistant_pd_money`（30.6%）、`assistant_cx` = `assistant_cx_money`（0.9%）、`goods` = `goods_money`（10.1%）、`recharge` = 充值 pay_amount（settle_type=5）
|
||||
- `electricity_money` 全为 0（门店未启用灯控），不纳入收入结构
|
||||
|
||||
#### 应用 3：客户数据维客线索分析
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"member_nickname": "客户昵称",
|
||||
"main_data": {
|
||||
"consumption_records": "近3个月消费数据（DWD+DWS 订单明细：台费、充值、助教消费等全维度）",
|
||||
"member_cards": "名下会员卡明细",
|
||||
"card_balance_total": 0,
|
||||
"stored_value_balance_total": 0,
|
||||
"expected_visit_date": "2026-03-10",
|
||||
"days_since_last_visit": 15
|
||||
},
|
||||
"reference": {
|
||||
"app6_clues": "应用6的线索结果（如有）",
|
||||
"app8_history": [
|
||||
{"generated_at": "2026-03-01", "clues": "最近第1套应用8结果"},
|
||||
{"generated_at": "2026-02-15", "clues": "最近第2套应用8结果"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 4：关系分析 / 任务建议
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"assistant_info": "助教基本信息（花名、级别、工龄等）",
|
||||
"service_history": "助教服务该客户的历史记录",
|
||||
"task_assignment_basis": "任务分配的依据（新结算/优先召回/高优先召回）",
|
||||
"customer_data": {
|
||||
"system_data": "客户近3个月消费数据（同应用3的 main_data 结构）",
|
||||
"notes": [
|
||||
{"recorded_by": "备注创建者", "content": "备注全文", "created_at": "时间"}
|
||||
]
|
||||
},
|
||||
"reference": {
|
||||
"app8_current": "当前最新维客线索（应用8结果）",
|
||||
"app8_history": [
|
||||
{"generated_at": "2026-03-01", "clues": "最近第1套应用8结果"},
|
||||
{"generated_at": "2026-02-15", "clues": "最近第2套应用8结果"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 5：话术参考
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"assistant_info": "助教基本信息",
|
||||
"service_history": "助教服务该客户的历史记录",
|
||||
"task_assignment_basis": "任务分配的依据",
|
||||
"customer_data": {
|
||||
"system_data": "客户近3个月消费数据（同应用3的 main_data 结构）",
|
||||
"notes": [
|
||||
{"recorded_by": "备注创建者", "content": "备注全文", "created_at": "时间"}
|
||||
]
|
||||
},
|
||||
"task_suggestion": "本次任务建议（应用4返回的完整结果）",
|
||||
"reference": {
|
||||
"app8_history": [
|
||||
{"generated_at": "2026-03-01", "clues": "最近第1套应用8结果"},
|
||||
{"generated_at": "2026-02-15", "clues": "最近第2套应用8结果"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 6：备注分析
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"current_note": {
|
||||
"content": "本次提交的备注内容",
|
||||
"recorded_by": "备注创建者",
|
||||
"created_at": "提交时间"
|
||||
},
|
||||
"reference": {
|
||||
"member_nickname": "客户昵称",
|
||||
"consumption_data": "客户近3个月消费数据（同应用3的 main_data 结构）",
|
||||
"all_notes": [
|
||||
{"recorded_by": "创建者", "content": "备注全文", "created_at": "时间"}
|
||||
],
|
||||
"app3_clues": "应用3的线索结果（如有）",
|
||||
"app8_history": [
|
||||
{"generated_at": "2026-03-01", "clues": "最近第1套应用8结果"},
|
||||
{"generated_at": "2026-02-15", "clues": "最近第2套应用8结果"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 7：客户分析
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"member_id": 12345,
|
||||
"member_nickname": "客户昵称",
|
||||
"objective_data": "客户近3个月消费数据（同应用3的 main_data 结构）",
|
||||
"subjective_data": {
|
||||
"notes": [
|
||||
{"recorded_by": "创建者", "content": "备注全文", "created_at": "时间"}
|
||||
]
|
||||
},
|
||||
"reference": {
|
||||
"app8_current": "最新维客线索（应用8结果）",
|
||||
"app8_history": [
|
||||
{"generated_at": "2026-03-01", "clues": "最近第1套应用8结果"},
|
||||
{"generated_at": "2026-02-15", "clues": "最近第2套应用8结果"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 应用 8：维客线索整理
|
||||
|
||||
```json
|
||||
{
|
||||
"current_time": "2026-03-08 14:30:25",
|
||||
"app3_clues": {
|
||||
"generated_at": "2026-03-05 14:30:00",
|
||||
"clues": [
|
||||
{"detail": "...", "category": "消费习惯", "summary": "...", "emoji": "📅"}
|
||||
]
|
||||
},
|
||||
"app6_clues": {
|
||||
"generated_at": "2026-03-05 14:25:00",
|
||||
"clues": [
|
||||
{"category": "社交关系", "emoji": "👥", "detail": "...", "summary": "..."}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 数据写入规则
|
||||
|
||||
- 应用 1：流式返回完成后，将完整的 assistant 回复写入 `ai_messages`（role=assistant），用户消息在发送时即写入（role=user）
|
||||
- 应用 3/6 的线索产出后，先写入 `ai_cache`，再触发应用 8
|
||||
- 应用 8 整合后的线索**全量替换**该客户在 `member_retention_clue` 中的所有 AI 来源线索（`source IN ('ai_consumption', 'ai_note')`），人工线索（`source='manual'`）不受影响。全量替换合理性：应用 8 输入包含应用 3 + 应用 6 的全部线索，AI 整合时会保留重要内容，输出即为该客户的完整 AI 线索集
|
||||
- 应用 2/4/5/7 的结果写入 `ai_cache`，供前端读取
|
||||
- 所有 AI 调用记录写入 `ai_conversations` + `ai_messages`（含 tokens_used 统计）
|
||||
|
||||
### 应用 8 → member_retention_clue 字段映射
|
||||
|
||||
应用 8 返回的每条线索写入 `member_retention_clue` 时，字段映射如下：
|
||||
|
||||
| 应用 8 返回字段 | member_retention_clue 列 | 说明 |
|
||||
|----------------|-------------------------|------|
|
||||
| `category` | `category` | 直接映射，枚举值必须与 DDL CHECK 约束一致（6 个值） |
|
||||
| `emoji` + `summary` | `summary` | emoji 拼接在 summary 前面存储，如 `📅 偏好周末下午时段消费`，前端直接读取展示 |
|
||||
| `detail` | `detail` | 直接映射 |
|
||||
| `providers` | `recorded_by_name` | 多提供者逗号分隔，如 `系统,张助教` |
|
||||
| — | `recorded_by_assistant_id` | 系统触发时填 NULL |
|
||||
| — | `source` | 根据线索来源判断：纯应用 3 产出 → `ai_consumption`，纯应用 6 产出 → `ai_note`，混合来源 → `ai_consumption`（以客观数据为主） |
|
||||
| — | `member_id` | 从触发上下文获取 |
|
||||
| — | `site_id` | 从触发上下文获取 |
|
||||
| — | `recorded_at` | 写入时间 NOW() |
|
||||
|
||||
### ai_cache 数据保留策略
|
||||
|
||||
- 应用 1（通用对话）：对话记录保留在 `ai_conversations` + `ai_messages` 中，无条数限制（按需清理）
|
||||
- 应用 2-8：每个 `(cache_type, site_id, target_id)` 组合保留最近 500 条记录，超过时删除最旧的
|
||||
- 清理时机：每次写入新记录后，异步检查并清理超限记录
|
||||
|
||||
### ai_cache target_id 约定
|
||||
|
||||
| 应用 | cache_type | target_id 含义 | 示例 |
|
||||
|------|-----------|---------------|------|
|
||||
| 应用 2 | app2_finance | 时间维度编码 | `this_month`、`last_week`、`last_3_months` 等 |
|
||||
| 应用 3 | app3_clue | member_id | `12345` |
|
||||
| 应用 4 | app4_analysis | `{assistant_id}_{member_id}` | `100_12345` |
|
||||
| 应用 5 | app5_tactics | `{assistant_id}_{member_id}` | `100_12345` |
|
||||
| 应用 6 | app6_note_analysis | member_id | `12345` |
|
||||
| 应用 7 | app7_customer_analysis | member_id | `12345` |
|
||||
| 应用 8 | app8_clue_consolidated | member_id | `12345` |
|
||||
|
||||
应用 2 的 8 个时间维度编码：`this_month` / `last_month` / `this_week` / `last_week` / `last_3_months` / `this_quarter` / `last_quarter` / `last_6_months`
|
||||
|
||||
### 应用 2 调度机制
|
||||
|
||||
- 调度方式：ETL 调度器中的调度任务，在每日 08:00（营业日切点）后的首次任务执行时触发
|
||||
- 执行逻辑：DWS 日更数据更新完成后，依次对 8 个时间维度发起独立调用（共 8 次百炼 API 调用）
|
||||
- 每次调用生成一条 `ai_cache` 记录，`target_id` 为时间维度编码
|
||||
- 如果 ETL 调度器中尚无此调度逻辑，需在 P5-A 阶段补充
|
||||
|
||||
### 应用 1 对话历史管理
|
||||
|
||||
- 每次从任意页面进入 chat 页面时，始终新建对话（`ai_conversations` 新增一行），不复用已有对话
|
||||
- 历史对话列表按时间倒序展示，20 条/页懒加载
|
||||
- 暂不支持删除对话
|
||||
|
||||
### 前端消费方式
|
||||
|
||||
| 应用 | 前端展示位置 | 数据来源 | 展示说明 |
|
||||
|------|-------------|---------|---------|
|
||||
| 应用 1 | chat 页面 | SSE 流式 + `ai_messages` | 实时对话，历史记录从 ai_messages 读取 |
|
||||
| 应用 2 | board-finance 财务看板 | `ai_cache`（cache_type=app2_finance） | JSON 数组渲染为洞察卡片（序号+标题+正文） |
|
||||
| 应用 3 | 不直接展示 | `ai_cache`（cache_type=app3_clue） | 作为基础资料供应用 8 整合，不在页面显示 |
|
||||
| 应用 4 | task-detail 任务详情页 | `ai_cache`（cache_type=app4_analysis） | 展示任务描述+行动建议+一句话总结；`summary` 摘要同时在 task-list 任务卡片中显示 |
|
||||
| 应用 5 | task-detail 任务详情页 | `ai_cache`（cache_type=app5_tactics） | 展示话术参考列表 |
|
||||
| 应用 6 | task-detail 备注卡片 | `ai_cache`（cache_type=app6_note_analysis） | `score` 以打星方式呈现在备注卡片上；线索部分不直接展示，作为基础资料供应用 8 整合 |
|
||||
| 应用 7 | customer-detail 客户详情页 | `ai_cache`（cache_type=app7_customer_analysis） | 展示运营策略数组+总结 |
|
||||
| 应用 8 | customer-detail + task-detail | `member_retention_clue` 表 | 展示整合后的维客线索（Emoji+标签+摘要+详情）；task-detail 中提供者显示为"By:系统"或"By:备注"（不显示具体人名） |
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] 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）
|
||||
### P5-A 阶段（当前执行，Prompt 已确定 + 调用骨架）
|
||||
|
||||
- [ ] T1：创建 `biz.ai_conversations` + `biz.ai_messages` + `biz.ai_cache` 表（cache_type 扩展 app7/app8）
|
||||
- [ ] T2：实现百炼 API 统一封装层（流式/非流式、重试、日志、JSON 输出模式）
|
||||
- [ ] T3：实现应用 1 通用对话 API（SSE 流式返回，上下文注入框架先搭建，页面文本化工具留接口）
|
||||
- [ ] T5：实现应用 2 财务洞察轮询任务（Prompt 已完全确定，JSON 输出：序号+标题+正文）
|
||||
- [ ] T6-骨架：实现应用 3 触发机制 + 调用框架（Prompt 拼接函数留接口，`consumption_records` 等字段待 P9-T1 细化）
|
||||
- [ ] T7-骨架：实现应用 4 触发机制 + 调用框架（Prompt 拼接函数留接口，`service_history` 等字段待 P6-T4 细化）
|
||||
- [ ] T8-骨架：实现应用 5 联动框架（Prompt 拼接函数留接口，随应用 4 同步细化）
|
||||
- [ ] T9-骨架：实现应用 6 触发机制 + 调用框架（Prompt 拼接函数留接口，`consumption_data` 等字段待 P9-T1 细化）
|
||||
- [ ] T10-骨架：实现应用 7 触发机制 + 调用框架（Prompt 拼接函数留接口，`objective_data` 等字段待 P9-T1 细化）
|
||||
- [ ] T11：实现应用 8 维客线索整理（Prompt 已完全确定，应用 3/6 产出后触发，合并去重→写入 member_retention_clue）
|
||||
- [ ] T12：实现 AI 缓存读写 API（前端读取缓存结果）
|
||||
- [ ] T13：查阅百炼文档确认流式返回技术方案（SSE vs WebSocket）及 JSON 输出最佳实践
|
||||
|
||||
### P5-B 阶段（Prompt 细化，分散到对应页面 spec）
|
||||
|
||||
以下任务不在 P5 中独立执行，而是嵌入对应页面的开发任务：
|
||||
|
||||
- [ ] T4：实现页面内容文本化工具（各页面数据 → AI 可读文本）→ 随 P6-P9 各页面逐步实现
|
||||
- [ ] T6-完整：应用 3 Prompt JSON 细化 + 拼接实现 → 在 P9-T1（customer-detail API）中完成
|
||||
- [ ] T7-完整：应用 4 Prompt JSON 细化 + 拼接实现 → 在 P6-T4（task-detail API）中完成
|
||||
- [ ] T8-完整：应用 5 Prompt JSON 细化 + 拼接实现 → 在 P6-T4（task-detail API）中完成
|
||||
- [ ] T9-完整：应用 6 Prompt JSON 细化 + 拼接实现 → 在 P9-T1（customer-detail API）中完成
|
||||
- [ ] T10-完整：应用 7 Prompt JSON 细化 + 拼接实现 → 在 P9-T1（customer-detail API）中完成
|
||||
|
||||
100
docs/prd/specs/P5.1-mcp-server-ai-extension.md
Normal file
100
docs/prd/specs/P5.1-mcp-server-ai-extension.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# P5.1：MCP Server AI 扩展 — mcp-server-ai-extension
|
||||
|
||||
> 优先级：P5.1（分批执行，见下方阶段说明）
|
||||
> 预估工作量：中等
|
||||
> 前置条件：ETL 数据全景文档 ✅ 已完成（`docs/reports/DWD-DOC/`，2026-03-06）、P5 AI 集成层 spec 确定
|
||||
|
||||
---
|
||||
|
||||
## 分批执行策略（2026-03-07 评审决定）
|
||||
|
||||
P5.1 的任务按依赖成熟度分三批：
|
||||
|
||||
### 批次 A：立即可执行（无前置依赖）
|
||||
- T4：重写 MCP 查库手册 — ETL 库部分（DWD-DOC 已完成，DWS 34 张表全字段）
|
||||
|
||||
### 批次 B：P5-A 之后（需 biz 表存在）
|
||||
- T1：MCP Server 新增 `zqyy_app` 数据库连接池
|
||||
- T2：扩展 MCP 工具支持多数据库路由
|
||||
- T3：实现 `zqyy_app` 敏感字段脱敏策略
|
||||
- T5：重写 MCP 查库手册 — 业务库部分（auth/biz/public 全字段）
|
||||
- T6：补充常用查询模式
|
||||
|
||||
### 批次 C：批次 B 完成后
|
||||
- T7：手册上传百炼平台并验证 AI 应用引用效果
|
||||
|
||||
---
|
||||
|
||||
## 需求（Requirements）
|
||||
|
||||
### 用户故事
|
||||
|
||||
1. 作为 AI 应用（应用 1 通用对话），我需要通过 MCP 工具查询 `etl_feiqiu` 数据仓库，获取会员、订单、助教、财务等运营数据。
|
||||
2. 作为 AI 应用（应用 1 通用对话），我需要通过 MCP 工具查询 `zqyy_app` 业务库，获取备注、任务、维客线索、AI 缓存等业务数据。
|
||||
3. 作为系统，MCP Server 需要提供完整的数据库查询手册，供百炼平台 AI 应用作为知识库引用。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：MCP Server 支持同时连接 `etl_feiqiu`（ETL 六层 Schema）和 `zqyy_app`（auth/biz/public Schema）
|
||||
- AC2：`zqyy_app` 连接仅允许只读查询（SELECT），与 `etl_feiqiu` 相同的安全限制
|
||||
- AC3：MCP 查库手册覆盖所有可查询表的完整字段说明（每张表列出全部字段）
|
||||
- AC4：手册上传百炼平台后，AI 应用可直接参考手册进行查询，无需频繁调用 describe_table
|
||||
|
||||
---
|
||||
|
||||
## 设计要点
|
||||
|
||||
### MCP Server 扩展
|
||||
|
||||
当前 MCP Server（`apps/mcp-server/`）仅连接 `etl_feiqiu` 库。需要扩展：
|
||||
|
||||
1. **新增 `zqyy_app` 数据库连接**
|
||||
- 使用 `APP_DB_DSN` 环境变量（已在根 `.env` 定义）
|
||||
- 只读连接，与 `etl_feiqiu` 相同的安全策略
|
||||
- 可访问 Schema：`auth`、`biz`、`public`
|
||||
|
||||
2. **工具扩展**
|
||||
- 现有 4 个工具（list_tables、describe_table、describe_schemas、query_sql）需支持指定目标数据库
|
||||
- 新增参数 `database`（可选，默认 `etl_feiqiu`，可选 `zqyy_app`）
|
||||
- 或通过 schema 名称自动路由（`ods/dwd/dws/core/meta/app` → etl_feiqiu，`auth/biz/public` → zqyy_app）
|
||||
|
||||
3. **权限控制**
|
||||
- `zqyy_app` 的 `auth` schema 中敏感字段（如 `wx_openid`、`phone`）需要在查询结果中脱敏或限制访问
|
||||
- `biz` schema 的 `ai_messages.content` 字段包含对话内容，需考虑隐私保护
|
||||
|
||||
### MCP 查库手册重写
|
||||
|
||||
当前手册：`docs/mcp/AI-DATABASE-QUERY-MANUAL.md`
|
||||
|
||||
> **数据字段权威参考**：手册中涉及的 DWD/DWS 层字段来源、金额口径、业务逻辑，
|
||||
> 以 `docs/reports/DWD-DOC/` 校准文档为准（数据快照 2026-03-06）。
|
||||
> 核心规则：
|
||||
> - `consume_money` 存在三种历史口径混合，不可直接使用；应使用 `items_sum`（= table_charge_money + goods_money + assistant_pd_money + assistant_cx_money + electricity_money）
|
||||
> - 收入结构拆分为台桌费、陪打费、超休费、商品费、电费五项，不使用笼统的 `service_fee`
|
||||
> - settle_type 映射：1=台桌结账(78.6%)、3=商城订单(21.4%)、5=充值、7=充值退款、6=结算退款
|
||||
> - 详见 [consume_money 口径说明](../reports/DWD-DOC/consume/consume-money-caliber.md)、[财务全景](../reports/DWD-DOC/03-financial-panorama.md)、[业务全景](../reports/DWD-DOC/01-business-panorama.md)
|
||||
|
||||
重写范围：
|
||||
- **保留**：架构流程、六层 Schema 概览、4 个 MCP 工具详解
|
||||
- **补充**：DWS 层完整表清单（34 张表按业务域分组，每表全部字段）
|
||||
- **新增**：`zqyy_app` 业务库表结构（biz.notes、biz.coach_tasks、biz.member_retention_clue、biz.ai_cache 等）
|
||||
- **新增**：常用查询模式（维客线索、任务系统、备注、AI 缓存）
|
||||
- **新增**：金额口径说明章节（consume_money 不可用、items_sum 定义、settle_type 映射表）
|
||||
- **优化**：补充表的最新数据量统计、查询性能建议
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
### 批次 A — 立即可执行
|
||||
- [ ] T4：重写 MCP 查库手册 — ETL 库部分（DWD/DWS 全字段，基于 DWD-DOC 标杆文档）
|
||||
|
||||
### 批次 B — P5-A 之后（依赖 P1 + P4 + P5-A，biz 表已建）
|
||||
- [ ] T1：MCP Server 新增 `zqyy_app` 数据库连接池（使用 `APP_DB_DSN`）
|
||||
- [ ] T2：扩展 MCP 工具支持多数据库路由（按 schema 名称自动选择连接）
|
||||
- [ ] T3：实现 `zqyy_app` 敏感字段脱敏策略
|
||||
- [ ] T5：重写 MCP 查库手册 — 业务库部分（auth/biz/public 全字段）
|
||||
- [ ] T6：补充常用查询模式（维客线索、任务、备注、AI 缓存）
|
||||
|
||||
### 批次 C — 批次 B 完成后
|
||||
- [ ] T7：手册上传百炼平台并验证 AI 应用引用效果
|
||||
@@ -1,7 +1,8 @@
|
||||
# P6：小程序前端 — 任务模块 — miniapp-fe-tasks
|
||||
|
||||
> 优先级：P6（依赖 P3 + P4 + P5）
|
||||
> 优先级：P6（依赖 P3 + P4 + P5-A）
|
||||
> 预估工作量：大
|
||||
> P5-B 承接：T4 同时细化 P5 应用 4/5 的 Prompt JSON 结构
|
||||
|
||||
---
|
||||
|
||||
@@ -24,6 +25,9 @@
|
||||
- AC5：跟/弃 icon 正确展示
|
||||
- AC6：当月数据显示"预估"标记
|
||||
- AC7：跳档激励"到达XXX即得YYY"计算正确
|
||||
- AC8：任务卡片展示应用 4 的一句话总结（ai_cache 缓存读取）
|
||||
- AC9：备注卡片以打星方式展示应用 6 评分（1-10 分，映射公式：`星数 = score ÷ 2`，5 颗星，支持半星；如 score=7 → 3.5 星）
|
||||
- AC10：维客线索提供者按 source 字段显示"By:系统"或"By:备注"，不显示具体人名
|
||||
|
||||
---
|
||||
|
||||
@@ -31,14 +35,22 @@
|
||||
|
||||
### task-list（任务列表 + 绩效）
|
||||
- 任务列表：优先级分组、长按操作
|
||||
- 任务卡片：展示应用 4 的 `summary`（一句话总结）作为 AI 摘要（从 `ai_cache` cache_type=app4_analysis 读取）
|
||||
- 绩效区域：当月业绩/档位/工资/跳档激励
|
||||
- 通用组件：爱心 icon、喜好标签、跟/弃 icon
|
||||
|
||||
### task-detail（任务详情）
|
||||
- 客户信息卡片
|
||||
- 近期服务记录（时间+时长）
|
||||
- AI 区域：消费习惯（应用3缓存）、关系分析+任务建议+一句话总结（应用4缓存）、话术参考（应用5缓存）、备注星级（应用6）
|
||||
- 备注入口（提交后触发回访完成判定）
|
||||
- AI 区域：
|
||||
- 维客线索（应用 8 整合线索 + 人工，读取 `member_retention_clue`；Emoji 作为二级标签、提供者逗号分隔展示）
|
||||
- 客户分析（应用 7 缓存：运营策略数组 + 总结）
|
||||
- 关系分析 + 任务建议 + 一句话总结（应用 4 缓存，读取应用 8 最新线索）
|
||||
- 话术参考（应用 5 缓存）
|
||||
- 备注分析评分（应用 6 缓存：1-10 分）
|
||||
- 备注入口（提交后触发回访完成判定）；备注弹窗含星星评分（再次服务意愿+再来店可能性，各 1-5 星）：回访任务默认展开评分区域，其他任务类型默认隐藏通过"展开评价"按钮手动打开
|
||||
- 备注卡片展示应用 6 的 `score`（1-10 分），以打星方式呈现（`星数 = score ÷ 2`，5 颗星，支持半星；从 `ai_cache` cache_type=app6_note_analysis 读取）
|
||||
- 维客线索（应用 8）提供者显示规则：`source=ai_consumption` 显示"By:系统"，`source=ai_note` 显示"By:备注"，不显示具体人名
|
||||
- "问问助手"按钮 → chat.html
|
||||
|
||||
### notes（备注管理）
|
||||
@@ -47,12 +59,27 @@
|
||||
|
||||
---
|
||||
|
||||
## 小程序前端开发强制规范
|
||||
|
||||
> 以下规范适用于本 SPEC 中所有小程序页面实现，具有强制约束力。
|
||||
|
||||
1. **原型图是唯一视觉真相**：`docs/h5_ui/pages/*.html` 中的结构、层次、元素、配色、间距、交互行为是小程序页面实现的唯一参考标准。任何偏离原型图的实现都需要明确的产品确认。
|
||||
2. **WXML ≠ HTML**：严禁在小程序中使用 HTML 标签（div/span/p/a/img 等），必须使用小程序原生标签（view/text/image/navigator 等）。
|
||||
3. **WXSS ≠ CSS**：使用 rpx 单位、仅支持有限选择器、无 DOM/BOM API、样式隔离机制不同。Tailwind CSS 类名必须手动转换为 WXSS。
|
||||
4. **TDesign 优先**：凡 TDesign 组件库能覆盖的 UI 元素，必须使用 TDesign 组件；自定义实现仅限 TDesign 无法覆盖的场景。
|
||||
5. **Power 文档优先**：实现前必须加载 `wechat-miniprogram` Power 的相关 steering 文件（`view-layer.md`、`tdesign.md`、`builtin-components.md`），确保语法和组件用法正确。
|
||||
6. **项目踩坑指南必读**：实现前必须阅读 `docs/prd/MIGRATION-PLAYBOOK.md` 第六章，该文档是基于本项目实际转换经验的避坑手册，涵盖 WXML/WXSS 差异、事件系统、TDesign 用法、rpx 换算规则及新页面开发 Checklist。
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现 task-list 页面（任务列表 + 分组 + 排序）
|
||||
- [ ] T2：实现长按操作（置顶/放弃/AI）
|
||||
- [ ] T3：实现绩效展示区域（业绩/档位/工资/跳档激励）
|
||||
- [ ] T4：实现 task-detail 页面（客户信息 + 服务记录 + AI 区域）
|
||||
- [ ] T5：实现备注提交功能（集成回访完成判定）
|
||||
- T4-a：细化 P5 应用 4（关系分析）Prompt JSON 结构，实现 `service_history`、`assistant_info` 等字段的拼接函数（对应 P5-T7-完整）
|
||||
- T4-b：细化 P5 应用 5（话术参考）Prompt JSON 结构，实现拼接函数（对应 P5-T8-完整）
|
||||
- [ ] T5：实现备注提交功能（集成回访完成判定 + 星星评分：回访任务默认展开，其他任务类型通过"展开评价"按钮手动打开）
|
||||
- [ ] T6：实现 notes 页面（列表 + 删除）
|
||||
- [ ] T7：实现通用组件（爱心 icon、喜好标签、跟/弃 icon、预估标记）
|
||||
|
||||
@@ -10,14 +10,14 @@
|
||||
### 用户故事
|
||||
|
||||
1. 作为助教，我在绩效页面能看到当月收入、业绩档位、工资预估。
|
||||
2. 作为助教，我能看到本月/上月的服务记录明细，按天归总。
|
||||
2. 作为助教，我能看到本月/上月的服务记录明细，按天归总。（营业日以 08:00 为分割点，如"本月"= 当月1日 08:00 ~ 次月1日 08:00）
|
||||
3. 作为助教，我能看到"我的新客"（首次服务且 2 月内服务 ≤2 次的客户）和"我的常客"（2 月内服务次数最多的客户）。
|
||||
4. 作为助教，我在业绩明细页能看到每条服务的详情，包括定档折算惩罚展示。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- AC1：收入与业绩档位数据从 `dws_assistant_salary_calc` 正确读取
|
||||
- AC2：服务记录按天归总展示，支持本月/上月切换
|
||||
- AC2：服务记录按天归总展示，支持本月/上月切换（营业日以 08:00 为分割点）
|
||||
- AC3："我的新客"筛选逻辑正确（该助教首次服务 + 2 月内 + 服务次数 ≤2）
|
||||
- AC4："我的常客"按服务次数降序，展示次数、小时数、工资合计
|
||||
- AC5：业绩明细每条展示：结账时间、课程类型、台桌/房间、会员昵称、开始/结束时间、业绩分钟
|
||||
@@ -31,14 +31,14 @@
|
||||
### performance（我的绩效）
|
||||
|
||||
- 收入与业绩档位卡片
|
||||
- 服务记录明细（按天归总，本月/上月切换）
|
||||
- 服务记录明细（按天归总，本月/上月切换；营业日以 08:00 为分割点）
|
||||
- 我的新客列表（按最后服务时间排列）
|
||||
- 我的常客列表（按服务次数降序）
|
||||
- 服务明细：按天/月归总整合数据
|
||||
|
||||
### performance-records（业绩明细）
|
||||
|
||||
- 口径选择（本月/上月/本周/上周等）
|
||||
- 口径选择（本月/上月/本周/上周等；营业日以 08:00 为分割点，如"本月"= 当月1日 08:00 ~ 次月1日 08:00）
|
||||
- 业绩列表（每条含：结账时间、课程类型、台桌/房间、会员昵称、开始/结束时间、业绩分钟+折算展示）
|
||||
- 按天/月归总整合
|
||||
|
||||
@@ -56,6 +56,19 @@
|
||||
|
||||
---
|
||||
|
||||
## 小程序前端开发强制规范
|
||||
|
||||
> 以下规范适用于本 SPEC 中所有小程序页面实现，具有强制约束力。
|
||||
|
||||
1. **原型图是唯一视觉真相**：`docs/h5_ui/pages/*.html` 中的结构、层次、元素、配色、间距、交互行为是小程序页面实现的唯一参考标准。任何偏离原型图的实现都需要明确的产品确认。
|
||||
2. **WXML ≠ HTML**：严禁在小程序中使用 HTML 标签（div/span/p/a/img 等），必须使用小程序原生标签（view/text/image/navigator 等）。
|
||||
3. **WXSS ≠ CSS**：使用 rpx 单位、仅支持有限选择器、无 DOM/BOM API、样式隔离机制不同。Tailwind CSS 类名必须手动转换为 WXSS。
|
||||
4. **TDesign 优先**：凡 TDesign 组件库能覆盖的 UI 元素，必须使用 TDesign 组件；自定义实现仅限 TDesign 无法覆盖的场景。
|
||||
5. **Power 文档优先**：实现前必须加载 `wechat-miniprogram` Power 的相关 steering 文件（`view-layer.md`、`tdesign.md`、`builtin-components.md`），确保语法和组件用法正确。
|
||||
6. **项目踩坑指南必读**：实现前必须阅读 `docs/prd/MIGRATION-PLAYBOOK.md` 第六章，该文档是基于本项目实际转换经验的避坑手册，涵盖 WXML/WXSS 差异、事件系统、TDesign 用法、rpx 换算规则及新页面开发 Checklist。
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现绩效汇总 API（含定档、工资、档位）
|
||||
@@ -64,4 +77,4 @@
|
||||
- [ ] T4：实现业绩明细 API（含定档折算惩罚字段）
|
||||
- [ ] T5：实现 performance 小程序页面
|
||||
- [ ] T6：实现 performance-records 小程序页面
|
||||
- [ ] T7：实现"预估"标记组件（当月/本周数据自动标记）
|
||||
- [ ] T7：实现"预估"标记组件（当月/本周数据自动标记；营业日以 08:00 为分割点）
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# P8：小程序前端 — 看板模块 — miniapp-fe-boards
|
||||
|
||||
> 优先级：P8（依赖 P2 + P3 + P5）
|
||||
> 优先级：P8（依赖 P2 + P3 + P5-A）
|
||||
> 预估工作量：大
|
||||
|
||||
---
|
||||
@@ -18,7 +18,7 @@
|
||||
|
||||
- AC1：财务看板支持 2 组筛选交叉（区域 × 时间），选择非"全部区域"时预收资产板块消失
|
||||
- AC2：财务看板环比数据正确计算
|
||||
- AC3：财务看板 AI 洞察从缓存读取（应用 2 每日更新）
|
||||
- AC3：财务看板 AI 洞察从缓存读取（应用 2 每日更新，JSON 格式：序号+标题+正文数组）
|
||||
- AC4：客户看板 8 个维度筛选正确（最应召回/最大消费潜力/最高余额/最近充值/最高消费60天/最频繁60天/最近到店/最专一）
|
||||
- AC5：客户看板"最专一"维度下类型筛选锁定为"不限"
|
||||
- AC6：助教看板维度×项目×日期三重筛选交叉正确
|
||||
@@ -30,16 +30,16 @@
|
||||
|
||||
### board-finance（财务看板）
|
||||
|
||||
- 筛选器：区域筛选 + 时间筛选（本月/上月/本周/上周/前3月/本季/上季/近6月）
|
||||
- 筛选器：区域筛选 + 时间筛选（本月/上月/本周/上周/前3月/本季/上季/近6月；营业日以 08:00 为分割点，如"本月"= 当月1日 08:00 ~ 次月1日 08:00）
|
||||
- 数据板块：收入结构、预收资产（条件隐藏）、支出汇总、平台结算
|
||||
- 环比展示
|
||||
- AI 智能洞察（应用 2 缓存结果）
|
||||
- AI 智能洞察（应用 2 缓存结果，JSON 结构化输出：数组，每条含序号+标题+正文详情；UI 布局参考 `docs/h5_ui/` 财务看板 AI 智能洞察）
|
||||
- "问问助手"入口 → chat.html
|
||||
|
||||
### board-customer（客户看板）
|
||||
|
||||
- 维度筛选（8 个维度，默认"最应召回"）
|
||||
- 类型筛选（全部/台球/斯诺克/麻将/团建 + 台费包厢流水过滤）
|
||||
- 类型筛选（全部/🎱 中式/追分/斯诺克/🀄 麻将/棋牌/🎤 团建/K歌 + 台费包厢流水过滤）
|
||||
- 筛选互斥规则："最专一"锁定类型为"不限"
|
||||
- 客户列表（前 100 名）
|
||||
- 每个客户卡片：昵称、爱心 icon、喜好标签、关键指标值
|
||||
@@ -48,8 +48,8 @@
|
||||
### board-coach（助教看板）
|
||||
|
||||
- 维度筛选：定档业绩最高/最低、工资最高/最低、高客源储值额最高、任务完成最多
|
||||
- 项目筛选：全部/中🎱/斯诺克/麻将/团建
|
||||
- 日期维度筛选：本月/上月/本周/上周/前3月/本季/上季/近6月
|
||||
- 项目筛选：全部/🎱 中式/追分/斯诺克/🀄 麻将/棋牌/🎤 团建/K歌
|
||||
- 日期维度筛选：本月/上月/本周/上周/前3月/本季/上季/近6月（营业日以 08:00 为分割点，如"本月"= 当月1日 08:00 ~ 次月1日 08:00）
|
||||
- 助教列表
|
||||
- 右下角 AI 按钮 → chat.html
|
||||
|
||||
@@ -64,12 +64,50 @@
|
||||
| `GET /api/board/customers` | 客户看板（维度+类型筛选） | 是 |
|
||||
| `GET /api/board/coaches` | 助教看板（维度×项目×日期） | 是 |
|
||||
|
||||
### 财务看板数据字段映射（已校准，数据源：DWD-DOC 03-财务全景）
|
||||
|
||||
收入结构（settle_type=1，台桌结账）：
|
||||
|
||||
| 收入来源 | DWS 字段 | 占比 | 说明 |
|
||||
|----------|----------|-----:|------|
|
||||
| 台费 | `table_charge_money` | 56.6% | 按秒计时，台区单价固定 |
|
||||
| 助教陪打 | `assistant_pd_money` | 30.6% | 按秒计时，单价按等级 |
|
||||
| 商品 | `goods_money` | 10.1% | 酒水食品 |
|
||||
| 助教超休 | `assistant_cx_money` | 0.9% | 按课时，190 元/课时 |
|
||||
| 灯控电费 | `electricity_money` | 0% | 门店未启用，全为 0 |
|
||||
|
||||
> ⚠️ 消费金额口径：使用 `items_sum`（= tc + goods + pd + cx + electricity），不得使用 `consume_money`（三种历史口径混合）。
|
||||
|
||||
充值收入（settle_type=5）：从 `dws_finance_recharge_summary` 读取，充值退款（settle_type=7）需扣除。
|
||||
|
||||
支付渠道分布（settle_type=1）：
|
||||
- 纯团购券 60.6%、纯线上支付 14.0%、纯储值卡 10.6%、线上+团购券 9.7%
|
||||
|
||||
### 客户看板金额口径说明
|
||||
|
||||
- "最高消费60天"：基于 `dws_member_consumption_summary` 中的消费汇总字段，底层应基于 `items_sum` 聚合
|
||||
- "最高余额"：基于 `dws_member_consumption_summary` 中的余额字段（= 储值卡余额，独立于消费金额）
|
||||
- "最近充值"：基于 `dwd_recharge_order`（settle_type=5）
|
||||
|
||||
### 缓存策略
|
||||
|
||||
- 看板数据缓存层：Redis 或内存缓存
|
||||
- 缓存粒度：`site_id` + 筛选条件组合
|
||||
- 缓存过期：ETL 数据更新后失效（约 1 小时）
|
||||
- AI 洞察缓存：从 `biz.ai_cache` 读取（应用 2 每日更新）
|
||||
- AI 洞察缓存：从 `biz.ai_cache` 读取（应用 2 每日更新，`cache_type = app2_finance`，`result_json` 为 JSON 数组：序号+标题+正文详情）
|
||||
|
||||
---
|
||||
|
||||
## 小程序前端开发强制规范
|
||||
|
||||
> 以下规范适用于本 SPEC 中所有小程序页面实现，具有强制约束力。
|
||||
|
||||
1. **原型图是唯一视觉真相**：`docs/h5_ui/pages/*.html` 中的结构、层次、元素、配色、间距、交互行为是小程序页面实现的唯一参考标准。任何偏离原型图的实现都需要明确的产品确认。
|
||||
2. **WXML ≠ HTML**：严禁在小程序中使用 HTML 标签（div/span/p/a/img 等），必须使用小程序原生标签（view/text/image/navigator 等）。
|
||||
3. **WXSS ≠ CSS**：使用 rpx 单位、仅支持有限选择器、无 DOM/BOM API、样式隔离机制不同。Tailwind CSS 类名必须手动转换为 WXSS。
|
||||
4. **TDesign 优先**：凡 TDesign 组件库能覆盖的 UI 元素，必须使用 TDesign 组件；自定义实现仅限 TDesign 无法覆盖的场景。
|
||||
5. **Power 文档优先**：实现前必须加载 `wechat-miniprogram` Power 的相关 steering 文件（`view-layer.md`、`tdesign.md`、`builtin-components.md`），确保语法和组件用法正确。
|
||||
6. **项目踩坑指南必读**：实现前必须阅读 `docs/prd/MIGRATION-PLAYBOOK.md` 第六章，该文档是基于本项目实际转换经验的避坑手册，涵盖 WXML/WXSS 差异、事件系统、TDesign 用法、rpx 换算规则及新页面开发 Checklist。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
# P9：小程序前端 — 详情与对话模块 — miniapp-fe-details
|
||||
|
||||
> 优先级：P9（依赖 P3 + P4 + P5）
|
||||
> 优先级：P9（依赖 P3 + P4 + P5-A）
|
||||
> 预估工作量：大
|
||||
> P5-B 承接：T1 同时细化 P5 应用 3/6/7 的 Prompt JSON 结构
|
||||
|
||||
---
|
||||
|
||||
@@ -37,7 +38,8 @@
|
||||
- 商城订单：助教列表（花名+级别+课程类型+服务时长+定档绩效）、支付金额、食品酒水总金额
|
||||
- 充值：充值金额、支付方式
|
||||
- 备注列表
|
||||
- AI 消费习惯分析（应用 3 缓存）
|
||||
- AI 维客线索（应用 8 整合线索 + 人工，读取 `member_retention_clue`；Emoji 作为二级标签、提供者逗号分隔展示）
|
||||
- AI 客户分析（应用 7 缓存：运营策略数组 + 总结，结账单出现后自动生成；从 `ai_cache` cache_type=app7_customer_analysis 读取）
|
||||
- "问问助手"入口 → chat.html
|
||||
|
||||
### coach-detail（助教详情）
|
||||
@@ -81,22 +83,68 @@
|
||||
|
||||
### 消费记录 settle_type 区分
|
||||
|
||||
需要查库确认的字段（待 P1 完成后验证）：
|
||||
- 台桌结账：`settle_type` 对应值（需查 `dwd_settlement_head`）
|
||||
- 商城订单：`settle_type` 对应值
|
||||
- 充值：从 `dwd_recharge_order` 单独查询
|
||||
### settle_type 与消费记录类型映射（已校准，数据源：DWD-DOC 01-业务全景）
|
||||
|
||||
### 正价金额字段（待用户复核）
|
||||
| settle_type | 含义 | 数量占比 | 消费记录样式 |
|
||||
|:-----------:|------|---------|-------------|
|
||||
| 1 | 台桌结账 | 78.6% | 下沉到 `dwd_table_fee_log` 台费明细 |
|
||||
| 3 | 商城订单 | 21.4% | 助教列表 + 支付金额 + 食品酒水 |
|
||||
| 5 | 正常充值 | — | 从 `dwd_recharge_order` 单独查询 |
|
||||
| 7 | 充值退款 | 极少（10 笔） | 不在消费记录中展示 |
|
||||
| 6 | 结算退款 | 极少（1 笔） | 不在消费记录中展示 |
|
||||
|
||||
需要在 `dwd_settlement_head` 或相关 DWS 表中确认：
|
||||
- `original_amount` vs `total_amount` vs 其他字段
|
||||
- 此项标记为"需用户复核"
|
||||
### 金额字段说明（已校准，数据源：DWD-DOC 02-账务全景 + consume 口径文档）
|
||||
|
||||
⚠️ 不得直接使用 `consume_money`（三种历史口径混合，不稳定）。
|
||||
|
||||
正价金额（消费项目合计，全时期一致）：
|
||||
```sql
|
||||
items_sum = table_charge_money + goods_money + assistant_pd_money
|
||||
+ assistant_cx_money + electricity_money
|
||||
```
|
||||
|
||||
实付金额需按支付渠道拆分展示：
|
||||
| 支付渠道 | 字段 | 说明 |
|
||||
|----------|------|------|
|
||||
| 线上支付 | `pay_amount` | 不含 balance，= `point_amount` + `cash_amount` |
|
||||
| 储值卡 | `balance_amount` | 独立渠道，= `recharge_card_amount` + `gift_card_amount` |
|
||||
| 团购券抵扣 | `coupon_amount` | 门店实际抵扣额 |
|
||||
| 会员折扣 | `member_discount_amount` | 仅 settle_type=1 |
|
||||
| 台费调整 | `adjust_amount` | 手动调价 |
|
||||
| 抹零 | `rounding_amount` | 收支平衡减项 |
|
||||
|
||||
团购券三层价格体系（展示时注意区分）：
|
||||
- 顾客支付价 → `PCR.sale_price`
|
||||
- 平台结算价 → `SH.pl_coupon_sale_amount`（= SUM(GR.ledger_unit_price)）
|
||||
- 门店抵扣价 → `SH.coupon_amount`（= SUM(GR.ledger_amount)）
|
||||
|
||||
已知限制：
|
||||
- `online_pay_channel` 全为 0，无法区分微信/支付宝（聚合支付接入）
|
||||
- `settlement_head_ex` 中 `payment_method`、`is_use_coupon`、`is_activity` 等字段全为 0，不可用
|
||||
- 团购券与会员折扣不叠加
|
||||
- 2025-11-09 前台费明细 `is_delete=1`，历史数据不完整
|
||||
|
||||
---
|
||||
|
||||
## 小程序前端开发强制规范
|
||||
|
||||
> 以下规范适用于本 SPEC 中所有小程序页面实现，具有强制约束力。
|
||||
|
||||
1. **原型图是唯一视觉真相**：`docs/h5_ui/pages/*.html` 中的结构、层次、元素、配色、间距、交互行为是小程序页面实现的唯一参考标准。任何偏离原型图的实现都需要明确的产品确认。
|
||||
2. **WXML ≠ HTML**：严禁在小程序中使用 HTML 标签（div/span/p/a/img 等），必须使用小程序原生标签（view/text/image/navigator 等）。
|
||||
3. **WXSS ≠ CSS**：使用 rpx 单位、仅支持有限选择器、无 DOM/BOM API、样式隔离机制不同。Tailwind CSS 类名必须手动转换为 WXSS。
|
||||
4. **TDesign 优先**：凡 TDesign 组件库能覆盖的 UI 元素，必须使用 TDesign 组件；自定义实现仅限 TDesign 无法覆盖的场景。
|
||||
5. **Power 文档优先**：实现前必须加载 `wechat-miniprogram` Power 的相关 steering 文件（`view-layer.md`、`tdesign.md`、`builtin-components.md`），确保语法和组件用法正确。
|
||||
6. **项目踩坑指南必读**：实现前必须阅读 `docs/prd/MIGRATION-PLAYBOOK.md` 第六章，该文档是基于本项目实际转换经验的避坑手册，涵盖 WXML/WXSS 差异、事件系统、TDesign 用法、rpx 换算规则及新页面开发 Checklist。
|
||||
|
||||
---
|
||||
|
||||
## 任务清单
|
||||
|
||||
- [ ] T1：实现客户详情 API
|
||||
- T1-a：细化 P5 应用 3（维客线索）Prompt JSON 结构，实现 `consumption_records`、`member_cards` 等字段的拼接函数（对应 P5-T6-完整）
|
||||
- T1-b：细化 P5 应用 6（备注分析）Prompt JSON 结构，实现 `consumption_data` 字段的拼接函数（对应 P5-T9-完整）
|
||||
- T1-c：细化 P5 应用 7（客户分析）Prompt JSON 结构，实现 `objective_data` 字段的拼接函数（对应 P5-T10-完整）
|
||||
- [ ] T2：实现消费记录分页 API（三种样式区分 + 懒加载）
|
||||
- [ ] T3：实现客户指数总览 API
|
||||
- [ ] T4：实现助教详情 API
|
||||
|
||||
Reference in New Issue
Block a user