很多人神化了 AI 的能力

昨晚和几位测试同学交流 AI 在日常工作中落地的话题，听了好几种不同的落地案例，以及落地过程遇到的问题和当前的进度。这些案例给了我不少启发，今天就来聊聊我对于 AI 在测试工作场景中落地的思考。

在上述案例中，有同学说他们在推 AI 生成测试用例，但进展很慢，过程中遇到了很多问题。也有大厂同学说，调研之后直接放弃了利用 AI 生成测试用例的想法。当然也有同学想尝试在 UI 自动化测试场景中落地 AI，但目前停留在调研阶段。

看到这里，是不是觉得和网上看到的各种资料所说的不一样？老实说，DeepSeek 刚出来的时候，我也想过借助它的能力直接在工作中落地应用，但真正深入了解 AI 大模型的技术原理和特性后，我立马放弃了之前的天真想法。

如果 AI 真的具备如网上各种自媒体所描述的那种能力，那确实能很快提升个人和团队的工作效率。但不幸的是，当前阶段的各种 AI 大模型和工具，并不具备开箱即用深度使用的能力。

换个角度来说，不是 AI 不具备这种能力，而是要达成如大家所想的效果，需要满足一定的前置条件。但这些前置条件是什么，该如何达成，目前并没有很详细的介绍和可参考的落地路径。

很可怕的一点在于，目前很多公司就是很迷信 AI 的能力，畅想 AI 能降本增效，大幅增加公司的效率，甚至带来新的营收。

只能说 AI 大模型出圈的这三年不到的时间，群体认知的泡沫还没挤破。

从原理来说，大模型会根据用户输入不断预测下一个 Token，且每个已经生成的 Token 都会影响下一个 Token 的生成。

从本质来说，大模型就是一个概率预测机器。同样的 Prompt(提示词)会产生不同的答案，这就是所谓的信息幻觉问题。

什么是信息幻觉？简单来说就是：同样的提示词，重复多次后大模型的输出结果是不一样的，即不具备幂等性。甚至为了迎合用户的诉求，大模型甚至会虚构一些不存在的数据给你。

要缓解信息幻觉，当前最通用的方法就是 RAG，即结合向量数据库中与用户问题相关的信息，以及 Prompt 一起投喂给大模型，再生成结果。

这也是为什么很多公司要训练自己的私有大模型的原因。

以目前阶段 AI 大模型的能力来说，它更擅长解决的是标准的、富有逻辑和清晰边界的问题，而实际的工作场景大多都是不确定性的因素。

在 IT 互联网行业研发工作为例，我们面临的实际工作场景是什么？一句话需求，技术设计做的很烂，数据结构勉强能看，这种情况下，你又怎么能指望 AI 帮你解决呢？

AI 解决不了人的不专业和沟通成本高昂的问题，这是人的问题，不是技术的问题。

回到本文开篇的问题：AI 能生成可用的测试用例吗？答案是可以。

但这个答案的前提在于：标准化的流程、清晰详细的需求文档描述、良好的技术和数据结构设计，只有满足这几点前置要求，才能借助 AI 的能力生成基本可用的测试用例。

这里的基本可用并不是说可以直接拿来无缝插入日常研发测试环节，而是技术人员需要根据自己的经验和使用场景进行微调之后，才能真正用起来。

当然，以当下的测试工作场景来说，API 自动化和单元自动化，AI 倒是有很大的可供想象的落地场景。定义好数据结构，设计好 API，然后利用 AI 帮你生成测试数据，或者应用层的自动化测试代码，落地难度并不高。

但这样做可能会出现新的问题，即无法满足领导的大脑自嗨，毕竟领导要的是创新和降本增效。对于这个问题，还有一个更适合向上管理 PPT 汇报的方式，那就是智能体和工作流。

将日常可以自动化执行的部分，切换为工作流(和自动化本质没区别)，替代人工执行。比如代码自动提交、自动化部署流水线等结构化可重复的场景。

将线上监控、容灾自愈、配置热更新等非结构化的复杂场景，进行抽象设计然后整合为 Agent。

二者结合使用，智能体可以增强工作流的灵活性(动态调整步骤)，工作流可以协调多个智能体完成更复杂的问题。

如此一来，既有落地案例，又有技术创新和汇报材料，何乐而不为。

AI 是工具，是锤子，问题是钉子。不能拿着锤子四处敲钉子，而是找到钉子该钉住的位置，然后再敲锤子。