高校AI项目如何编写验收标准？

定义：可复测的验收标准写的是什么

在高校立项、招标和交付语境里，AI项目验收标准是一组能被学校人员当场重跑、能留下证据、能对应到合同条款的测试条目。它描述的是：用谁的账号、在什么环境、输入什么材料、按什么步骤操作、应当看到什么结果、谁判定通过。一条合格条目至少能被另一个没参加演示的人按同样条件复现。

标准的对象通常分成六类：功能、性能、安全、数据、集成、培训。六类可以写进同一张验收条目表，但必须分开判定。功能通过只说明流程走得通；性能通过只说明约定条件下可复测；安全通过只说明越权、出域和注入用例失败并留痕。一类通过不能覆盖另一类失败。采购参数回答“学校要买什么条件”，验收标准回答“交付当天怎样核验这些条件”；二者应对齐，但不能互相替代。参数怎么写成可测试句子，见高校AI采购参数怎么写。

它不是什么

• 它不是到货安装完成、页面能打开就签字。
• 它不是领导观摩、宣传稿或一次生成结果的通过证明。
• 它不是只有供应商操作、学校人员旁观的演示记录。
• 它不是把准确率、并发和安全写在同一句话里，却没有测试集和环境。

可复测标准与建设方案、产品介绍、培训课件可以对照阅读，但职责不同。建设方案回答为什么做、先做哪一场景；产品介绍展示一种实现路径；培训课件教人怎么用；验收标准只保留学校必须核验的条件和失败后的处理。后文提到的校级治理能力，也只作为能力对照，不构成指定品牌或指定产品。

为什么演示通过在高校走不通

学校推进生成式人工智能时，验收现场最容易出现四类同时发生的问题。它们看起来像“已经看过系统”，实际会让合同支付和正式上线同时失去依据。

第一，场景和测试数据没有冻结。验收当天临时找几条制度、几个学生问题，或直接使用厂商自带语料。题目覆盖不全，过期文件和必须拒答的问题没有出现，判定人无法解释“通过”对应哪一版知识。没有双方签字的测试集，效果类指标全部变成无法重跑的印象分。

第二，演示路径被预置。供应商使用自己的高权限账号、已经缓存的知识、已经调好的提示词和不会触发写操作的样例。页面都能点开，成绩更正、发文、推送仍可能被模型直接触发，或者教师无法从回答回到原文。学校人员换一套低权限账号或换一份未入库材料，结果立即不同。

第三，六类条件被捆成一次观摩。主持人走完一轮对话，就把功能、性能、安全、数据、集成和培训一并宣布通过。空载时延被当成高峰性能，演示账号被当成权限模型，签到表被当成学校已具备运维能力。学期评教、论文提交或办事高峰到来时，当初的观摩记录没有任何复测价值。

第四，失败没有闭环。现场出现引用错误、超时或越权提示，却只记在会议纪要里，没有缺陷单、责任方和复测时间。阶段款按“演示完成”支付后，整改变成人情协商。学校真正需要的是可当场重跑的条目、可关闭的缺陷和可演练的试运行，而不是一次无法追溯的通过仪式。

因此，验收标准编写应先回答：试点场景是否冻结、测试数据谁出题谁签字、每条条目由谁操作谁判定、失败后几天复测、试运行怎样才算允许扩大用户。五个问题清楚后，再展开六类条目。先看演示再补标准，几乎总会在支付和上线阶段返工。

实践中还有两类偏差需要在验收准备会上提前排除。一是把招标功能清单原样当成验收表，条目仍是“支持知识库、支持智能体”，现场只能打勾看页面。二是为了赶学期节点，用领导参观代替业务处室出题，造成“看过了但没测过”。纠正这两类偏差不需要先扩预算，需要先补条目表和测试集。参数如何避免倾向性，见高校AI项目怎样避免参数倾向性；条目表和缺陷单框架可从建设与验收资料获取后再按本校场景改写。

五步编写：从场景冻结到试运行口径

智库把验收标准压成五步，是为了让信息化、业务处室、安全和采购能在同一张表上讨论，而不是各写各的章节。五步可以对应合同附件的不同表格，但缺一步就应视为验收设计未完成。

第一步：先固化试点场景和测试数据，双方签字确认

从候选清单中只冻结一到两个高频、责任部门明确、测试数据可授权的闭环，例如制度查询加办事导引，而不是把“校园大脑”一次写进验收范围。测试集由业务部门出题，信息化配合脱敏和编号，安全确认不得含真实敏感原文。双方签字冻结版本、标注规则和正误口径。没有这份冻结记录，后面所有条目都会在现场被改题。

第二步：功能项必须走到人工确认、拒答、引用和日志

功能按真实流程写，不按产品模块写。每条至少覆盖：授权用户登录、提出业务问题或提交办理材料、系统给出可核验输出、该人工确认的步骤实际发生、引用能回到原文、无法支持时拒答、会话日志可按人与时间检索。查询类流程要写引用定位；办理类流程要写回到原系统或人工岗。教师审核知识、辅导员确认推送、教务确认成绩相关答复，都必须出现在条目里，而不是出现在培训PPT里。

第三步：性能项写并发、响应、失败率和测试模型

同时写下并发定义、模型或接口版本、输入输出长度、是否检索或工具调用、运行环境和统计口径。响应区分首字时延和整段完成时间，并写是否允许排队。性能与功能分开记结果。用空载演示代替约定脚本，应视为未测。更换模型后必须按同一脚本复测，不能沿用旧报告。

第四步：安全项包含越权、泄露、提示注入和日志检索

安全条目必须能变成现场动作：学生账号读取教师工作区、低权限角色导出内部字段、提示词诱导出域或绕过拒答、未授权接口被调用。期望结果是失败、拦截并留下可检索日志，而不是“原则上符合等保”。安全失败应停止扩大用户范围，不得用功能演示覆盖。

第五步：培训、文档、账号移交和试运行报告一并列入

学校人员接不住账号、知识更新和日志检索，系统上线后仍不可运营。文档、培训对象、上机抽查、账号移交表、试运行周期和通过标准应与功能、安全、性能并列，作为移交条件。只交安装报告和演示录像，视为验收未完成。

比较：演示通过与条目复测

下表用于验收准备会和现场争议处理，不构成唯一合法文本。学校仍须对照政府采购、合同条款、网络安全、教育数据分类分级和校内验收办法。表中“条目复测”列给出写法方向，具体阈值由学校按试点场景自行测定，本文不填写任何中标额、效果承诺或客户数量。

审查验收方案时，可以把每一条改写成“输入—步骤—期望—环境—责任人”。改写失败的句子，通常就是演示词。改写成功后，现场可以要求换人、换账号、抽题重跑，而不是比较谁的讲解更完整。演示可以用于培训和沟通，不能用于符合性判定。

六类条目：每条怎样写成可复测句子

每条建议固定七个字段：编号、类别、输入、步骤、期望结果、环境、责任人；必要时加证据形式和失败处理。下面按六类给出写法，不给出虚构准确率、并发峰值或客户数量。阈值由学校按试点测定后填入空位，本文只给必须出现的条件。

功能：走完真实业务，而不是走完菜单

输入应是已授权的制度编号、办事问题或脱敏后的办理材料，而不是“随便问一句”。步骤应写清登录角色、进入场景、提交问题、查看引用、触发拒答或转人工、打开日志。期望结果应能被第三人核对：引用指向约定文件的章节或段落；超范围问题给出拒答理由；办理类建议不得直接改库；人工确认节点实际发生。环境写部署位置、知识版本和模型或接口版本。责任人建议业务处室判定对错，信息化确认日志可检索。

功能条目至少应覆盖四类题目：应当正确回答、应当拒答、应当引用、应当转人工。只有成功样例的功能表，等于把演示脚本换了一个名字。

性能：条件写全，数字才有意义

输入是双方确认的压测脚本或等价操作序列。步骤写启动条件、持续时间、观察指标和停止规则。期望结果写约定并发定义下的完成时间、失败率和是否允许排队，而不是“响应迅速”。环境必须同时出现模型或接口版本、输入输出长度、是否检索或工具调用、是否流式返回。责任人由信息化执行或监交，业务确认脚本对应真实场景而不是空载点击。更换模型、量化方式或检索策略后，该组条目全部重测。

安全：用失败证明有效

输入是越权账号、诱导出域的提示、批量导出请求或未授权接口调用。步骤由学校安全或信息化按用例执行，供应商不得替换为“安全介绍”。期望结果是请求失败或被拦截，日志能按人、时间、场景、是否出域检索到该次尝试。环境写统一身份、权限策略版本和网关策略。责任人由网络安全与保密部门判定，业务确认用例没有漏掉本处室的高密级对象。安全项失败，功能项即使全部通过，也不得宣布可以扩大用户。

数据：来源、用途、停用分开写

输入是数据目录中的对象和字段级授权范围。步骤抽查某条知识或某条业务数据能否进入训练、检索或生成，以及停用后是否按约定删除或不可检索。期望结果：未授权全文不能被问答；高密级原文不进入低密级应用；测试集与生产知识版本可区分；学校可按约定格式导出知识、日志和配置。环境写存储位置和备份策略。责任人是数据归口部门加信息化。没有目录就验收向量库，应视为数据项未测。

集成：核对源系统，而不是核对样例库

输入是接口清单中的对象、字段、读写方向和同步频率。步骤从源系统取一条已授权记录，在AI场景中查询或引导办理，再核对一致性；对写操作验证是否回到原系统或人工岗。期望结果：查询与源系统一致；无权限字段不进入提示词或回答；接口中断时降级提示，不得编造课表、成绩或政策条文。环境写联调窗口和回切方式。责任人是源系统主管部门。只展示已经灌好的样例，视为集成未测。

培训：看会不会做，不看有没有来

输入是培训对象名单和必须独立完成的操作清单。步骤抽查业务管理员更新一条知识申请、教师复核一条回答、信息化检索一条日志、值班人员按手册报修或回退。期望结果：指定岗位能在无供应商代操作的情况下完成日常动作；文档包含场景与权限、数据与接口、模型版本、备份恢复、评测集和退出迁移。环境是学校将接手的正式或准生产环境。责任人是场景主责部门和信息化接口人。签到不能关闭培训条目。

编制步骤：输入、角色、动作与输出

下列步骤按时间顺序排列，便于写入项目计划和合同附件目录。角色名称可按学校处室调整，但不能出现“只有供应商、没有校内主责”。

1. 冻结场景、角色和禁止事项

动作：选出可评价试点，写用户角色、禁止事项、是否允许出域和是否允许写操作。输出：场景说明书、责任矩阵和“本期不验收”清单。

2. 编制测试集与条目表

动作：为每条补齐输入、步骤、期望、环境、责任人和证据形式；删除无法对应到流程的模块名。输出：验收条目表和签字确认的测试数据集。

3. 准备缺陷单与分项记录

动作：规定功能、性能、安全、数据、集成、培训分列签字；缺陷单字段固定为现象、重现步骤、对应条目、责任方、时限、复测人。输出：问题缺陷单模板和分项验收记录表。

4. 现场复测与缺陷关闭

动作：按编号重跑；演示脚本只可用于对照，不得替换条目；失败项当日立案。输出：分项结果、缺陷清单和现场证据编号。

5. 试运行、培训抽查与移交

动作：在约定周期内按真实业务使用；抽查培训成果；核对接手文档是否可独立运维。输出：试运行报告、培训抽查记录、账号移交表和是否允许扩大用户的决定。

如果某一步缺少输出物，不要进入下一阶段确认。尤其是没有测试集就宣布效果达标、没有缺陷闭环就支付阶段款、没有培训抽查就撤场，都会在学期中途暴露。

试运行通过标准与缺陷闭环

试运行不是“先用起来再说”，而是正式验收的延续。通过标准必须在进场前写进附件，避免到期后只讨论体感。建议至少写清五件事：周期、纳入用户范围、必测场景和抽测频率、缺陷分级与关闭口径、扩大用户或支付的前提。

试运行应观察什么

必测场景应与冻结的试点一致，不得在试运行中途改成未授权的新业务。观察记录建议按日或按周汇总：真实问题中的拒答是否合理、引用是否仍指向有效文件、接口中断是否降级、权限变更后是否仍能拦住越权、学校人员能否按手册完成知识更新申请和日志检索。AI效果继续绑定同一测试集做抽样复测，而不是用“老师觉得还行”代替。

用户范围应先限制在责任部门明确、能提供判定人的处室。没有主责人的扩大试用，会把缺陷变成无法归口的意见。信息化可以提供平台值班，但不能代替业务判定对错。

缺陷如何分级和关闭

建议至少分三级：不影响试点闭环的一般缺陷、核心场景不可用、安全或数据事件。一般缺陷可在约定时限内关闭后复测；核心场景不可用应停止扩大用户并启动回退或人工通道；安全或数据事件应按校内制度报告，不得用功能补丁悄悄覆盖。关闭的唯一证据是按原条目重跑通过，并保留新旧两次记录。口头说“下个版本会好”不能关单。

缺陷单必须能指回条目编号。无法指回的问题，说明条目表仍有空洞，应补条目后再测，而不是记成“体验问题”长期悬挂。演示成功、参观记录和宣传稿，都不能覆盖未关闭缺陷。

移交后仍要能复测

模型更新、知识更新、权限调整和接口变更，都会让旧的通过记录失效。移交物应包含评测集、压测方法、安全用例和复测责任人，使学校在供应商不在场时仍能抽查。合同结束时的退出迁移，也应能按条目验证：知识、日志、配置可导出，账号可回收，约定数据可删除或不可检索。相关表格框架见建设与验收资料。