wxsales/微信营销管理系统总体设计与实施方案.md

# 微信营销管理系统总体设计与实施方案

> 文档日期：2026-07-14  
> 目标：在现有微信聊天记录本机获取、PostgreSQL 知识库、bge-m3 向量化和 Web 检索能力的基础上，建设一套面向多销售、多微信号、多产品的微信营销管理、销售分析、培训对练和 AI 销售系统。

---

## 一、项目目标

系统需要解决五个核心问题：

1. 为每个销售配置一个业务微信号，持续获取销售与客户的沟通内容。
2. 使用 AI 分析销售过程，重点研究高成交销售的行为、节奏、方法和话术。
3. 将优秀销售方法转化为新销售可练习、可评分、可复盘的培训能力。
4. 使用真实优秀销售数据训练或增强 AI，使 AI 具备高水平销售能力。
5. 将产品知识、客户画像、销售阶段和合规策略配置化，使系统适用于大多数产品。

最终产品不是单纯的聊天记录查看器，而是一套完整的销售智能闭环：

```text
沟通数据采集
  → 客户与会话识别
  → 消息标准化
  → 销售过程结构化
  → 成交结果关联
  → 优秀销售模式分析
  → 方法、策略和话术沉淀
  → 培训对练与评分
  → AI 销售辅助或自动销售
  → 新结果回流并持续优化
```

---

## 二、当前已经具备的基础能力

当前已经完成一个本机单账号验证系统，具备以下能力。

### 2.1 微信数据库获取

- 定位 macOS 微信 4.x 本地数据目录。
- 在微信退出后复制数据库副本。
- 使用已授权的本机工具获取当前账号数据库解密信息。
- 成功解密 22 个微信数据库。
- 所有处理均在本机进行，不上传数据库或密钥。

### 2.2 数据解析与标准化

已经解析：

- 联系人。
- 个人会话。
- 群聊和群成员。
- 消息发送者。
- 消息时间。
- 消息正文。
- 图片、语音、视频、表情、文件和应用消息类型。
- 引用消息、视频号分享和 XML 应用消息。

页面展示层已经将原始 XML 转为可读内容：

- 图片显示为 `[图片]`。
- 语音显示为 `[语音]`。
- 视频显示为 `[视频]`。
- 表情显示为 `[表情]`。
- 文件显示文件名。
- 引用消息显示引用人和引用内容。
- 视频号分享提取标题或内容描述。
- 无法解析的应用消息显示为 `[链接或应用消息]`。

原始数据仍保留在数据库中，展示清洗不会破坏原始证据。

### 2.3 PostgreSQL 知识库

当前数据库：

```text
数据库：wechat_knowledge
PostgreSQL：17
向量扩展：pgvector
连接方式：本机 Unix Socket
TCP 监听：关闭
```

现有主要数据规模：

| 数据类型 | 数量 |
|---|---:|
| 联系人 | 46,485 |
| 对话 | 2,325 |
| 消息 | 627,933 |
| 知识片段 | 279,994 |
| 语义文档 | 57,145 |
| 实体 | 48,807 |
| 关系 | 12,141 |

### 2.4 本地向量能力

- 使用 Ollama 运行本地 `bge-m3`。
- 向量维度为 1024。
- 只对经过清洗的语义文档生成向量。
- 已有向量不重复生成。
- 新增语义文档通过 `embedding IS NULL` 增量处理。
- 使用 HNSW 索引进行语义相似度检索。

### 2.5 Web 搜索页面

当前本机页面：

```text
http://127.0.0.1:8765
```

支持：

- 按聊天内容搜索。
- 按用户名、备注、微信号或群名搜索。
- 选择指定对话。
- 按日期和消息类型筛选。
- 查看消息前后上下文。
- 关键词高亮。
- 分页加载。
- 响应式布局和深色模式。

### 2.6 每日增量同步

当前使用 macOS `launchd` 每天 05:00 执行增量同步：

```text
com.freedak.wechat-knowledge-sync
```

同步过程：

1. 记录同步前统计。
2. 正常退出微信；如果 AppleScript 被拒绝，则使用 SIGTERM。
3. 复制一致性数据库副本。
4. 立即重新打开微信。
5. 验证已有密钥。
6. 解密数据库副本。
7. 增量导入联系人、对话和消息。
8. 增量生成语义文档。
9. 为缺少向量的文档生成 bge-m3 向量。
10. 输出 JSON 和 Markdown 统计报告。
11. 删除加密和解密临时数据库。

原始消息去重键：

```sql
UNIQUE(source_shard, source_table, source_local_id)
```

现有脚本：

- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/daily_wechat_sync.py`
- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/run_daily_wechat_sync.sh`
- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/postgres/import_wechat.py`
- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/postgres/incremental_semantic_documents.py`
- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/postgres/embed_chunks.py`
- `/Users/freedak/Documents/Codex/2026-07-14/ni/work/postgres/wechat_sync_stats.py`

---

## 三、从单机验证到营销管理系统的关键变化

当前系统证明了技术可行性，但多销售生产系统不能只是复制当前单机脚本，需要完成以下升级。

| 当前验证系统 | 生产营销系统 |
|---|---|
| 单个微信账号 | 多销售、多微信账号 |
| 单机本地数据库 | 中央业务数据库或分布式数据节点 |
| 每日离线同步 | 准实时或可配置周期同步 |
| 关键词搜索 | 客户、商机、阶段、意向和风险分析 |
| 聊天记录展示 | 销售过程管理与经营分析 |
| 简单联系人实体 | 客户、联系人、企业、商机、订单统一身份 |
| 仅聊天数据 | 聊天、CRM、订单、回款、产品和客服数据关联 |
| 通用语义向量 | 产品知识、销售方法和客户阶段分层向量库 |
| 人工查看 | AI 自动分析、建议、培训、评分和销售辅助 |

生产系统最重要的变化是必须将“聊天记录”和“成交结果”关联起来。没有订单、合同、回款或明确成交标签，就无法可靠判断什么话术真正有效。

---

## 四、总体系统架构

```text
销售微信 / 企业微信 / CRM / 订单系统
              │
              ▼
        数据采集与同步层
              │
              ▼
        消息标准化与身份层
              │
      ┌───────┴────────┐
      ▼                ▼
 PostgreSQL业务库    对象存储
 消息/客户/商机      图片/语音/文件
      │
      ▼
 AI解析与销售过程结构化
      │
      ├── 客户画像
      ├── 意向与阶段
      ├── 需求/异议/预算
      ├── 销售动作
      ├── 风险与待办
      └── 成交结果归因
      │
      ▼
 销售智能与知识资产层
      │
      ├── 优秀销售模式
      ├── 场景话术库
      ├── 案例库
      ├── 产品知识库
      ├── 客户问题库
      └── 销售策略库
      │
      ├───────────────┬────────────────┐
      ▼               ▼                ▼
 销售管理后台      培训对练系统      AI销售助手/AI销售
```

---

## 五、数据采集方案

### 5.1 账号与设备模型

建议建立以下层级：

```text
企业
  └── 销售团队
       └── 销售人员
            └── 业务微信账号
                 └── 登录设备或采集节点
```

每个销售微信号必须绑定：

- 企业 ID。
- 团队 ID。
- 销售人员 ID。
- 微信账号内部标识。
- 采集设备 ID。
- 数据授权状态。
- 最后同步时间。
- 同步健康状态。

### 5.2 数据获取优先级

生产落地建议按以下优先级选择数据来源：

1. 企业微信官方会话存档、CRM 官方接口或获得明确授权的合规接口。
2. 企业统一管理的销售设备，通过本机采集代理同步。
3. 销售人工导出并导入聊天记录。
4. 当前 macOS 本机数据库解析方式，仅作为内部授权设备的技术方案。

当前本机数据库方式适合验证和受控内部使用，但大规模商业化前必须评估：

- 微信版本更新造成的数据结构变化。
- 多平台差异。
- 账号安全和风控。
- 客户隐私、员工知情和授权。
- 平台服务条款。
- 数据跨设备传输和保存要求。

### 5.3 同步方式

支持三种模式：

#### 每日同步

- 适合经营分析和培训。
- 成本最低。
- 当前系统已经实现。

#### 小时级同步

- 每 30～60 分钟采集一次。
- 适合销售跟进提醒和主管管理。
- 需要更可靠的数据快照机制。

#### 准实时同步

- 适合实时销售助手。
- 延迟目标 1～5 分钟。
- 应优先采用官方接口或合规消息通道。
- 不建议通过持续注入或高风险进程监听实现。

### 5.4 增量去重

不能只依赖单一自增 ID。生产系统建议使用多层去重键：

```text
租户ID
+ 微信账号ID
+ 会话ID
+ 服务端消息ID
+ 本地消息ID
+ 消息时间
+ 内容指纹
```

建议生成稳定的消息指纹：

```text
SHA256(
  tenant_id
  + account_id
  + conversation_external_id
  + server_message_id
  + sender_external_id
  + created_at
  + normalized_content
)
```

### 5.5 多媒体处理

- 图片：OCR、产品识别、报价单识别、截图语义提取。
- 语音：ASR 转写、说话人识别、情绪和语速分析。
- 视频：只提取标题、描述、字幕和关键帧，不默认保存完整视频。
- 文件：解析 PDF、Word、Excel、PPT 和文本附件。
- 小程序与链接：提取标题、来源和业务参数。

多媒体原文件应存入受权限控制的对象存储，PostgreSQL 只保存元数据和引用地址。

---

## 六、统一数据模型

### 6.1 核心业务实体

| 实体 | 作用 |
|---|---|
| tenant | 企业租户 |
| team | 销售团队 |
| salesperson | 销售人员 |
| channel_account | 微信号或其他沟通账号 |
| customer | 客户主体 |
| customer_contact | 客户联系人 |
| conversation | 单聊或群聊 |
| conversation_member | 会话参与者 |
| message | 原始标准化消息 |
| lead | 销售线索 |
| opportunity | 商机 |
| product | 产品或服务 |
| order | 订单 |
| payment | 回款 |
| sales_stage | 销售阶段 |
| sales_event | 销售动作和事件 |
| analysis_result | AI 分析结果 |
| playbook | 销售打法 |
| script | 场景话术 |
| training_session | 培训对练记录 |

### 6.2 消息表关键字段

```sql
message_id
tenant_id
channel_account_id
conversation_id
sender_identity_id
customer_id
salesperson_id
external_message_id
message_type
raw_content
normalized_content
created_at
reply_to_message_id
media_asset_id
content_hash
source_metadata
```

### 6.3 商机表关键字段

```sql
opportunity_id
tenant_id
customer_id
owner_salesperson_id
product_id
source_channel
current_stage
expected_amount
probability
created_at
first_contact_at
last_contact_at
won_at
lost_at
lost_reason
actual_order_amount
actual_payment_amount
```

### 6.4 AI 分析结果必须可追溯

每条 AI 判断必须保存：

- 分析类型。
- 模型和版本。
- 提示词版本。
- 输入消息范围。
- 输出结构。
- 置信度。
- 支撑证据消息 ID。
- 创建时间。
- 人工确认状态。

AI 结论必须能回到原始聊天证据，不能只保存一段不可验证的总结。

---

## 七、客户与会话身份识别

微信昵称、备注和群名会变化，不能直接把显示名称当作客户唯一身份。

需要建立身份解析层：

```text
微信内部ID
  ↕
手机号 / 企业名称 / CRM客户ID / 订单客户ID
  ↕
统一 customer_id
```

身份合并信号包括：

- 微信内部 username。
- 手机号。
- CRM 客户编号。
- 企业名称。
- 收货信息。
- 合同主体。
- 订单主体。
- 销售人工确认。

身份合并必须支持撤销，避免错误合并两个客户后污染全部分析。

---

## 八、销售过程 AI 分析

### 8.1 单次会话分析

对一段聊天识别：

- 客户是谁。
- 客户在问什么。
- 客户显性需求和隐性需求。
- 预算、时间、决策人和使用场景。
- 客户顾虑和异议。
- 销售采取了什么动作。
- 销售是否回答完整。
- 是否形成明确下一步。
- 当前意向等级。
- 推荐回复和待办事项。

### 8.2 客户级长期分析

将同一客户多次会话串联，形成：

- 客户画像。
- 产品兴趣。
- 需求变化。
- 关键时间线。
- 历史异议。
- 价格敏感度。
- 决策链和影响人。
- 承诺事项。
- 成交概率。
- 流失风险。

### 8.3 销售阶段识别

推荐采用可配置阶段，而不是写死：

```text
新线索
  → 建立联系
  → 需求发现
  → 方案匹配
  → 产品演示
  → 报价
  → 异议处理
  → 决策推进
  → 成交/未成交
  → 复购/转介绍
```

不同产品可以配置不同阶段。例如低客单零售可能只有“咨询—推荐—下单—复购”，企业服务则需要更长的决策链。

### 8.4 AI 输出结构示例

```json
{
  "sales_stage": "异议处理",
  "intent_score": 78,
  "customer_needs": ["降低人工成本", "支持多门店"],
  "objections": ["价格较高", "担心上线周期"],
  "decision_roles": ["门店老板", "运营负责人"],
  "sales_actions": ["解释ROI", "提供案例"],
  "missing_actions": ["没有确认预算", "没有约定下次沟通时间"],
  "next_best_action": "发送同规模门店案例并预约30分钟演示",
  "evidence_message_ids": [123, 126, 131],
  "confidence": 0.87
}
```

---

## 九、高成交销售分析

### 9.1 先定义“高成交”

不能只看订单数量。建议综合以下指标：

- 成交金额。
- 回款金额。
- 成交率。
- 平均客单价。
- 从首次联系到成交的周期。
- 有效线索转化率。
- 折扣率。
- 退款率和投诉率。
- 复购率。
- 转介绍率。
- 客户满意度。
- 数据样本量。

应按产品、线索质量、区域、客户类型和时间范围进行校正，避免把“拿到更好线索”误判为“销售能力更强”。

### 9.2 分析维度

对优秀销售重点分析：

#### 沟通节奏

- 首次响应速度。
- 跟进间隔。
- 每个阶段平均停留时间。
- 什么时候催进度。
- 什么时候给客户思考空间。
- 什么时候从文字切换语音、电话或会议。

#### 提问方式

- 开放式问题比例。
- 是否优先询问业务场景。
- 是否确认决策人。
- 是否确认预算和时间。
- 是否复述并验证客户需求。

#### 价值表达

- 先讲功能还是先讲结果。
- 是否使用量化收益。
- 是否使用同行案例。
- 是否根据客户角色调整表达。
- 是否将产品优势映射到客户痛点。

#### 异议处理

- 价格异议。
- 效果异议。
- 信任异议。
- 竞品比较。
- 决策拖延。
- 没预算。
- 需要请示。

#### 成交推进

- 是否提出明确下一步。
- 是否制造合理紧迫感。
- 是否降低客户决策风险。
- 是否给出套餐或选择题。
- 是否在关键节点要求承诺。

### 9.3 从相关性走向有效性

“优秀销售经常说某句话”不等于“这句话导致成交”。需要进行对照分析：

- 成交会话和未成交会话对比。
- 同产品、同来源、同客户类型对比。
- 同一销售不同阶段表现对比。
- 使用某种话术前后的转化率对比。
- 话术命中后的下一步行为对比。
- A/B 测试新话术。

输出应包含：

```text
适用场景
+ 客户特征
+ 销售阶段
+ 推荐策略
+ 示例话术
+ 禁用条件
+ 历史样本量
+ 转化提升
+ 置信区间
+ 原始证据
```

### 9.4 优秀话术不是简单复制

系统需要提炼“话术背后的策略”：

```text
客户说：价格太高

低质量复制：我们产品其实不贵。

策略抽象：
1. 先确认客户比较的基准。
2. 将价格转为使用周期成本。
3. 用客户业务结果解释价值。
4. 提供同类型客户案例。
5. 给出低风险试用或分阶段方案。
```

只有抽象成策略，系统才能跨产品复用。

---

## 十、销售方法与话术知识库

建议建立六类知识库：

### 10.1 产品知识库

- 产品功能。
- 适用客户。
- 使用场景。
- 价格和套餐。
- 实施周期。
- 限制条件。
- 常见问题。
- 合规边界。

### 10.2 客户案例库

- 客户行业和规模。
- 原始问题。
- 采用方案。
- 实施过程。
- 量化结果。
- 可公开范围。

### 10.3 销售策略库

- 需求发现策略。
- 价值表达策略。
- 异议处理策略。
- 成交推进策略。
- 复购和转介绍策略。

### 10.4 场景话术库

话术必须带元数据：

```text
产品
客户行业
客户角色
销售阶段
客户意向
异议类型
沟通渠道
适用条件
禁用条件
来源销售
历史使用次数
成交表现
合规等级
```

### 10.5 失败案例库

除了优秀案例，还要保存：

- 过早报价。
- 只讲产品不问需求。
- 没有确认下一步。
- 对客户持续轰炸。
- 使用虚假紧迫感。
- 承诺产品无法实现的能力。
- 对敏感信息处理不当。

失败案例对培训和 AI 安全非常重要。

### 10.6 销售 Playbook

Playbook 是完整打法，不是单句话：

```text
目标客户
  → 触达方式
  → 首次沟通
  → 需求发现问题清单
  → 价值表达
  → 产品演示
  → 常见异议
  → 报价策略
  → 成交动作
  → 交付衔接
  → 复购和转介绍
```

---

## 十一、培训对练系统

### 11.1 训练模式

#### 单场景练习

- 客户询价。
- 客户说贵。
- 客户对效果不信任。
- 客户正在比较竞品。
- 客户表示需要请示老板。
- 客户长时间不回复。

#### 完整销售流程练习

AI 扮演客户，从首次咨询到最终成交或流失。新销售必须完成需求发现、方案匹配、异议处理和成交推进。

#### 优秀案例复盘

隐藏原销售回复，让学员回答，再与优秀销售真实回复、策略和结果进行对比。

#### 失败修复练习

给出一段失败聊天，让学员识别问题并重新组织回复。

### 11.2 AI 客户角色

AI 客户应具备可配置属性：

- 行业。
- 企业规模。
- 职位和决策权。
- 预算。
- 紧迫程度。
- 真实需求。
- 隐藏顾虑。
- 竞品使用情况。
- 沟通风格。
- 价格敏感度。
- 信任程度。
- 成交条件。

AI 客户不能因为学员随便说几句话就成交，必须遵守预先定义的角色状态和决策逻辑。

### 11.3 评分体系

建议采用百分制：

| 维度 | 权重 |
|---|---:|
| 需求发现 | 20 |
| 倾听与信息确认 | 10 |
| 产品匹配 | 15 |
| 价值表达 | 15 |
| 异议处理 | 15 |
| 下一步推进 | 10 |
| 沟通体验 | 10 |
| 合规性 | 5 |

评分必须引用具体对话证据，并给出：

- 做得好的地方。
- 遗漏的问题。
- 风险表达。
- 推荐改写。
- 优秀销售对照案例。
- 下一轮训练目标。

### 11.4 培训闭环

```text
能力评估
  → 识别短板
  → 分配训练场景
  → AI 对练
  → 自动评分
  → 主管复核
  → 再次训练
  → 真实销售表现验证
```

最终判断培训是否有效，必须观察学员真实销售数据是否改善，而不仅是模拟考试分数。

---

## 十二、AI 销售能力建设

### 12.1 四个成熟阶段

#### 阶段一：销售复盘助手

- 总结客户需求。
- 提取待办。
- 识别风险。
- 给出跟进建议。

#### 阶段二：回复建议助手

- 根据当前上下文生成 2～3 个建议回复。
- 销售人工选择、编辑并发送。
- 记录采用率和修改内容。

#### 阶段三：销售 Copilot

- 自动生成客户画像。
- 主动提示销售阶段和下一步动作。
- 自动准备案例、报价和产品资料。
- 对高风险回复进行合规提醒。

#### 阶段四：受控 AI 销售

- 在低风险场景自动回复。
- 涉及价格、承诺、合同、退款或敏感信息时转人工。
- 自动回复必须可审计、可撤回、可随时接管。

不建议一开始就让 AI 完全自动与客户沟通。应从建议模式开始，用真实采用率、成交率、投诉率和合规率逐步验证。

### 12.2 AI 销售决策输入

AI 每次回复前需要获得：

- 当前聊天上下文。
- 客户长期画像。
- 当前销售阶段。
- 客户需求和异议。
- 产品知识。
- 价格权限。
- 可用案例。
- 优秀销售策略。
- 企业合规规则。
- 不允许承诺的事项。
- 推荐下一步动作。

### 12.3 推荐的 AI 架构

```text
销售策略模型
  决定现在应该做什么
        │
        ▼
知识检索 RAG
  找产品、案例、话术和证据
        │
        ▼
回复生成模型
  生成自然、个性化回复
        │
        ▼
事实与合规检查
  检查价格、承诺、敏感信息
        │
        ▼
人工确认或自动发送策略
```

不能只用一个提示词直接让大模型回复客户。策略、知识、生成和安全检查应分层。

### 12.4 是否需要微调模型

第一阶段建议使用 RAG、结构化策略和优秀案例，不立即微调。

原因：

- 产品和价格变化频繁。
- 优秀话术依赖场景。
- 微调后知识更新较慢。
- 原始聊天中包含隐私和噪声。
- 先要证明训练样本和评价标准可靠。

当积累大量经过人工确认的高质量数据后，可以微调：

- 销售阶段分类模型。
- 意向和异议识别模型。
- 回复风格模型。
- 评分模型。

微调数据必须去除隐私信息，并保证有明确授权。

---

## 十三、适用于大多数产品的方法

要实现跨产品复用，系统必须把“通用销售能力”和“产品专属知识”分开。

### 13.1 通用层

- 建立关系。
- 需求发现。
- 决策链识别。
- 预算和时间确认。
- 价值表达。
- 异议处理。
- 下一步推进。
- 成交和复购。

### 13.2 产品配置层

每个产品配置：

- 产品名称和分类。
- 目标客户。
- 典型场景。
- 价值主张。
- 功能与限制。
- 价格和折扣权限。
- 竞品信息。
- 客户案例。
- 常见问题。
- 禁止承诺。
- 销售阶段。
- 成交条件。
- 评价指标。

### 13.3 行业模板

可以逐步建设：

- SaaS 软件销售模板。
- 企业服务模板。
- 招聘和人力资源服务模板。
- 教育培训模板。
- 餐饮数字化模板。
- 零售和电商模板。
- 高客单咨询模板。
- 本地生活服务模板。

系统底层保持一致，行业模板调整客户角色、销售周期、阶段、知识库和评分规则。

---

## 十四、管理后台产品功能

### 14.1 销售工作台

- 今日待跟进客户。
- 高意向客户。
- 长时间未回复客户。
- 客户关键需求和异议。
- 推荐下一步动作。
- AI 回复建议。
- 承诺事项提醒。

### 14.2 主管工作台

- 团队成交漏斗。
- 销售响应速度。
- 跟进覆盖率。
- 商机阶段分布。
- 高风险商机。
- 销售能力雷达图。
- 优秀和失败案例。
- 培训建议。

### 14.3 客户详情页

- 客户统一画像。
- 所有微信会话。
- 关键时间线。
- 需求、预算和决策人。
- 当前商机阶段。
- 报价和订单。
- AI 总结和建议。
- 原始聊天证据。

### 14.4 销售分析页

- 成交率和回款。
- 按产品、渠道和客户类型对比。
- 各阶段转化率。
- 优秀话术和策略使用情况。
- 异议处理能力。
- 培训前后表现变化。

### 14.5 话术与案例中心

- 按场景检索。
- 按产品和客户角色筛选。
- 显示真实使用效果。
- 显示适用和禁用条件。
- 主管审核和版本管理。

### 14.6 培训中心

- 能力测评。
- AI 客户对练。
- 优秀案例模仿。
- 失败案例修复。
- 自动评分。
- 团队排行榜。
- 训练和实战效果关联。

---

## 十五、指标体系

### 15.1 数据质量指标

- 账号同步成功率。
- 消息采集完整率。
- 消息重复率。
- 客户身份匹配率。
- 多媒体解析率。
- AI 分析证据覆盖率。

### 15.2 销售过程指标

- 首次响应时间。
- 平均响应时间。
- 有效跟进次数。
- 下一步动作明确率。
- 需求字段完整率。
- 报价前需求确认率。
- 商机停滞时间。

### 15.3 结果指标

- 线索转商机率。
- 商机成交率。
- 成交金额。
- 回款金额。
- 平均客单价。
- 平均成交周期。
- 折扣率。
- 退款和投诉率。
- 复购和转介绍率。

### 15.4 AI 指标

- 阶段识别准确率。
- 意向识别准确率。
- 异议识别召回率。
- 回复建议采用率。
- 销售修改率。
- AI 建议带来的转化提升。
- 错误事实率。
- 不合规建议率。
- 自动回复转人工率。

---

## 十六、权限、隐私与合规

这是系统能否商业化的核心，不是附加功能。

### 16.1 基本原则

- 员工对采集范围和用途知情并授权。
- 企业有明确的数据管理制度。
- 客户隐私按适用法律和业务要求处理。
- 只采集业务所需内容。
- 敏感字段加密保存。
- 原始聊天和 AI 结论都必须有访问权限。
- 所有查看、导出和修改操作保留审计日志。

### 16.2 权限模型

- 销售只能查看自己的客户和会话。
- 主管只能查看授权团队。
- 培训人员优先查看脱敏案例。
- 模型训练只使用获得授权的数据集。
- 管理员也不能默认查看全部原始聊天，应按职责授权。

### 16.3 数据脱敏

用于培训、分析或模型训练前，处理：

- 姓名。
- 手机号。
- 微信号。
- 身份证件。
- 地址。
- 银行和支付信息。
- 合同敏感字段。
- 企业机密。

### 16.4 AI 销售红线

AI 不得：

- 虚构产品能力。
- 虚构客户案例。
- 擅自承诺价格和折扣。
- 擅自承诺合同条款。
- 制造虚假稀缺或虚假身份。
- 发送骚扰、歧视或违法内容。
- 未经允许处理或泄露客户敏感信息。

---

## 十七、部署建议

### 17.1 验证阶段

- 单机 PostgreSQL。
- 本地 Ollama + bge-m3。
- 1～3 个销售账号。
- 每日离线同步。
- 只做复盘和建议，不自动回复。

### 17.2 团队试点阶段

- 10～30 个销售账号。
- 中央 PostgreSQL。
- 每台销售设备部署采集代理。
- 消息加密传输。
- 小时级同步。
- 接入 CRM、订单和回款。
- 上线主管工作台和训练系统。

### 17.3 生产平台阶段

- 多租户架构。
- 消息队列和异步任务。
- 对象存储。
- 模型服务集群。
- 权限、审计和数据生命周期管理。
- 监控、告警、备份和灾难恢复。
- 官方接口和合规采集通道优先。

---

## 十八、推荐技术架构

| 模块 | 推荐技术 |
|---|---|
| 管理后台 | React / Next.js 或现有团队熟悉的前端框架 |
| API 服务 | Python FastAPI |
| 业务数据库 | PostgreSQL 17 |
| 向量检索 | pgvector，规模扩大后评估专用向量库 |
| 消息队列 | Redis Streams、RabbitMQ 或 Kafka |
| 异步任务 | Celery、RQ 或 Temporal |
| 对象存储 | S3 兼容存储或 MinIO |
| 本地向量 | bge-m3 |
| 语音转写 | 本地 Whisper 或合规云 ASR |
| 文档解析 | 独立文档解析服务 |
| 模型层 | 可切换的本地模型和云模型网关 |
| 监控 | Prometheus + Grafana 或等价方案 |
| 权限 | RBAC + 数据范围权限 + 审计日志 |

---

## 十九、实施路线图

### 第一阶段：销售分析最小可用产品

目标：证明聊天数据能解释销售结果。

功能：

1. 支持 3～5 名销售。
2. 建立销售、微信账号、客户和商机模型。
3. 接入订单和成交结果。
4. 自动识别需求、异议、阶段和待办。
5. 生成销售个人和团队报告。
6. 对比高成交与普通销售。
7. 人工审核首批优秀策略和话术。

成功标准：

- 客户身份匹配率达到可用水平。
- 商机与聊天关联准确。
- AI 销售阶段识别可被主管接受。
- 能发现至少 3～5 个可验证的优秀销售模式。

### 第二阶段：培训对练

1. 建立产品和案例知识库。
2. 建立场景话术库。
3. 建立 AI 客户角色。
4. 上线模拟对练和自动评分。
5. 将培训成绩与真实销售效果关联。

### 第三阶段：销售 Copilot

1. 实时或小时级同步。
2. 推荐下一步动作。
3. 推荐回复、案例和资料。
4. 销售人工确认后发送。
5. 统计建议采用率和成交影响。

### 第四阶段：受控 AI 销售

1. 只开放低风险场景自动回复。
2. 建立价格、承诺和合规策略引擎。
3. 建立人工接管机制。
4. 持续进行 A/B 测试。
5. 达到业务和合规标准后逐步扩大范围。

---

## 二十、下一步最优先工作

下一步不应立即训练“全自动 AI 销售”，而应先完成以下基础工作：

### 优先级一：定义业务数据

- 选择首个试点产品。
- 确定试点销售人员。
- 获取销售、客户、订单和回款数据。
- 定义成交和失败标准。
- 定义销售阶段。

### 优先级二：建立销售数据模型

- 多销售账号。
- 客户统一身份。
- 商机和订单关联。
- 消息证据链。
- 权限和审计。

### 优先级三：建立第一版分析

- 客户需求。
- 意向等级。
- 异议类型。
- 当前阶段。
- 下一步动作。
- 销售过程评分。

### 优先级四：分析优秀销售

- 选取高成交销售。
- 建立可比对照组。
- 按产品、客户类型和线索来源校正。
- 提炼策略而不是只摘录句子。
- 由销售主管审核。

### 优先级五：上线培训对练

- 从最常见的 10 个销售场景开始。
- 每个场景准备优秀案例和失败案例。
- 建立明确评分规则。
- 用真实销售结果验证训练效果。

---

## 二十一、核心结论

这个系统的核心竞争力不是“获取微信聊天记录”，而是将以下数据真正连接起来：

```text
客户是谁
+ 客户需要什么
+ 销售做了什么
+ 客户如何回应
+ 商机如何推进
+ 最终是否成交和回款
```

只有形成这一条完整证据链，系统才能可靠回答：

- 哪些销售方法真正有效。
- 哪些话术适用于什么客户和阶段。
- 新销售缺少什么能力。
- AI 应该采取什么销售策略。
- AI 的建议是否真的提高成交。

推荐产品演进路径：

```text
聊天搜索工具
  → 销售过程分析系统
  → 优秀销售方法知识库
  → 新销售培训对练系统
  → 销售 Copilot
  → 受控高水平 AI 销售
```

> 合规提示：本系统只能处理企业拥有合法处理依据、员工已知情授权、客户隐私得到适当保护的数据。任何自动销售能力都应设置人工接管、事实核验、权限控制、审计记录和合规红线。