AI 项目验收标准，不应该只写功能完成

先说结论。

这是一份 AI 项目验收工作坊草案，面向准备从原型进入试点或生产，并能同时安排业务、技术、数据与安全责任人的团队。材料齐备时，可用 1 个工作日形成七层验收表初稿；依赖复杂或角色较多时安排 2 个工作日。产出是样本口径、阻断项、责任人和证据清单，不是“项目已通过”的结论。

AI 项目只写“支持上传文档、支持问答、支持 Agent 调用工具”，验收时一定会争议。功能完成只能证明入口存在，不能证明结果可靠、系统稳定、权限正确、成本可控，也不能证明出错时有人接住。

验收标准应在开发前与样本、环境、角色和口径一起定义。

适合谁与不适合谁

这套验收专题适合准备从原型进入试点或生产的 AI 项目团队。前述 1 至 2 个工作日是工作坊安排，不是对所有项目的完成时长承诺；开始前必须备齐当前范围、流程图、去敏样本、测试环境说明、依赖清单和各层责任人。缺少材料时，工作坊只能登记待办，不能假装完成标准。不适合一次性课堂 Demo，也不适合没有业务验收人、数据授权和运行责任人的项目。

功能验收只解决“有没有”

传统功能清单仍然必要：账号能否登录、文档能否上传、流程能否触发、结果能否写回。但 AI 输出具有概率性，同一功能可能在不同输入上表现不同。

因此每个功能后都要补“什么输入、期望什么结果、允许什么偏差、失败如何处理”。没有样本和判断规则，“问答功能完成”无法执行验收。

功能是验收的一层，不是全部。

效果验收要基于任务和样本

先定义任务类型，例如事实问答、字段提取、分类、摘要或草稿。不同任务不能共用一个模糊的“准确率”。

评估样本应来自合法、去敏的真实场景，覆盖正常、边界、缺失、冲突和范围外输入。每项指标说明计算方式、人工判断角色和无法判断如何记录。

若项目尚无数据，不编造阈值。可以先把建立基线和标注规则作为阶段性交付。

稳定性验收要主动制造失败

测试模型超时、外部接口错误、重复请求、超长输入、格式错误、审批超时和系统重启。检查是否有限重试、幂等、状态恢复、告警和人工降级。

仅在理想网络下跑成功路径，不能证明生产可用。关键写操作要验证“结果不确定”场景：请求超时后先查询外部状态，避免重复执行。

验收环境、依赖版本和配置应被记录，避免换环境后无法复现。

成本验收要定义计量和上限

记录每类任务的模型用量、工具调用、存储和第三方服务消耗。实际价格以供应方当前账单为准，验收更应关注用量与预算控制，而不是写死永久单价。

需要测试异常输入是否造成无限循环、上下文膨胀或重复调用。设置单任务、单用户或周期预算上限，并定义触发后的降级方式。

成本不能只在月底看总账，要能追到任务类型和流程版本。

权限验收要覆盖越权和数据隔离

测试不同角色能看哪些知识、能调用哪些工具、能批准哪些动作。普通用户不能通过提示内容绕过后端权限，也不能因为 Agent 代为调用就获得更高权限。

权限测试应包含反向用例：访问无权文档、修改他人记录、请求导出敏感内容、伪造审批人。系统要拒绝并留下安全日志。

高风险动作在工具调用前重新校验身份和权限。

日志验收要能重建一次任务

从最终输出反查触发入口、输入版本、模型与提示版本、检索来源、工具参数摘要、状态变化、审批记录和执行结果。

同时检查日志是否泄露密钥、敏感原文和不必要的个人数据。日志访问与保留也要有权限和周期。

如果发生错误却只能看到“调用失败”，就不满足可维护验收。

人工兜底本身也要验收

测试拒答、请求补充、转人工、审批、修改、退回、超时和恢复。确认责任人能收到任务，看到足够上下文，并能回到原流程。

人工兜底不是页面上的“联系客服”。它需要队列、角色、响应方式和结果回写。若人工修改无法记录，系统也失去持续评估入口。

边界是低风险内部草稿可以抽样复核，不必每条审批；风险分级应先定义。

维护验收要交付系统之外的材料

至少包括部署与回滚说明、配置和密钥位置、监控告警、知识更新流程、评估集维护、已知限制、第三方依赖和责任人。

模型、文档和业务规则变化后，谁触发回归测试，谁批准发布，也要写清。没有运行手册的系统，即使当前能用，也不能算完整交付。

常见误区会让验收失去约束

验收还要区分阻断项和改进项。越权访问、不可逆重复执行、敏感信息泄露和无法回退通常应阻断上线；摘要措辞、低风险界面细节和部分长尾样本可以进入已知问题清单。两类问题混在一起，会出现严重风险被“总体通过率”掩盖的情况。

每个阻断项要有复测记录和批准人。改进项则要写负责人、优先级和是否影响当前使用范围，不能用一句“后续优化”无限延期。

一是项目结束才讨论指标。二是只测开发者准备的成功样本。三是用一次现场演示替代回归测试。四是把所有错误归为模型问题。五是合同写“达到行业领先”，却没有计算口径。

反例是一次性内部实验，可以缩减稳定性和维护要求，但必须标注结果不进入生产决策。

验收清单可以按七层组织

1. 功能：入口、主路径和输出是否存在。
2. 效果：任务样本与判断规则是否通过。
3. 稳定：超时、重复、重启和依赖失败是否可恢复。
4. 成本：用量可追踪，预算有上限。
5. 权限：身份、数据和工具动作不越权。
6. 日志与人工：任务可追溯，风险可接管。
7. 维护：文档、监控、回归和责任人完整。

最终交付应包括版本化样本集、七层验收表、阻断项与改进项记录、复测证据、签字角色、运行手册和下次回归触发条件。仅有一份“功能完成”表，不构成 AI 项目验收包。

FAQ

所有层都必须达到同一个分数吗？ 不应该。不同任务用不同口径，越权、敏感信息泄露和不可逆重复执行等阻断项也不能被平均分抵消。

没有真实数据能否先验收？ 只能验收技术环境与流程骨架。业务效果应标为待验证，并把数据采集和标注作为下一阶段交付。

谁负责最终签字？ 业务、技术、数据或知识所有者以及安全责任人分别确认自己的边界。项目经理负责汇总，不代替专业角色判断。

验收通过后还要做什么？ 按文档、模型、提示、权限和业务规则变化触发回归；历史失败样本必须保留在回归集中。

方法的可信边界

本文提供的是待验证的工作坊结构，不提供虚假的统一阈值，也不声称已经在未披露项目中获得验证。正式作为服务页面使用前，应补充一份脱敏验收表样例，标明它来自合成演练还是真实项目、版本日期和删除字段；若没有真实履历证据，就持续保留“草案”说明。

每一条标准都必须回到项目自己的样本、环境、证据与责任人。涉及安全、法律或行业规范时，应由有权限的专业角色批准。

下一步把现有合同里的每个“支持”改成一条可执行测试。谁提供样本、在哪个环境、谁判断、失败如何记录，都写进去。验收标准越早具体，项目后期越少靠印象争论。