AI定制开发合同与验收：源码、评测和运维边界

一、把业务范围、AI效果和资产交付分开约定

AI软件项目至少需要三类技术附件：业务功能与接口范围、效果评测方法、资产与运行交接清单。功能附件写用户角色、输入、输出、审批和系统动作；评测附件写样本、判定规则和复测条件；交接附件写代码、配置、部署及维护资料。这里只讨论工程验收安排，不替代针对具体合同的法律审查。

“智能化完成”“回答准确”“系统稳定”都需要转换为可检查条件。例如知识回答应区分有依据、依据冲突、无答案和越权问题；有依据的任务核对结论与引用，无答案的任务核对拒答或转人工。模型能力受资料与场景影响，技术附件既不能承诺所有问题绝对正确，也不能用这种不确定性免除约定的工程责任。

二、评测集需要版本、分母和争议处理办法

为每条验收任务保留编号、授权输入、预期行为、判定依据和业务确认人，并记录模型、提示、知识索引与规则版本。调试集和验收集分开管理，修改样本或判定规则要留下理由。若外部模型升级或知识资料变化，双方先确定复测范围，不能拿不同输入和不同版本的结果直接比较。

以质检为演算示例：人工复核确认20条实际违规，系统报出18条疑似违规，其中15条确认有效，则精确率为15/18，召回率为15/20。剩余3条是误报，5条是漏报；这些不同风险不能用一个含糊的“准确率”掩盖。实际样本量、业务分布与门槛需要另行确认，示例数字不是推荐阈值或知华项目成果。

需要把上述方法落实到对话审核时，可查看AI客服质检与人工复核，分别约定证据定位、规则覆盖、误判申诉和复核记录。

三、模型答对之外，还要验收系统不会做错事

应用接入订单、客户或财务系统后，应单独验证权限不足、重复提交、接口超时和人工驳回。模型给出正确建议，不等于系统可以绕过审批写入正式记录。测试执行账号是否遵守对象级权限、同一任务重试是否只生成一条业务记录、外部服务不可用时是否能暂停并通知责任人。

例如AI生成报价草稿的项目，验收既要检查品名与金额来源，也要检查草稿不能未经审核发送、客户切换后不会带出其他客户数据。敏感字段应在日志中按约定保护，人工撤销和后续补偿要能追踪。这样才能避免模型测试通过，但整套软件在真实权限和异常条件下仍无法上线。

四、以独立复建验证交付，而不是只收到压缩包

资产清单应写明仓库与版本、依赖及许可、数据库迁移、配置项、知识处理规则、提示、工具定义、评测样本、部署和恢复文档。外部模型服务、商业组件或受限数据不能含糊承诺全部转让，应注明客户获得的使用范围、账号责任和替代条件。真实密钥通过授权渠道交接，不写入公开文档。

让接手人员在约定的新环境按文档完成构建、部署、关键任务复测与恢复演练。只有原开发者的电脑能够运行，说明交付仍缺少隐含依赖。验收记录列出已通过项、遗留缺陷、影响程度与处置计划；无法立即完成的内容需要明确双方接受的限制，不能用一份打包文件代替交接结论。

五、区分缺陷、新需求和外部变化

同一需求版本下未满足已约定行为，通常应进入缺陷处理；新增岗位、字段或审批链则需要评估范围变更；模型、原系统接口或平台政策变化还需要检查外部依赖责任。分类应回到具体技术附件和合同约定，而不是仅凭哪一方先提出问题。每次处理保留复现输入、版本、影响和确认结果。

阶段付款可以对应评审通过、试点验证、生产上线和独立交接等可复核成果。持续运营另外明确监控、知识维护、效果回归、故障响应与费用范围。不要承诺模型永不变化，也不要把上线后的所有质量问题都自动归为收费新需求；双方需要能依据记录判断问题属于哪一层。

如需先确定各阶段应包含哪些投入，可返回企业AI定制开发预算指南核对研发、运行和内部配合三类成本，再据此细化技术附件。

接管验收：让新负责人实际完成一次运行与恢复

交接附件按资产、版本、控制主体、存放位置、使用授权、更新人和核验方式列项。源码只是一项；提示模板、知识原文与重建规则、工具契约、固定任务集、部署配置、监控和费用也要可查。供应商通用框架或受第三方许可限制的内容单独注明使用与迁移条件，不笼统写“全部资产永久归客户”。密钥通过约定安全方式处理，不放在公开仓库、演示截图或普通交接附件中。

在授权测试环境由接管人员按文档完成构建、知识更新与任务测试，并处理一次超时、状态不明或部分失败。业务负责人查看目标系统实际记录，不只看对话截图。无法重建、缺少账号授权或评测不一致时形成阻塞清单，补齐后重新确认。正式切换先确认连续运行、费用和故障责任，再撤回原人员权限并轮换相关凭据，保留协议约定的支持窗口。此处是验收建议，不代表某个项目已经完成演练。