crm_project/SHBL-ERP_CRM软件升级需求1.md

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 接口完成闭环。