最近一个月，我几乎每天都在跟同一个"幽灵"较劲——公司自研的AI质检系统，明明上一轮回归测试跑得好好的，下一轮就突然给同一条客户对话打出了两个完全不同的风险分。一开始我以为是环境问题，排查了半天，最后发现是模型在"自由发挥"。这就是我想写这篇东西的原因：测试AI和测试传统软件，真的完全是两码事。如果你是一名软件测试工程师，正准备接手AI产品，或者你已经在AI测试项目里被各种"不可解释"的问题折磨得头秃，这篇内容值得你花十分钟看完——我会把这段时间踩过的坑、试出来的方法、以及那些让我深夜怀疑人生的"意外"全部摊开来讲。
1. 从一次"见鬼"的回归测试说起：AI产品为什么这么难测
1.1 同样的用例，跑五次五个结果
那天版本要上线，验收之前我按惯例把100条核心回归用例跑了一遍。第一遍，92条通过，8条失败；我不服气，重跑，90条通过，10条失败；再跑，95条通过，5条失败。同一个版本，同一个环境，同一条用例，结果在两次执行里都能不一样。传统软件测试讲究"可复现性"——一个Bug复现不了，提Bug单都要被开发驳回。但在AI产品上，这条铁律直接失效了。
后来我才明白，LLM推理本身带有随机性。即便你固定住prompt和输入，当模型做采样生成时，每一步都会从概率分布中选取下一个token，同一个输入在两次推理中可能走出完全不同的路径。这不是偶发故障，而是模型的底层机制。我一度改用贪婪解码、temperature调到0，结果仍然不可完全复现——因为浮点运算在不同算子实现下也会有细微差异，更别提GPU的并行处理顺序了。
这段经历给我上的第一课是：测试AI产品之前，你得先问一句——"我们测的到底是确定性系统，还是一个天生带有随机性的系统？"如果答案是后者，你的整套测试策略都要跟着变。
1.2 测试堡垒的坍塌：断言无从写起
传统功能测试的根基是"断言"。点击按钮，弹出一个对话框，字段值等于预期值，这就叫通过。可AI产品的输出是自然语言，面对"请对这条客户投诉进行情感分析"这样的输入，模型可能回复"客户情绪偏负面"，也可能回复"语句中含有明确不满情绪，建议回复时效性调高"。这两段话语义相同，但字符串完全不同。
如果你拿精确匹配去断言，AI输出的正确率会让你怀疑人生；如果你拿"包含关键词"去断言，模型换一种措辞绕过你预设的关键词，断言就失效了。跟我搭过传统自动化框架的同事，第一次写这类用例时是崩溃的，他问我："断言都没有，测试还测什么？"我当时也答不上来，但后来我意识到，AI测试不是取消断言，而是把断言从字符串层级提升到了语义层级。
2. 测试AI的第一性原理：从"输出对不对"到"行为合不合规"
2.1 你要测的不是单条输出，而是一个分布
既然单次输出带有随机性，那我们能测的只能是一个"行为分布"。我后来的做法是：每条case跑N次（一般N=5或N=10），统计输出落在什么范围内的概率。比如一个风险评估任务，模型5次里有4次给出"高风险"、1次给出"中风险"，这条用例就不是简单"通过"或"失败"，而是需要一个"通过率"或者"一致性分数"。
这个转变非常关键。我举一个例子，同样是电商客服的投诉识别，单独跑一次看起来没问题，但按分布去跑10次之后，你会看到模型在"退货原因"和"商品质量问题"这两个类别上经常摇摆。这个摇摆频率本身就是最重要的测试结论——它可以转化为模型的置信度指标，喂给开发去调优，也让业务方知道"模型在哪些边界情况下还不稳定"。
2.2 语义断言：用模型去测模型
解决"断言没法定"的办法，是用模型来做语义评估。我们团队试过三种路子：
- 模板加正则：适合非常固定的输出结构，比如判断回复是否包含订单号，这种用传统方式就够了。
- 文本相似度计算：用余弦相似度对比模型输出和人工参考答案的语义距离，超过阈值算通过。轻量、快，但对复杂逻辑（比如"是否漏掉了关键动作"）无能为力。
- LLM作为评估器：写一个独立的评估prompt，让它判断模型输出是否满足预设的业务要求，输出"是/否/不确定"，再配合人工抽检。这个方法最灵活，也是AI产品团队现在最常用的。
这里有个陷阱：用模型评估模型，评估模型本身也有偏见和幻觉，所以你需要定期做"评估器校准"——拿一批已知标准答案的样本去验证评估器的打分准不准。我们在实践中发现，某些评估prompt会倾向给"长回复"高分，跟业务方的主观判断有偏差，这就要调整评估器的评分标准，而不是直接信任它。
2.3 数据漂移监控：测试不是上线前一次性的事
传统功能上线之后，你要关注的通常是"服务是否挂了"；但AI产品上线之后，哪怕服务没挂，输入数据的分布也会变。你的线上客户一天比一天说话更"AI化"（很多人找客服时自己先copy了一段AI生成的话），或者某个地区突然推出新政策，客服话术中多了大量新词汇——这时候模型在测试集上表现很好，在线上却开始犯低级错误。
所以我们后来搭了一个非常朴素但有效的监控：每天随机采集100条真实线上输入，跑一遍离线评测，看关键指标（准确率、拒绝率、平均置信度）有没有明显回落。发现异常不要急着甩锅算法，先做数据分析，看是数据漂移还是模型退化，这个动作让我们避免了好几次"半夜被业务方电话叫醒"的惨剧。
3. 把"幻觉"当Bug上报之后：非确定性缺陷的身份困境
3.1 什么是"可复现"：至少要对随机种子保持敬畏
有一次，测试环境里的AI写手功能凭空生成了一段"客户要求退款并投诉媒体"的内容，但原始对话里完全没有这回事。我兴冲冲提了一个"重大Bug"，开发回了一句："你跑几次？每次都复现吗？"结果我还真复现不出来。因为模型在低概率采样路径中编造了不存在的细节，属于典型的"幻觉"，它既不是每次必现，也不是完全随机的，而是概率性触发。
后来我养成了一个习惯：不管提什么Bug，先做"复现实验"，至少跑十次，记录触发概率。如果触发概率低于某个阈值，比如5%，还不能算作严重缺陷，而更像一个待优化的质量风险；如果触发概率在30%以上，就必须启动专题分析。这类概率触发的问题，我会把触发样本的种子参数、模型版本、推理参数全部记录下来，作为附件贴在Bug单上。虽然开发仍然可能因为环境不同复现不了，但至少我们双方有了一批"坏样本"，能过一起去分析模型的哪些环节产生了错误分支。
3.2 记录"坏样本"比记录"失败用例"更重要
在传统软件测试中，一个失败的用例通常自带完整的输入和输出，开发照做就能定位。但AI测试里，哪怕你把同一个prompt发给开发，开发用自己的模型版本跑一遍，可能完全复现不了你的结果。所以你需要保存的是"坏样本"本身——模型在这个输入上给出了错误输出，这个输出可能包含模型生成的完整日志、分布概率、甚至内部attention权重。
我把这些坏样本组织成了一个"坏样本集"，每次发版前用这个集合回归一遍。这个动作带来的收益立竿见影：以前开发改一版模型，我只能靠感觉判断"是不是变好了"，现在直接用坏样本集在模型A和模型B上各跑一遍，对比错误率有没有下降。所谓AI测试，从某种角度讲，就是不断扩充和清理这个坏样本集的过程。
3.3 Prompt也是测试代码：版本化你的测试输入
我们团队有个很痛的教训。某个Prompt我们直接在线上改了两个字，没有走配置下发流程，结果所有测试用例的输出格式全变了一轮。排查半天，最后发现是Prompt被直接改在了代码里，甚至没有提交记录。那一刻我意识到，Prompt对AI产品的行为影响，不亚于一行核心逻辑代码——它是需要被版本管理、评审、回归测试的"一级公民"。
现在我们的做法是：所有Prompt统一走配置平台，每一次修改都生成一个新版本号，测试用例挂在具体的Prompt版本下面。一旦线上出了问题，我们第一件事就是确认线上Prompt版本与测试基线是否一致，这一步能在五秒内避免至少一个小时的瞎排查。
4. 荒诞背后：用AI测试AI的双向奔赴
4.1 用大模型生成测试数据的实践
测试AI产品最缺的就是测试数据。我们曾经为了构造"愤怒客户对话"样本，人工写了整整两天，也只写出了一百来条，还带着强烈的"人工味"——句式工整、逻辑清晰、情绪表达过于明显，跟线上真实数据完全不像。后来我们开始尝试用大模型生成对抗样本和变异数据：把已有的种子样本喂给模型，要求它改写成方言版本、口语化版本、语序错乱版本、含蓄不满版本等等。
这一试就很上头。原来我们完全没想到，模型在"擦边表白式投诉"这种语义含糊的样本上会这么脆弱——客户说"你们这个质量，呵呵"，模型居然判成了"中性"。这类样本用人工编写，很容易被我们不自觉地写成"经典抱怨句式"；但模型改写之后，它把真实世界那种语言表达的多样性给带进来了。用AI生成测试数据，不等于编造假数据，而是用生成方式穷举"真实可能出现的表达变体"。
4.2 多AI协作：一个生成，一个评估，一个监督
现在很多团队在做AI Agent，我们的测试平台也在尝试多智能体协作。一开始我只想做个简单的"自动化测试助手"，后来发现一个智能体根本不够用：你让它生成测试用例，它可能一本正经地编出了业务上不存在的场景；你让它评估结果，它可能被另一个模型的长篇大论带着走。
于是我们搭了一个三方协作的结构：用例生成Agent负责产出候选测试场景，评估Agent负责对输出打分，监督Agent负责抽样检查两边的质量，判断生成Agent是否在捏造、评估Agent是否在误判。这个结构谈不上多高大上，但它解决了一个核心问题——用模型去校验模型，永远需要一个"第三只眼"，否则错误会悄悄双向强化。
4.3 测试开发的新技能树：写评测脚本和调Prompt也是一种测试
过去招聘测试工程师，我重点看自动化脚本能力和对业务的理解；现在面试经常有人问我："你了解LLM评测吗？你写过评估集吗？"这确实是一个新方向。作为一个老测试，我的真实感受是：我们的核心能力"发现问题、定位问题、推动解决"并没有变，但解决问题的工具变了。
最主要的两个新工具就是"评测脚本"和"Prompt调优"。多数情况下，一条AI测试用例本质上就是"输入文本 + 预期行为描述 + 评估标准"，全都写在调试Prompt的过程里。所以现在测试工程师和算法工程师的边界正在模糊——你不再只是找Bug，你还要参与定义"什么样的模型行为是及格的"。这个定义工作，传统测试很少参与，但在AI测试里，它恰恰是最高价值的环节。
5. 找AI产品Bug的避坑清单：都是拿真金白银换来的
5.1 复现三板斧：固定种子、锁定模型快照、冻结Prompt版本
给AI产品提Bug，先按下面的步骤做可复现实验，避免被开发一句"我这边好的啊"打回来：
- 设置并记录随机种子（如果框架支持），或至少记录temperature、top_p等采样参数。
- 锁定模型快照版本。模型迭代更新后，同一个输入可能得到完全不同的输出，所以必须记录模型版本号。
- 冻结Prompt版本。线上Prompt和测试环境Prompt不一致，是大量"伪Bug"的根源。
每一个无法复现的"偶现问题"，记录触发概率和坏样本比硬要一个结论更重要。这不是妥协，而是AI测试的客观现实：有些问题不是每一次都会出现的，但它们累积起来会影响产品体验，值得跟进。
5.2 从热搜词看趋势：物联网设备、银行项目、渗透测试都在变
最近我注意到行业里的热门问题也在跟着变：从前大家问"软件测试怎么学"、"软件测试面试八股文"，现在已经开始问"涉及物联网设备的软件测试怎么测"、"AI生成图片怎么测"、"Agent测试怎么测"。我还看到有同行在琢磨怎么把Prompt和用例一起管理，这跟我的体会完全一致——AI测试这条路，其实是在把传统测试的成熟方法论，搬到"行为不可穷举"的新系统上。
物联网设备尤其如此。设备端的模型更新频繁，网络环境五花八门，一旦把AI嵌入到设备端，传统测试"搭一套固定测试环境"的思路就失效了，你必须建设一套支持多版本、多环境、多输入分布同时跑的测试矩阵。银行项目则更看重合规和安全，这让我联想到渗透测试领域同样面临新挑战——Prompt注入本质上就是一种新型攻击面。这些方向在未来几年会持续缺人，也是老测试工程师转型的好机会。
5.3 三个至今仍然让我头疼的开放问题
如果文章到此就结束，有点过于"岁月静好"了，说实话这些坑到今天也没有完美解法：
- 评估器本身的偏差到底怎么系统化消除？我们的评估模型偶尔会放过明显的错误输出，人工抽检也很难发现它的失误规律。
- 语义冲突场景下怎么制定"唯一正确"的断言？当模型对同一条影评既被要求判断情感，又被要求判断是否包含广告倾向时，两套标准的优先级冲突会让断言极其不稳定。
- 回归测试成本怎么控？每条用例跑N次意味着N倍的计算开销，测试团队如果没有GPU资源，AI回归测试可能排队排到天荒地老，这需要平台能力和预算的支撑。
这些问题目前没有标准答案，我也不觉得短期内会有。它们就像传统软件测试当年面对"自动化率怎么提升""环境不稳定怎么处理"一样，是需要整个行业共同磨出来的。
最后分享一个我自己的小习惯：每次遇到AI产品"意外"输出，我第一反应不再是想"这Bug怎么提"，而是先截图、留存输入、记录参数，然后顺手再喂十遍看看概率。这个动作帮我过滤掉了很多"伪Bug"，也帮开发省下了大量无意义的定位时间。测试AI，与其说是找Bug，不如说是在给一个"非确定性的黑盒"画行为画像——画得越细，产品就越可靠，这大概就是这条路最迷人的地方。
