架构专题

销售数据怎么自动采集？三层管道设计让信息自己流进来

Soloharness 团队 · 2026 年 5 月 28 日

所有销售AI系统的第一个瓶颈都不是模型能力，而是数据从哪来。

你搭了一套精妙的MEDDIC评分系统、一套漂亮的Pipeline看板、一套自动推送的晨间待办——然后发现数据源头是空的。销售不填CRM、不写拜访记录、不更新客户状态。你设计的再好，没有数据喂进来，系统就是个空壳。

传统解法是"加考核"——不填CRM扣绩效。结果销售为了应付考核填一堆垃圾数据，比不填还糟。

我们的解法：三层采集管道，让数据自己流进来，销售零录入。

第一层：通讯层——聊天记录自动归档

数据采集的第一层解决的是最基础的问题：销售和客户聊了什么，系统要知道。

实现方式：每个销售bot绑定一个企微机器人，企微的聊天记录通过webhook自动同步到服务器。同步后的原始记录经过格式清洗（去掉表情包、系统消息、撤回通知），归档为Markdown格式的沟通日志，存放在该客户对应的MD文件中。

关键设计：一个客户一个MD文件。不是按时间线堆在一起，而是每个客户独立一份。文件名是客户ID，内容按时间倒序排列——最新的沟通在最上面。当LLM需要分析这个客户时，读一个文件就够了。

通讯层不需要销售做任何事。聊天发生、记录被抓取、文件被更新——整个过程对销售透明。唯一需要销售确认的是：这条消息确实是对这个客户说的（而不是群里的无关消息）。这一步通过LLM做初步过滤，准确率约95%，剩余5%在晨间推送时由销售顺手修正。

通讯层解决了"有什么"，但没有解决"意味着什么"。第二层是用LLM从沟通日志中提取结构化事实。

提取的事实类型包括：

提取结果写入两个地方：一是客户MD文件的结构化头部（YAML front matter），方便后续Gate-check直接读取；二是tasks.db的对应字段，供看板和推送使用。

提取不是一次性的。每次通讯层有新的沟通记录进来，事实层都会增量提取——只处理新增部分，和已有事实做合并去重。这保证了结构化数据始终是最新状态，而不需要销售手动更新。

前两层解决了"客户说了什么"和"这意味着什么"，第三层解决的是"所以销售该做什么"。

结构层的输入是事实层提取的结构化数据，输出是三样东西：

第一，Gate进度更新。gate-check技能夜间运行，对照六步法21道通关凭证，结合事实层提取的最新信息，判断当前客户在哪个Gate、缺什么要素。结果写入tasks.db的gate字段。

第二，MEDDIC评分刷新。基于事实层的决策链、预算、竞品信息，实时更新六要素评分。评分变化超过阈值时自动生成待办——比如EB从"已接触"变为"14天未接触"，触发一条"重新触达EB"的待办。

第三，待办推送到销售。task_push_cron.py每天07:40从tasks.db查询所有待办，按优先级+金额排序，通过企微推送给每个销售。销售看到的不是原始数据，而是经过排序、带有推荐动作的行动指南。

三层不是独立运行的，而是形成一条连续的数据流：

通讯层 → 事实层：通讯层每次有新记录，触发事实层增量提取。这个触发不是实时的（不需要每次聊天都跑一次LLM），而是批量的——每天夜间02:00-02:30，集中处理当天所有新增沟通记录。

事实层 → 结构层：事实层提取完结构化数据后，gate-check在02:30-02:57读取这些数据，更新Gate进度和MEDDIC评分。结构层的输出在07:40推送给销售。

结构层 → 销售 → 通讯层：销售收到推送后采取行动（拜访客户、打电话、发方案），新的沟通产生新的聊天记录，回到通讯层。这是一个闭环。

有人会问：为什么不直接从聊天记录一步到位提取所有需要的信息？

因为每一层的容错需求不同。通讯层的容错要求最低——只要记录不丢就行，格式不完美可以后补。事实层的容错要求中等——提取错误可以被结构层的交叉验证发现并修正。结构层的容错要求最高——推送给销售的待办必须准确，否则销售会失去对系统的信任。

三层分离意味着每一层可以独立优化、独立重试、独立监控。通讯层出问题不影响已有事实；事实层提取偏差不影响已有Gate进度。解耦是可靠性的前提。

在一个10人销售团队的实际部署中，三层管道上线后第一个月，销售CRM录入量从平均每人每天3.2条降到0.4条（仅修正AI误判时的主动录入），而系统可用的结构化数据量反而增加了4倍——因为聊天记录里有大量销售不会主动录入的细节（客户提到的决策链、竞品、时间节点），LLM都提取了出来。

如果你也在搭建销售 AI 系统，soloharness.com 可能值得看看。