摘要
在上一篇研究文章《为什么AI应用需要新的质量保障体系？——从软件测试到AI质量工程》（RP-AQE-001）中，我们提出了一个核心判断：当软件行为从确定性逻辑走向概率模型驱动时，质量保障的范式需要被重新审视。
本文是这一议题的深化。我们不讨论AI测试工具，不比较模型能力，也不提供测试脚本示例。本文试图回答一个更根本的问题：为什么"软件测试"这个概念本身，已经不足以描述AI时代的质量工作？
答案不在于软件测试的失效，而在于质量保障体系的边界正在发生结构性扩展。本文将从质量对象（Quality Objects）、质量目标（Quality Goals）和质量生命周期（Quality Lifecycle）三个维度展开分析。
一、传统软件测试解决了什么问题
在讨论AI质量工程之前，需要先明确传统软件测试的边界。这不是否定——恰好相反，只有理解传统测试的价值，才能看清AI质量工程扩展了什么。
1.1 传统软件测试的成熟体系
经过数十年发展，软件测试已经建立了一套覆盖软件质量多个维度的成熟体系：
- 功能正确性：验证软件是否按照需求规格正确运行，包括单元测试、集成测试、端到端测试等分层测试策略
- 性能：评估系统在特定负载下的响应时间、吞吐量和资源消耗
- 安全性：检测漏洞、注入攻击、权限绕过等安全风险
- 兼容性：确保软件在不同环境、平台、设备上的行为一致性
- 可维护性：通过代码审查、静态分析、架构评估等手段保障软件长期可维护
这一体系经过大量实践验证，是软件工业质量保障的基石。
1.2 一个根本前提
传统软件测试的有效性建立在以下前提之上：
软件行为由确定性逻辑驱动。给定相同的输入和相同的系统状态，输出是确定的。
这一前提使得测试可以依赖"预期结果"（expected result）作为判断标准：定义输入 → 执行代码 → 比较实际输出与预期输出。这是软件自动化测试的基石，无论是单元测试中的断言还是端到端测试中的验收标准。
1.3 本文的出发点
本文的讨论并非要否定这套体系。相反，我们的出发点是：当上述前提发生变化时——当软件行为不再是确定性的，而是依赖模型推理时——质量工作的有效边界需要从哪里开始扩展？
二、AI应用改变了什么
要理解质量工作的扩展，首先需理解AI应用与传统软件的本质区别。
2.1 从确定性到概率性
最根本的变化不在于代码本身，而在于软件开始依赖模型推理作为核心计算路径。这一变化并非简单的环节替换——引入大模型也不是在已有架构中增加一个新的函数调用——而是改变了软件行为的基本特性。
传统软件的处理链路：
输入（确定）
↓
代码逻辑（确定性规则）
↓
输出（确定）
AI应用的处理链路：
输入（自然语言 / 半结构化）
↓
Prompt（上下文构建）
↓
模型推理（概率计算）
↓
输出（概率分布上的采样）
↓
后处理（解析 / 校验 / 格式化）
注意两个关键差异：
第一，核心计算不再由确定性规则完成。 模型推理是一个概率过程：同一输入在不同时刻、不同模型版本下可能产生不同输出。这不是bug，而是机制特性。
第二，输入端变得开放。 传统软件的输入空间是有限且可枚举的（API参数、表单字段、数据库记录）。AI应用的输入空间是自然语言，开放且不可穷举，无法通过传统方法覆盖。
2.2 被普遍低估的变化
上述变化带来了一个尚未被行业充分讨论的问题：
当一个系统中存在一个非确定性组件时，围绕这个组件构建的整个应用，其质量属性会发生什么变化？
这不是一个边界清晰的技术问题。质量的不确定性会沿着系统链路传播：模型输出的细微差异可能导致下游Agent决策的连锁变化，Prompt的微小调整可能改变整个任务导向，而模型版本更新则可能使之前积累的所有测试数据失效。
质量工作的对象、目标和方式，都需要随之重新审视。
三、质量对象发生了变化
如果质量保障的本质是"对质量对象进行系统性的检查与评估"，那么当质量对象本身发生变化时，质量工作的方法体系就需要相应调整。
3.1 传统软件的质量对象
在传统软件工程中，质量保障关注的对象相对明确且边界清晰：
| 质量对象 | 典型关注点 |
|---|---|
| 代码 | 逻辑正确性、边界条件、异常处理 |
| 接口 | 请求/响应格式、状态码、错误处理 |
| 数据库 | 数据一致性、查询性能、迁移安全 |
| 页面 | 交互行为、视觉效果、无障碍访问 |
| 服务 | 可用性、响应时间、资源消耗 |
这些对象具有一个共同特征：它们的行为是确定的，可以由规则进行穷举验证。
3.2 AI应用的质量对象
当AI功能成为系统的核心路径，新的质量对象开始出现。这些对象并非传统软件测试对象的变体，而是具有根本不同的特性：
| 质量对象 | 特性 | 与传统测试对象的根本差异 |
|---|---|---|
| 模型 | 概率输出、版本依赖、行为漂移 | 无法通过规则穷举验证 |
| Prompt | 对措辞敏感、上下文依赖、脆弱性 | 输入空间开放，无预期输出定义 |
| 知识库 | 内容覆盖度、时效性、检索相关性 | 质量取决于检索泛化能力，非功能正确性 |
| Agent | 自主规划、多步推理、工具决策 | 行为链不确定，需评估决策过程而非最终结果 |
| 工作流 | 多组件编排、步骤依赖、失败传播 | 质量评估需要覆盖链路中所有组件的交互 |
| 工具调用 | 外部依赖、格式约定、容错行为 | 需额外验证调用正确性和异常处理 |
| 评估指标 | 度量有效性、指标与业务一致性 | 评估体系的工程化本身成为质量保障对象 |
| 反馈数据 | 数据质量、标注一致性、覆盖偏差 | 数据作为模型行为的训练输入，直接影响质量 |
3.3 不是"更多测试对象"，而是"新的质量对象类型"
这里的核心观点不是"AI应用的测试对象变多了"，而是：出现了传统软件测试从未处理过的质量对象类型。
- 对代码做单元测试，和对Prompt做有效性评估，使用的是不同的方法论
- 对API做契约测试，和对模型输出做一致性评估，面对的是不同量级的不确定性
- 对数据库做迁移测试，和对知识库做覆盖度评估，衡量的是不同的质量维度
质量保障体系正在从围绕确定性对象构建的方法论，扩展到同时覆盖确定性和非确定性对象的工程体系。这种扩展不是量的增加，而是质的变化——它要求引入全新的评估方法论和工程实践。
四、质量目标发生了变化
质量对象的扩展驱动了另一个深层变化：质量目标的重新定义。
4.1 传统软件的质量目标：Correctness
传统软件测试的核心质量目标是正确性（Correctness）：
系统是否按照规格完成预期功能？
几乎所有测试维度——功能测试、集成测试、回归测试——最终都服务于这一目标。正确性的优势在于它相对明确：有需求规格可以对照，有预期结果可以作为判断依据。
4.2 AI应用需要的质量目标：Trustworthiness
当系统行为从确定性变为概率性，"正确"这个概念本身开始变得模糊。
对于"帮我总结这份合同的风险条款"这类任务，不存在唯一的正确答案。模型的输出可能事实准确但语气不当，可能内容合理但关键条款遗漏，可能格式漂亮但推理链条有误。在这种情况下，"是否正确"已经不再是充分的判断标准。
AI应用的质量保障需要从以正确性为中心，走向以**可信赖性（Trustworthiness）**为中心：
| 质量维度 | 传统定义 | AI质量工程中的扩展 |
|---|---|---|
| 可靠性（Reliability） | 系统正常运行时间 | 模型输出在大量样本上的一致性表现 |
| 一致性（Consistency） | 数据校验一致性 | 模型在不同语境下对同一事实的判断一致 |
| 可控性（Controllability） | 配置管理可控 | Prompt和系统约束能否有效约束模型行为 |
| 可解释性（Explainability） | 代码可读性 | 模型推理过程和Agent决策过程的可追溯 |
| 持续稳定性（Continuous Stability） | 系统行为可预测 | 模型版本更新后行为变化的可检测性 |
值得注意的是，这些维度的质量目标并非替代正确性，而是在正确性之上增加了一个新的质量层次。传统软件也需要可靠性，但AI应用中的可靠性问题来源不同、表现不同、检测方法也不同。
4.3 一个总结性的判断
用一句话概括这一转变：
AI质量工程正在推动软件质量的核心关切，从Correctness走向Trustworthiness。
这不是说正确性不再重要——当AI系统执行关键操作时，正确性依然是底线。但当"正确答案"本身难以唯一定义时，质量保障的目标自然地扩展为：能否信任这个系统的行为，在足够大概率上是可靠的、一致的、可控的、可解释的和持续稳定的？
五、质量生命周期发生了变化
5.1 传统软件的质量生命周期
传统软件测试有一个天然的"完成"节点：
开发 → 测试 → 上线 → 运维（监控异常即可）
测试阶段确认软件符合质量要求，上线后运维团队关注的主要是服务可用性和性能指标，而非持续的功能验证。质量保障在发布前集中完成，发布后转为异常监控。
5.2 AI应用的质量生命周期
AI应用引入了一个根本性变化：质量在上线后仍会持续变化。
这不是运维问题，而是机制问题：
- 模型版本更新可能导致同一Prompt的表现完全不同，且这种变化往往不是全量可预期的
- 知识库内容变更可能引入新的覆盖盲区或事实准确性风险
- 用户行为模式变化可能触发模型在训练中未见过的分布外（out-of-distribution）场景
- Prompt退化——长时间运行的Prompt模板可能因上下文累积而逐渐偏离初始设计
换言之，AI应用的质量不是一个静态快照，而是一个持续演化的过程。 "测试通过，可以上线"不再意味着质量工作结束——它只是质量持续管理的开始。
5.3 持续评估（Continuous Evaluation）的引入
这驱动了一个新的质量工程概念的落地：
数据准备 → 模型选型 → Prompt工程 → Agent编排
↓ ↓ ↓ ↓
└──────────┴──────────┴───────────┘
↓
持续性评估
↓
质量反馈
↓
持续优化
↓
重新评估（循环回到持续性评估）
这不是传统意义上的"回归测试"。回归测试验证的是"改动的代码是否破坏了已有功能"，其范围是明确的、可预先定义的。持续评估面对的是"系统行为的概率性波动是否需要干预"，其判断依据需要建立在对模型行为的统计理解之上。
将这一变化概括为：
AI质量工程从"测试-发布"的质量门禁模式，走向"持续评估-持续优化"的质量循环模式。
这一问题将在本系列的下一篇文章《为什么AI应用需要持续评估》（RP-AQE-003）中做更深入的分析。
六、AI质量工程是什么
经过上述三个维度的分析，我们可以尝试给出一个定义。
6.1 定义
AI质量工程，是围绕AI应用全生命周期建立持续质量保障能力的一套工程体系。
它在传统软件测试的基础上，将质量保障的对象扩展至模型、Prompt、知识库、Agent和工具调用等非确定性组件；将质量目标从以正确性（Correctness）为核心扩展至以可信赖性（Trustworthiness）为核心；将质量生命周期从"测试-发布"的门禁模式扩展至"持续评估-持续优化"的循环模式。
6.2 与传统软件测试的关系
需要反复强调的是：AI质量工程包含软件测试，但不止于软件测试。
可以用一张图来表达两者在质量对象层面的关系：
传统软件质量保障 AI质量工程
代码 ────────────────────────→ 代码
接口 ────────────────────────→ 接口
数据库 ────────────────────────→ 数据库
页面 ────────────────────────→ 页面
┌ 模型
├ Prompt
├ 知识库
├ Agent
├ 工作流
├ 工具调用
├ 评估体系
├ 反馈数据
└ 持续优化
AI质量工程包含了传统软件质量保障的核心要素——确定性代码、接口、数据和交互，同时将其扩展至传统测试框架从未覆盖的新型质量对象。
测试仍然是AI质量工程的一部分，但它不是全部。 正如在传统软件中，测试只是质量保障体系的一个环节（而非全部），在AI应用中，这一规律同样成立——只是质量保障的边界扩展得更远。
6.3 为什么这个区分是必要的
将"AI质量工作"等同于"AI测试"是有害的简化。这种简化的后果包括：
- 组织层面：企业可能将AI质量责任完全归入测试团队，而忽视Prompt工程、模型选型等环节的质量前置需求
- 工具层面：团队可能寻找一个"AI测试工具"来解决问题，而实际需要的是一套工程化评估体系
- 方法论层面：沿用"定义预期结果 → 验证"的思维模式评估AI输出，忽略了评估体系设计本身的质量问题
理解AI质量工程与传统软件测试的区别，不是为了维护一个概念边界，而是为了确保在实践层面，企业不会用旧方法论去解决新问题。
七、九维创智观点
7.1 行业判断
当前行业在AI质量保障领域仍处于早期探索阶段。越来越多的企业开始意识到"AI应用需要测试"，但较少关注"AI应用的质量保障需要什么样的工程体系"这一更根本的问题。
从趋势来看，以下几个方向值得关注：
- 方法论共识的逐步形成：行业内关于AI质量评估的标准和最佳实践将逐步收敛，类似软件测试领域从混乱走向体系化的过程
- 质量工程角色的出现：可能出现既理解软件测试方法论、又掌握AI系统特性的新型技术角色，专门负责AI应用的质量工程化
- 质量左移的深化：与传统软件测试的"测试左移"理念类似，AI质量工作将从应用开发的后期环节，前移至模型选型、Prompt设计的早期阶段
7.2 九维创智的实践方向
九维创智技术团队在软件质量工程领域有持续积累。在AI质量工程方向，我们关注的不是开发一款"AI测试工具"，而是探索以下几个方面：
第一，AI质量工程的方法论建设。 将传统测试工程中的成熟方法论——测试分层、风险评估、持续集成——与AI系统的不确定性特性相结合，形成可操作的AI质量工程实践指南。
第二，评估体系的工程化设计。 AI应用的评估不仅是"运行一些测试用例"，而是需要建立覆盖模型、Prompt、知识库和Agent行为的体系化评估框架。这本身就是一个系统性的工程问题。
第三，质量能力的组织化建设。 帮助企业从"寻找AI测试工具"的思维，转向"建设AI质量工程能力"的战略认知。因为在AI时代，质量能力不再是测试团队的专项技能——它正在成为整个技术团队的基础能力。
八、结语
本文从三个维度分析了AI质量工程与传统软件测试的本质区别：
- 质量对象：从确定性组件（代码、接口、数据库），扩展至包含概率性组件（模型、Prompt、Agent）的更大范围
- 质量目标：从以正确性（Correctness）为核心，走向以可信赖性（Trustworthiness）为核心
- 质量生命周期：从"测试-发布"的门禁模式，走向"持续评估-持续优化"的循环模式
这些变化并不意味着传统软件测试的失效或过时。确定性软件的质量保障方法依然在AI应用的架构中发挥基础性作用。真正需要被重新审视的，是当质量保障的边界被技术变革推动着向外扩展时，我们的方法论、工具和组织结构是否跟上了这个扩展的节奏。
AI质量工程不是传统软件测试的升级版，而是软件质量保障体系的一次结构性扩展。这种扩展正在发生——不是在未来某个时间点，而是在当下每一个将AI集成到业务系统的工程实践中。
下一篇文章预告：
《为什么AI应用需要持续评估》（RP-AQE-003）将继续讨论AI质量工程中"持续评估"这一核心概念——为什么传统的一次性测试无法保障AI应用的长期质量，以及持续评估的工程化实践。