接入 ERP 或 CRM 的目标，是让一项任务在两个系统之间有明确的输入、结果和责任。上线前，应能回答：AI 获得了哪些数据，实际执行了什么，当前状态是否可信，遇到异常由谁处理。
从一条具体流程画出边界
下面是售后工单创建的设计示例：客服提交描述，助手整理待填写字段，系统读取订单资料，客服确认后创建工单，最后返回工单编号。模型可以帮助理解描述，但订单是否存在、用户是否有权限、字段是否有效，需要由接口与业务规则核对。
如果订单信息缺失，应返回待补充状态；如果创建结果不明确，应进入核对状态。不能因为助手生成了一句“已创建”，就把任务标记为成功。
接口开工前准备表
| 项目 | 需要双方确认的内容 |
|---|---|
| 业务对象 | 客户、订单或工单的唯一编号及关联关系 |
| 字段规则 | 必填、枚举、格式、金额单位和时间口径 |
| 访问方式 | 测试环境、认证、用户范围和网络条件 |
| 运行限制 | 超时、调用频率、分页及批量操作约束 |
| 状态查询 | 如何确认任务已执行、失败或仍在处理 |
| 故障协作 | 两侧联系人、日志定位方式和维护时间 |
已有 API 不代表接入工作已经完成。接口版本、字段含义和测试数据仍需要联调；没有开放接口时，先确认可用的文件交换或其他授权方式，再决定是否适合本期实施。
超时不能简单当作失败重做
创建工单请求发出后，如果连接中断，业务系统可能已经完成创建。再次盲目提交会带来重复工单。AWS 的幂等 API 工程说明讨论了用唯一请求标识处理重复请求的方法。
项目中需要核对目标 API 是否支持幂等，以及标识的有效期和参数约束。不支持时，应评估任务状态存储、业务编号查重或人工核对，不能仅在客户端生成一个编号就认为已经防止重复操作。
验收完整状态，而不只看成功响应
安排正常创建、字段错误、身份过期、重复请求、请求超时及部分成功等测试。每类结果都应在界面上给出可理解状态，并能够通过任务编号关联两侧记录。
跨系统操作无法全部完成时，应说明哪些动作已经发生。恢复方案可能是继续处理、由业务人员修正或执行已定义的补偿步骤；不能承诺所有操作都能自动撤销。