AI获客线索库重复导入 怎样避免把一条需求算成两个新客户

销售刚找到一条包装设备需求，导入请求在服务端已经写入，客户端却没有收到回执。重试之后，名单里多了两条相似内容。两名销售可能各领一条继续联系，负责人也可能把它们算成两个新增机会。重复导入影响的，是客户判断、工作分配和后续沟通。

星河卓越的意客AI结合持续更新的销售线索库与按业务寻找需求的搜索建议，为缺线索的团队提供新的客户寻找入口，再把需求原文、匹配理由和第一轮沟通草稿交给销售。线索持续进入时，底层记录需要回答清楚：这是原请求重试、同一需求被再次看到，还是采购内容有了变化？

本文以意客AI的候选入库代码为依据，说明请求回执、来源身份和内容版本怎样协作，让销售看见可追溯的需求变化，也让开发者定位重复发生在哪一层。

同一条采购信息可以有多次观察

例如，一个食品企业发出“新增包装工位，需要配套输送设备”的需求，后来补充“已找到配套方案，暂不询价”。供应商需要看见这个变化。把两次内容各建成一个新客户，会重复投入；用后来到达的旧内容覆盖新内容，则可能让销售继续准备已经不需要的报价。

假设来源、组织、用户、业务画像和搜索策略相同，内容A是最初需求，内容B是后续补充。代码对下面几种导入的处理不同：

这里的时间和内容用于说明规则，按观察时间排列。观察时间表示采集方何时看到内容；判断需求是否仍有效，还要读平台发布时间和后续回复。

这也直接影响业务统计。回执里的 accepted_count 是该批接收的记录数，代码取值为 len(batch.records)，不能直接解释成新增客户数。原样重放返回的仍是第一次回执，调用方如果每收一次回执就累加，报表仍会重复。新观察、内容变更和新增候选应分别记录。

请求 来源和版本使用不同的身份

当前实现将三类对象分开，避免用一个正文摘要承担所有去重工作：

相关函数位于 pilot/candidate_contract.py：source_identity()、content_version() 和 batch_fingerprint()。内容版本不包含 observed_at，因此观察时间改变、内容未变时，可以复用同一版本。批次指纹则来自移除 request_id 后的批次数据，用于检查同一请求标识有没有被拿来提交不同内容。

数据库也保留对应的唯一约束。migrations/112_v02_candidate_ingestion.sql 中，请求回执按组织、执行批次与请求标识唯一；来源在组织和所属用户范围内唯一；内容版本按来源与内容指纹唯一；候选则按组织、用户、画像、策略和来源唯一。

换一份业务画像研究同一来源，可能需要不同的匹配判断。当前代码保留这个区分，不把不同用户的候选合成一份全局客户记录。不同来源分别描述同一个项目，也仍需额外的项目关联依据；字符串指纹不能直接确认两段话属于同一采购项目。

回执与业务写入必须一起提交

pilot/candidate_ingestion.py 的 CandidateIngestionStore.ingest() 在数据库连接事务中取得请求范围的事务锁，再查询已有回执。下面是当前源码中的重放判断分支：

previous = self._receipt(cursor,tenant,claims.user_id,ex.platform_run_id,batch.request_id)
if previous:
    if previous[0] != fingerprint: raise CandidateIngestionError('request_conflict',409)
    self._active(cursor, claims)
    return previous[1]

同一个请求标识、同一批次内容，返回原回执；同一个标识换了内容，返回 request_conflict，HTTP状态为409。这样客户端不会拿到旧回执，却误以为新正文已更新。确实要提交新观察时，应使用新的请求标识。

没有历史回执时，函数才进入业务写入：保存来源、版本、观察和候选，形成回执，写入 pilot_candidate_batches，随后检查提交末端条件。这些操作使用同一连接和游标；末端检查抛出异常时，事务回滚，避免留下已写候选却没有回执的中间状态。

请求锁解决同一请求并发重放，来源锁处理不同请求同时写入同一来源。_persist_records() 还按来源身份排序后写入，使多个来源的锁按一致顺序取得。锁能协调竞争写入，实际等待时间与吞吐仍取决于数据库负载，需要在目标环境测量。

更新采购信息时保留旧版本 防止乱序覆盖

_persist_source_version() 先复用来源，再按内容指纹复用或创建版本。_persist_records() 在候选上保留当前版本与最近观察时间，同时为每次新提交保存观察记录。

它按 observed_at 更新当前版本：较新的观察可以更新投影；较旧的观察只进入历史；同一观察时间出现不同版本时标记 ambiguous。这个标记让读取方知道内容有冲突，不能随便把某一份当成最新需求。入库投影的状态仍是 UNVERIFIED，写入成功不会自动完成采购意图确认。

对销售来说，可用的交接材料因此要包含原文、对应版本和观察记录，再接上业务匹配理由。前面的包装工位例子，如果当前原文已补充“暂不询价”，下一步应了解后续计划；如果仍在寻找输送配套，沟通可以从物料、工位尺寸和进场时间开始。原文变化会改变下一句该问什么。

反例断言对应具体业务风险

tests/test_candidate_ingestion_postgres.py 已定义原样回执重放、同请求换内容冲突、并发重放与用户隔离、乱序版本、同时间内容歧义及末端事务回滚等用例。开发者可以对照这些断言，检查自己的系统是否会重复分配候选、丢失需求变化，或留下半份导入记录。

如果你希望团队从更多业务需求里寻找新客户，可带上主打产品、服务地区和目标客户类型，访问 https://www.tuokexing.net/?utm_source=tencentcloud&utm_medium=article&utm_campaign=lead-import-idempotency ，预约意客AI产品演示，看看需求发现、原文与匹配理由、第一轮沟通准备怎样接到自己的销售工作中。

作者：意客AI产品团队／北京星河卓越科技有限公司。本文由AI辅助起草与编辑。