# SHBL-ERP 升级 PRD：AI 原生销售攻坚教练引擎 (Phase 3.0)

**项目代号**：天津硕博霖销售攻坚智能体改造 **关联基础版本**：v0.2.0 **核心目标**：实现 AI 从“被动问答”向“业务流主动拦截与教练辅导”的跨越，提升针对燃气轮机、透平压缩机等大型工业设备的大客户攻坚成功率。

## 一、 数据库层改造 (Database Schema Updates)

目前核心数据持久层基于 PostgreSQL。本次需要引入向量检索能力并扩展现有业务表，以支持结构化的 AI 评估数据。

- **扩展 1：引入 `pgvector` 插件**
  - **需求**：在当前的 PostgreSQL 宿主机实例中安装并启用 `pgvector` 扩展。
  - **目的**：构建原生向量表（如 `kb_obsidian_vectors`），用于将平时沉淀的设备工况数据、润滑油 TDS/MSDS 及历史技术方案进行向量化存储，供大模型进行检索增强 (RAG)。
- **扩展 2：修改 `sales_logs` 表**
  - **变更**：新增字段 `ai_coaching_feedback` (类型：`JSONB`，可空)。
  - **目的**：存储 AI 异步评估后返回的结构化教练反馈（含 MEDDIC 扫描、SPIN 提问建议）。
- **扩展 3：修改 `crm_customers` 表**
  - **变更 1**：新增字段 `health_score` (类型：`Integer`，默认 100)。
  - **变更 2**：新增字段 `meddic_status` (类型：`JSONB`，可空)。
  - **目的**：固化大客户的交易健康度，便于王 X 等管理层直观把控高净值客户的推进阶段。
- **迁移任务**：通过 Alembic 生成对应的 `async` 迁移脚本。

## 二、 后端接口层改造 (FastAPI Backend Updates)

需要改变目前 AI 模块仅依靠 SSE 实时流式输出的单向模式。

- **改造 1：重构 `POST /api/sales-logs` 接口**
  - **主逻辑不变**：接收前端提交的销售日志，校验 `involved_company_ids`，执行常规的快速数据库 `INSERT`，立刻向前端返回 200 OK，确保业务流程不卡顿。
  - **新增逻辑**：挂载 FastAPI 原生的 `BackgroundTasks`。在后台异步触发 `httpx` 请求，调用 Dify 的 Workflow API，将新生成的 `log_id`、客户信息与日志内容发送给底层部署在公司机架上的 R740-A 服务器进行深度思考。
- **新增 1：内部回调接口 `POST /api/dify-tools/log-feedback`**
  - **目的**：接收 Dify Workflow 执行完毕后返回的标准化 JSON 数据，反向执行 `UPDATE sales_logs SET ai_coaching_feedback = ? WHERE id = ?`。
- **新增 2：SSE 通知系统 `GET /api/notifications/stream`**
  - **目的**：当后台 `ai_coaching_feedback` 字段更新完毕时，向对应的销售人员（`owner_id`）推送一条前端消息提示：“💡 您的最新拜访日志已生成 AI 战术诊断，请查阅。”

## 三、 前端交互层改造 (Vue 3 + Element Plus)

- **改造 1：全局悬浮球 (FloatingChat) 上下文嗅探**
  - **需求**：修改前端逻辑，拦截悬浮球的开启事件。读取 Vue Router 当前路径。如果处于 `/customers/detail/:id` 路由下，隐式提取当前客户画像与近期沟通历史，随 Chat API 的 Payload 自动发送。
- **改造 2：`sales_logs` 详情视图扩展**
  - **需求**：在日志详情页增加一个“教练评估面板 (Coaching Board)”。
  - **渲染逻辑**：读取 `ai_coaching_feedback` (JSONB) 字段。如果为空，显示“🧠 AI 战术推演中...”的骨架屏；如果有数据，使用 Element Plus 的折叠面板或卡片组件，结构化渲染“MEDDIC 盲区警告”、“Solution 诊断需求”和“SPIN 提问剧本”。

------

## 四、 Dify 编排层配置指南 (Workflow API)

此阶段的算力将严格依赖 R740-A 节点。其中 RTX 3090 (`qwen3.5:27b`) 负责深度逻辑剖析，RTX 4060 (`bge-m3`) 负责高频知识库向量检索。

**配置模式**：在 Dify 中新建应用，**必须选择“工作流 (Workflow)”类型**，而非传统的“聊天助手”。

### 1. 变量定义节点 (Start Node)

定义明确的系统级输入变量，确保接口调用规范：

- `log_id` (String)：系统日志主键。
- `customer_context` (String)：由 FastAPI 拼装的客户基础信息（行业、设备规模等）。
- `log_content` (String)：业务员刚提交的散乱日记文本。

### 2. 知识检索节点 (Knowledge Retrieval)

- **配置**：挂载基于 Obsidian 笔记构建的技术参数知识库。
- **作用**：根据 `log_content` 中的关键词（如特定型号的伺服阀、透平压缩机），从向量库中抽取出相应的油样分析标准或故障排查手册。

### 3. LLM 处理节点 (Core Engine)

- **模型选择**：`qwen3.5:27b` (位于 192.168.1.88:11434)。

- **System Prompt**：植入我们上一轮确定的“工业大客户攻坚教练” Markdown 提示词。

- **关键指令**：在 Prompt 末尾增加 JSON 约束指令：

  > "你必须严格输出合法的 JSON 格式，不要包含任何 Markdown 代码块包裹（即不要带有 ```json）。结构必须如下：" `{"meddic_alerts": ["..."], "solution_diagnostics": "...", "spin_questions": [{"type": "Situation", "question": "..."}, ...]}`

### 4. HTTP 请求节点 (HTTP Request - End Node)

- **配置**：不使用默认的结束节点。在 LLM 节点后，直接拼接一个 HTTP Request 节点。
- **动作**：将 LLM 生成的 JSON 结果，加上 `log_id`，以 POST 形式发送回你后端的 `/api/dify-tools/log-feedback` 接口完成闭环。