# 微信营销管理系统总体设计与实施方案 > 文档日期：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 销售 ``` > 合规提示：本系统只能处理企业拥有合法处理依据、员工已知情授权、客户隐私得到适当保护的数据。任何自动销售能力都应设置人工接管、事实核验、权限控制、审计记录和合规红线。