大模型接入业务系统，验收不能只看能否返回答案

先定义一次业务任务的开始和结束

演示页面能生成一段文字，并不代表业务系统已经完成任务。以“收到客户资料后生成跟进摘要”为例，需要明确资料从哪里来、谁能读取、摘要由谁确认，以及最终保存到哪一条业务记录。

接口集成的交付应围绕这条任务链来描述。模型、页面、工作流和已有系统分别承担哪一步，失败后由谁接管，都应能在流程图和实际界面里找到。

把输入输出约定成可检查的格式

• 输入：必填字段、文件类型、长度上限和空值处理。
• 输出：字段名称、数据类型、允许的枚举以及必须保留的原文依据。
• 状态：等待、处理中、需人工处理、完成和失败分别如何呈现。
• 身份：操作人、任务编号、关联的业务记录和创建时间。

业务系统要对返回结果进行校验。缺少必要字段或格式不符合约定时，任务应进入明确的异常流程，而不是显示成功后再让使用者寻找丢失的信息。

权限与使用范围要按角色测试

区分读取资料、调用模型、确认结果和写回系统的权限。用普通业务账号和管理账号分别走同一流程，核对可读取的范围和可执行的动作。

连接器能访问什么，不能只由页面按钮决定。服务器端也应检查权限，并保留必要的操作记录。接口凭证由受控配置提供，避免放入公开网页或日志正文。

超时、限流和重复操作必须进入验收

Microsoft 的重试模式文档提醒：需要区分可能恢复的临时故障与持续故障，并考虑最大尝试次数及重复执行的副作用。本文把这些原则转成业务验收问题，不预设某个固定的重试次数适合所有系统。

• 模型超时：页面是否停止等待并显示任务状态，后台是否仍在处理。
• 调用受限：是否按策略延后处理，是否存在总次数和等待上限。
• 重复点击：同一任务是否被识别，是否重复写入业务记录。
• 回执丢失：目标系统可能已完成时，能否先查询再重试。
• 持续失败：能否暂停相关任务并交给负责人，而不是无限重复请求。

费用和故障交接也属于交付

至少能按任务或业务场景查看调用量、失败次数和重试消耗。试点预算应同时考虑模型调用、相关服务、系统部署和维护，具体费用以实际选用的服务和合同约定为准。

交接材料应包含配置位置、权限负责人、日志入口、故障判断步骤、回退方法和支持范围。让业务人员知道“这个任务卡住后去哪里看、联系谁、是否需要重新提交”。

用一套任务样本做最终核对

选择正常任务、缺少信息的任务、无权访问的任务以及模拟超时或重复提交的任务，逐项记录预期结果、实际结果和遗留问题。恢复操作也要验证，不能只留下“支持重试”的说明。

咨询时可提供现有系统名称、可用接口说明、一个典型业务流程和脱敏样本。先确认读取与写入的范围，再讨论 AI 应用开发、模型接入、部署和维护的具体分工。

参考资料与范围

• Microsoft Learn：Retry pattern：重试需要考虑临时与持续故障、尝试上限和幂等性；回执丢失时重复执行可能产生副作用。

以上资料用于说明技术路径。本文的实施步骤和验收建议为编辑整理，不是第三方客户效果证明。