从 WhatsApp/微信聊天到销售记忆：AI 为什么要先做硬事实台账

聊天摘要不是销售事实

很多 AI 销售工具处理 WhatsApp 或微信聊天时，会直接做一件事：把最近消息摘要成"客户意向"。

这听起来很高效，但对销售系统来说很危险。

聊天记录里的关键线索常常不是一句完整的话，而是散落在上下文里的硬事实：

• 客户问了哪个型号；
• 提到什么尺寸、材料、功率或配置；
• 是否谈到价格、折扣、付款方式；
• 是否发过图纸、照片、PI、装箱或安装资料；
• 是经销商、终端客户，还是渠道冲突中的第三方；
• 哪些内容只是客户问过，哪些已经被我方确认。

如果 AI 只给一句"客户有采购意向"，后面写入 KnowSales 或 CRM 时就会丢掉最值钱的部分。

正确流程：先逐聊天历史，再硬事实台账

更稳的做法是把聊天处理分成三步：

逐聊天历史 -> hard-fact ledger -> 审核稿 / 写入计划 -> KnowSales

第一步不是看候选摘要，也不是看搜索片段，而是回到逐聊天历史。尤其是批量处理时，session list、candidate TSV、signal scan snippet 都只能作为候选层，不能直接变成销售结论。

第二步建立 hard-fact ledger。它不是作文，而是一张硬事实表，至少要覆盖或明确排除这些字段：

字段	为什么重要
金额 / 折扣	影响报价、利润和审批
型号 / 配置	决定技术适配和后续报价
付款条件	决定商务风险
PI / 发货 / 交期	决定订单状态和履约风险
安装 / license / service issue	决定售后和技术支持边界
产品参数 / 附件	决定是否需要工程复核
dealer / direct / reseller / channel conflict	决定跟进策略和渠道风险

第三步才是生成审核稿或写入计划。只有用户确认后，才把对应内容写入 KnowSales。

每条事实都要有身份标签

hard-fact ledger 还有一个关键字段：事实来源状态。

同样一句话，含义可能完全不同：

标记	含义
customer_asked	客户提出过，还未被确认
team_confirmed	我方已经确认
needs_engineering	需要工程或产品团队确认
historical_record	来自历史记录
third_party_claim	第三方说法
unclear	还不清楚

没有这个标记，AI 很容易把"客户问能不能支持某个规格"写成"客户确认要这个规格"，也可能把"第三方说法"写成公司事实。

这就是很多 CRM 脏数据的来源。

写入 KnowSales 时，分层比速度重要

确认后的材料也不能一股脑写进客户 profile。

更稳的落点是：

• 一次聊天、邮件、电话、订单、付款、售后事件 -> 写成 customer activity；
• 稳定公司背景、联系人、长期需求 -> 写进 customer profile；
• 可复用产品知识、FAQ、异议话术、需求边界 -> 写进产品知识或话术岛；
• 仍需人工确认的内容 -> 留在审核稿，不写入 durable memory。

SalesFlow 的 communication-summary 工作流适合承担这一步：它先区分事实与判断，再输出候选写入计划。KnowSales 负责长期记忆，但入口必须守住证据边界。

这类文章为什么适合 SEO

很多团队正在搜索"WhatsApp 销售线索提取""微信聊天 CRM 自动归档""AI 分析客户聊天记录"。

真正的问题不是"能不能提取"，而是：

• 提取出来的内容是否可追溯；
• 是否能区分客户事实和销售判断；
• 是否能防止客户身份错配；
• 是否能写到正确的知识层。

这正是 KnowSales 和 SalesFlow 的组合价值：不是做更花哨的摘要，而是把销售聊天变成可验证、可确认、可复用的销售记忆。

小结

WhatsApp 和微信聊天里有大量销售金矿，但不能直接把摘要当事实写进系统。

先从逐聊天历史建立 hard-fact ledger，再生成审核稿和写入计划，最后按 profile / activity / product knowledge / tracker 分层落地。这样 AI 才不是在制造更快的脏数据，而是在帮团队建立真正可复利的销售记忆。