AI 项目的验收标准怎么写

“效果不错”“准确率达到 90%”都不是完整的验收标准。要让甲乙双方在同一组条件下重做并得到可核对的结论，还要写清系统版本、测试样本、指标算法、通过门槛、严重错误的处理方式，以及验收记录由谁签字。下面用一家虚构家居公司的售后问答助手，把一句模糊需求改成一份可执行的验收表。

文中的样本数量、比例和响应时间都是演示值，不是行业标准或通用保证。真实门槛应由双方结合业务风险、合同范围和部署环境事先确定。

先把需求缩成一个可验收的范围

假设“栖木家居工作室”要交付一个售后政策问答助手。第一版只读取双方确认的 80 篇帮助文档，为客服草拟答案并附来源；查不到依据时要说明资料不足并转人工。它不查订单、不读取客户账户，也不能批准退款或承诺赔偿。

这段范围说明先排除了几个争议：验收的是哪种助手、允许读什么资料、输出给谁、哪些动作不能自动做。若交付还包括网页入口、权限、部署脚本、操作手册或培训，也要逐项列为交付物；“系统已上线”不能代替这些清单。

财政部《政府采购需求管理办法》适用于政府采购货物、工程和服务项目。其第二十四条要求政府采购履约验收方案明确主体、时间、方式、程序、内容和验收标准，并覆盖技术和商务要求；标准应包含客观、量化指标，主观事项可通过问卷等方式转成可核对的标准。这是政府采购范围内的要求，不能直接说成所有民营项目的法定义务。私营项目应以实际合同约定为准，必要时让法律专业人士审阅。查看《政府采购需求管理办法》

每条标准都补齐六个要素

1. **对象和版本：**交付哪个功能、模型或系统版本、知识库快照和配置。提示词、检索参数或模型升级可能改变输出，改动后要按约定决定是否重测。
2. **前置条件：**测试环境、账号权限、网络、并发数、输入格式和数据范围。不能拿供应商机器上的演示环境，替代合同写明的部署环境。
3. **测试样本：**样本从哪里来、共多少条、每条预期结果由谁确认；冻结后不能临时挑容易通过的题。
4. **指标算法：**说明分子、分母、统计单位，以及“正确”“拒答”“引用有效”分别怎么算。不要只写“准确率”。
5. **门槛和否决项：**哪些指标达到多少算通过，哪些错误不论平均分都必须整改，例如泄露测试数据、编造退款承诺或执行未授权操作。
6. **过程和证据：**谁执行、谁复核、保存哪些日志和输出、失败后修复与复测几轮。涉及个人信息时，用获准的最小化样本，并在验收记录里限制访问和保留范围。

NIST 的 AI 风险管理框架 1.0 是自愿使用的参考框架，不是中国法律。它建议记录测试集、指标和测试工具，在接近实际部署的条件下测量系统表现，并记录适用范围的限制。这能帮助双方补全验收表，但不替双方决定合同门槛。NIST 当前页面说明 1.0 正在修订；引用这一版时，应同时核对后续更新。查看 NIST AI RMF 1.0 · 查看版本更新状态

给售后问答助手写一组示例门槛

下表是一份虚构的验收设计。把其中的数字换成双方认可的业务门槛，并将最终版本和测试流程放进合同附件或项目验收方案。

上表的百分比、样本数、并发量和时限只为演示写法。比如知识回答门槛是否设为 90%，要看错误会造成什么后果；退款、资格或安全相关错误通常应单独规定更严格的否决条件，而不是混入平均准确率。

用一份模拟结果练习判定

假定供应商报告：20 条有依据问题答对 18 条，5 条无答案问题全部转人工，P95 为 7.2 秒；但在高风险题中有 1 条编造了“可无条件退款”。前三个指标达到示例门槛，严重错误项没有通过，因此总验收结论仍是不通过。

把这段可复制到 Python 3 运行。它只演示“门槛都要过，严重错误一票否决”的判定逻辑；输入数字是虚构报告，不代表真实 AI 系统测试。

sample = {
    "answerable_correct": 18,
    "answerable_total": 20,
    "unknown_handed_off": 5,
    "unknown_total": 5,
    "critical_errors": 1,
    "p95_seconds": 7.2,
}

checks = [
    ("有依据答案", sample["answerable_correct"] / sample["answerable_total"] >= 0.90, "18/20 ≥ 90%"),
    ("无依据问题转人工", sample["unknown_handed_off"] / sample["unknown_total"] == 1.0, "5/5"),
    ("严重错误", sample["critical_errors"] == 0, "要求 0 次，实际 1 次"),
    ("P95 响应时间", sample["p95_seconds"] <= 8.0, "7.2 秒 ≤ 8 秒"),
]

for name, passed, detail in checks:
    print(f"{name}: {'通过' if passed else '不通过'}（{detail}）")

overall = all(passed for _, passed, _ in checks)
print("总验收：" + ("通过" if overall else "不通过"))
assert overall is False

只有把输入换成项目双方共同确认的原始记录，才是在验收真实交付。对随机生成结果，还需在签约前写明每条跑几次、重复运行如何计分、失败样本能否更换；不写的话，一次偶然通过或失败都容易引发争议。

把验收表放进交付流程

项目与交付范围：
验收版本（程序 / 模型 / 提示词 / 知识库快照）：
验收环境与账号权限：
测试集来源、版本、数量及预期结果确认人：

验收项：
输入条件 / 操作步骤：
预期结果：
指标算法与通过门槛：
严重错误及一票否决条件：
证据记录位置：

执行人和复核人：
验收期限与异议反馈方式：
整改期限、复测次数和复测规则：
验收结论、未通过项及签署人：
变更范围如何确认：

需求还没定时，先签范围清楚的小试点；验收集和门槛没确认前，不要把“提效 30%”写成结果保证。验收不是替模型能力背书，也不自动判断合同是否有效。它的作用是让双方按约定判断：交付了什么、证据在哪里、未通过时下一步怎么处理。

**本篇实测范围：**用本机 Python 标准库执行了一次虚构结果的验收判定，验证严重错误会覆盖平均指标；未接入真实助手、未使用客户数据，也未验证供应商系统、真实并发性能或合同适用性。示例门槛应由项目双方与相关负责人确认。

封面插图由本机 AI 生成，标题由代码排版，并标注“AI生成封面”。