微信小程序页面迁移校验之前 P5任务处理之前

2026-03-09 01:19:21 +08:00
parent 263bf96035
commit 6e20987d2f
1112 changed files with 153824 additions and 219694 deletions
--- a/docs/prd/specs/00-数据依赖矩阵.md
+++ b/docs/prd/specs/00-数据依赖矩阵.md
@@ -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 结果缓存 |
--- a/docs/prd/specs/01-SPEC任务拆分总览.md
+++ b/docs/prd/specs/01-SPEC任务拆分总览.md
@@ -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 并行
--- a/docs/prd/specs/P10-tenant-admin-web.md
+++ b/docs/prd/specs/P10-tenant-admin-web.md
@@ -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（修改/删除/隐藏）+ 后端路由扩展
--- a/docs/prd/specs/P2-etl-dws-miniapp-extensions.md
+++ b/docs/prd/specs/P2-etl-dws-miniapp-extensions.md
@@ -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`

 ### 命名方案

--- a/docs/prd/specs/P3-miniapp-auth-system.md
+++ b/docs/prd/specs/P3-miniapp-auth-system.md
@@ -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）
--- a/docs/prd/specs/P4-miniapp-core-business.md
+++ b/docs/prd/specs/P4-miniapp-core-business.md
@@ -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`），无需单独处理
--- a/docs/prd/specs/P5-miniapp-ai-integration.md
+++ b/docs/prd/specs/P5-miniapp-ai-integration.md
@@ -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）中完成
--- a/docs/prd/specs/P5.1-mcp-server-ai-extension.md
+++ b/docs/prd/specs/P5.1-mcp-server-ai-extension.md
@@ -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 应用引用效果
--- a/docs/prd/specs/P6-miniapp-fe-tasks.md
+++ b/docs/prd/specs/P6-miniapp-fe-tasks.md
@@ -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、预估标记）
--- a/docs/prd/specs/P7-miniapp-fe-performance.md
+++ b/docs/prd/specs/P7-miniapp-fe-performance.md
@@ -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 为分割点）
--- a/docs/prd/specs/P8-miniapp-fe-boards.md
+++ b/docs/prd/specs/P8-miniapp-fe-boards.md
@@ -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。

 ---

--- a/docs/prd/specs/P9-miniapp-fe-details.md
+++ b/docs/prd/specs/P9-miniapp-fe-details.md
@@ -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