构建AI能力回归测试集的具体实践

前几天我陪朋友梳理他们团队的 AI 工具升级流程，发现一个挺有意思的现象：大家不是没有测试意识，而是每次都在"临时试一把"。今天试个新提示词，明天换个小模型，感觉不错就上，出了问题再回滚，来回折腾几轮，谁也说不清到底是变好了还是变差了。

后来我们坐下来聊，核心问题其实不是"哪个工具更强"，而是缺一套能反复用的测试集。就像写代码要有回归测试一样，AI 能力迭代也该有个固定的检验标准，不然每次升级都是凭感觉拍脑袋。

我建议他们先别急着测新功能，而是把过去踩过的坑攒下来。比如之前哪个场景下模型输出过敏感信息、哪类输入经常触发错误、哪些边界情况让流程卡住，这些真实发生过的案例，比任何"好看的演示 prompt"都值得沉淀。把它们整理成固定样本集，每次大版本更新就拿出来复测一遍，结果很直观：如果新版本在这些历史坑上表现更稳，才谈得上考虑升级；如果连老问题都没解决，那新增的花哨功能大概率只是转移注意力。

另一个容易被忽略的点是，测试要贴近真实流程，而不是单独跑几个孤立的问答。我让朋友挑了一条他们最核心的业务链路，从输入数据到中间调用的接口、知识库，再到最终输出的审批环节，整条路径完整跑一遍。因为很多问题不是单点功能不行，而是跟上下游系统联调的时候才暴露出来。权限受限场景、并发稍高的情况、异常输入的处理，这些都得覆盖到，否则测试结果再漂亮，落到生产环境照样翻车。

最后我想说，这套测试集不是一次建完就完事，得跟着业务一起长。每次线上出了新问题，就补进样本里；每次发现某个边界情况没覆盖到，就加进去。时间越长，这套回归集对你的业务就越精准，对升级的判断也越有底气。与其每次被新版本追着跑，不如先把自己的地基打牢，让工具迭代变成一件可复盘、可决策的事，而不是靠运气。