AI获客线索反复出现？如何保留需求变化，减少重复开发

销售最缺的是新的客户开发对象。一个AI获客工具，如果每天报回同一批旧内容，销售仍要自己逐条翻；如果把修改过的需求直接过滤掉，又可能错过一次值得重新沟通的采购变化。

两位同事对照纸面业务流程讨论

业务讨论场景（AI编辑插图）。

200件变成2000件，要保留同一来源的变化

例如，同一条加工需求上午写“需要200件铝合金外壳”，后来改成“需要2000件”。来源还是那一条，内容却变了。接单团队可能要重新考虑设备排期、批量加工和报价方式，原先为小批量准备的沟通也需要调整。

如果只按正文去重，两个文本会变成两条孤立线索；如果只按来源去重，后来的2000件又可能被忽略。比较合理的记录方式，是保留一个来源、保存两个内容版本，让销售看见这次要求发生了什么变化。

下面以意客AI的来源与入库代码为例，沿着同一条需求的两次更新，看看记录应怎样变化。

来源回答在哪里，版本回答写了什么

source_identity把平台、记录类型、来源标识和评论标识纳入身份摘要。来源优先使用external_source_id，没有时使用public_url；PUBLIC_WEB还包含网址的origin。这套身份用于识别来源条目，不是在识别一个自然人或企业。

content_version则对公开网址、标题、作者公开标识、正文、发布时间和父内容求摘要；存在source_context或page_metadata时也将它们纳入。正文改成2000件会得到不同版本，网址等参与字段变化也可能形成新版本，不能把每次版本变化都解释成采购数量变化。

identity = source_identity(record, platform)
digest = content_version(record)
scope = (tenant,user,profile_version_id,strategy_version_id,source_id)

上面是源码中的三处关键赋值，节选编排。source_id与version_id分别持久化；candidate投影使用最后一行的业务范围查找，因此同一来源在同租户、用户、画像版本和策略版本下复用研究记录。画像或策略换了，研究范围也随之改变。

同一来源 S1
├─ 内容版本 V1：200件  ← 10:00 / 10:05观察
└─ 内容版本 V2：2000件 ← 10:10观察
同一业务范围的研究记录 C1 → 当前 V2

观察留历史，当前记录不跟着乱序消息倒退

一次读取还有observed_at。它是采集记录上报的观察时间，与客户内容里的published_at是两个字段。旧帖子今天被读到，可以有今天的观察时间，不能据此向销售展示成今天刚发布的需求。

入库会为每条记录保存观察，把它连到来源、版本和candidate。新观察时间较晚时，投影改用该观察及其内容版本；时间较早时，观察仍然保留，但当前投影不回退到旧版本。下面将这些分支放在同一来源、同一业务范围内比较。

表里的“10:08”是较早的观察，不是较早到达服务端。如果只按入库先后覆盖，迟到的旧消息会把2000件重新变成200件。源码比较观察时间，是为了让乱序到达与内容变化分开处理。

同一时间的矛盾内容，要留下冲突信号

当观察时间相同、内容版本不同，且当前未标记冲突时，代码设置ambiguous并增加revision，没有随意挑一个版本覆盖。后续较新观察到来时，可以更新当前版本并清除ambiguous。这里处理的是系统收到的记录矛盾，不能自动判断哪一次表达更符合客户真实意图。

对获客界面，这意味着值得把当前原文、观察时间和变化线索放在一起。销售读到2000件后，可以先询问数量是否已确定，再讨论交期；内容矛盾时，应先看回来源。

还有一个边界不能混淆：两个平台各出现同一家企业，不会因为上面的来源摘要就自动成为一个客户。这里复用的是同来源、同业务范围的研究记录，跨平台客户合并需要另外的身份依据。

这段实现给销售线索库留下了持续研究的材料：同一条需求变了，团队能回到当前原文重新准备沟通，而不必把它当作另一个新客户。对开发团队，来源、内容版本和业务记录分开存，才有机会同时处理重复读取与需求更新。

如果你的团队正在为“下一批客户去哪里找”发愁，可以带上主营产品或服务，访问意客AI官网，预约产品演示，看看从业务搜索到需求原文、联系准备的一次完整操作。

作者：意客AI产品团队／北京星河卓越科技有限公司

本文由AI辅助起草与编辑。