高校AI采购参数怎么写？

定义：可测试的采购参数写的是什么

在高校立项和招标语境里，AI采购参数是一组能被供应商响应、能被评标对照、能在交付现场复测的条件。它描述的是学校要完成的业务结果和约束，而不是某一厂商产品手册上的模块名称。一条合格参数至少能回答四个问题：在什么场景、由谁操作、输入什么、期望看到什么证据。

参数的对象通常包括：试点场景范围、用户角色、功能流程、数据与知识、模型或推理接口、性能条件、身份与权限、日志与备份、安全边界、系统接口、迁移与培训、试运行和售后。这些对象可以拆进技术需求、测试大纲和合同附件，但不能互相替代。技术需求写“做什么”，测试大纲写“怎么测”，合同附件写“测不过怎么办”。

它不是什么

• 它不是把产品宣传页改写成技术规格。
• 它不是用“国内领先、高度智能、拟人交互”代替指标。
• 它不是只写建设内容、不写测试数据、环境和责任人。
• 它不是把价格、中标额或历史项目金额写进能力证明。

可测试参数与建设方案、产品介绍可以对照阅读，但三者职责不同。建设方案回答学校为什么做、先做哪一场景；产品介绍展示一种实现路径；采购参数只保留学校必须核验的条件和允许等价替代的空间。后文提到的校级治理能力，也只作为能力对照，不构成指定品牌或指定产品。

为什么功能清单招标在高校走不通

学校推进生成式人工智能时，采购文件最容易出现四类同时发生的问题。它们看起来像“写得更全”，实际会让评标和验收同时失效。

第一，场景没有冻结。文件同时写办事助手、教学评价、就业推荐、论文检测和科研知识库，却没有用户角色、禁止事项和首期范围。供应商只能按最大功能集报价，学校也无法在一个学期内完成端到端验收。没有冻结的范围，后面所有量化指标都会变成无法解释的平均数。

第二，功能被写成名词。招标书出现“支持知识库、支持智能体、支持多模型、支持数据分析”，却不写输入从哪来、输出给谁、哪一步必须人工确认。演示时每个名词都能点开页面，上线后成绩更正、发文、推送仍可能被模型直接触发，或者教师无法解释回答来源。

第三，效果无法复测。文件要求“回答准确、响应迅速、安全可靠”，却没有测试集、并发定义、运行环境和故障等级。交付当天只能看厂商准备好的对话脚本。学期高峰、权限切换或接口中断时，当初的形容词全部失去约束力。

第四，品牌或模型被提前锁死。指定唯一商标、唯一模型或无法验证的中间件版本，会把同等能力的替代方案排除在外，也会在模型停服或许可证变化后失去续约空间。学校真正需要的是可导出的数据、可移交的日志、可替换的推理后端和可演练的回退，而不是一次无法退出的绑定。

因此，参数编写应先回答：这个项目要解决哪一个业务目标、服务哪些角色、数据能否出域、和哪些系统集成、怎样才算试运行通过。五个问题清楚后，再展开功能、性能、安全和售后。先堆模块再补指标，几乎总会在评标澄清阶段返工。

实践中还有两类偏差需要在需求会上提前排除。一是把“对标某校已建系统”写成参数来源，却拿不到对方的测试集、接口字段和验收记录，最后只复制了菜单名称。二是把市场调研纪要里的产品卖点直接粘进招标文件，造成倾向性表述。纠正这两类偏差不需要先扩预算，需要先补场景说明书和可复测条目。具体如何避免参数倾向性，见高校AI项目怎样避免参数倾向性；如何把条目写成可当场重跑的验收标准，见高校AI项目如何编写验收标准。

五段参数结构：从范围写到售后

智库把采购参数压成五段，是为了让信息化、业务处室、安全和采购能在同一张表上讨论，而不是各写各的章节。五段可以对应招标文件的不同附件，但缺一段就应视为需求未完成。

第一段：项目范围、用户角色和业务场景

写清建设目标属于试点、校级平台还是专项系统；首期纳入哪些处室和哪些流程；明确不做什么。用户至少区分学生、教师、业务管理员、系统管理员和外部访客。每个角色写可提问范围、可调用工具、不可见字段和必须转人工的情形。场景建议只冻结一到两个高频、低风险、责任部门明确的闭环，例如制度查询加办事导引，而不是把“校园大脑”一次写进范围。

这一段的输出应是场景说明书：业务目标、用户故事、禁止事项、数据能否出域、是否允许写操作。没有这份说明书，后面的功能表会重新膨胀成产品目录。

第二段：功能流程、输入输出和人工审核点

功能按流程写，不按产品模块写。每条流程至少包含：触发条件、输入材料、系统动作、输出物、人工审核点、失败处理和日志。查询类流程要写引用和拒答；办理类流程要写回到原系统或人工岗的节点。教师审核知识、辅导员确认推送、教务确认成绩相关答复，都必须出现在参数里，而不是出现在培训PPT里。

输入输出要落到对象。例如：输入是已授权的制度文件编号和用户问题，输出是带原文定位的答复、无法支持时的拒答理由、以及可检索的会话日志。不要只写“智能生成办理建议”。

第三段：数据规模、模型来源、并发和响应条件

数据写来源系统、对象数量级、字段级授权、更新频率和能否进入训练、检索或生成。模型写来源、许可证、是否允许替换、版本记录和评测基准，不写唯一商标。并发和响应必须带运行环境，详见后文量化口径。这一段的目的是让不同供应商在同一组假设上响应，而不是比谁把参数量写得更大。

第四段：身份、权限、日志、备份和安全要求

身份对接学校统一认证；权限按角色、院系、密级和工具叠加；日志至少能按人、时间、场景、是否出域检索。备份写范围、频率、恢复验证和保留期限。安全写越权拒答、提示注入、批量导出内部字段、未授权出域，以及生成内容的边界。安全要求应能变成测试用例，而不是单独一章原则性表述。校内分级和生成式使用边界，对照安全与合规边界落条款，不在参数里发明另一套密级名称。

第五段：接口、迁移、培训、试运行和售后服务

接口写系统名称、对象、字段、读写方向、同步频率、超时和回切。迁移写知识、配置、日志和账号如何导出。培训写对象、学时或场次、是否上机、能否独立完成日常操作。试运行写周期、并发、缺陷关闭标准和是否允许扩大用户。售后写故障等级、响应与恢复时限、升级通道和驻场或远程边界。这一段决定学校能不能把系统接住，也决定合同结束时能不能退出。

比较：功能清单招标与可测试参数

下表用于需求讨论和文件审查，不构成唯一合法文本。学校仍须对照政府采购、招标投标、网络安全、教育数据分类分级和校内采购制度。表中“可测试参数”列给出写法方向，具体阈值由学校按试点场景自行测定，本文不填写任何中标额、报价或历史成交金额。

审查招标文件时，可以把每一条技术需求改写成“对象—条件—期望—证据”。改写失败的句子，通常就是功能清单。改写成功后，评标可以要求供应商在学校提供的测试数据上出具报告，而不是比较谁的模块名称更多。

必须量化：四类口径怎么写成可复测句子

量化不是把数字写得越大越好，而是让同一条件能被不同人在同一环境重跑。高校AI项目至少要把下面四类口径写进技术附件或测试大纲。阈值由学校按试点测定，本文只给句式，不给虚构指标，也不引用任何项目中标额。

1. 测试集和准确性口径

测试集应在招标或合同谈判阶段由业务部门出题、信息化配合脱敏、双方签字确认。题目覆盖正确回答、必须拒答、必须引用、必须转人工四类。标注规则写清：以哪一版制度为准、过期文件如何处理、部分正确如何计分。准确性只在该测试集和约定模型或接口版本上统计，并分开报告正确率、拒答率、引用错误率和越权失败率。没有测试集，不得把准确率写成符合性条款。

AI效果必须同时写局限：哪些问题不在范围内、知识更新滞后时如何提示、无法溯源时是否禁止作答。验收时允许供应商说明失败原因，但不允许用“大模型存在幻觉”代替缺陷关闭。

2. 并发用户、响应时间与运行环境

并发要定义是同时请求、同时会话还是同时在线账号，并写清是否含检索和工具调用。响应要区分首字时延和整段完成时间，写失败率、是否允许排队以及排队超时后的提示。运行环境写部署位置、模型或接口版本、量化方式、上下文长度、是否流式返回，以及压测脚本归属。更换模型后必须复测，不能沿用旧报告。

性能验收与功能验收分开。功能通过只说明流程走得通；性能通过只说明约定条件下可复测。用空载演示代替高峰脚本，应视为未测。

3. 接口数量、数据字段和同步频率

接口清单按系统列出对象，而不是只写“对接N个系统”。每个对象写字段、主键、读写方向、同步频率、增量或全量、冲突以谁为准。查询结果应能抽查到与源系统一致；无权限字段不得进入提示词或回答。写操作不得由生成结果直接改库。接口中断时必须降级提示，不得编造课表、成绩或政策条文。

数据规模可以给数量级，用于估算存储和检索，但不能用“海量数据、全量治理”代替目录。进入训练、微调、检索、生成的数据要分开授权，停用后按约定删除或导出。

4. 故障等级、响应时间和恢复要求

建议至少分三级：不影响业务的缺陷、核心场景不可用、安全或数据事件。每一级写发现后的响应时限、恢复时限、通报对象、是否切换回退版本，以及事后报告字段。响应和恢复的证据是工单时间戳、监控记录和复测结果，不是口头承诺“全年服务”。试运行应演练一次可恢复故障和一次回退，学校人员能按手册完成或监交。

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

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

1. 冻结目标与场景

动作：从候选清单中选出可评价试点，写用户角色、禁止事项和成功标准。输出：场景说明书、责任矩阵和“本期不做”清单。

2. 把功能改写成流程条目

动作：删除无法对应到流程的模块名；为每条流程补失败处理和拒答。输出：功能条目表，每条带期望结果和证据形式。

3. 编制测试集与量化附件

动作：固定测试集版本、准确性口径、并发脚本、接口字段和故障等级。输出：测试大纲、数据目录、接口清单和安全用例，作为招标附件。

4. 中性化审查与等价替代

动作：删除唯一品牌、唯一模型和无法验证的“智能程度”；对确需兼容的接口改为规格描述；要求投标人提供等价替代说明。输出：中性参数清单和评分中实测、安全项的权重说明。详细原则见避免参数倾向性。

5. 把验收和售后写进同一组条件

动作：规定功能、安全、性能分别验收；文档、培训、账号移交和试运行报告列入通过条件；未通过项写缺陷、责任方和复测时间。输出：验收条目表、缺陷单模板和售后等级表。条目写法见验收标准编写指南。

如果某一步缺少输出物，不要进入招标公告。尤其是没有测试集就写准确率、没有场景说明书就写“全校智能体”，都会在澄清和验收阶段被打回。

验收：四条必须同时成立

用真实流程完成端到端测试

端到端指：授权用户登录、提出真实业务问题或提交真实办理材料、系统给出可核验输出、该人工审核的步骤实际发生、日志可检索。测试账号应使用学校提供的角色，覆盖低权限和高权限。知识必须来自已授权且未过期的材料。厂商演示脚本可以用于培训，不能用于符合性判定。

安全、性能和功能分别验收

功能看流程、引用、拒答、审核和接口一致性。安全看越权、出域、注入、批量导出和日志完整性。性能看约定并发、模型和环境下的时延与失败率。三份记录分开签字。安全失败应停止扩大用户范围；性能失败应停止宣称“已具备校级并发”；功能失败应列出缺陷关闭计划。详细条目表的写法见验收标准。

AI效果说明测试集与局限

报告应包含测试集版本、题目分类、判定人、模型或接口版本、分项结果和失败样例。同时写明：知识未覆盖时如何拒答、源系统中断时如何降级、生成内容不得作为成绩或处分依据。没有局限说明的效果报告，视为未完成效果验收。

交付文档和培训纳入验收

最低移交物包括：场景与权限说明、数据与接口目录、模型或接口版本记录、拓扑与备份恢复、测试集和压测方法、值班与升级、退出迁移说明。培训应使指定岗位能独立完成日常问答复核、知识更新申请、日志检索和一般故障报修。培训签到不能代替上机抽查。相关清单和表格框架可从建设与验收资料获取，再按本校场景改写。

验收未通过项必须留下缺陷单：现象、重现步骤、对应参数条目、责任方、整改时限和复测人。演示成功、领导观摩或宣传稿，都不能覆盖条目失败。合同支付或阶段确认应与复测结果挂钩，而不是与到货或安装完成挂钩。