MaaS平台验收不能只看一次请求是否成功。模型资产、服务接口、资源权限、日志审计和运维恢复需要分别设置对象、动作、证据和判定标准，才能判断平台是否具备交付条件。功能菜单存在但没有可复核流程，不能作为生产放行依据。

验收口径：本文给予模型、接口、权限与运维四条验收线，不给出厂商排名、性能阈值、价格或默认服务承诺。

验收前先定义对象与边界

验收开始前，先确定本期交付包含哪些模型、服务、项目、调用方、资源、网络和运维动作。范围不清时，供应商可能用演示环境完成测试，采购方却按生产环境理解结果，最终在版本和责任上产生争议。

建议建立一张基础清单：

• 模型、版本、来源、元数据和可见范围
• 推理服务、运行时、配置、资源和访问入口
• 用户、应用、项目、角色和权限
• 网关、接口、路由、限流、计量和日志
• 监控、告警、升级、备份、故障和回退

每个对象要指定负责人、当前状态和证据位置。未纳入本期交付的模型、硬件、接口或运行时应显式标记，不能用“后续支持”模糊处理。

*图：验收从范围与对象开始，经四条验证线汇入证据包；关键失败不能被其他顺利获得项抵消。*

模型资产如何验

模型验收不止检查文件是否存在，还要验证来源、归属、版本、元数据、授权和服务引用。可以让授权用户登记一个测试模型，补充模型卡或必要元数据，设置项目可见性，再由另一个角色查找并进入服务发布。

需要保留：模型来源说明、版本标识、存储位置、授权结果、变更记录和服务引用关系。若模型撤回或版本更新，也要检查已有服务如何提示、切换或回退。涉及第三方模型许可证、训练数据或商业使用边界时，应由法务与项目负责人另行确认。

接口与异常如何验

接口验收至少包含正常调用、无权调用、参数错误、限额或资源不足和服务异常。检查返回状态只是起点，还要确认请求如何关联到用户、应用、模型、服务和日志，故障时能否定位到具体层次。

以下表格可作为验收记录框架：

性能测试如纳入验收，必须写清模型、输入输出、并发、硬件、运行时和统计方法。缺少这些前提的数字不能直接作为合同结论。

权限和审计如何验

权限验收要覆盖用户、应用、项目、模型、服务、资源和运维角色。管理员可以完成所有动作，不代表普通角色已经正确隔离；角色名称存在，也不代表权限范围和审计记录符合企业要求。

建议至少验证：

• 授权用户能查看和调用约定对象，不能修改超出范围的配置
• 未授权用户不能访问模型、服务、日志或敏感数据
• 应用身份与个人身份可以区分，密钥或凭证有明确管理责任
• 权限变更、模型发布、服务配置和运维操作能够留痕
• 日志包含足够的时间、身份、对象、动作和结果字段

审计证据不等于无限留存全部内容。日志字段、脱敏、保存周期和访问权限应结合企业制度与项目范围确认。

运维恢复如何验

生产验收必须安排至少一次低风险异常演练，验证发现、升级、定位、恢复和复盘。可以选择服务配置错误、模型版本切换、资源不足或调用入口异常，避免在未备份的生产环境做破坏性测试。

演练应记录：

1. 异常条件和预期影响。
2. 告警、状态、日志和责任人的发现路径。
3. 恢复、回退或人工接管动作。
4. 恢复后的业务与技术验证。
5. 问题记录、改进项和未覆盖风险。

供应商可以参与处理，但企业内部也需要知道谁发起升级、谁确认影响、谁批准回退和谁判断业务恢复。只有外部人员知道操作路径，平台还未形成企业可运营能力。

结果如何分级与放行

建议把验收结果分为顺利获得、条件顺利获得、失败和不适用。条件顺利获得必须写明依赖条件、补测动作、责任人和期限；失败项如果影响权限、数据、关键路径或回退，应阻止生产放行；不适用项要说明为什么不属于本期范围。

最终验收包至少包含范围清单、测试条件、配置、状态、日志、截图或导出、异常演练、问题单和责任确认。只有“功能已演示”或“供应商口头确认”不足以支持交付结论。

验收证据如何进入采购与合同

验收用例应追溯到需求或合同编号，每个编号对应适用版本、环境前提、操作角色、输入、预期结果、证据和未达标处理。供应商产品文档可以说明范围，但最终判定必须来自约定环境的实测记录。涉及服务支持的条款，还要验证问题提交、升级、恢复和关闭流程，而不是只核对联系人名单。

条件顺利获得不能成为无限延期的出口。每个条件项要写责任人、补测窗口、临时控制、逾期处理和是否允许生产使用。权限越界、数据路径不明、关键接口不可恢复或回退不可执行等问题，不能顺利获得其他功能项高分抵消，应直接进入阻塞清单。

验收后的成本与退出边界

验收同时要确认持续运行需要的资源、日志、备份、监控、值守、升级和外部支持是否已纳入预算和责任。测试环境能够运行，不代表生产容量和服务窗口已经具备；额外组件、许可、实施或企业内部人力应显式列出，避免交付后再追加。

退出验收至少检查模型与元数据、服务配置、接口契约、权限和必要日志如何导出或重建，旧入口保留到什么条件，切换失败如何恢复。正式删除旧环境不属于普通验收动作，但可在隔离环境验证导出、重建和回退步骤，为未来迁移或合同终止保留证据。

下一步建议

在正式验收前，先让技术、采购、业务、安全和运维共同审阅四条验收线，确认每项由谁操作、谁取证、谁判定。然后在与生产接近但风险可控的环境执行测试，保留未验证项。

若验收涉及具体Alauda能力，应以知识库和官网公开资料核验产品边界，不把通用MaaS验收框架直接写成产品支持矩阵。所有线上链接、接口和最终环境也应在发布或放行前进行实物复验。

常见问题

功能演示能否作为验收？

功能演示可以用于理解产品，但不能单独作为验收。演示通常选择管理员账号、预置模型和最顺利路径，不会覆盖权限拒绝、资源不足、配置错误、版本变化和故障恢复。验收需要固定环境、条件、操作人、证据和判定标准。

可以把演示转成验收用例：使用目标角色重新执行，保存配置、状态、日志和结果，再增加至少一个异常或无权限场景。如果只能观看供应商操作而无法取得可复核证据，应将结论保留为待验证。

验收还应检查演示对象与合同版本是否一致，操作账号是否符合目标角色。若供应商使用预置环境，应记录差异和补测计划，不能把演示结果直接复制到正式验收报告。

性能验收需要哪些前置条件？

至少要固定模型和版本、输入输出长度、请求类型、是否流式、并发、持续时间、预热方式、硬件和运行时，并说明失败请求、重试和统计窗口如何处理。不同条件下的吞吐、首Token和完整响应无法直接横向比较。

性能结果还要关联资源使用和异常情况，避免只取最好时段。采购方应保存测试脚本或步骤、环境配置、原始记录和汇总方法；没有这些证据，性能数字只能作为参考，不能作为可重复的验收结论。

还要明确性能未达标时的处理、回归次数和资源调整责任。为了达到结果临时增加大量资源或关闭安全控制，应如实记录，不能把改变条件后的结果与原门槛混为一谈。

权限测试如何避免真实数据泄露？

使用脱敏或构造数据、受控账号和隔离环境，先确认测试范围和日志处理。权限测试的目标是验证允许和拒绝路径，不需要读取真实敏感内容。测试账号、密钥和临时授权应在结束后回收，并保存审批与审计记录。

如果必须在接近生产的环境验证，应限定时间、对象和操作，提前准备回退和取证方式。涉及个人信息、重要数据或行业要求时，由安全与法务决定测试方法，不能为了证明平台能力扩大访问范围。

测试数据、日志和临时凭证也要设置清理与留存责任，结束后验证回收。所有访问都应在审批范围内，测试人员不能为了取证扩大权限或复制真实数据。

验收失败后如何安排回归？

先把失败项定位到对象、条件和责任，保留原始证据，不要只记录“修复后重测”。回归计划应说明修改内容、影响范围、测试环境、重复用例、关联用例和回退条件。权限、数据、关键接口和故障恢复类失败通常需要完整复验。

修复后应使用相同或更严格的条件再次执行，并确认没有引入新的问题。若某项能力暂时不纳入本期交付，应由项目和采购负责人确认范围变化，不能直接把失败改成不适用。

回归顺利获得后仍要更新问题单、验收映射和剩余风险，由原判定角色复核。若修复改变版本、资源或接口，还应评估相关用例是否需要连带重测，避免局部修复引入新差异。