wxsales/MVP.md

微信营销管理系统 MVP 方案

文档日期：2026-07-14 定位：最小可用产品，验证"微信聊天数据 → 客户与沟通记录 → 成交关联"的核心闭环

---

一、MVP 目标

用最简路径完成一件事：把每个销售的微信聊天采集到中央数据库，AI 分析出客户和沟通记录，成交数据手动录入，形成"沟通→成交"的证据链。

不做的事：

• 不做培训对练
• 不做 AI 自动回复
• 不做多租户
• 不做实时同步
• 不做复杂权限体系

---

二、MVP 范围

2.1 核心流程

销售设备本机采集微信数据
  → 传输到中央数据库
  → AI 识别客户、提取沟通记录
  → 销售手动录入成交数据
  → 关联聊天与成交
  → 基础报表

2.2 支持规模

• 3～5 名销售
• 每人 1 个微信号
• 每日离线同步（复用现有 launchd 机制）
• 单台中央 PostgreSQL

---

三、系统架构

销售设备 A (macOS)          销售设备 B (macOS)         销售设备 C (macOS)
  本机微信数据库采集          本机微信数据库采集          本机微信数据库采集
  采集代理脚本                采集代理脚本                采集代理脚本
        │                          │                          │
        └──────────────┬───────────┘──────────────────────────┘
                       ▼
               中央 PostgreSQL
            (wechat_sales_db)
                       │
                       ▼
               AI 分析服务
            (客户识别 + 沟通摘要)
                       │
                       ▼
               Web 管理后台
        (客户列表 / 聊天记录 / 成交录入 / 报表)

---

四、数据模型

MVP 只建 6 张核心表，不搞复杂实体关系。

4.1 salesperson — 销售人员

CREATE TABLE salesperson (
    id          SERIAL PRIMARY KEY,
    name        TEXT NOT NULL,
    team        TEXT,
    wx_account  TEXT NOT NULL,      -- 绑定的微信号
    device_id   TEXT,                -- 采集设备标识
    created_at  TIMESTAMPTZ DEFAULT now()
);

4.2 contact — 联系人（微信好友）

CREATE TABLE contact (
    id              SERIAL PRIMARY KEY,
    salesperson_id  INT NOT NULL REFERENCES salesperson(id),
    wx_username     TEXT NOT NULL,       -- 微信内部 ID
    nickname        TEXT,                -- 昵称
    remark          TEXT,                -- 备注
    display_name    TEXT,                -- 计算字段：备注优先，其次昵称
    is_group        BOOLEAN DEFAULT FALSE,
    created_at      TIMESTAMPTZ DEFAULT now(),
    UNIQUE(salesperson_id, wx_username)
);

4.3 conversation — 会话

CREATE TABLE conversation (
    id              SERIAL PRIMARY KEY,
    salesperson_id  INT NOT NULL REFERENCES salesperson(id),
    contact_id      INT REFERENCES contact(id),
    wx_chatroom     TEXT,            -- 群聊标识（群聊时用）
    conv_type       TEXT NOT NULL,   -- 'single' | 'group'
    last_synced_at  TIMESTAMPTZ,
    created_at      TIMESTAMPTZ DEFAULT now()
);

4.4 message — 消息

CREATE TABLE message (
    id                  BIGSERIAL PRIMARY KEY,
    salesperson_id      INT NOT NULL REFERENCES salesperson(id),
    conversation_id     INT NOT NULL REFERENCES conversation(id),
    sender_wx_username  TEXT NOT NULL,
    sender_display_name TEXT,
    message_type        TEXT NOT NULL,       -- text/image/voice/video/file/emoji/link/quote
    raw_content         TEXT,
    normalized_content  TEXT,                -- 清洗后可读内容
    created_at          TIMESTAMPTZ NOT NULL,
    source_shard        TEXT,
    source_table        TEXT,
    source_local_id     BIGINT,
    UNIQUE(source_shard, source_table, source_local_id)
);
CREATE INDEX idx_message_conv_time ON message(conversation_id, created_at);
CREATE INDEX idx_message_salesperson ON message(salesperson_id);

4.5 customer — 客户（AI 从联系人中识别）

CREATE TABLE customer (
    id              SERIAL PRIMARY KEY,
    salesperson_id  INT NOT NULL REFERENCES salesperson(id),
    contact_id      INT NOT NULL REFERENCES contact(id),
    customer_name   TEXT,                -- AI 识别的客户名称
    industry        TEXT,                -- AI 推断行业
    intent_level    TEXT,                -- high/medium/low/none
    key_needs       TEXT[],              -- AI 提取的关键需求
    last_analysis   TIMESTAMPTZ,
    created_at      TIMESTAMPTZ DEFAULT now(),
    UNIQUE(salesperson_id, contact_id)
);

4.6 deal — 成交记录（手动录入）

CREATE TABLE deal (
    id              SERIAL PRIMARY KEY,
    salesperson_id  INT NOT NULL REFERENCES salesperson(id),
    customer_id     INT REFERENCES customer(id),
    contact_id      INT REFERENCES contact(id),
    product_name    TEXT NOT NULL,
    amount          NUMERIC(12,2) NOT NULL,
    deal_date       DATE NOT NULL,
    status          TEXT NOT NULL DEFAULT 'closed',  -- closed/pending/refunded
    notes           TEXT,
    created_at      TIMESTAMPTZ DEFAULT now()
);

---

五、采集方案

5.1 复用现有能力

当前单机系统已具备：

• macOS 微信 4.x 数据库定位与解密
• 联系人、会话、消息解析与标准化
• 每日 launchd 定时同步
• 增量去重（UNIQUE(source_shard, source_table, source_local_id)）

MVP 阶段直接复用，只需扩展为多设备。

5.2 多设备采集流程

每台销售设备部署相同的采集代理：

1. launchd 每天 05:00 触发
2. 退出微信 → 复制数据库副本 → 重启微信
3. 解密数据库副本
4. 解析联系人、会话、消息
5. 通过 SSH/HTTP 将增量数据推送到中央服务器
6. 中央服务器写入 PostgreSQL
7. 清理临时文件

5.3 中央服务器接收

中央服务器提供一个简单的接收接口：

POST /api/sync
{
  "salesperson_id": 1,
  "device_id": "macbook-abc123",
  "contacts": [...],
  "conversations": [...],
  "messages": [...]
}

或者更简单：每台设备直接配置 PostgreSQL 远程连接，采集脚本直接写入中央库。MVP 阶段建议后者，省去中间服务。

5.4 数据隔离

每条数据都带 salesperson_id，确保销售之间数据隔离。查询时按销售过滤。

---

六、AI 分析

6.1 分析目标

MVP 只做两件事：

1. 客户识别：从联系人中筛选出真实客户（排除微商、广告、纯社交联系人）
2. 沟通摘要：对每个客户会话生成结构化摘要

6.2 客户识别

对每个联系人，取最近 N 条消息，调用 LLM 判断：

{
  "is_customer": true,
  "customer_name": "张总",
  "industry": "餐饮",
  "intent_level": "medium",
  "key_needs": ["收银系统", "会员管理"],
  "reason": "多次询问产品价格和功能，提到门店运营需求"
}

筛选规则：

• 有超过 5 条对话的联系人
• 消息内容涉及产品咨询、价格、合作等关键词
• 排除纯群聊通知、广告推送类联系人

6.3 沟通摘要

对每个客户会话，按时间窗口（如最近 7 天或全部）生成：

{
  "summary": "客户最初咨询收银系统价格，对比了竞品后关注会员管理功能，销售安排了产品演示，客户表示需要和合伙人商量。",
  "stage": "产品演示",
  "objections": ["价格偏高", "需要合伙人确认"],
  "next_action": "等待客户反馈，建议3天后跟进",
  "last_contact_date": "2026-07-12"
}

6.4 模型选择

• 优先使用现有 Ollama 本地模型（如 qwen2.5）降低成本
• 消息量大时分批处理，每次传入不超过 50 条消息
• 分析结果存入 customer 表，不单独建表

---

七、成交数据录入

7.1 录入方式

Web 后台提供简单表单：

• 选择销售
• 选择客户（从 AI 识别的客户列表中选）
• 填写产品名称、金额、成交日期
• 可选填写备注

7.2 关联逻辑

成交记录通过 contact_id 自动关联到对应的微信会话。这样就能看到：

• 某个成交客户的所有聊天记录
• 从首次接触到成交的完整沟通时间线
• 成交前的关键沟通节点

---

八、Web 管理后台

8.1 技术选型

模块	选型
前端	React + TailwindCSS
后端	Python FastAPI
数据库	PostgreSQL 17
部署	单机部署，Nginx 反向代理

8.2 页面清单

MVP 只做 5 个页面：

首页 / 仪表盘

• 今日新增消息数
• 活跃客户数
• 本月成交金额
• 各销售消息量对比

销售列表

• 每个销售的消息量、客户数、成交金额
• 最后同步时间
• 同步状态

客户列表

• 按销售筛选
• 按意向等级筛选
• 显示客户名称、行业、意向、最后沟通时间
• 点击进入客户详情

客户详情

• 客户基本信息（AI 识别结果）
• 完整聊天记录（时间线展示，复用现有搜索页面能力）
• AI 沟通摘要
• 关联的成交记录

成交录入

• 简单表单
• 成交列表（可按销售、日期、产品筛选）

---

九、实施计划

第 1 周：数据采集多设备化

• 创建中央 PostgreSQL 数据库 wechat_sales_db
• 建表（6 张核心表）
• 改造现有采集脚本，支持写入中央库（增加 salesperson_id 字段）
• 在 2 台设备上部署采集代理并验证

第 2 周：AI 分析 + Web 后台

• 搭建 FastAPI 后端骨架
• 实现客户识别分析脚本
• 实现沟通摘要分析脚本
• 搭建 React 前端骨架
• 完成客户列表和客户详情页

第 3 周：成交录入 + 报表

• 成交录入表单
• 成交列表页
• 仪表盘基础数据展示
• 聊天记录页面集成

第 4 周：联调 + 试点

• 3～5 名销售实际接入
• 录入真实成交数据
• 验证"聊天→客户→成交"关联准确性
• 收集反馈，修复问题

---

十、成功标准

MVP 上线后需验证：

1. 采集完整性：每个销售每天的消息采集率 > 95%
2. 客户识别准确率：AI 识别的客户中，> 80% 被销售确认是真实客户
3. 成交关联可用：手动录入的成交记录能正确关联到对应聊天记录
4. 基础报表可用：能看到每个销售的消息量、客户数、成交金额
5. 闭环验证：至少能从 1 个成交客户回溯完整沟通链路

---

十一、与完整方案的关系

MVP 是总体方案"第一阶段"的精简版，主要区别：

维度	MVP	完整方案第一阶段
数据模型	6 张表	20+ 张表
成交数据	手动录入	接入 CRM/订单系统
AI 分析	客户识别 + 沟通摘要	阶段识别 + 意向评分 + 异议分析 + 待办
权限	按 salesperson_id 简单隔离	RBAC + 数据范围权限
同步	每日离线	每日 + 小时级
报表	基础统计	销售漏斗 + 能力雷达 + 话术分析
部署	单机	单机但面向多设备

MVP 验证通过后，按完整方案路线图逐步扩展。