企业 AI 项目 Wiki · 环境、版本与上线

用户验收测试环境（UAT 环境）

也常写作UAT 环境 · UAT environment · 用户接受度测试环境 · 业务验收环境

定义

用户验收测试环境（UAT 环境）是供获得授权的业务用户、客户代表或其他验收责任人，使用约定的业务场景和验收标准，对一个可唯一识别的候选版本作正式业务确认的受控非生产环境。它需要提供足以代表目标业务的配置、权限、数据和系统依赖，同时阻断未获授权的正式业务副作用，并保留从测试输入、实际结果、问题处理到签署决定的可追溯记录。

UAT 环境到底用来确认什么

开发和测试团队可以证明功能按设计工作，却不能代替业务方判断系统能否支持真实岗位完成工作。UAT 环境把熟悉业务规则、例外处理和日常操作的人带入正式验收，使他们能够围绕业务流程而不是代码模块作出判断。

这里被确认的不是一个模糊的“系统”，而是指定版本在指定环境条件下，对约定业务范围产生的结果。版本、配置、数据、身份、依赖或知识库发生实质变化，原来的证据就不一定还能支持同一个验收结论。

UAT 环境提供的是作出验收决定的条件和证据，不是自动生成通过结论。业务代表签署前，仍要核对验收标准、未关闭问题、已知差异和残余风险；环境可用也不等于业务已经接受。

一套可正式使用的 UAT 环境由什么组成

它不只是一个网址和几组账号。下列条件共同决定一次 UAT 结果是否可解释、可复现、可签署。

可唯一识别的验收对象

记录应用构建、配置、数据库结构与迁移、接口契约以及本次包含和不包含的范围。环境页面应能看到或查到版本，避免测试途中无记录换包。

代表业务的配置与流程

组织、角色、审批链、规则、时区、币种、模板和状态转换要能覆盖本期业务，不应为了测试方便绕过关键控制。

受控且可恢复的数据基线

准备正常、边界、异常和历史状态样本，标明来源与授权；每轮测试能恢复到已知状态，防止前一次操作污染后续结论。

按真实岗位设计的身份权限

为验收人员配置与目标岗位相符的角色，另设受控管理和支持权限。既要验证该看见和能办理的内容，也要验证不该看见和不能执行的操作。

明确的依赖与副作用边界

标明每个接口连接模拟、沙箱、测试实例还是受限正式服务；邮件、短信、支付、下单、审批和写回业务系统必须防止误触真实对象。

可观察、可取证的记录能力

保留用例编号、输入、时间、执行人、实际结果、截图或输出、应用日志、接口记录和版本信息，同时避免日志泄露敏感内容。

问题处理和现场支持

约定问题入口、严重程度、响应人、是否阻断、修复版本、复测责任和关闭权限，并给业务测试人员清晰的支持联系方法。

开放给业务用户之前的就绪检查

验收范围和标准已经批准吗？
把本期流程、角色、数据变化、接口、非功能要求和不在范围内的事项对应到可执行场景。
记录：批准版验收方案、标准、场景和范围基线。
本轮版本已经冻结吗？
锁定代码、配置、数据库变更和依赖版本；紧急修改必须生成新候选并说明需要重测的范围。
记录：版本号、构建摘要、配置清单和部署时间。
账号、权限和人员准备好了吗？
验收人完成必要培训，账号可以登录，角色贴合其业务职责，签署人和替代人已经明确。
记录：人员名单、角色矩阵、访问测试和授权责任。
业务样本可用且合规吗？
样本覆盖关键流程、例外和权限边界，来源、脱敏、保留、删除和跨境条件符合组织规则。
记录：数据清单、授权依据、基线批次和清理日期。
真实副作用已经阻断吗？
逐一确认支付、通知、订单、工单、审批和外部写入的端点、收件人白名单、额度与撤销办法。
记录：端点清单、拦截规则和受控验证结果。
环境差异不会误导结论吗？
登记与生产在容量、数据、域名、身份、网络、依赖和监控上的差异，并说明每项差异使哪些判断失效。
记录：差异、风险、补偿验证、负责人和接受人。
证据和缺陷流程可用吗？
先试走一条用例从执行、取证、提单、修复、复测到关闭的完整链路。
记录：演练用例、问题单、状态流和审批日志。

一轮 UAT 怎样执行和形成结论

建立本轮基线
记录验收窗口、环境、候选版本、数据批次、参与人、标准和已知限制，执行就绪检查后再开放。
由业务角色执行场景
业务用户按真实岗位完成端到端流程，既检查结果，也检查步骤、权限、交接、例外处理和必要的人工判断。
当场保存实际证据
把输入、操作、输出、时间、身份和相关日志绑定到用例，明确通过、失败、阻塞或未执行，不能只在会议里口头反馈。
分诊问题而不现场改答案
区分产品缺陷、数据问题、配置问题、环境故障、培训疑问和新需求；未经记录的现场修补会破坏版本和证据基线。
在新版本上复测
修复形成新的可识别版本，先验证问题，再按影响范围做回归；不能把旧版本失败记录直接改成通过。
汇总例外和残余风险
列出每条标准、执行状态、阻断问题、获准延期项、生产差异和补救安排，使签署人看到完整事实。
由授权人作出决定
按约定给出通过、附条件通过、退回修复或不通过，并记录决定人、日期、适用版本、条件和后续责任。
封存并清理环境
保存所需报告和证据，撤销临时权限、测试密钥和白名单，按规则删除数据，防止 UAT 环境长期变成无人负责的影子生产。

企业 AI 项目的 UAT 环境还要固定什么

固定整条 AI 系统链路

除应用版本外，还要记录模型及服务版本或别名、系统提示词、参数、安全策略、嵌入模型、知识文件、切分、索引、检索、重排和工具定义。只写“使用某大模型”无法锁定验收对象。

按业务风险组织样本

把高频正常场景、关键边界、资料不足、相互冲突、恶意输入、敏感信息和高影响操作分开；样本要代表实际部署条件，并保留来源、期望和评分方法。

允许不确定输出，但不能允许不确定判定

生成式结果可以存在合理表达差异，验收标准仍要说明事实正确性、引用、完整性、语气、拒答、升级人工和允许误差，由经过校准的业务评审者按同一量表判断。

验证知识边界与权限继承

同一问题用不同角色执行，检查检索结果、引用和回答是否遵守文档权限；同时验证过期、删除、无权限和无资料时不会编造或越权披露。

隔离工具调用的真实动作

智能体或助手调用订单、消息、工单、审批等工具时，使用测试端点、白名单和最低权限，并检查参数确认、幂等、防重复、超时、失败恢复、审计和人工接手。

定义必须停止的结果

越权泄露、不可逆误操作、关键事实无依据、应拒绝时继续执行、绕过人工批准或无法审计等结果，应预先列为阻断项，不能用平均得分抵消。

处理波动与可复现性

记录每次输入、上下文、检索内容、模型设置、输出和时间；对关键样本重复执行并报告波动。外部模型无通知变更时，要重新判断原验收证据是否仍适用。

最终应留下哪些记录

环境与版本基线
环境标识、部署时间、产物摘要、配置、数据和依赖版本，以及与生产的差异。
人员与权限记录
测试者、业务角色、支持人员、问题关闭人和最终签署人的身份及授权依据。
用例与执行结果
每个场景的前置条件、样本、步骤、预期、实际、证据、执行时间和结论。
问题与复测轨迹
严重程度、影响、责任、修复版本、复测证据、关闭决定和未关闭项处理。
验收决定
明确适用版本、通过状态、附带条件、已接受风险、后续行动、负责人和日期。
环境收尾记录
证据归档位置、数据删除或保留、临时账号撤销、密钥轮换和环境后续用途。

UAT 环境容易与什么混淆

相关概念	与 UAT 环境的区别
用户验收测试（UAT）	UAT 是业务用户依据标准执行测试并作出接受判断的活动；UAT 环境是承载这项活动的技术和数据条件。
普通测试环境	普通测试环境服务于开发、QA、自动化、集成或异常验证；UAT 环境特别面向获授权业务角色、正式业务场景和可签署证据。
预发布环境	预发布侧重候选产物能否按正式路径在生产相似条件下运行；UAT 侧重业务是否接受其结果。两者可以共用基础设施，但目标、权限、窗口和记录必须分清。
生产环境	生产承载真实业务和正式运行责任。UAT 只能在经过明确批准的受控情形下接触真实样本或正式服务，不能因“接近真实”而默认连接生产。
培训环境	培训允许用户练习并可反复重置，不产生验收结论；UAT 执行已批准场景并保留正式结果，培训不充分还会污染 UAT 判断。
演示或试点	演示用于展示，试点可能让有限真实用户在受控生产范围内使用；UAT 环境仍是非生产的正式验收条件，结论只覆盖已定义的版本和范围。

依据与适用边界

本文解释的是承载用户验收测试的受控非生产环境，不是用户验收测试活动、验收方案或验收结论本身。UAT 可以使用独立环境，也可以在符合条件的测试或预发布基础设施上进行；名称和物理资源是否独立不是关键，关键是验收对象、业务数据、人员权限、外部副作用、环境差异和证据能否被控制。进入 UAT 环境不表示版本已经验收通过。