最危险的不是 AI 说错，而是同一动作做两遍
员工点了一次“生成并发送”，页面卡住，他不知道是否成功，于是又点了一次。或者 AI 已经调用了邮件系统，返回结果时网络中断，平台以为失败，自动重试。最终客户收到两封通知，销售重复跟进，财务产生两条记录。问题看起来像模型不稳定，实际是工作流没有定义重复执行的后果。
企业 AI 一旦从生成文字进入建单、发信、改状态、写回 CRM 等动作，就不能只讨论提示词和模型。每一步都要问：任务的唯一身份是什么，什么时候算开始，什么时候算成功，失败后能不能安全重试，已经成功的请求再次到来时系统应该返回什么。
先给每个业务任务一个稳定编号
幂等设计的起点是任务编号。用户发起一次业务动作时，系统生成一个可追踪的任务 ID，并把客户、业务对象、动作类型和创建时间关联起来。后续重试使用同一个编号，而不是每次都新建一条完全陌生的请求。这样系统才有机会判断“这是继续执行，还是新的业务意图”。
编号不能只存在日志里。任务记录至少要能关联输入摘要、目标系统、当前状态、最后一次尝试和最终结果。对于同一客户同一业务对象的动作，还要根据业务规则判断是否允许短时间内再次执行。某些任务可以重复生成草稿，某些任务只能发一次通知，不能用一套规则覆盖全部。
- 为业务动作生成唯一任务 ID，并贯穿所有系统调用。
- 把已提交、执行中、成功、失败和需人工确认区分开。
- 按动作风险决定重复请求是返回结果、排队还是拒绝。
状态要比“成功或失败”更细
网络超时不等于业务失败。系统可能已经完成写回，只是响应没有回来；AI 生成完成也不等于邮件已经发送；接口返回成功也不等于下游业务真正落账。企业 AI 需要把状态拆开，例如待执行、已调用、待确认、已完成、可重试和人工核对，才能避免盲目重跑。
对员工来说，状态必须能看懂。页面不能只显示“系统异常”，而应该说明“正在确认是否已发送，请勿重复点击”或“生成完成，等待负责人确认”。清楚的状态提示本身就是控制重复操作的一部分，不能把所有责任推给用户。
高风险动作要把幂等边界交给业务确认
对于发消息、改合同状态、提交采购、扣减库存等动作，系统应先判断是否已经存在相同任务的成功记录。若存在，就返回原结果或提供查看链接；若无法确认，就进入人工核对，而不是再执行一次。哪些动作可以自动重试、哪些必须人工确认，要由业务负责人和系统人员共同确定。
幂等不意味着所有错误都能自动解决。外部系统没有查询接口、第三方返回不明确、业务对象发生变化时，仍然需要人工介入。企业 AI 的交付文档要把这些例外写出来，让运行人员知道什么时候等待、什么时候查询、什么时候停止。
验收要主动制造重复和中断
上线前至少测试四种情况：用户连续点击两次、调用超时后自动重试、下游已经成功但上游没收到响应、任务运行到一半服务重启。每种情况都要检查客户是否收到重复通知、系统是否产生重复记录、任务状态是否可解释，以及人工能否找到原始任务。
验收结果不要只写“接口正常”。要保留任务编号、状态变化和处理结果，作为以后排查的样本。AI 工作流真正进入生产，不是完成一次演示，而是在重复、延迟和不确定响应出现时，仍然不会把业务动作无意执行两遍。
交付文档中还要写清重试责任。系统可以自动重试多少次，超过次数由谁检查，员工看到“待确认”时不能做什么，哪些外部动作需要联系对接方核对。把这些规则放进日常操作手册，才能避免项目上线后所有异常都回到开发人员身上。
对于可以安全重复的动作，也要记录重复次数和原因。连续重试可能说明下游接口变慢、任务输入不完整或用户误操作，不能只把它当成系统自愈。运行一段时间后，团队可以按任务类型回看这些记录，优先修复最常出现的重复来源。
要点总结
- 凡是会写回业务系统、改变状态或产生外部影响的动作，都应考虑重复执行。
- 先判断原任务是否已完成，不能把超时直接等同于失败。
- 需要业务负责人共同确定哪些动作可重试、哪些动作必须人工确认。
参考来源说明
本文围绕“AI 工作流重复执行两次，客户收到两封通知：企业交付要先做幂等设计”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。