AI 结果写入 CRM 怎么避免重复记录？先设计可重试的交接

先确认接口的重试语义

AI 结果写入 CRM 时，超时不等于写入失败。请求可能已经到达系统并创建记录，只是调用方没有及时收到回应。若流程把“没收到回应”直接理解成“没有写入”，再次提交就可能生成重复记录。上线前先约定如何识别同一项业务任务、如何查询已有结果以及什么情况下允许重试。

第一步定义业务唯一键。它应来自能区分同一业务事件的稳定信息，例如内部任务编号，或经业务方确认的组合字段。不要简单拿 AI 生成的摘要文本做唯一键：同一事实每次措辞都可能不同；也不要用姓名、电话等个人字段拼成键，除非该用途经过授权且设计上确有必要。若没有可靠标识，应先让人工确认新记录还是已有记录。

把结果未知和写入失败分开

第二步把写入状态拆细。最少区分“待发送”“已发送待确认”“已确认写入”“明确失败”“结果未知”。网络超时、连接中断和服务端报错的语义并不总相同。状态未知时先查目标系统是否已存在对应业务键，再决定继续、人工处理或重试。错误提示要被保留下来供排查，但避免把不必要的客户全文复制到日志里。

第三步核对 API 对重试的支持。RFC 9110 对 HTTP 方法定义幂等语义，但这并不意味着所有第三方接口或自定义写入端点都有相同行为。确认目标 API 是否提供幂等键、唯一约束、请求查询或安全的 upsert 操作；把适用条件记到实施说明中。如果 API 没有可用机制，可以在本方先按业务键做去重与状态锁，但仍需验证并发请求、超时和部分成功的处理。

第四步演练容易重复的路径：同一事件被队列重复投递、用户连续点击、系统在写入成功后丢失响应、执行重试与首次请求并发。每个场景都记录应该生成几条记录、状态如何变化、如何查到最终结果。演练用获准的测试空间和非生产数据；不要在真实客户记录上制造重复操作来验证。

设计重复识别与人工处置

最后设计人工核对队列。若系统无法确认目标记录状态，将任务交给能访问 CRM 的负责人，并给出业务键、请求时间、错误状态和查询入口。重试应该是有条件且有上限的动作，而不是无休止循环。对于发送邮件、触发合同或删除记录等实际副作用，先核实动作是否已经执行，再决定恢复路径。

发布前逐项确认：唯一键是否稳定且合规；目标 API 的重试约定是否查过官方文档；未知状态是否能查询；重复触发是否有拦截；并发行为是否测试；人工队列是否有负责人；以及测试是否只在批准环境进行。确认不了的项目先留在人工步骤中。幂等设计减少重复风险，但不能替代业务校验、权限控制和异常接手。