传统自动化测试通常依赖三个前提：输入由我们控制、预期输出可以提前确定、代码不变时测试结果能够重复。生成式 AI 削弱了这三个前提。真实用户会粘贴长邮件、打错字、混用语言、一次问好几个问题，也可能在对话中途改变目标。相同问题可能有几种合理回答；模型、提示词、检索内容或工具变了，即使应用代码没有变化，系统行为也可能不同。

AI 测试需要支持另一种决策：判断剩余风险是否可以接受。任何测试都无法证明所有输入下风险都不存在，因此策略要做的是收集足够可信的证据。The Quality Duck 将这项工作拆成五个相互连接的转变：输入、验证、安全、基线和可观测性。

来源：The Quality Duck 于 2026 年 10 月 7 日发布的《How to build a strategy for testing AI》。下文的四周试点和发布检查表属于 QA 工程实践延伸，不是原文规定的框架。

一、输入转变：覆盖测试人员没有想到的提问

少量手写提示词主要覆盖测试团队已经想到的情况。输入转变借鉴了探索式测试中的用户画像方法：描述不同类型的用户，为每个画像设定目标，再让模型与被测产品进行多轮交互。

设计测试用户画像时，至少要记录五方面：上下文（用户知道什么、试过什么）、表达方式（语言、词汇、错别字和表达长短）、行为（是否耐心、配合或容易跑题）、限制（用户不知道什么或不愿透露什么），以及目标（他们真正想完成什么）。

例如，一个急躁的多语言顾客已经尝试申请退款，却没有提供订单号；三轮没有解决后，他要求转人工。生成器可以围绕不同画像和目标产出数百甚至数千段对话，但数量本身不能证明覆盖有效。给模拟用户设定目标和停止条件——例如完成任务或达到固定轮数——能让每次运行更容易解释。测试用户画像应作为长期维护的测试资产；产品变化后，再重新生成具体对话。

覆盖范围需要有意识地设计。把产品相关的用户类型、任务、语言、难度和语气组合起来；也要考虑不同使用情形：刚接触产品的新手、提供过多信息的专家、正在生气的顾客，以及只给出部分信息的人。条件允许时，用脱敏后的真实案例校准用户画像，并人工抽看生成的对话。合成用户往往比真实用户更连贯、更礼貌。它能补足覆盖，不能代替真实使用情况。

二、验证转变：评估标准，而不是唯一的标准答案

当多种回答都可能正确时，逐字比对就不够用了。大语言模型评估器可以依据书面标准检查回答，同时读取用户请求、待测回答和相关来源材料，再输出结论与证据，供人检查或汇总。标准可以分别关注准确性、是否有材料依据、是否切题或语气是否合适。

每个评估器只负责一项标准。例如，单独判断回答有没有无依据的事实，不要让一个评估器同时判断回答“好不好”。问题应具体且可核查，结果尽量使用通过/失败或定义清楚的少量等级；先说明证据，再给结论，并使用结构化输出。没有提供政策原文时，评估器无法核实政策事实。记录评估模型、参数、标准版本和输出格式，方便比较不同版本。原文指出，标准变化时，改写一个范围明确的评估器可能一个下午就能完成；相比之下，固定数据集包含 2,000 条预期回答，构建和修改都更费力。降低评估模型的温度可以减少结果波动，但不能完全消除波动。

{
  "criterion": "unsupported_claim",
  "passed": false,
  "evidence": "回答承诺 24 小时内退款，但政策没有规定这一时限。",
  "rubric_version": "v1.2"
}

评估器也有自己的偏差：它可能偏爱较长的回答、偏爱成对比较时排在前面的回答、对同一模型家族的输出更宽容，或被自信的语气误导。成对比较时应交换回答顺序并对两轮结果取平均；高风险场景可考虑用不同模型家族交叉评估；评分标准也应明确扣除无关的冗长内容。

人工校准经常被跳过。先让领域专家用同一套标准标注一批样本，再运行自动评估器，测量一致程度并逐项检查分歧。发现标准含糊就修改，再重复评估。模型、提示词或产品发生变化后也应重新核对。评估器本身也要像软件一样接受验证和复核。

三、安全转变：明确哪些情况必须由人复核

基准数据和自动评估器能扩大检查规模，却不能替团队承担发布后果。法律、医疗、财务、安全及其他高影响场景，都需要明确的人工监督策略。

一个可行的起点是：复核自动评估器标出的所有问题；抽查它判定为正常的对话；抽查自动评估没有覆盖的流量；并对确定性规则标出的案例定向复核，例如异常冗长的对话。抽样比例应随证据和风险调整。模型、提示词、检索、工具或功能发生变化后提高抽查强度；只有积累了足够证据，才考虑降低。

评审界面最好把请求、回答、检索证据、评估理由和对话历史放在一起。提供统一指南与示例，抽样检查不同评审者的判断是否一致，并轮换短时评审，减少疲劳。人工评审不只是“通过”或“拒绝”：他们还要判断回答是否有用、是否符合业务立场，发现评分标准没有覆盖的新问题，校准自动评估器，并把确认过的失败补进回归集。还要明确谁可以接受剩余风险、谁能阻止发布。

四、基线转变：用经过审核的案例比较版本

新模型或新提示词可能改善一部分回答，同时让另一部分变差。黄金数据集为团队提供经过审查的比较基线，案例可以来自生产追踪、支持工单、用户反馈、专家设计的边缘场景和历史失败，并记录预期行为或评估标准。

按任务、语言、风险和失败类型给案例分类，并确保覆盖核心任务、边缘场景、已知历史失败和职责范围外的请求；为数据集和评分标准做版本管理；保留一部分案例不参与调参，以降低过拟合；每次严重线上失败都应成为新的回归案例。几百条可信案例，通常比几千条未经核实的案例更有用。

对于运行结果波动明显的案例，要重复运行并比较通过率和结果分布，不能只看一次结果。发布门槛应结合后果制定：语气评估达到 95% 通过率或许可以接受，但如果错误可能造成伤害，就不能直接沿用这个门槛。关键指标退化时，应阻止自动发布，或交由负责人明确评估风险。

发布卡可以记录模型、提示词与检索配置版本，黄金数据集版本，关键通过率及相对基线的变化，高风险失败和人工复核结论，监控与回滚计划，以及由谁接受剩余风险、由谁批准发布。评分可以来自代码、自动评估器、人工复核或几种方式组合；每项标准使用什么方法都应写清楚。

除了汇总分数，也要保存评估结果、人工判断和意外失败。这些记录可以用于完善数据集、校准评估器和改进产品。策略的主要产出是信心，逐步积累的评估数据则是有价值的副产品。

发布卡可以保持简短，便于每次发布实际使用：

  • 模型、提示词和检索配置版本：
  • 黄金数据集版本：
  • 关键标准通过率及相对基线变化：
  • 高风险失败和评审结论：
  • 生产监控与回滚计划：
  • 剩余风险接受人和发布批准人：

五、可观测性转变：上线后继续追踪请求

上线前的测试无法覆盖所有真实交互。用户、数据、模型和依赖都会变化，质量评估因此还要延伸到生产环境。

追踪（Tracing）把一次请求的各个步骤串起来：原始输入、最终组装的提示词、检索到的材料和引用、模型调用、工具调用及返回、最终回答、延迟、Token 用量和成本。回答出错时，追踪能帮助团队判断问题来自检索、编排、工具还是生成。相互关联的追踪片段（Span）、版本信息、用户反馈（例如评分、编辑回答或中途放弃）和线上评估结果，也能让记录更有用。追踪还可以支持线上抽样评估与告警、把案例分派到人工评审队列、扩充评估数据集，以及发现系统行为随时间发生的漂移。

OpenTelemetry 的生成式 AI 语义约定，以及 Langfuse、LangSmith、Arize Phoenix 等工具都可以作为实现选择；重要的是能够沿着一次请求查清证据链，而不是选了哪家工具。追踪可能包含个人信息或机密，因此采集前要确定脱敏、抽样、保留时间、访问权限与合规边界。

五个转变可以融入已有测试方法

原文把五个转变放进既有测试方法中：用户画像和早期评估可以加强左移；评估器和基准可接入交付流水线；追踪和线上抽样评估则在发布后继续工作。这些做法结合起来，支持贯穿生命周期的整体测试。团队可以沿用当前工作流程，更早考虑质量、持续测试，并在产品生命周期中持续收集证据。

建议的落地顺序

原文建议先建立追踪能力，再用约 50–100 条由领域熟悉者审核的真实案例建立小型基线。随后增加一到两个范围明确的评估器，并用人工标注校准；写清基于风险的人工复核策略；再根据已发现的覆盖缺口引入合成用户画像；最后在指标可信后增加发布门槛和线上评估。面向客户且涉及高风险内容的助手应更早引入人工复核；内部低风险摘要工具可以从轻量方案开始。

如果团队还不知道怎样评估对话，先生成成千上万条数据只会增加数量，无法证明覆盖有所改善。

给 QA 团队的四周试点

下面是结合原文观点整理的工程实践建议。

第一周：让一个流程可观测。 选择一个重要用户流程，加入可关联的追踪标识，记录模型和提示词版本及工具调用，制定脱敏规则，并收集真实失败案例。

第二周：建立基线。 由 QA、产品和领域专家审核 50–100 个案例，记录可接受与不可接受的行为、风险与失败标签，并为数据集编号管理版本。

第三周：校准评估。 针对“事实是否有依据”“是否越出职责范围”等可核查标准，先建立一到两个评估器。与人工标注比较，优先检查可能漏掉高风险问题的情况。

第四周：把证据接入发布。 将约定的回归门槛接入持续集成，准备发布卡，指定风险负责人，并把生产抽样中的失败送入复核与数据集更新流程。

指标可以分三类看：质量（关键标准通过率、严重线上失败）、评估可信度（人机和评审者一致程度、覆盖范围）以及运行成本（延迟、Token 和复核工时）。不要让一个汇总分数替代发布决策。

发布前自查

每项记录结果、证据链接和负责人。选择“部分做到”时，应写明具体缺口，不要只留下一个分数。

输入

  • 每个测试用户画像都说明上下文、表达方式、行为、限制和目标。
  • 测试覆盖多语言、错别字、中途改变目标及难以沟通的用户。
  • 人工抽查合成对话，并用真实反馈校准。

验证

  • 每个自动评估器只检查一项明确标准。
  • 评估标准、模型、参数和输出格式均有版本记录。
  • 自动评估结果与人工标注对比，并复核分歧。

安全

  • 高风险回答和所有被自动评估标记的问题都有人工复核路径。
  • 抽查已判定正常的回答，以及自动评估未覆盖的流量。
  • 发布阻断权限和剩余风险接受人已经明确。

基线

  • 黄金数据集包含真实案例、专家设计案例和历史失败案例。
  • 案例带有可用标签；数据集有版本，并留出未参与调参的案例。
  • 对波动较大的案例重复运行，比较通过率或结果分布。
  • 关键门槛写入发布卡或持续集成检查。

可观测性与反馈

  • 追踪能够串联输入、提示词、检索、模型和工具调用。
  • 在适用范围内记录版本、延迟、Token、成本和用户反馈。
  • 脱敏、访问、保留期限和抽样规则已经写明。
  • 线上失败可以回流到数据集并触发回归检查。

下一步应选团队能在两周内缩小的最大证据缺口，并在发布卡上写明负责人和验证方式：

当前最大的质量证据缺口是：。未来两周可以采取的最小有效行动是：。

建立信心，而不是追求确定性

一个绿色对勾不能证明生成式 AI 产品在所有情况下都安全、正确。好的测试策略应能说明测过哪些输入、依据什么标准判断、哪些结论经过人工复核、相对上一版本有哪些变化，以及上线后怎样发现新的失败。团队由此可以基于证据作出风险决策，并在现实变化时重新评估。

参考资料

测试策略测试策略说明分析式测试策略安全测试白盒测试
分享