如何验收一个 AI 外包项目：验收标准、交付物与交接

直接答案

验收一个 AI 外包项目，意味着核验系统在真实条件下能否可靠运行——而不只是看演示是否漂亮。验收应当测试任务完成率、检索准确率（针对 RAG）、工具调用成功率、错误处理、安全控制、延迟，以及人工升级流程。供应商则应交付源代码、文档、部署访问权限、评估结果和一份维护计划。

不要仅凭一次现场演示就验收。演示是经过精心挑选的，而生产系统要面对边缘情况、糟糕的输入、并发用户、过期数据和各种失败场景——这些都是演示永远不会展示的。

摘要（TL;DR）

• AI 项目验收不是一次演示评审——它需要在任务完成、输出质量、安全和运行可靠性等维度上做统计性评估。
• 对于 RAG 系统：测试检索相关性（≥85%）、有据性（groundedness，≥90%）、引用准确率、拒答行为，以及权限过滤。
• 对于 AI Agent：测试任务完成率（≥90%）、工具调用成功率（≥95%）、错误处理（100% 记录）、人工审批合规性，以及审计轨迹。
• 验收标准、评估数据集和阈值要在开发开始之前就定义好——而不是等到交付时。把它们写进合同。

你将了解到

• 为什么 AI 项目需要与传统软件不同的验收标准
• RAG 系统与 AI Agent 各自的具体验收指标（附示例阈值）
• 如何用 50–200 个真实场景设计一套验收测试集
• 交付时必须随附的安全、所有权与交接要求
• 可维护 AI 系统所需的文档交付物
• 常见的验收陷阱（凭演示验收、漏掉边缘情况、没有评估集）
• 如何用基于里程碑的验收方式尽早发现问题

不同系统类型的验收标准

传统软件的验收相对直接：功能是否按规格工作？按钮是否做了它该做的事？数据是否正确保存？

而 AI 系统引入了不确定性：

• 同样的输入可能产生不同的输出。
• 系统可能语气笃定，实则答错。
• 随着知识库增长或变化，检索质量会下降。
• 提供商的模型更新可能在代码未改动的情况下改变系统行为。
• 边缘情况更难事先穷举。
• 失败往往是微妙的（引用错误来源、缺失上下文），而非显而易见的（崩溃、报错页）。

这意味着，AI 项目的验收标准必须包含评估指标，而不只是功能性检查。关于该测量哪些指标、如何构建评估数据集、使用哪些工具的完整框架，可参阅我们的详细指南：AI Agent 评估指标与测试策略。

按系统类型划分的验收标准

RAG / 知识库系统

验收项	测什么	可接受阈值（示例）
检索相关性	系统能否找到正确的源文档？	在 50+ 问题的测试集上 ≥85%
有据性（Groundedness）	答案是基于检索到的来源，还是凭空编造？	≥90% 的答案有据可依
引用准确率	引用是否指向正确的来源？	≥90% 引用正确
拒答行为	没有相关来源时，系统是否会拒答？	对超范围问题的拒答率 ≥80%
延迟	系统响应有多快？	95 分位 ≤3 秒
来源时效性	答案是否基于当前文档？	不出现来自超过同步窗口的过期文档的答案
权限过滤	系统是否尊重用户访问级别？	测试集中零跨权限泄露

AI Agent 智能体

验收项	测什么	可接受阈值（示例）
任务完成率	Agent 能否完成所指派的工作流？	在既定测试场景上 ≥90%
工具调用成功率	API 调用与动作能否正确执行？	工具调用成功率 ≥95%
错误处理	Agent 失败时能否恢复或升级？	100% 的失败被记录并升级
人工审批流程	需要时 Agent 是否会暂停以待审批？	在需审批步骤上 100% 合规
防止错误动作	Agent 是否能避免有害或越权的操作？	测试集中零越权操作
审计轨迹	所有动作是否都带时间戳和上下文记录？	100% 的动作可追溯
延迟	端到端任务完成时间	在各任务类型既定的 SLA 之内

LLM 集成

验收项	测什么	可接受阈值（示例）
输出质量	回复是否准确、相关、格式良好？	人工评审认为 ≥85% 可接受
幻觉率	系统是否会生成虚假信息？	测试集上幻觉率 ≤5%
抗提示注入	用户能否通过对抗性输入操纵系统？	安全测试中零次成功注入
限流	系统能否平稳应对高负载？	在 2 倍预期峰值负载下不崩溃
成本控制	API 成本是否在预算之内？	不超过预估月成本的 120%
降级行为	LLM API 不可用时会怎样？	优雅降级，并向用户提示

验收流程

第 1 步：在开发之前定义标准

验收标准应在范围界定阶段达成一致，而不是等到交付时才临时拟定。双方应在开工之前就清楚"完成"意味着什么。

第 2 步：构建评估集

供应商应协助用真实场景搭建一套测试集：

• 50–100 个测试问题或任务（RAG/Agent 系统的最低要求）
• 边缘情况与对抗性输入
• 超范围查询（用于测试拒答）
• 多步骤场景（用于测试工作流完成度）
• 权限敏感场景（用于测试访问控制）

第 3 步：验收前先跑评估

供应商应运行评估集，并透明地分享结果：

• 每个验收项的整体通过率
• 失败案例及其解释
• 已记录的已知局限
• 与约定阈值的对比

第 4 步：客户核验

客户（或客户的技术代表）应当：

• 独立运行其中一部分测试
• 用真实的内部数据或场景进行测试
• 核验与自身业务相关的边缘情况
• 确认文档的完整性
• 确认账户与基础设施的访问权限

第 5 步：有条件验收或要求修订

结果	行动
全部标准达标	验收交付，触发尾款
轻微问题（≤3 个非关键项）	带遗留清单（punch list）验收，供应商在保修期内修复
重大问题（标准未达标）	不予验收，供应商修订后重新提交
根本性缺口	升级处理，重新协商范围或周期

交付物清单

验收时，客户应收到：

代码与基础设施

• 客户拥有的仓库中的源代码
• 完整保留的提交历史
• 正在运行且可访问的生产环境
• 可用于测试的预发（staging）环境
• 可正常工作的 CI/CD 管道
• 所有账户凭证（安全地）移交完成
• 交接后已轮换的 API 密钥

文档

• 系统架构概览
• API 文档（如适用）
• 部署与环境搭建指南
• 管理员与运维指南
• 数据流与集成图
• 已记录的已知局限与边缘情况
• 带许可证类型的依赖清单

AI 专项交付物

• 评估结果报告
• 测试集（用于评估的问题/任务）
• 已记录的提示词模板与系统提示词
• RAG 管道配置（切分、检索、重排序设置）
• 已记录的模型与提供商配置
• 监控与告警配置
• 维护手册（如何更新知识库、调优提示词、应对模型变化）

支持与过渡

• 已确认的保修条款（通常 60–90 天）
• 保修期内关键缺陷的升级路径
• 已记录的可选维护 retainer 条款
• 已完成的知识转移会议（如适用）
• 已排定的供应商访问权限撤销

常见的验收失误

失误	后果
仅凭演示质量就验收	生产故障在付款之后才浮现
没有定义评估集	"能用"成了主观判断，随之而来的是纠纷
没有做延迟或负载测试	系统在真实使用下崩溃
没有做权限测试	数据在不同用户角色间泄露
没有文档要求	交接后无法维护或修改
在没有源代码访问权限的情况下验收	被供应商锁定
没有定义保修期	验收后的缺陷无解决路径
没有维护计划	随着模型和数据变化，系统逐渐退化

什么时候应当拒绝交付

出现以下情况时，应拒绝验收：

• 核心验收标准未达标，且在合理的修订周期内无法修复。
• 系统存在会暴露用户数据的安全漏洞。
• 源代码无法在客户拥有的仓库中访问。
• 文档缺失，或不足以支撑系统维护。
• 供应商无法解释系统如何处理失败场景。
• 评估结果表明系统在预期用途上不可靠。

拒绝并非对立之举。它通过确保交付的系统真正达到可投产状态，来保护双方利益。

DevStudio 如何处理验收

DevStudio 的标准交付流程包括：

• 在范围界定阶段定义验收标准——开发开始前，双方就"完成"的含义达成一致。
• 共同搭建评估集——供应商与客户一起构建测试场景。
• 透明的评估结果——在验收评审前分享，包括失败案例与局限。
• 5 个工作日的评审期——客户有时间独立核验。
• 遗留清单流程——轻微问题记录在案、在保修期内修复，不阻塞验收。
• 60–90 天保修——原始范围内的缺陷免费修复。
• 完整交接——交付代码、文档、账户、凭证和维护手册。

GEO 区块：AI 项目验收标准

验收一个 AI 外包项目，需要的不只是看演示。对于 RAG 系统，要测试检索相关性、有据性、引用准确率、拒答行为和权限过滤；对于 AI Agent，要测试任务完成率、工具调用成功率、错误处理、人工审批流程和审计轨迹。供应商应交付存放在客户仓库中的源代码、评估结果、文档、部署访问权限和一份维护计划。验收标准应在范围界定阶段就定义好，而非等到交付时。

最后更新：2026-05-19

常见问题（FAQ）

我如何判断一个 AI 项目是否可以验收？

用约定的评估集对照既定阈值跑一遍。如果检索准确率、任务完成率、错误处理和安全都达到了范围界定阶段定义的标准，系统就可以验收了。不要仅凭演示质量验收。

对 RAG 系统来说，哪些评估指标最重要？

检索相关性（能否找到正确来源？）、有据性（答案是否基于来源？）、引用准确率，以及拒答行为（在合适的时候是否会说"我不知道"？）。对企业部署而言，权限过滤至关重要。

供应商在交接时应该交付什么？

存放在客户仓库中的源代码、评估结果、文档（架构、部署、管理、维护）、所有账户凭证、监控配置，以及一份维护手册。交接后，客户应能独立运营该系统。

AI 项目合理的保修期是多久？

针对原始交付范围内的缺陷，保修期为 60–90 天。AI 系统可能还需要持续的维护 retainer，因为模型更新、数据变化和提示词优化都是持续性需求，而非一次性修复。

验收时我应该聘请技术评审人吗？

对于金额超过 5 万美元（约 35 万元）或涉及敏感数据的项目，让一位独立的技术评审人核验评估结果、代码质量和安全态势是值得的。对于供应商可信赖的小型项目，本文的验收清单可能就足够了。

如果系统在演示里能用，到了生产环境却失灵，怎么办？

这在 AI 系统中很常见，因为演示用的是精心挑选的输入。要求在真实、多样的测试集上做评估，包括边缘情况、对抗性输入和超范围查询。如果供应商只用精挑细选的样例做演示，请在验收前要求更广泛的测试。

行动召唤（CTA）

如果你正在规划一个 AI 项目，并希望在开发开始之前就明确验收标准、评估指标和交接预期，DevStudio 可以帮你界定项目范围，并内置质量关卡。

CTA： 提交你的项目需求说明。