系统整合 · 实作指南
AI 工作流重试，如何避免多建一张订单
用操作纪录区分业务意图与网络重试，避免把重送当成新订单。
先问这是不是同一项业务意图
假设一个订单接收试点：背景工作已建立订单，但回应途中断线；再次执行的模型又建议新增，客户其实只要求一张。建议在呼叫模型之前，先为这项业务操作建立识别码，重试沿用同一码。不能只凭相同文字或金额判断重复，因为客户也可能真的要求两张内容相同的订单。操作意图应来自已确认的请求，而不是由模型重新猜测。
用纪录表，不靠对话记忆
操作纪录可保存所属公司、意图识别码、已验证参数、处理状态与外部纪录编号，状态例如准备、提交、确认或待核对。可行时，识别码保留和本地资料修改应在同一交易内完成。同一码却带来不同参数时应暂停调查，不能默认後来的内容正确。纪录不需要保存密码或整段客户私隐资料；保留足以核对业务结果的资讯即可。
流程一览
不确定时先核对外部结果
若目标系统支援幂等请求，应按其合约传送操作码，并核对保留期限。若不支援，先使用稳定外部参考号查询结果，再决定是否重送。这不等於所有系统都能保证只执行一次；没有唯一参考或查询能力的目标，可能仍须人工确认。员工画面要显示待核对，避免另一位同事看到逾时便另外新增一次。
刻意测试成功後断线
验收时刻意模拟写入成功後断线、两位员工同时提交、延迟重送，以及同一码参数被改动。评估的不是成功回应数，而是有否多建业务纪录、还有多少操作无法确认。AWS 与 Stripe 的文件提供幂等设计背景，本文的纪录表和介面安排则是实作建议。每项待核对操作都应有负责人与处理期限，才不会长期积压。
一页验收纪录
订单试点可保存一页验收表，列出操作身份、首次提交、模拟故障、外部订单实际数量和核对负责人。与客户一起检查结果，不只交一份技术测试报告。另加一项反例：客户确实要两张完全相同订单时，系统必须两张都接受，不能为减少重复而误删合法业务。这能把技术去重与真实意图分开，并让双方理解例外处理的界线。
来源与延伸阅读
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。