做技术的，谁没经历过通宵排查Bug呢？最近我们团队的AI测试自动化系统在线上出了一个诡异的Bug，我从晚上八点排查到第二天早上六点，终于找到了根因。

这篇文章我想记录一下这次排查的过程，从发现问题到定位根因再到修复，分享一下踩坑经验。如果你也在做AI相关的测试自动化，希望这篇文章能帮你避免类似的坑。

问题的出现

那天是周五，本来准备下班过周末了。晚上八点，监控系统突然报警，说AI测试自动化系统的失败率飙升。我打开监控面板一看，好家伙，平时失败率不到5%的系统，突然涨到了40%多，而且还在上升。

我赶紧登录系统看日志，发现大量的测试用例都失败了，而且失败的原因五花八门。有的是断言失败，有的是超时，有的是返回结果格式不对。看起来不像是某个特定的问题，更像是系统整体出了问题。

我第一反应是AI模型的API出问题了。因为我们的测试自动化系统依赖大模型来生成测试用例和判断测试结果，如果模型API出问题，整个系统都会受影响。我查了一下模型API的状态，发现响应时间确实变长了，而且有不少500错误。

我以为是模型服务商的问题，就联系了他们的技术支持。对方说他们那边没问题，让我查查是不是我这边的问题。我半信半疑，开始深入排查。

第一轮排查：模型API

第一轮排查，我聚焦在模型API上。

我写了一个简单的测试脚本，直接调用模型API，传入固定的prompt，看返回结果是否正常。测了几十次，发现API的返回是正常的，内容也符合预期。这说明模型API本身没问题。

那问题出在哪里呢？我开始看我们系统调用模型API的代码。我们的系统是用Python写的，用的是官方的SDK。我仔细看了代码，发现了一个可疑的地方：我们在调用API的时候，传了一个temperature参数，值是0.7。

temperature参数控制模型输出的随机性，值越高，输出越随机。我们的测试系统需要稳定的输出，所以应该用比较低的temperature。但0.7也不算太高，之前一直用这个值，没出过问题。

我试着把temperature改成0.1，重新跑了一批测试。神奇的事情发生了，失败率从40%降到了10%。看来问题确实和temperature有关，但为什么之前用0.7没问题，现在就有问题了呢？

我查了一下模型API的更新日志，发现服务商在当天下午悄悄更新了模型的版本。新版本的模型，在同样的temperature下，输出的随机性比旧版本更高。也就是说，同样的0.7，在新版本上输出更随机，导致我们的测试结果不稳定。

找到了原因，我赶紧把temperature调到0.1，失败率继续下降，到了8%左右。但还是比平时的5%高，说明还有其他问题。

第二轮排查：提示词

第二轮排查，我聚焦在提示词上。

我们的测试系统用了很多提示词模板，这些模板是之前针对旧版本模型优化的。模型更新之后，同样的提示词，效果可能不一样了。

我把所有的提示词模板都翻出来，一个个检查。发现有几个提示词，在新模型上的效果很差。比如有一个提示词，要求模型输出JSON格式的测试结果。旧版本的模型能很好地遵循这个要求，但新版本的模型经常在JSON外面加一些解释性的文字，导致我们的解析失败。

还有一个提示词，要求模型判断测试用例是否通过。旧版本的模型会输出"通过"或"失败"，但新版本的模型有时候会输出"应该通过""大概率失败"这种模糊的答案，导致我们的断言失败。

我花了几个小时，重新优化了这些提示词。对于JSON输出的问题，我在提示词里加了更明确的指令，并且加了几个示例，让模型知道应该输出什么样的格式。对于判断结果的问题，我要求模型只输出"通过"或"失败"，不要加任何其他内容。

优化完提示词之后，我重新跑了一批测试，失败率降到了6%左右，接近平时的水平了。但还是有一些零星的失败，我继续排查。

第三轮排查：数据问题

第三轮排查，我聚焦在数据上。

我们的测试系统会用一些历史的测试数据来训练和验证模型。我怀疑是不是这些数据有问题，导致模型的判断出错。

我抽查了一些失败的测试用例，发现了一个规律：失败的用例，大部分都是最近一周新增的。这些新增的用例，是我们的运营人员手动添加的，格式和之前的用例不太一样。

比如，之前的用例描述都是简洁的一句话，而新增的用例描述很长，而且包含了很多特殊字符和emoji。模型在处理这些用例的时候，可能会被这些干扰信息影响，导致判断出错。

我写了一个数据清洗的脚本，把新增用例里的特殊字符和emoji都去掉，把过长的描述精简一下。清洗完数据之后，重新跑测试，失败率终于降到了正常的5%以下。

这时候已经是凌晨四点了。问题基本解决了，但我还想搞清楚，为什么这些数据问题之前没有暴露出来。

第四轮排查：根因分析

第四轮排查，我想找到根本原因。

回顾整个排查过程，问题的触发点是模型服务商悄悄更新了模型版本。新版本的模型，在输出随机性、提示词遵循度、数据处理上，都和旧版本有差异。我们的系统没有做好版本兼容，导致模型更新之后出了问题。

但这只是表面原因。更深层的原因是，我们的系统对模型API的依赖太强了，没有做好容错和降级。

第一，我们没有锁定模型的版本。模型服务商更新模型的时候，我们没有收到通知，也没有办法指定使用旧版本。模型一变，我们的系统就受影响。

第二，我们的提示词没有做充分的测试。提示词是针对旧版本模型优化的，模型更新之后，没有重新验证提示词的效果。

第三，我们的数据校验不够严格。运营人员新增的用例，没有经过格式校验就直接入库了，导致脏数据影响了模型的判断。

第四，我们的监控不够细致。监控只看整体的失败率，没有细分到模型版本、提示词模板、数据来源等维度，导致问题出现之后，不能快速定位是哪里出了问题。

找到了这些根因，我开始制定修复方案。

修复和改进

针对找到的根因，我做了以下几个方面的修复和改进。

第一，锁定模型版本。我联系了模型服务商，确认他们支持指定模型版本。我们在调用API的时候，明确指定使用某个版本的模型，避免模型悄悄更新影响我们的系统。同时，关注模型的更新通知，新版本出来之后，先在测试环境验证，没问题再切换。

第二，建立提示词测试集。我们整理了一套提示词的测试用例，每次模型更新或者提示词修改之后，都跑一遍测试集，确保提示词的效果符合预期。

第三，加强数据校验。在数据入库之前，加了严格的格式校验，过滤掉特殊字符和emoji，限制描述的长度。同时，对历史数据做了一次全面的清洗。

第四，细化监控维度。在监控系统里，加了模型版本、提示词模板、数据来源等维度的监控。这样问题出现的时候，能快速定位是哪个环节出了问题。

第五，加了降级机制。如果模型API出问题，系统会自动降级到规则引擎，用传统的方式来判断测试结果。虽然准确率低一些，但能保证系统基本可用。

做完这些改进之后，已经是早上六点了。我重新跑了一遍全量测试，全部通过，失败率稳定在3%左右。

这次排查的教训

这次通宵排查，给了我很多教训。

第一个教训是，不要过度依赖AI模型的稳定性。AI模型是黑盒，它的行为可能会因为版本更新而变化。在使用AI模型的时候，一定要做好版本锁定和兼容性测试，不要假设模型的行为永远不变。

第二个教训是，提示词工程很重要。同样的模型，不同的提示词，效果可能天差地别。要花时间优化提示词，并且建立提示词的测试和维护机制。

第三个教训是，数据质量是基础。AI系统的效果，很大程度上取决于输入数据的质量。脏数据会严重影响模型的判断，一定要做好数据的清洗和校验。

第四个教训是，监控要细致。AI系统的问题往往是隐蔽的、渐进的，粗粒度的监控发现不了。要建立多维度的监控，及时发现异常。

第五个教训是，要有降级方案。AI模型可能会出问题，系统要有降级机制，在AI不可用的时候，能用传统的方式保证基本功能。

写在最后

这次通宵排查，虽然很累，但收获很大。它让我对AI系统的稳定性有了更深的认识，也让我们的系统变得更健壮了。

AI测试自动化是一个很有前景的方向，但它也带来了新的挑战。传统的软件测试方法，在AI系统上不完全适用。我们需要新的方法和工具，来保证AI系统的质量和稳定性。

如果你也在做AI相关的系统，希望我的这次经历能给你一些启发。做好版本管理、提示词测试、数据校验、细致监控和降级方案，你的AI系统就能更稳定地运行。

最后用一句话来结束这篇文章："AI很强大，但也很脆弱。用好AI，不仅要会用它的能力，还要能应对它的不确定性。"

愿每一个做AI系统的工程师，都能少熬夜，少踩坑，系统稳定运行。