企业 AI 项目 Wiki · 测试与验收

验收版本

也常写作Acceptance version · 验收版 · 验收候选版本 · 验收基线

定义

验收版本是由项目授权方在某一验收轮次开始前正式指定，并与验收范围、环境、标准和证据关联的一套解决方案配置基线。它应列明应用制品、配置、数据库变更、接口与依赖、必要数据状态、文档以及企业 AI 的模型、提示词、知识和工具版本，使所有验收参与者能够确认测的是同一对象；任何实质修改都要形成新基线并重新判断受影响的验收范围。

为什么正式验收必须先指定版本

验收结论只能针对一个确定对象成立。如果测试人员上午和下午面对的代码、配置、数据或知识库不同，却把结果合并为同一次验收，就无法说明到底哪个对象通过。

指定验收版本的作用，是在“继续开发”和“正式判断”之间建立边界。开发可以继续进行，但进入本轮验收的对象必须有独立基线；问题修复也不能悄悄覆盖原对象，而要形成可识别的新基线。

验收版本不是要求所有内容永远不变，而是要求变化可见、可批准、可追踪。只有这样，失败、修复、复测、例外和最终签署才能落到具体对象上。

完整验收版本通常包含什么

具体项目可以裁剪，但凡是会改变验收结果的对象，都应纳入基线或明确登记为受控外部条件。

应用与服务制品

列出前端、后端、移动端、任务、插件和中间件制品的版本、构建、存储位置与内容摘要，不以分支名或 `latest` 代替。

配置与功能开关

记录影响行为的环境变量、业务规则、权限映射、模板、Feature Flag、定时任务和关键参数；秘密记录引用与版本，不在验收文件中暴露明文。

数据库与数据迁移

列出结构版本、迁移脚本、初始化或主数据批次、迁移结果及兼容条件。相同应用在不同数据结构上不是同一验收对象。

接口和外部依赖

明确 API 契约、第三方或客户系统的版本、端点类型、测试替身、证书和已知限制；不可固定的依赖作为环境差异登记。

验收数据状态

把支持用例的业务样本、迁移数据、账号角色和初始状态关联到本轮，区分它们是版本组成、测试基线还是外部输入。

操作与用户文档

若验收包含使用、管理、部署或交接能力，相应说明书、接口文档、运行手册和已知问题清单也要有版本。

构建与配置清单

用一份可机器读取或可审计的清单把产品版本号映射到上述组件、提交、构建、摘要和批准记录。

怎样指定并冻结一轮验收版本

确认本轮验收范围
把需求、验收标准、业务流程、角色、非功能项、明确排除项和允许例外确定下来。
组装候选基线
由交付团队从已完成前置测试的组件中生成版本清单、制品和部署说明，不在验收环境里临时拼装。
部署并核对身份
将清单中的不可变制品部署到约定 UAT 环境，核对页面或 API 报告的版本、摘要、配置和数据库状态。
完成进入检查
确认环境、账号、数据、依赖、日志、问题流程和硬停止条件可用，已知差异不会使计划结论失真。
由授权人指定
记录验收版本 ID、清单摘要、适用范围、环境、验收窗口、批准人和时间，通知所有参与者从该基线开始留证。
保护基线
限制覆盖制品、直接改库、修改配置、移动模型别名或无记录更新知识索引；必要变更走统一变更流程。

验收中发现问题后怎样换版本

先保留原失败证据
记录原基线、场景、输入、实际结果、日志和问题编号，不能修复后把原记录直接改成通过。
证据：失败用例、缺陷单和原版本清单。
明确改了哪些配置项
修复单关联源码、配置、脚本、数据、提示词或知识变更，并评估直接和间接影响。
证据：变更请求、代码审查、组件差异和风险判断。
产生新的验收基线
任何会改变受测行为的内容更新都生成新版本 ID 或修订号，并重新生成清单与摘要。
证据：新清单、构建、部署和批准记录。
决定复测与回归范围
至少复测失败项；根据共享组件、数据迁移、权限、接口和非确定性影响，增加相关功能与端到端回归。
证据：影响分析和经批准的复测范围。
区分条件接受和未修复
若问题不修复而拟接受，要记录影响、临时措施、截止日期、负责人和有权接受风险的人，不得用换号掩盖。
证据：例外或豁免、残余风险和签署。
只汇总同一基线的结论
最终报告逐项标明在哪个版本通过；若多轮证据合并，要说明为什么未受后续变更影响。
证据：标准—用例—版本—结果追踪矩阵。

验收版本记录应能回答哪些问题

验收的对象是什么？
产品版本、组件列表、制品摘要、配置、数据库、文档和外部依赖清楚可查。
谁在什么时候指定？
指定人与权限依据、指定时间、验收窗口、环境和清单摘要有不可抵赖的记录。
它从哪里构建并怎样部署？
源码提交、依赖、构建流水线、制品库、部署运行和环境核对能够串联。
适用哪些标准和用例？
本轮范围、验收标准、样本、测试用例、非功能检查和明确排除项均可追踪。
中途发生过什么变化？
每次修订的原因、内容、批准、影响分析、复测、回归和关闭状态完整。
最终决定覆盖哪个版本？
签署明确版本 ID、清单摘要、通过状态、附带条件、未关闭问题、残余风险和后续责任。

企业 AI 的验收版本还要锁定什么

模型和托管部署

记录供应商、模型 ID、固定快照或注册表版本、部署名称、区域、内容策略与关键参数。若只有可移动别名，要保存当时解析结果和复验触发条件。

提示词和编排

系统提示词、模板、输出 Schema、智能体工作流、路由、记忆策略、工具定义和人工批准步骤全部纳入版本清单。

知识状态

锁定源文件批次、权限快照、清洗、切分、嵌入模型、索引构建、检索、重排和缓存状态。验收中无记录重建索引等同于换版本。

工具与外部动作

列出每个工具的 API 契约、凭据范围、测试端点、白名单、幂等与确认策略；即使回答文本不变，工具逻辑变化也会改变验收对象。

评测基线

把样本集、正常与异常分类、参考事实、评分量表、评审人校准、自动评测器和重复次数与系统基线一起版本化。

非确定性变更判断

单次输出不同不一定是换版本，但模型别名移动、知识更新、提示词修改、参数变化或供应商行为更新会使原证据可能失效，需要按影响重新验收。

验收版本容易与什么混淆

相关概念	与验收版本的区别
版本号	版本号是标识；验收版本是被正式指定的完整配置基线，并包含号码、组件、条件和控制记录。
最新版本	最新只表示时间或排序上的当前对象，可能尚未完成前置测试，也可能在验收中继续变化。
发布候选版本	发布候选是准备进入发布流程的候选对象；只有被指定进入正式验收并绑定范围与证据后，才成为本轮验收版本。两者可以重合。
UAT 环境	UAT 环境是执行验收的技术与数据条件；验收版本是部署在其中接受判断的对象。
验收标准	验收标准规定怎样判定；验收版本规定判定针对什么对象。标准相同也可以用于不同修订版本。
已验收版本	验收版本在开始时只是受测对象；只有完成测试并由授权人签署后，才能称为已验收版本。
生产版本	生产版本是实际部署并运行的对象。已验收版本是否进入生产以及部署后是否仍为同一基线，需要发布和部署记录证明。

依据与适用边界

“验收版本”不是所有软件标准都统一采用的固定术语。本文把它定义为项目中被明确指定接受正式验收的一套完整、可识别、受控的解决方案基线，而不是号码后面加上“验收版”三个字。它不等同于版本号、最新构建、发布候选、UAT 环境、验收标准、验收结果或生产版本；一个项目也可以使用“验收基线”“UAT 候选”等名称，只要对象和控制方式相同。